Stop Writing Briefs. Start Building Them.
Estimated reading time: 8 minutes
Key Takeaways
- Clients are no longer arriving with a written brief, they’re arriving with an AI-generated prototype and asking us to make it work.
- So we’ve flipped our process: we take a brief and turn it into a working AI prototype within a day, before any workshop, sprint or wireframe.
- That prototype becomes the base layer for everything that follows: research, ideation, testing, design and build.
- A prototype built in a day is a starting point, not a product. The detail that makes a product succeed still has to be designed.
- If you own a project, the most useful brief you can write today is something people can click on.
The Brief Has Changed
“We’ve built a version of it already, can you redesign it and make it work properly?”
Over the past six to nine months, that’s become the most common opening line I hear from new clients. They’re no longer sending a 20-page requirements document. Nor are they sending a slide deck of personas and a wish list of features. Just a working prototype link, a description, and a list of the technical stack used.
In most cases you’d be led to believe they’re experienced engineers, but typically they’re not. It’s usually a curiously minded founder, a product owner or a head of operations who spent a few weeks experimenting in Lovable, Figma Make, or Claude code, and now wants their vision turned into something production ready.
At first, it felt like a shortcut that would cause more problems than it solved. However, the times are changing and you have to change with them, so rather than turning my ‘product guy’ nose up at it, I now view it as a practice in reverse engineering.
So in essence, we’ve stopped fighting it. Instead, we’ve started doing it ourselves.
Why Briefs Are Losing
As the way to explain the vision, the written brief alone is okay, but far less important, in the sense that a prototype can accelerate that transfer of knowledge far more efficiently and clearly. Here’s why.
A written brief is a guess. Every project owner reads it differently, every agency prices it differently, and nobody really knows what’s being asked for until something appears on a screen. Weeks of discovery can be spent turning words into something everyone could have looked at on day one.
Words hide the gaps. “Users can manage their accounts” sounds complete on paper, but put it on a screen and the questions arrive immediately: which users, which settings, what happens when two people change the same thing at once. A prototype exposes those gaps on day one rather than in week six.
People are far better critics than they are authors. Ask a stakeholder what they want and you’ll get a feature list. Put something in front of them and you’ll get the truth, in about thirty seconds: “that’s not how we do it”, “where’s the approval step?”, “no one would ever look at that number first”.
Briefs go stale the moment they’re signed off. By the time a document has been written, reviewed, circulated and approved, the thinking behind it has already moved on. A prototype gets changed in an afternoon. A brief gets defended.
The tools changed, and with them surfaced the cheapest, fastest way to find out what a product should be.
A Prototype in a Day
So here’s what we’ve started to do, we take a brief, whatever shape it arrives in, and we turn it into a working AI prototype within a day. Really fast, before the workshop, before the wireframes, before anyone has written a user story. It starts like this:
- Unpack the brief. A short call to understand what’s in the brief, the users, the core journeys and the one or two things the product absolutely has to get right.
- Build the first version. Using AI prototyping tools like Claude Code, our designers generate a clickable prototype of those core journeys, real screens, real flows, plausible data.
- Put it in front of the client. By the end of the day, the team is looking at something they can click through, pull apart and argue about.
That prototype then becomes the base layer for everything else. Research sessions have something to reference, and any ideation exercises start from a shared reference point. Stakeholders who would typically never engage in the ideation exercises can view the prototype straight away and give feedback early on. We’ve essentially got something to work with before we’ve even really got going, and that changes the quality of every conversation that follows.
Now you might think, if it’s all about prototyping, doesn’t that undermine the collaborative bits, such as the design sprint?
Personally I swear by our four-hour design sprints for collaborative ideation, so creating a prototype ahead of one seems kind of counterproductive, right? But follow me on this. If that prototype is treated as a starting point we can pick apart during a lightning demo (where the team reviews existing ideas for inspiration), rather than an answer, then I’m all for it. Right or wrong, its job is to get everyone thinking about how to improve the product. If it does just that, then I’m happy, and so far, so are our clients.
A Starting Point, Not a Product
It’s so easy to look at an AI generated prototype and go “wow” that’s it, no need to do anything else, in fact every AI prototype a client has handed us looks finished and totally isn’t. The screens are tidy, the buttons work, and underneath it sits a set of assumptions nobody has tested. The edge cases are missing, and to be honest – they all kinda look the same, albeit the extra special ones have used ShadCN or Untitled UI as a design system 🙂
Of course then there’s the technical hot mess, the permissions model is a guess. The data is invented. The flow that works for the happy path falls over the moment a real user does something unexpected, which real users do constantly.
That’s not a criticism of the tools or the people using them, I use them and I love what can be achieved, heck it’s what they’re for. But in my opinion it all comes down to this, an AI prototype is brilliant at answering “is this roughly the right thing?” and poor at answering “is this the right thing, done properly?”
And it’s the second question where products are won or lost. The fine detail, the empty states, the error messages, the accessibility, the way a dashboard behaves with ten thousand rows rather than ten, and that’s what separates a product people just about tolerate, from one they actually want to use. That detail still has to be researched, designed, tested and built by people who know what they’re doing.
So the prototype doesn’t replace design or development in my view, moreover it moves the starting line. Instead of spending the first fortnight working out what we’re building, we spend it working out how to build it well.
Stop Writing Briefs. Start Building Them.
If you own a product or a project, here’s my take on it. The brief you’re about to spend weeks writing could be the least useful thing you’ll hand an agency. Try and build something instead, it doesn’t need to be good. It just needs to exist and help tell the story.
- Make it ugly and make it quick. A rough prototype that shows the core journey beats a polished document that describes it.
- Write down what you’re unsure of. The assumptions you made to get it working are more valuable to us than the screens themselves.
- Don’t fall in love with it. It’s a question, not an answer. Expect most of it to change.
- Bring the why. A prototype shows what you want. Only you can tell us why it matters and who it’s for.
And if you don’t have the time or the tools to build one? Send us the brief anyway. We’ll have a prototype back to you by the end of the day.
Frequently Asked Questions
What tools do you use to build an AI prototype?
Whichever fits the problem, e.g. Figma Make, or Claude. The tool matters far less than knowing which journeys to prototype and which questions the prototype needs to answer.
Can you take an AI prototype we’ve already built and turn it into a real product?Yes, and it’s now one of the most common ways projects start with us. We treat it as the starting brief, test the assumptions underneath it, then redesign and rebuild it properly in React and TypeScript.
Can we just ship the AI prototype?
We’d strongly advise against it. Prototypes are built to answer questions quickly, not to be secure, accessible, maintainable or ready for real users at scale.
Does this replace user research?
No. It makes research better. Participants react to something real rather than something imagined, which gives sharper, more honest feedback, earlier.
Interested in learning more about the future of designing with AI design and digital product development? Check out the following links for more content.