Tag: DesignBrief

Posted on

How to resuscitate a brief – stage 3

The final stage in our brief resuscitation process is to test it. We test a design brief by developing ideas in response.

When we do this we may discover: 

  • Zero solution — when we add up all the requirements and discover there isn’t a way to meet them all. We need to loosen the constraints.
  • The ideas are unambitious — ideas that meet the requirements of the brief don’t achieve very much then maybe the brief is too limiting
  • The ideas are uninspiring — when we come up with ideas that meet the brief but fail to delight, it may be that the brief stipulates the minimum that should be achieved, rather than provoking the heights we should be aiming for.
  • The brief missed the point — sometimes we stumble upon ideas that don’t meet the brief, but would be a good idea in any case. In which case maybe the original brief missed the point, and a better outcome is possible by changing the assumptions.

Ultimately the brief and the ideas should match, but the two evolve to reach compatibility. Coupling a brief with the ideas it enables helps us to ask questions that challenge the brief, and keep it moving – that keep it alive. 

Posted on

How to resuscitate a brief — stage 2

The second way to breathe life into a design brief is to remind ourselves that it was never as complete as it originally sounded.

We do this by exploring the Five Elements of a Design Brief:

  • The explicit – what is actually written.
  • The implicit – what is meant by what is written
  • The assumed – what is assumed in the writing and in the reading. 
  • The missing – what the brief writer forgot to tell you. 
  • The unknown – what the writer didn’t include in the brief because they hadn’t realised they wanted it yet.

In practice, read the brief aloud, slowly. For each sentence, ask:

  • What is explicit here?
  • What is implicit?
  • What is assumed?
  • What is missing?
  • What might be unknown?

The questions test both our understanding of the brief, and also whether we have the right requirements. And open to the door evolving the brief. 

Posted on

How to resuscitate a design brief – stage 1

Design briefs become lifeless when we treat them as fixed, and unchanging.

We bring life to them when we allow them to evolve.

The first stage is to make your design brief a live, editable document (with changes tracked if necessary).

The brief should prompt questions – write those down on the brief.

New requirements will be discovered – add those in so they don’t get lost.

New possibilities for what you want emerge – note these down too.

Gather the people who care about the brief to review these changes, challenge or approve them.

A living brief is one that is being worked on.

Posted on

Is your brief dead?

You are midway through a project. Ask yourself, has my design brief changed, or has it stayed the same.

If it hasn’t changed, then you should check if your design brief is very nearly, or very actually, dead.

A lifeless brief breathes no life into the design process

A brief without a pulse clings to its original constraints without shifting the boundaries.

An ex-brief is one that looks nothing like what you are working on.

A stiff brief is unmoved by new discoveries made during the design process.

A deceased brief ceases to be of any use.

If you suspect these symptoms then your brief needs urgent resuscitation. Because in design, a healthy brief is alive.

(It is possible that you brief may just be resting, in which case you need to wake it up).

[With apologies to Monty Python’s “Dead Parrot” sketch]

Posted on

The living brief

This week, I’ve been updating and consolidating my writing on design briefs. The design brief is a fundamental component of the design process, and it is a core topic in our design teaching.

But I realise in gathering together my writing that there is an idea I have been dancing around without naming it.

A design brief is not something that is static that we define at the start of a project. It is something that evolves, and grows as part of the design process.

I’ve started to call this the Living Brief. And you can read all about it here.

Posted on

A flow for thinking about regenerative infrastructure

A final post this week to draw together the long form posts into a simple flow. 

Across these posts I’ve explored how infrastructure shapes the metabolism of the economy, the insufficiency of system resilience on its own, and how mindsets shape our view of infrastructure.

Taken together they suggest a simple flow for thinking about regenerative infrastructure. 

Mindset>Brief>Ideas>Tests>Iterate

Mindset

We start by using the Changing Mindsets motif to challenge our assumptions about infrastructure

Brief

We create a brief that moves beyond delivering infrastructure efficiently to seeing infrastructure as part of what enables humans and the living world to thrive together.

Ideas

We fill our Kalideacope with two libraries:

  • Resilient systems architecture
  • Ecological participation patterns

And we turn our Kalideascope with an additional library:

  • Regenerative mindset prompts

Different combinations generate new possibilities for infrastructure design

Tests

