I believe a good brief will:
Empower a set of individuals to creatively solve the right problems
Provide context for any individual to judge the success of those solutions.
The essay below documents some of my thoughts, experiences and theories on the quest for the perfect project brief. This was largely informed by my experience of moving from a very small company working on a very small project the team clearly understood (Media Molecule and LittleBigPlanet respectively); to joining a very big company and working on a very big project that was distributed across many different disciplines, teams and timezones (Sony and Playstation4).
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
As designers we are often expected to embrace ambiguity, and to a degree it is the designer’s job to creatively fill in the blanks. However there is funambiguity (funbiguity) and unfun ambiguity. A couple of weeks spent exploring this ambiguity and signing off a brief might save you months of negotiation, tweaking and politics further down the line.
Unfun ambiguity might include things like:
Relationship to other projects
Friction between executives
Actual points of responsibility
Opaque path to production
In the process of exploring this ambiguity, and writing the project brief, you will inevitably reach out and speak to a whole bunch of people. In doing so you should build consensus by creating a shared understanding of what the project actually is.
No stone should be left unturned or possibly relevant person left unnotified. Put the brief on Googledocs, invite everyone to annotate or even edit. Don’t leave things open to misinterpretation by truncating or simplifying. Assume that your colleagues are engaged enough to read and understand longform documents.
Ultimately the discussions around the project are what is important and the document merely an artefact of this.
With that in mind, here is a section by section breakdown of what I like to see in a brief, and why:
#1. The Author(s)
First, put the author’s name and email address (as you are reading this essay I’m assuming it will be your details here). A lot of the writing below is going to be about responsibility and accountability and this starts on the first page of the brief.
Briefs also have a habit of wandering without the author’s express permission and to people they may not know. Having the author’s contact details there means nobody is out of the loop unless they choose to be.
And who should write briefs? Well that depends a lot on where you work. At Sony I would expect the product manager and perhaps a senior designer or UX person to work on the brief. But to be clear in writing a brief you are primarily working to facilitate a broad conversation within the wider team, with the brief document as an output of that process. Expect the document that gets signed off to be wildly different from your first draft.
#2. The Problem / Opportunity
Are you starting with a piece of existing tech and retroactively trying to engineer a use for it? In that case, this essay is probably not for you.
A good opportunity statement describes an itch, not the method we might use to scratch it. What is the key need that people want fulfilled?
Is it to feel less isolated?
To feel like they have control over their digital lives?
To involve rather than exclude their kids?
To be able to creatively express themselves without the fear of being judged too harshly?
This is the first step in building a cohesive narrative that needs to run throughout the brief. Every idea proposed both in and beyond the brief document should refer back to this original itch. Every idea proposed should be questioned by all project members. Do we believe in this need? Do we believe our proposals will meet this need?
If we don’t believe the opportunity is solid then should this project even exist?
Think how much work we could avoid by asking this earlier! Experience has taught me that identifying and agreeing an opportunity is usually (and rightfully) the hardest part of writing a brief.
The opportunity section is also a good place to talk about more nuts and bolts subjects like demographics, competitors or any other additional information which can be used to effectively narrow the area your team will then have to explore. Especially in large companies ownership of demographics, or more usefully “the voice of the customer” is a fascinating rabbit hole. Resolving the competing inputs from business verticals, marketing and corporate strategy is key to setting up a successful project.
#3. The Ask / Proposal
An alternative way to think about the ask is as an experiment that will be conducted to investigate the opportunity above.
Given the Opportunity X, this team believes that by pushing button Y we will see result Z.
As soon as you pose this kind of hypothesis hopefully there should be lots of tension exposed between the Opportunity and the Ask. This kind of statement should invite lots of productive questions like “Do we believe in the button?” “Do we believe in the opportunity?” “How do we measure Z?”.
Hopefully the brief should also help contain statements like “my gut tells me” or “I will use my seniority to mandate something a bit random”. Not that these tangents aren’t allowed, indeed sometimes a project requires them, but here the brief is a tool to make it clear that is what is happening, how that relates to the project narrative, and whose decision it is to depart from that narrative.
All of which leads onto…
Impact and Outcome
A design should have a point. It shouldn’t just be “create a new feature Y” but it should be “to scratch itch X, create a new feature Y that will engender result Z”. When you get testing data back, what change do you expect to see? This change can be many things, and often a combination of several things, such as:
Time viewing content versus navigating UI
There are also a bunch of other traditional framing factors that should be listed, for instance:
Within a budget
Within a set time frame
With less than X bugs
These things in combination will form the core of your deliverables, a subject we will get onto later.
If you can, define what you are NOT going to do. Again this will create lots of tension initially, but it could be key in creating a successful project with successful contributors. Things you might exclude include:
Hardware platform B
Integration to social networks
There is a distinct Lean Methodology flavour to all this, which is A-OK. Regardless of which holy book you subscribe to it is interesting to try and decide what is the minimum we need to prove an idea, and if that is different from the minimum we need to ship it, and if so, how important is the difference?
This section is itself divided into two subsections. The first is the team who are actually going to be doing the work, the second is everyone else.
Realistically you probably inherited a team before reading this essay. While it might be tempting to try and figure out the Tetris-like puzzle of matching existing people to existing work, perhaps try reversing this and listing out what the required tasks are and then working out from there. This can also be a good place to start thinking about generating job descriptions for contractors or new hires.
As well as skill sets make sure to detail reporting lines and contact points — when it actually comes to progressing the project and unblocking issues thenwho and how are going to be key factors.
Defining everyone else’s roles in relation to the project can be fraught. For instance people will get hung up on whether a “Stakeholder” is defined by holding budget. That said, my experience has been that if you step up and assign people roles then 90% of them (who are happy to be given a clear context in which to respond to the work) will go with whatever decision you make.
Again though, have discussions about input, impact and responsibilitiesnow, not half way through the project or even worse when you are stuck in sign-off limbo. There is no swifter death to a project than a key person wading into a final review and saying “I wasn’t aware of this decision” or “I don’t understand what you are solving”.
For a couple of projects we have used the role of ‘Advisor’ as a catch-all for people whose input is key to the project, but who don’t necessarily have a final say on the direction of the work.
There should be no secret contributors to the project.
When breaking down a proposal into individual tasks and timings stay honest to the narrative that has been built in previous sections of the brief. Often deliverables are defined by a volume of work (N features, levels, buttons, branded elements etc) but this is not the same as the testable changes you defined in the Impact and Outcome section above.
Also, In the drive for design volume it is easy to assume that a bunch of things untested at the time of planning — e.g. whether we will succeed in hiring an effective team, if core technologies will actually work, if users find the key flows at all compelling — are assumed to succeed when sometimes they don’t.
Discussing these steps honestly and staying focussed on agreed goals should create more opportunities to test, review, refine or maybe even pivot in pursuit of the original goals without either blowing everything up or plowing ahead while trying to patch over fundamental flaws.
#6. Beyond The Brief
It can also be helpful to start to try and define some stuff that might happen beyond the brief. What are the next features you might investigate, or things you might like to test?
It is relatively easy to write an essay about largely abstract ideas. This is not presented as a definitive guide, but more as a series of ideas and tests that have helped me. I still face recurring stumbling blocks on my projects. Things like:
I can’t realistically plan beyond date X
This VP refuses to talk to that VP
Until we have agreed the opportunity I have no idea what the concepts might look like.
Remaining honest when you are being pushed for answers is hard and I repeatedly let desirable estimates feel more definite than they actually are. I need to get better at that.
Good luck. Please let us know how you get on!
I would also like to give shout outs to Trevor Jones, Chris Depizzol andJonny Hopper who have been key in field-testing and iterating some of this stuff ☺