The Parts of a Good Brief

Why this matters

Lesson 5 gave you the seed sentence. Seeds still leave whole gardens of ambiguity: which users, which pages, what it must not do, what the result should look like. Every missing part is a decision the tool makes for you, silently, usually in the most generic way. A complete brief does not take longer to write than the three repair rounds it replaces, and unlike repair rounds it compounds: the same brief briefs the chat, instructs the coding assistant, and feeds the app builder. Write once, build three ways.

Concepts

The seven parts, each one sentence unless noted:

1. Goal. What success looks like: "Collect Saturday orders without lost paper notes." Prevents building something impressive that solves nothing.
2. User. The one person from lesson 5, with situation: "Aylin, bakery owner, reads orders on her phone between customers." Prevents designing for everyone and no one.
3. Context. What exists today: "Orders arrive by phone; hours are 08:00 to 19:00, closed Mondays; no online payment." Prevents the tool inventing a business you do not have.
4. Scope. Version one as a short list, plus explicit non-goals: "In: products, hours, order form with name, items, pickup time. Out: payment, accounts, delivery tracking." Prevents bloat; the out-list is the most valuable line.
5. Example. One concrete case walking through: "Saturday 09:00, customer orders 2 loaves for 12:00 pickup; Aylin sees name, items, time on her phone." Prevents abstract features that fail on first contact with reality.
6. Constraints. Technical and style limits: "One page, works on phones, simple language, no framework jargon in visible text." Prevents results you cannot use or maintain.
7. Expected output. The shape of the answer: "First list the page sections, then write the text for each; then show the form fields as a list." Prevents a wall of text when you needed a structure, and vice versa.

Why each part earns its place: remove the goal and you get decoration; remove the user and you get everyone-features; remove context and you get a different business; remove scope and you get version three; remove the example and you get untested abstractions; remove constraints and you get unmaintainable cleverness; remove output shape and you get the right content in the wrong container.

Worked example

The bad brief: "Make a bakery website, modern and nice." What each missing part costs: no goal (nice for whom?), no user (walk-ins or phone?), no context (hours? payment?), no scope (shop included?), no example (which order?), no constraints (must it work on old phones?), no output (a design? code? text?). Seven gaps, seven generic guesses.

The improved brief, same idea: "Goal: collect Saturday phone orders without lost notes. User: Aylin, bakery owner, reads orders on her phone. Context: phone orders today, 08:00-19:00, closed Mondays, no online payment. Scope in: products, hours, order form (name, items, pickup time). Out: payment, accounts, tracking. Example: Saturday 09:00 order of 2 loaves for 12:00 pickup visible on her phone. Constraints: one page, phone-friendly, simple words. Output: list the sections first, then two sentences each, then the form fields as a list." Feed this to any of the three tool categories and compare: the result is specific on the first try, because there was nothing left to guess.

Expected result: a seven-part brief for your own version-one idea, each part one to three sentences, with an out-list of at least three items.

The common wrong move

Writing the brief as adjectives instead of decisions: "user-friendly, modern, professional, clean." Adjectives are wishes; parts are decisions. If a line cannot change what the tool builds, delete it and write a decision.

Lab and next step

Lab A04 (paired with lesson 5) produces the structured brief and the copyable prompt from a vague restaurant request. Next, lesson 7 splits the brief into small buildable steps, because even a perfect brief fails when built all at once.