Why we love design briefs

by Claire Brown - central team member - communications

We’ve fallen somewhat in love with design briefs over the past few weeks, so let us tell you why and what we’ve learned.

A good design brief, whether it’s for a video, product feature or leaflet, should always include everything the designer needs to know to do their job well. This includes:

  • Objectives (why are we designing this?)

  • Key ingredients (what elements absolutely have to be included?)

  • Specification (what are the dimensions, format or platform?)

  • Audience (who is this for and how is this relevant to them?)

  • Timeline (when do we need this for?)

A great design brief should hit the sweet spot between ensuring the final outcome hits your objectives and giving the designer the creative space they need to be awesome at their job.

Briefs that are too loose don’t give designers enough of an idea as to what needs to be achieved which risks wasting time and causing frustration on both sides. Briefs that are too tight, giving instruction rather than direction, strangle designers and limit the possibilities for the final outcome.

The designer’s perspective

I asked our UI designer, Efe, who has been on the receiving end of design briefs for the past nine years, for his thoughts on their place in the creative process.

“It is more than a bunch of words on a document. Those words have superpowers: they instigate design thinking and shine like a beacon in the night throughout the process.”

“As a designer, I consistently check the brief, refer to it at meetings (especially when there’s confusion or diversion), and use it as a litmus paper to test the design work.”

Pretty powerful stuff.

What we’ve discovered, is that including our design team (Efe, and our trainee designer, Celia) in the development of the brief from the very beginning is working wonders. Or as Efe puts it:

“Being involved in creating the document that guides our design team (including me) helps to shape my thinking. I try to take my designer hat off and be as objective as possible so I don’t subconsciously influence the brief. Now I feel like I’m designing the design system, which ticks a lot of my boxes.”

Designing the design system

We’re now into our third two-week cycle of product iteration and user testing. On Mondays the whole team reviews the analysis of the user research we did on the previous Friday and decides on the focus for the next iteration. The creative team then meets to collaborate on the design brief based on user feedback, assigns tasks and builds a timeline for more whole-team discussion and demos as needed. After two weeks of designing, we test with users on Friday and analyse the research.

The first time our trainee designer, Celia, saw a design brief was when she helped to construct one. She told me:

“I enjoy the collaborative nature of writing briefs and this has been key to my learning. I admire how everything in the briefs will have stemmed from the key findings and lessons from the previous user research session.”

“Having a user-centred design brief means that during user testing we’re receiving more feedback for the ‘things that worked’ column and less for the ‘problems to solve’ column.”

What’s working for us

Here are the features of the Local Welcome design brief that we really like:

1. Articulating the challenge in the form of a ‘How might we’


2. Being clear about the user(s)


3. Including user research lessons from the last iteration


4. Having an ‘extension’ project, something to stretch us if we have time


5. Being clear about individual requirements/tasks and who is responsible


6. Borrowing the GDS ‘relative confidence’ indicator to manage risk


7. Having a clear timeline the whole team commits to


8. Being clear about unknowns, noting questions and when and how we expect them to be answered.


And underpinning all of this is team collaboration - everyone working together to create a living document that serves the team, the process and ultimately, the users.

If you need anymore convincing, watch this…