How to write a brief that gets you good work
The best projects we deliver start from briefs that describe a problem, not a solution. A short guide to writing one.
Most briefs we receive are a feature list. Feature lists are useful eventually, but they lock in a solution before anyone has agreed on the problem — and they make it impossible for us to suggest a better approach.
Lead with what is going wrong. 'Customers call us to book because the online form confuses them' tells us more than 'we need a new booking form', because it leaves room for the answer to be something other than a form.
Say who it is for, specifically. Not 'our customers' — the actual person, their device, their patience, how often they do this.
State what success looks like in a number if you can. More bookings is a wish. Fifteen percent more completed bookings in three months is a target we can design against and check ourselves against afterwards.
Be honest about budget and deadline. Not to be negotiated down — so we can propose something that fits. A realistic constraint stated early produces better work than an unrealistic one discovered late.
Finally, tell us what must not change. Existing brand rules, a system you cannot migrate off, a compliance requirement. Constraints are not obstacles to good design; they are the edges that make it specific.
Working on something this applies to?
Book a free 30-minute discovery call. We will tell you what we would do, whether or not you hire us to do it.
