Turning the brief into requirements we can test

In my last post I asked how do I know if my ideas are any good? My answer was that a good idea is one that meets the requirements of the brief. In this post I turning the brief into requirements we can test – and how the process can be surprisingly creative.

I have split this post into two parts. The first is creating the list of requirements and the second is establishing tests for these requirements.

1- Creating the list of requirements

Begin by creating a list of the obvious things.

The brief for a project or activity can come in various forms: an email; a detailed specification; a vague conversation. All of which can be boiled down into a series of requirements.

It may sound simple, but a good thing to do early in a creative project is to list all those requirements. Start with the obvious, explicit things listed in the brief. What must the design have? What should the project deliver? Who for and when?

Write down the unwritten requirements

As I have written before, it is the invisible ingredients in the design dough that make it rise. The implicit and assumed requirements. If you have been exploring and deepening your understanding of the brief you can start to make explicit these implicit and assumed requirements.

Keep the list live

We learn about the brief through the act of design. As we generate ideas we learn more about the brief, what it is and what it isn’t. This means we can keep adding to and modifying our list of requirements. We therefore need that list to be editable. Keep a live list somewhere. Something that you can work with and change.

Having established a list of requirements we now need to think about tests for these requirements.

2 – Establishing the tests for our requirements

The second part of turning the briefing into requirements we can test is to think about how we know if our requirements have been met.

Journey to an island in the imaginary archipelago

I like to think of the brief as a description of an imaginary island to which we are setting sail. It is as detailed an account of the imaginary island as we can make in advance. The trouble is that there are many islands in this imaginary archipelago – so we need to know if the island we are approaching is the one we intended.

We need a checklist so that we when we land there we can check we are in the right place. Does this island have X. Can I see Y. Is there are mixture of A and B. This is what I mean by a checklist.

Start with the easy requirements

Some requirements of a brief are easy to convert into tests – for example, dimensional requirements. A requirement that a design being designed is 10cm wide is easy to convert into a test. The test is simply: is the design 10cm wide?

This is an example of a simple objective requirement. The test is usually a statement of compliance. Is this requirement met: yes or no?

Some requirements are threshold requirements: the design must meet a exceed a minimum threshold or be under a maximum threshold. For example a requirement for the design to have a maximum weight of 10 grams. Then the test is simply: is the weight less than or equal to 10 grams.

Requirements as code

I find some people find it helpful to think of this approach as writing code for a computer to test compliance. If you were writing a computer programme to test the requirements of an idea against a brief, what would be the parameters you are testing for and how could you create simple if/then statements that test for these requirements.

The more murky waters of subjective requirements

So far so good for objective requirements but we have to think a bit harder when we start to establish tests for more subjective requirements.

Take for example the requirement that a design should be elegant. How can we turn this requirement into a test? I have several suggestions for approaches to try.

1) Find a proxy

The first is to find some more objective proxy for the requirement. For example, a proxy for elegance could be symmetry or proximity to some pre-defined proportional ratios. The test for elegance could then become is the design symmetrical.

2) Find a benchmark

An alternative approach is to assemble a series of other designs that everyone concerned agrees are elegant and then to test does the idea you are testing resemble these benchmark designs.

Here you have the opportunity to engage with your client about what they think is elegant. I see this as doing more work to resolve the Designer’s Paradox: you are gaining greater clarity on what they mean by elegance.

Even when you have established some benchmarks, the test of whether the new design resembles the benchmarks is still subjective but at least the problem is more bounded and easier to discuss.

3) Delegate the decision

The third approach I will recommend here is to delegate the judgement of whether something is elegant to someone else and for the test merely to be do a particular audience find the design elegant.

This approach I am least keen on, particularly during conceptual design when you have little time. I think it is much more interesting to take a stand using approaches one or two above and then learn from what happens.

The creative process of creating tests

The idea of writing tests may seem a convergent, reductive process, but I find the process can be really creative. When someone says they want X, and I ask, well, what do you mean by X, the question can open up a whole dialogue about what the requirements really mean and what are the different ways they can be fulfilled.

Sometimes interrogation of a requirement reveals a more fundamental underlying need that is really what the client is looking for but hadn’t realised yet.

Finding benchmarks, one of the techniques suggested above is also a great way to get inputs for your creative process (see my posts on Filling the Kalideascope).

Next steps

This post has been about turning the brief into requirements we can test, all in the service of knowing whether our ideas are any good. Having established our series of tests, the next thing we need to do is figure out how to apply them, which is the subject of my next post.

Conceptual Design of Buildings

For more of my writing on design and idea generation check out the Chapter 2 of Conceptual Design of Buildings, published by the IStructE.