If you've been asked to put together a brief for a new website, an app, a customer portal or a replatform of something that's been running since 2019 and you've got a few weeks to get it out to an agency or three, you're probably starting from either a blank page or a briefing template someone's handed you.
A template is a good place to start. Just read the whole thing through before you send it out, because a lot of them were written for a different kind of project and they'll ask you for things that don't really apply to yours.
The briefs that come to us at Adrenalin take all sorts of formats, anywhere from a two-page document to a spreadsheet with a requirement ID on every row and both of those can work really well. In twenty years I don't think I've seen the same format twice, so if you're worried there's a correct structure you're missing, there really isn't one.
What's changed, and why the brief matters more now
The thing that's shifted in the last two years is how fast the build happens.
AI-accelerated delivery is real and we use it every day. The parts of a project that used to take months - building the pages, moving the content across, writing the tests and getting the first set of designs together - now take weeks. That's genuinely good news, because it means more of your money goes on getting the experience right instead of on production.
It's also raised the stakes on the brief. When a build took eighteen months, a vague brief usually got corrected somewhere along the way, because there was time for the problem to show up and for someone to fix it. When the same build takes five months, a vague brief gets built exactly as written.
I wrote something similar on LinkedIn a while back and it's the part I'd most want a client to take from all of this. AI-accelerated delivery that fails commercially costs you more than slow delivery that fails commercially, because you've burned the budget faster to arrive at the same disappointing revenue number. Speed is worth having, but it isn't the thing to aim at and what you're building and who it's for still are.
So the brief matters more than it used to, which is a slightly annoying conclusion but it's the honest one.
The good news is that a better brief is not a longer brief. What makes the difference for us is how much you tell us about the outcomes you're after and how much room you leave us to work out the best way to get there (which usually means a bit less writing for you, not more).
So here's what we'd recommend covering. Ten sections and what we've found makes each one useful.
1. The problem you're solving, and how you know
How this is typically written:
"We need a new website designed, developed and launched by November."
How it should be written to deliver a more successful outcome:
"Our site was built in 2019 and two thirds of visits are now on a phone. Session recordings show people dropping out of the booking form at the address step. We're losing bookings we've already paid to acquire."
The second version gives whoever reads it something to work with, because they can see what's struggling, what's worth keeping and where your money should go and they'll come back with a view rather than just a price.
You don't need a research programme for this. Session recordings, support tickets and whatever your contact centre gets asked all day will get you most of the way there (your support team usually knows exactly where the site falls over and they're worth half an hour of your time before you write anything).
If you've got a year of support tickets sitting in a system and no time to read them, that's now a twenty-minute job rather than a fortnight's work. Export them, put them through whichever AI tool your organisation has approved and ask it to group the complaints by theme and count them. It won't be perfect and it doesn't need to be. What you're after is the three or four things people keep raising and that's a much stronger opening to a brief than a general sense that the site could be better.
2. Who it's for
How this is typically written:
"Visitors to the website."
How it should be written to deliver a more successful outcome:
"People who want to buy without creating an account. People who'd sign up if it were quicker. Existing customers who just want to change their mobile number. Our own team, who update the site every week."
Naming the groups whose needs genuinely differ gives us the differences to design around and it means the trade-offs later on get decided by you rather than assumed by us.
Your own team is worth including. When the people maintaining the site are in the brief, the admin experience tends to come out much better and that's the part everyone lives with long after launch.
There's a newer audience worth a line as well, which is the AI assistants now doing the shopping on your customers' behalf. Google and OpenAI have both released ways for an assistant to search, compare and buy on a website without a person clicking through it. You don't need to build for that in this project. It's worth saying whether it's on your horizon, because it changes how much we care about your product information being accurate, complete and written in a way software can read properly and that's cheap to get right during a build and expensive to add later.
3. What you want to be true when it's finished
This section has two halves. Most briefs write the first and skip the second and the second is where most of the value is.
How this is typically written:
"Increase overall conversion rates by 2%."
How it should be written to deliver a more successful outcome:
"A returning customer can reorder in under 30 seconds without logging in. We expect that to move checkout conversion from 26% to 28%."
Same number, but now there's something to design and something to test and a reason the number should move at all.
This is the section we get the most value from and it's the one that most often arrives as the commercial half on its own. When the customer outcome is in there too, it changes what we design, because we know what a good experience looks like to you rather than having to work it out from a conversion target.
Both halves are worth writing. The commercial outcome tells everyone why the investment is worth making and the customer outcome tells them what they're actually building.
This is also the part of a brief that AI doesn't change at all. A model can generate a checkout flow in an afternoon, but it can't tell you that your customers abandon at the address step because they don't want marketing emails. That judgement is yours. It comes from knowing your business and it's the most valuable thing you'll put in the document.
4. Your budget, and what you expect back for it
How this is typically written:
"Budget to be confirmed. Please provide your best price."
How it should be written to deliver a more successful outcome:
"$150,000 to $200,000 for the first release. That's been approved on the basis of about $400,000 of additional online revenue in the first year, which assumes conversion moves roughly two points on current traffic."
So why hand over your number? Two things happen when you do.
First, you get proposals scoped to what you can actually spend, so you can compare them properly. And if what you're after genuinely can't be done for that, you'll hear it early rather than six weeks in.
Second, the expected return tells us which parts of the work matter most to you. If most of the return sits in checkout, we know that's where your budget should go rather than the homepage. Without it we're working from instinct and instinct tends to favour the things that are most visible over the things that pay.
The number doesn't need to be exact (nobody's going to hold you to a business case you wrote before the work was scoped). You almost certainly did this maths to get the money approved in the first place, so most of it is a copy and paste rather than new work.
One thing worth knowing about budgets now. Building the thing has got cheaper, so the same money buys more than it did three years ago. What it buys more of is the part that was always the constraint, which is research, testing and getting the details of the experience right, rather than more features. If a proposal comes back with the same feature list and the same price as 2023, it's fair to ask what the extra speed has been spent on.
5. What you already know
How this is typically written:
"The site needs to be more user friendly."
How it should be written to deliver a more successful outcome:
"We tested a shorter sign-up form last year and completion went up, but we rolled it back because the shorter version didn't capture the data our loyalty platform needs."
Three things are worth putting here:
Prior research and what it told you
What's been attempted before and how it went
Anything you've already ruled out, with the reason
This is one of the quickest sections to write and one of the most useful to receive. Everything you put in it is something nobody has to go and find out again, which means more of the discovery budget goes on the questions you haven't already answered.
It also matters more than it used to. Discovery has got faster, so the risk now is that a team moves quickly in a direction you already know doesn't work. Ten minutes writing down what you tried in 2024 will save you a month.
6. The systems you're working with
Your CRM, your loyalty provider, your payment platform, your finance system, wherever your content lives (including the bits nobody quite owns any more, which every organisation has).
The really useful move here is to separate what's genuinely fixed from what you simply happen to be on today.
Fixed:
"Our loyalty platform, contracted until 2029."
Current, but open to a case for change:
"Our content management system."
That one distinction can change a whole proposal. If your content management system is off the table we'll design around it and if it's negotiable some of your problems may have a much cheaper answer than the one you were expecting.
It's worth listing the constraints you think are obvious, too. Regulatory requirements, brand rules, security standards and procurement conditions are all easier to design for at the start than to add on later.
Then there's the state of your data, which decides more about what's possible with AI than the choice of tool does. Personalised content, product recommendations, a search box that understands a question asked in plain English and an assistant that can actually answer a customer all need your product information, content and customer records to be reasonably clean and reachable from one place. If your product data lives in three systems and the three disagree with each other, that's the real project and it's much better to know at brief stage than to find out in month two.
You don't need to have solved it. Just tell us honestly where it stands, including "we don't know", which is a perfectly common answer.
7. Your requirements, in priority order
Every brief needs a list of requirements and yours should be as detailed as you can make it. Write down everything the website or app has to do. Nothing in this article is an argument for leaving things out.
Two things make that list more useful than most and neither of them takes long.
The first is how you word each requirement.
How the requirement is typically written:
"The checkout will consist of these seven screens, with Apple Pay, Google Pay and PayPal in this order."
How it should be written to deliver a more successful outcome:
"Customers need to be able to pay without creating an account and to reuse details they've already given us."
Both of those are specific. The difference is that the second one says what has to be true and leaves the design open, which is where we can bring you options you may not have seen. It's the harder of the two to write, because the solution is the part you can picture (and the part that's easiest to put on a slide for your exec team, which doesn't help).
If you've already worked out the seven screens, that's completely fine. It just means what you need is a build team rather than a design and build partner and it's worth knowing which one you're shopping for before you go out.
Wording matters a bit more each year, because interfaces are becoming less fixed. Generative UI, where a page puts itself together around what the person appears to be trying to do, so two customers can see two different layouts, is moving out of demos and into real products. A brief built around seven particular screens has locked in a layout that may not be the right one by the time you launch. A brief built around what a customer needs to do stays true either way.
The second is putting the list in priority order.
Sort your requirements into what you need working on day one and what can come later. Two groups is enough.
If you've come across MoSCoW, it's the same idea with four groups instead of two: must have, should have, could have and won't have this time. Either approach works. What matters is that anyone reading can tell the difference between the things you can't launch without and the things you'd like if the budget stretches.
This ordering is probably the most valuable thing in a brief, for two reasons. It lets you compare three proposals properly, because everybody has priced the same must-haves rather than guessing at different ones. And it means the conversation about what to trade off happens now, while you're in the room, instead of in month four when something has to give and somebody else decides for you.
And a note on AI features specifically.
If someone above you has asked what the AI story is, the useful answer in a brief is the job you want done rather than the technology you want used.
How the requirement is typically written:
"The site will include an AI chatbot on the homepage."
How it should be written to deliver a more successful outcome:
"Around 40% of our support contacts are people asking where their order is. We'd like customers to be able to get that answer themselves, at any hour, without calling us."
The second version might be answered with a conversational assistant. It might also be answered with a better order-status page and an email that arrives before anyone thinks to ask, which would cost a fraction as much and work more reliably. You'll get the better of the two options if the brief describes the job.
I judged the Webby Awards across the web and app categories a while ago and the weaker entries had something in common: a branded chat box dropped onto a homepage and called an AI assistant, with nothing useful behind it. That isn't what anyone set out to build. It's what tends to arrive when a brief asks for a chatbot rather than describing a problem.
8. Your timing, and what's driving it
How this is typically written:
"Must go live by 15 November."
How it should be written to deliver a more successful outcome:
"We want it live by early November so it's stable before the Christmas trading period. The trading peak is the real constraint here."
Give us the reason behind the date and we've got something to work with. We might come back and suggest getting checkout live in October and the account area in February, which protects the part that actually matters to you. With the date on its own, the only available answers are yes or no.
If the timing is more flexible than it looks, that's worth saying as well. Briefs that are open about it tend to get more options back.
It's also worth asking what could be live sooner. Now that the build moves faster, a lot of projects run better as a first release in ten or twelve weeks followed by a run of improvements based on what real customers do, rather than one big launch at the end. That's usually a better commercial outcome, because you start learning from actual customers months earlier and it's much easier to plan for when the brief invites it rather than assuming a single date.
9. Who decides, and how quickly
How this is typically written:
"All work to be approved by the steering committee."
How it should be written to deliver a more successful outcome:
"Day to day: [name], who can approve anything inside the agreed scope. Sign-off on design and launch: [name]. We'll come back on any review within five working days."
Approvals move timelines more than almost anything else and this is the one section on the list that costs nothing to sort out beforehand. A five-day review commitment written into the brief is worth more to your delivery date than most of the other decisions you'll make.
If something has to go to a committee that meets monthly, that's completely workable when we know about it up front (we'll build the plan around the meeting dates, which is a much better outcome than discovering them in week six).
This has become the biggest risk on a fast project. When the build takes five months instead of eighteen, a three-week wait for feedback stops being a small delay and becomes a real chunk of the schedule. The build only gets quicker if the decisions get quicker with it.
10. How you'll know it worked
Two lists again, matching section 3.
Your commercial measures, each with today's number against it. "Increase conversion" is hard to hold anyone to, while "26% to 28%" is clear to everyone. If you don't know your baseline, it's worth finding out before you brief anyone (and if it takes three weeks to get the number, that's told you something useful about your analytics as well).
Your experience measures. Whether people can finish the task and how long it takes them. How many support tickets come in about this specific thing and whether that number falls. What people tell you in a survey after they've used it.
How this is typically written:
"More traffic. Easier to use."
How it should be written to deliver a more successful outcome:
"Checkout conversion from 26% to 28%. Guest order rate up 5%. Support tickets about login and account changes down by half. Task completion above 90% for reordering in usability testing."
The experience measures are less precise than the commercial ones and they're worth having anyway. A project can hit every revenue target while the experience slowly gets harder to use and the experience measures are what catch that in month three rather than year two.
If AI is part of what you're building, measure it the same way as everything else. Not how many people used the assistant, but how many of them got the answer they came for and whether your support contacts went down as a result. Plenty of things get used a lot without helping anyone.
Final thoughts
None of this makes for a longer brief. Most of the ones that work best are on the shorter side, because the outcomes are clear enough at the front that the requirements don't have to do all the explaining.
And there's a simple check before you send it. Hand the brief to someone who wasn't in any of the meetings. If they can tell you what you're trying to achieve, who it's for, what it's worth and what you'd count as a win, you're ready to go.
Learn from us
Join thousands of other Product Design experts who depend on Adrenalin for insights
