1. Describe the problem and intended outcome
Write what is difficult today and who experiences it. State the change you hope to make in observable terms, such as reducing repeated manual steps or making information easier to find. Avoid jumping directly to a solution before the problem is understood.
Separate the desired outcome from a guaranteed result. Record how you might recognize progress and what evidence is not yet available.
2. Identify users and important tasks
List the primary user groups and the tasks they need to complete. Include different access needs, devices, language requirements or operating contexts where relevant.
If user research has not been done, mark these descriptions as assumptions and decide how to validate them. Do not treat internal preferences as confirmed user needs.
3. Define scope and exclusions
List the pages, workflows, content, integrations and platforms that are in scope. Then record what is deliberately out of scope for this phase. This reduces misunderstandings when a project expands.
For each integration or data source, identify an owner and the access or documentation required. Flag dependencies that could affect estimates or sequencing.
4. Gather content and technical constraints
Inventory existing copy, images, documents, brand files, domains and systems. Confirm ownership and permission to reuse them. Note hosting requirements, supported browsers, privacy needs and security review expectations.
Keep secrets out of briefs and issue trackers. Use the approved secure channel for access credentials if they are needed later.
5. Agree review and acceptance
Name the people who can provide content, design, technical and final approval. Define how feedback will be consolidated and how quickly reviewers can respond.
Write acceptance criteria that can be checked. For example, specify which tasks must work, what devices are in scope and what accessibility expectations apply. Avoid subjective instructions such as ‘make it modern’ without examples or criteria.
Copy-and-use brief checklist
- Problem and intended outcome
- Primary users and their important tasks
- In-scope pages, workflows and platforms
- Out-of-scope items and known assumptions
- Content, systems, access and dependencies
- Constraints: timing, budget range, privacy and security
- Review owners, decision maker and acceptance criteria
- Open questions and how each will be resolved