Design process / 4 min read
Better briefs make room for better ideas.
Turn a vague website request into a workable brief that separates known facts, design assumptions, and decisions still needed.
Describe the problem without prescribing the look
“Build a modern website with lots of colour” names a preference before explaining the need. A more workable opening describes the situation, the people involved, and the decision the site should support. For this article, Fieldnote is a fictional neighbourhood workshop service. Its proposed website should help a beginner understand a clay-planter workshop and find dates. This is a studio exercise, so there is no existing analytics report or customer evidence to cite. In a real brief, attach the source of a problem statement: a support enquiry, a recorded observation, a content audit, or a business requirement. If the issue is only suspected, write it as a question to investigate.
Separate supplied facts from assumptions
Create three short headings: confirmed, assumed, and to decide. For the exercise, the supplied sample offer is “Make your first clay planter” with “A two-hour beginner workshop. Materials included.” The assumption is that someone unfamiliar with the service needs a concise introduction before choosing dates. The unresolved details include the actual venue, pricing, cancellation terms, access arrangements, and booking provider. Do not fill those gaps with plausible facts simply to finish the layout. Use clear placeholders in working files and assign each missing item to a responsible person. This gives a designer room to explore while preventing an invented price or accessibility claim from slipping into the final page.
Write the brief as decisions a team can use
The example below turns a general request into a compact brief: audience task, scope, constraints, and review plan. The core message is the workshop offer, and the proposed primary action is “View workshop dates”. The illustrated scope covers the homepage offer and workshop date list; booking checkout stays outside this exercise. In a real brief, state whether deliverables are concepts, prototypes, or production work; the same word “website” can imply very different commitments. Keep the first version small enough to revisit during a review. A useful brief leaves room for several design approaches while making it possible to say whether an approach addresses the agreed task.
Replace a taste request with a bounded task.
“Make Fieldnote feel more premium.”
- Visitor + task
- Help a beginner decide whether the clay planter workshop suits them.
- Scope
- Homepage offer and workshop date list. Booking checkout stays outside this exercise.
- Constraints
- Use the supplied workshop details and keep them readable on a small screen.
- Review
- Can a new reader find the duration, included materials, and workshop dates?
Define success and how you would check it
“Looks professional” gives reviewers too little direction. For Fieldnote, a proposed outcome is that a visitor can explain what they would make, identify the beginner level and included materials, and find the date information. The verification plan is to observe representative people attempting that task with realistic content. These are planned checks, not completed findings. A real commercial project might also track suitable enquiries or completed bookings, but it must define the event, period, data source, and factors outside the page design. Avoid promising a percentage improvement without a baseline and a credible measurement plan. Visual quality matters, yet it should support a result the team can describe in practical terms.
Record constraints that can change the design
Name the content owner, final decision-maker, required deliverables, technical platform, available assets, budget, and approval dates. Mark an unknown item as unresolved rather than leaving it silently open. A booking tool that cannot be customised affects the handover; a missing workshop photograph affects the image direction. For this fictional exercise, the visual approach uses clearly labelled original studio illustrations instead of suggesting that real sessions have been photographed. When sharing references, explain the feature you mean: the readable schedule, the calm spacing, or the way a small screen handles detail. A reference without that explanation can become an accidental instruction to copy somebody else’s identity.
Revisit the brief when scope changes
Before starting concepts, ask the people making decisions to describe the audience task in their own words. Resolve meaningful differences while the cost of change is low. During a review, connect comments back to the brief: “This title does not name the activity” is actionable; “Make it more exciting” needs clarification. If a new requirement adds gift vouchers or group bookings, record the change and agree what it replaces or adds. As a practical exercise, take a recent vague request and rewrite it under problem, audience, message, constraints, deliverables, and verification. Circle any statement with no evidence or owner. Those circles become your next questions, rather than assumptions disguised as a finished plan.