Write a Design Brief That Any Builder Can Follow
Most AI-built artifacts fail because the request was vague
You ask the assistant to build you a client onboarding guide. It produces something reasonable: an introduction, a few sections, some bullet points. The problem is that 'reasonable' is not what you wanted. You wanted specific sections for your industry. You wanted a tone that matches your company. You wanted the guide to end with a checklist the client signs. None of that was in your request, so none of it appeared in the output.
A design brief is the document that prevents this. It tells the assistant (or any builder) exactly what the should contain: who it is for, what it accomplishes, how it is structured, what constraints it must respect, and how you will know it is done. The brief is the bridge between 'I want something' and 'here is what I want, specifically.'
This applies to every you will ever ask an assistant to build. Websites, guides, reports, dashboards, presentations, quizzes, spreadsheets, templates, and training materials all benefit from a design brief written before the first draft. The five minutes you spend writing the brief save the hour you would spend correcting a draft that missed the point.
Nine sections make any buildable
A design brief answers nine questions. You do not need to fill in every section before starting, but each empty section is a guess the builder will make without your input.
The acceptance criteria and failure modes are the sections people skip most often. They are also the sections that prevent the most expensive mistakes. 'A new client can follow the guide without calling support' is a testable criterion. Without it, the builder has no way to know whether the guide is good enough.
The same brief pattern works for websites, guides, reports, and quizzes
The nine sections adapt to any type. The structure stays the same; the answers change.
For a website: the output contract names the pages, the navigation structure, and the calls to action. The design constraints cover responsive behavior, load time, and accessibility. The acceptance criteria describe what a visitor should be able to do.
For a report: the output contract names the sections, the data sources, and the visualizations. The design constraints cover length, audience expertise level, and executive summary requirements. The acceptance criteria describe what decision the reader should be able to make after reading it.
For a quiz: the output contract names the learning objectives, the question types, and the scoring logic. The design constraints cover difficulty distribution, distractor quality, and time limits. The acceptance criteria describe what the quiz should reliably measure.
For a dashboard: the output contract names the metrics, the filters, and the views. The design constraints cover refresh frequency, data sources, and who can see what. The acceptance criteria describe what question the dashboard should answer in under ten seconds.
The review rubric prevents subjective approval
Without a rubric, reviewing an becomes a matter of taste. You read the draft, feel something is off, and give vague feedback: 'this does not feel right' or 'can you make it better?' The builder (whether an assistant or a person) has no clear direction for revision.
The rubric converts taste into checkable criteria. For the client onboarding guide, the rubric might include: every step has an estimated time (yes/no), no jargon appears without definition (check), the FAQ covers the five most common client questions (count), and a real client was able to follow the guide without calling support (test result).
When you share the rubric with the assistant at the start, it uses the same criteria you will use to judge the draft. The first version arrives closer to what you want because the builder and the reviewer are working from the same standard.