We test the ideas against three criteria for regenerative infrastructure:

  • Metabolism — does the system operate within ecological limits?
  • Ecological participation — does it strengthen living systems?
  • Resilience — is the system well structured?

Iterate

Keep going until the idea meets the brief.

Or we change the brief to a better brief because the brief we first thought of is almost certainly not the right one.

And that shouldn’t be a surprise because regenerative infrastructure is not the conventional way of thinking about infrastructure. We should expect the thinking process to be hard. 

These tools are here to help.

Posted on

Design versus shopping

I’ve said it elsewhere, and so now I’m saying it here.

If the client knows exactly what they want at the start of a design process, then it isn’t design – it’s shopping. Shopping for the answer that you’ve already decided upon. Because design isn’t the business of dealing with knowns. It is precisely because there are unknowns that we need a design process.

By all means we should have an initial brief that describes outcomes we are trying to reach. And then begins a journey into realm of unknown possibilities and constraints to find out what might be possible. What we may discover is that that original statement of intent was not quite right. We might find something based on a better understanding of the situation.

And then we get a better brief. Better for everyone involved, including the client.

Consider the opposite. The client sets a tightly defined brief with highly specified outcomes. The designer is forced to the client’s exacting brief, tantamount to a shopping list (and which has probably become formalised as a contract). The designer discovers a better solution but because it is not on the client’s shopping list, it isn’t considered.

And so the client comes back from the shops with what they asked for. But there is no guarantee they are going to fit.

Posted on

Learning as a design process

Diagram showing the cycle of Continuous Place-Based Design: Observe, Brief, Ideas, Make & Test — all centred around Place.

In a flip of yesterday’s post — if design can be a learning process, then learning can be a design process too.

What would it look like to approach learning the way we approach design?

Design begins with intention. It asks: how do I take an existing situation and make it better? That invites us to name where we are now — and to define what better might mean for us.

Design also embraces divergence. In a learning context, that could mean exploring unexpected sources, challenging the materials in front of us, or inventing new ways to engage.

Design gives a different meaning to testing. Not testing to see if I made a grade, but testing to see if I fulfilled the brief. 

And design invites us to keep coming back to the brief and ask how could the brief be improved.

By designing our learning we have the potential to not just passively follow a learning process but to create one that more intentionally meets our needs. 

Posted on

Le paradoxe du design

I was in Paris last week to deliver a creative thinking workshop for engineers. I did the presentation in English and the Q&A in French — a happy balance that let me be precise in theory and looser in conversation. 

But I got a bit stuck translating ‘the Designer’s Paradox’ in French. 

The Designer’s Paradox says ‘you don’t know what you want until you know what you can have’ (McCann 2001)

Asking for help here’s some suggestions I got during the day.

On ne sais pas ce que l’on veut avoir, tant que l’on ne sais pas ce que l’on peut avoir. 

Translated back into English, this reads as ‘one doesn’t know what one wants for as long as one doesn’t know what one can have‘. It’s a fair translation, but long and literal. 

Then came:

‘Savoir ce que l’on veut, ou vouloir ce que l’on peut.’

Literally — know what you want or want what you can. It’s crisper and I like the rhythm. But the meaning drifts — it’s more about choosing between reality and desire. 

Mashing these together, I came up with: 

Savoir ce que l’on veut, savoir ce que l’on peut, vouloir le meilleur des deux

Know what you want, know what you can, want the best of both. But that isn’t really French!

In searching for the French version of the Designer’s Paradox, I’ve found another. 

Translate the meaning and lose the poetry

Translate the poetry and lose the meaning. 

That’s the translator’s paradox.

Posted on

Beating a new path

You’re out walking one morning and you reach a field of tall grass. Your destination is on the other side but you can’t see a way through. So you wade in, pushing through the tall stems until you emerge on the other side, leaving a path in your wake. 

On the next day’s morning perambulation you encounter the same field. Do you beat a new path — or take the one you made yesterday?

Of course, you follow the path. It’s easier. It’s the path of least resistance. 

And so it is when we develop ideas in response to a design brief. Beating a path through a sheaf of requirements takes effort. But once we have made that mental path, our brains prefer to follow it again. 

Why do the extra work of cutting a new route? 

This is cognitive ease at work: our brains tend to prefer the options they’ve already figured out over ones they haven’t figured out yet. 

There is no reason the first idea should be the best one. But cognitive ease makes it stick. So if we want better ideas, we need to resource ourselves to build beat a new path each morning.