Reg Tait Hull Web Designer[ + Menu]


Briefs, in brief

No design project should start without a well formed brief, from the simplest icon to the most advanced space shuttle. We need them to define the scope and make a plan.

Briefs nail down our thinking and provide a simple point of reference for everyone throughout the project. They’ll stop a project drifting off course. They should be short (brief!) and easy to understand. Aim for one side of a piece of A4.

A good brief will also form part of a contract, formally or informally.

A brief isn’t a lengthy technical spec. Trying to conjure one up front wastes time on a useless document that no-one reads, all full of guesswork and fantasy. No one wants that.

Before writing a brief we need to do our homework. This might require a period of research to gain customer-centric insights.

What to put in a brief

In an ideal world, a brief would magically appear at the start of any project. Most of the time though, designers need to help write them. Here’s what needs to go in.

Problem statement — Define the current state of play. What’s the problem to solve? This may require a deep understanding of unmet user needs - not what they’ve asked for.

End goal — Think of this from an end user’s viewpoint—not an organisation or a product.

Work to be done — Write this as a simple task. Design projects may be open ended—we might need to figure out exactly what we’re making and stay flexible as a project proceeds. Narrow in scope but broad in creativity.

Timings — Key dates. Deliverables. Presentations and prototypes.

Supporting info — Point to reports and other reference materials needed to get started.

More from the blog