How to brief a design studio

I read a lot of briefs. The ones that turn into good projects are almost never the longest, and they are almost never the most detailed about the interface.

The pattern is simpler than that. Weak briefs describe a solution somebody has already decided on. Strong briefs describe a problem precisely enough that you can tell whether the solution worked.

Here is what that looks like in practice.

The failure mode: briefing the answer

The most common brief we get reads roughly like this.

We need a website with a homepage, an about page, a services page with five sub-pages, a blog, and a contact form. Modern and clean. Something like [competitor]. Budget flexible. When can you start?

Everything in it is true and none of it is useful. It is a sitemap and a mood, handed over as though the thinking is finished. The problem is that all the decisions worth making have already been made silently — that you need a website, that it needs five service pages, that the reference site is succeeding at something you also want.

Any studio can build that. Whether it does anything for you is a separate question, and the brief has quietly removed everyone’s ability to ask it.

The fix is not to write more. It is to move one level up: say what is wrong now, and how you will know it is fixed.

The six things a brief has to answer

1. What is happening now that you want to stop happening. Not “we need a new site” — the actual symptom. Leads arrive and go cold. The sales team sends a PDF because the site cannot explain the product. People sign up and never come back on day two. Half of support tickets are the same question. A symptom you can name is a problem someone can solve; a vague dissatisfaction is not.

2. Who it is for, specifically enough to disagree about. “Businesses” is not an audience. “Operations managers at 20-to-100-person garment factories who currently run this on WhatsApp and paper” is an audience — and once it is written down, everyone can argue about whether a decision serves them. That argument is the useful part.

3. What has to be true for this to have worked. The single most valuable sentence in any brief. Not a feeling — a change you could observe. More qualified enquiries. Fewer support tickets in one category. A signup flow that people finish. Even a soft one is fine: “our salespeople stop apologising for the website.” Without this, every review meeting becomes a debate about taste, because taste is the only measure anyone has left.

4. The constraints that are real. A launch date tied to something that actually happens — a trade show, a funding round, a semester. A budget range, even a wide one. Technology you are locked into. A brand you cannot touch. An internal stakeholder whose approval is required. Every one of these changes the design, and every one that surfaces in month two instead of week one costs money.

5. What is definitely out of scope. Underused, and it does more for a project than almost anything else. “We are not touching the logo.” “The mobile app is a later conversation.” “We do not need a CMS; two people update this twice a year.” Each of those removes a whole branch of work and a whole category of expensive later surprise.

6. Who decides. Name the person. Not the committee — the person who can look at two directions and pick one. Projects do not usually stall on hard problems. They stall because five people each hold a soft opinion and nobody is allowed to overrule anyone.

What to leave out

Do not send a feature list as the whole brief. Send it as an appendix if you have one. Leading with it invites a studio to price the list rather than solve the problem, and you will get exactly what you asked for.

Do not include more than three or four reference sites. And when you do, say what you like about each one. “I like this” is unusable. “I like that the pricing is legible without a sales call” is a design instruction. Ten references with no annotation mostly reveal that the direction has not been decided yet.

Do not write the copy yet. Words and layout are the same problem, and final copy written before the structure exists gets thrown away or, worse, forces a bad structure to keep it.

Do not hide the budget. The most common reason for withholding it is a fear of being quoted up to it. What actually happens is that you get a proposal aimed at the wrong project entirely and both sides waste two weeks. A range is enough. Any studio worth briefing will tell you if your scope and your range do not meet.

A structure you can copy

Two pages is plenty. Longer than that and the important parts get skimmed.

The situation. Three or four sentences on what your organisation does and where it currently is. Assume the reader knows nothing and is smart.

The problem. What is happening now that should not be. Be specific, and include the evidence you have, even if it is anecdotal — “our two biggest clients both said the same thing” is real evidence.

The audience. Who is affected, what they are doing instead today, and what they are like. One paragraph.

Success. How you will know this worked, in six months. One or two statements, ideally observable.

Scope. What you think is included. Then, separately and explicitly, what is not.

Constraints. Dates, budget range, technology, brand, approvals, anything non-negotiable.

The decision. Who signs off, who else must be consulted, and how quickly you can turn around feedback. Add your timeline for choosing a studio — it is a courtesy and it tells us how to prioritise.

Appendix. Feature list, references with annotations, analytics, existing assets, anything you already have.

The same brief, twice

It is easier to see in a real one. Here is a brief we received, lightly anonymised, and here is what it became after one forty-minute call.

Before:

We’re a coaching centre in Dhanmondi. We need a modern website with online admission, a student portal, a payment system, notice board, and a mobile app. Please share your package and timeline.

Six deliverables, no problem, no audience, no success measure, and a request for a package price on something nobody has scoped. Any number quoted against that is a guess.

After:

We run a coaching centre with about 400 students across three batches. Admissions happen twice a year and we currently do them on paper and over WhatsApp — two staff spend most of a fortnight on data entry, and every intake we lose a handful of students who gave up on the process.

The people we need to serve are parents, mostly on phones, mostly paying by bKash, who want to enrol without visiting the office. The second audience is our own two admin staff, who are not technical and will not be trained.

It has worked if the next intake runs without a paper form and admin time drops from two weeks to a couple of days. We’d also like fewer “has my payment gone through” calls.

Not in scope: the mobile app, the notice board, and anything about our branding — we are happy with the logo. Constraint: it has to be live before the January intake, and bKash is non-negotiable. Budget is in the range of X to Y. I decide, and I can turn around feedback in a day.

Same organisation, same money, same two weeks of thinking. The second version took one call to produce, and it does three things the first cannot: it makes a small build obviously correct — no app, no portal, no notice board — it gives everyone a shared way to tell whether it worked, and it surfaces the one genuinely hard part, which is the payment reconciliation nobody had mentioned.

The first brief would have produced a quote for six things. The second produced a project for two, at a fraction of the price, that actually solved the problem the centre had.

What happens after you send it

A good studio’s first response should not be a price. It should be questions — and if the questions do not make you think about your own product slightly differently, that is information about the studio.

Expect to be pushed on the success criteria, because that is where briefs are usually softest. Expect to be asked what happens in the failure cases nobody demos: the payment that half-completes, the user who abandons halfway, the staff member who does not read the instructions. Expect at least one question that reveals a decision you did not know you had made.

Then expect a scope that is different from the one you wrote. Not wildly — but if a studio agrees with every line of your brief, they have read it as an order form rather than as a problem. The brief is the beginning of the thinking, not the end of it. That is exactly what it is for.

If you are putting one together now, send it to us — even a rough draft. We would rather read a half-finished brief and ask the questions than receive a polished one that has already closed off the interesting decisions.

And if the number at the bottom of it is the part you are least sure about, Taher wrote the companion piece on what a build actually costs.