Most design projects do not start with a twenty-page document. They start with a short, honest description of the problem. A brief does not have to be formal. It has to answer the questions a designer needs answered to say whether they can help, and roughly what it will take.
Here is a version that takes about twenty minutes and works for websites, products and internal systems.
The eight questions
- Who are you and what do you do? Two sentences. Who you serve and what you sell.
- What is not working today? The honest answer is the most valuable one. "Visitors do not understand what we do." "People abandon the signup." "The team re-enters the same data in three places."
- What do you need? A website, a product interface, a system, or a review. If you are not sure, say so.
- What would success look like? More enquiries, fewer support questions, faster onboarding. Numbers help if you have them.
- Who will use it? The main audiences and what each is trying to do.
- What is the timeline? A date if there is a hard one, such as a launch or event. Otherwise, how soon you would like to start.
- What is the budget range? If you know it. It lets a designer suggest a scope that fits instead of one that does not.
- What should I look at? Your current site or product, competitors you admire, anything you have already tried.
What to attach
Links and screenshots are enough. If you have analytics, support tickets or user feedback, mention what they say, even informally. You do not need to organise it first.
What a good brief is not
It is not a specification. You do not need to decide the pages, the features or the technology. Those are exactly the decisions a designer helps you make, and they are better made after the problem is clear.
What happens next
A good designer replies with questions, not a price. They will tell you what they understood, what they are unsure about and what the simplest way to start looks like. If you work async, that conversation can happen entirely in writing.