A brief connects a problem to a decision about what to build. You do not need a finished technical specification to write one. You do need enough detail for another person to understand the current process, the desired result and the constraints that make the work real.
1. Follow one person through the current workflow.
Choose a specific user and a specific task. What starts the task? Where does the information arrive? What does the person do next? Where do they wait, repeat work or ask someone else for help?
Consider a hypothetical studio coordinator who copies booking requests from messages into a calendar. “Build a booking dashboard” leaves many choices open. “Let the coordinator review a request and confirm an available session without copying details between tools” gives the team a workflow to examine.
Write down the current steps before suggesting screens. You may discover that the difficult part is resolving a scheduling conflict, rather than displaying a calendar.
2. Name the information and who controls it.
List the records the workflow needs. For the studio example, those might be a requested date, session length, contact details and a booking status. Identify where each record comes from and which system should hold the authoritative version.
Then describe access: who can view a request, change a time or cancel a session? Separate information needed to deliver the service from information that would merely be nice to collect. Include any data retention or approval requirements you already know; flag unknowns instead of guessing.
If AI is part of the idea, explain the task it would perform. Drafting a reply and confirming a booking have different consequences. Specify when a person must review the output and what should happen when the model cannot give a useful answer.
3. Replace “easy to use” with something you can check.
A useful acceptance criterion describes an observable result. For example: “When a coordinator confirms a request, the session appears once in the calendar and the request is marked confirmed.” Add a failure case: “If the time is no longer available, confirmation stops and the coordinator sees the conflict.”
Keep the criterion separate from the implementation. It does not need to prescribe a database or framework. It should let the person requesting the work and the person building it agree on whether the outcome has been delivered.
If speed matters, record the current baseline before setting a target. Avoid selecting a percentage improvement simply because it sounds impressive.
4. Decide what the first release can leave out.
A first release needs a complete useful path, even if it serves a narrow audience. For the booking example, that could mean internal staff reviewing requests and confirming sessions. Public self-service, payments and marketing automation can remain separate decisions.
Write exclusions directly in the brief. They protect the shared understanding of the work. Also list dependencies, such as access to the existing calendar, and constraints such as a fixed launch event or a system that cannot be replaced.
Finish with ownership after launch. Someone needs to review errors, manage access and decide when a change is ready. Naming that responsibility early makes the handover part of the project.
A compact brief you can adapt.
This is an illustrative example, not a VXU client case study.
- User
- The studio coordinator handling incoming session requests.
- Current problem
- Request details are copied manually between messages and a calendar.
- Desired workflow
- Review a request, check availability and confirm the session from one place.
- Required data
- Contact details, requested time, duration and booking status.
- Acceptance check
- A confirmed request creates exactly one calendar entry; a conflicting time cannot be confirmed.
- First-release boundary
- Internal staff only. No payments or public booking flow.
- Open question
- Which calendar owns availability, and what access can it provide?
- After launch
- A designated studio operator manages access and reviews failed confirmations.
Use the brief to start the next conversation.
A good brief exposes the questions that remain. Bring those questions to the people who use the workflow and the people who will build it. If they describe the outcome differently, resolve that difference before expanding the feature list.
Explore VXU’s custom software and AI development work. For an example of a focused integration, see VXU Codex for self-hosted n8n.