Throughout this course, we will build a small consultation-request website. A visitor chooses a service, enters a name and contact method, and sees a confirmation. Start with fictional data. Payments, a CRM, and automated email are outside version 1.
The goal of this module is not to describe every future feature. It is to make the first result understandable to both a person and an AI tool.
What you need
- One specific audience and a problem they encounter.
- 30–45 minutes for a short brief.
- A
PROJECT-BRIEF.mdfile in your project folder. Any text editor is fine.
You can use your own idea instead, but keep its first user journey just as narrow.
1. Name the person and the moment they need help
Use this sentence: “When [situation], [role] wants to [action] so they can [outcome].”
Too broad: “Build an AI website for experts.” It combines a website, AI, and expertise without a testable outcome.
Specific enough: “After choosing a consultation, a visitor can send a request and see that it was received.”
2. Describe one user journey
Write the steps as actions, without choosing technology yet:
- Opens the service page.
- Chooses one of three consultation options.
- Enters a name and contact method.
- Submits the request.
- Sees a confirmation or a clear error.
Ask: What appears first? What happens if the form is empty? How does the user know it worked? What if sending fails?
3. Draw the boundaries
| In version 1 | Later |
|---|---|
| One service page | User account |
| Name, contact, service choice | Payment |
| Required-field validation | Automatic email |
| Sending, success, and error states | Live CRM integration |
The “later” list prevents scope creep. New ideas go there instead of silently entering the current build.
4. Write acceptance criteria
An acceptance criterion describes behavior someone can observe. Avoid words such as “beautiful”, “easy”, or “smart” unless you explain how to check them.
| Situation | Expected result | Check |
|---|---|---|
| All fields are valid | Submission confirmation appears | Send a test request |
| No service is selected | Form is blocked and the field is identified | Submit without a service |
| Contact is missing | Submission stops and the field is marked | Clear the contact field |
| Server is unavailable | An error appears and retry is possible | Simulate a failed request |
| Phone viewport | Fields and button fit without horizontal scrolling | Check at 360 px |
5. Separate facts from assumptions
Label important statements Fact, Hypothesis, or Decision. A fact has an observation, document, or owner behind it. A hypothesis still needs evidence. A decision is today’s chosen option and can be revisited.
For example, “most requests come from phones” is a hypothesis until analytics confirms it. “We will not collect a phone number in version 1” is a decision.
Worked brief
User: someone choosing a consultation. Situation: they have read the service page and want to discuss a problem. Outcome: submit contact details and see confirmation. Version 1: service page and short form; no payment, account, or automatic promise about response time. Done: five form scenarios work on mobile and desktop; errors are understandable; an unsuccessful request never appears successful. Constraint: use a test environment and fictional data.
Practice
- Fill in the product brief template.
- Choose the one journey you will build.
- Write at least five criteria, including an error and a mobile check.
- Ask someone else to read the brief and explain what version 1 will do.
- Clarify the brief if their understanding differs from yours.
Save: PROJECT-BRIEF.md and your acceptance table. Later modules build on these decisions.
Self-check
- Can each criterion be checked without guessing what the author meant?
- Is it clear what is deliberately deferred?
- Are any unmeasured outcomes presented as facts?