A client says they need a new website. You ask about pages, design preferences, and a deadline. The conversation feels productive, so you start preparing an estimate. Two days later, you discover that the site must accept bookings, connect to an existing customer system, and support a second language. The original conversation was useful, but it did not yet define the work.
A project brief helps you discover those gaps before they become delivery problems. Its purpose is to make the desired outcome, required work, constraints, responsibilities, and open decisions visible together. A good brief can be short. What matters is whether another person can understand what is being requested and identify what still needs an answer.
The template below works as a starting point for independent designers, developers, consultants, and small service teams. The fictional example concerns a neighborhood repair business. Adapt the fields to your service rather than making every client complete questions that do not affect their project.
Start with the decision the brief must support
Before writing questions, identify what you need to decide next. An early discovery brief may support a recommendation about the right approach. A scoping brief may support an estimate. A production brief may tell a designer or developer what to deliver. Each decision needs a different level of detail.
If you are preparing an estimate, for example, you need enough information to understand the work and the uncertainty around it. You may not need final wording for every button. You probably do need to know whether the project includes writing copy, translating it, obtaining photography, or integrating another service.
Write the brief’s immediate purpose at the top: “This version supports an estimate for the website refresh.” That sentence helps everyone interpret incomplete details honestly. It also prevents a preliminary intake document from being mistaken for a fully approved production specification.
Use a small set of fields with clear jobs
A useful starting template has nine sections. Each section answers a practical question. You can put them in a document, a spreadsheet, or a dedicated requirements workspace. Keep the answer, its source, and its current status together wherever possible.
| Section | Question to answer | Useful evidence |
|---|---|---|
| Outcome | What should improve for whom? | A specific problem or workflow |
| Audience | Who will use the result? | Priority audience and use situation |
| Deliverables | What will be produced? | Named outputs and formats |
| Boundaries | What is included and excluded? | Explicit scope statements |
| Inputs | What must the client provide? | Assets, access, content, decisions |
| Constraints | What limits the approach? | Dates, budget range, existing systems |
| Acceptance | How will the result be reviewed? | Observable checks and reviewer |
| Ownership | Who can decide and respond? | Named people and responsibilities |
| Open decisions | What remains unresolved? | Question, owner, due date, impact |
For every section, allow an honest “unknown.” An empty answer is ambiguous: the client may have missed the question, considered it irrelevant, or lacked the information. A labeled unknown makes the next action easier to identify. It is useful to distinguish unknown, not applicable, and confirmed.
Describe the outcome before listing features
Features describe an implementation. Outcomes explain why the implementation is worth doing. “Add a booking calendar” is a feature request. “Reduce the back-and-forth needed to arrange a repair appointment” describes the problem the client hopes to solve.
For the fictional repair business, a useful outcome statement is: “Help local customers understand the repair services and send an appointment request with the information the team needs to respond.” That does not yet require a particular calendar service or automation. It gives you something to evaluate before choosing an approach.
Follow the outcome with the priority audience. In this example, the audience is local customers using a phone to arrange a first repair visit. Existing commercial customers with negotiated service arrangements are outside the first version. This distinction affects navigation, content, and the information requested in the form.
Avoid invented targets. If no one has measured current inquiry volume or response time, do not add a confident improvement percentage to make the brief appear rigorous. Record the missing baseline and decide whether collecting it is necessary before the next decision.
Turn deliverables into things someone can review
“A modern website” leaves too much room for interpretation. A more useful deliverable list names the actual outputs: a homepage, a service overview, three service-detail pages, a contact page, an appointment-request form, and a basic handover guide. The exact list should reflect what the client needs.
For each output, add the expected format or environment. Is the handover a PDF, a recorded walkthrough, or a live session? Is the design delivered as working pages or design files? Does the form send a notification, create a record, or both? These details can change the work substantially.
Write exclusions next to the relevant deliverables. In the repair example, the first version excludes online payments, automatic appointment confirmation, and customer accounts. These are illustrative boundaries for this fictional project. They should not be copied into a real brief without checking the client’s actual requirements.
A short exclusion list gives the team a place to discuss later requests. It does not need an adversarial tone. “Consider for a later phase” often communicates the boundary more usefully than leaving an important feature unmentioned.
Make client inputs and dependencies explicit
Projects often wait for something that was treated as a background detail: a logo file, a domain setting, a pricing decision, or permission to use a photograph. Put those dependencies into the brief while you can still plan around them.
In the example, the client provides service descriptions, current contact details, approved photographs, and access to the existing hosting account. The project owner confirms that the person providing access is authorized to do so. The team also needs a decision about which employee receives appointment requests.
For every dependency, identify an owner and the date it is needed. “Client to provide images” is less actionable than “Business owner to provide five approved workshop photographs before visual design begins.” If the client cannot meet that date, discuss an alternative before the dependent work starts.
Record the effect of missing inputs. Perhaps temporary copy can support a layout review, while production publishing must wait for approved wording. Perhaps hosting access is unnecessary during discovery but essential for deployment. Distinguishing those situations keeps one missing item from making the entire project appear equally blocked.
Separate facts, assumptions, and proposals
A brief becomes unreliable when a working assumption gradually turns into an apparent agreement. Label the difference. A fact has been confirmed. An assumption is being used temporarily. A proposal is an option someone still needs to approve.
For example, “The business currently receives requests by email” might be a confirmed fact. “The existing mailbox can receive form notifications” could be an assumption until tested. “Use a shared inbox for the service team” may be a proposal awaiting a decision.
Keep the source of consequential answers. You might record that the business owner confirmed the service list during a call on a particular date, while the operations manager supplied the request-handling process. This helps resolve conflicting information without relying on memory.
When two stakeholders disagree, preserve both positions and assign the decision to the appropriate person. Quietly choosing the answer you prefer makes the brief look complete while leaving the disagreement unresolved.
Write acceptance checks that can actually be used
Acceptance criteria describe how the work will be reviewed. “Looks professional” can start a conversation, but it is difficult to apply consistently. Pair subjective goals with observable checks that fit the deliverable.
For the appointment-request form, an illustrative check might say: “A customer can submit the required contact and repair information, receive a clear confirmation message, and understand that the appointment is not confirmed until the team responds.” Other checks might cover required fields, error messages, notification delivery, and the agreed mobile layout.
Do not make the brief a substitute for a complete test plan. Start with the checks that determine whether the requested outcome has been delivered. More detailed verification can follow during implementation. If a requirement is consequential, however, it needs a clear owner and a planned way to verify it.
Identify who performs the review and who can approve the result. A project can accumulate conflicting feedback when five people believe they have final authority. The brief should explain how comments are gathered and which person resolves disagreements.
Keep an open-decision register beside the brief
Open questions deserve their own small table. For each question, record the owner, the date an answer is needed, and the consequence of waiting. That makes uncertainty manageable without hiding it in a long paragraph.
| Open question | Owner | Needed for | Effect if unresolved |
|---|---|---|---|
| Which mailbox receives requests? | Business owner | Form setup | Notification delivery cannot be finalized |
| Who approves service descriptions? | Operations manager | Content review | Pages remain draft |
| Is a second language required at launch? | Project sponsor | Scope estimate | Estimate may need a separate option |
Review the register before producing a quote or beginning a dependent stage. Some unknowns can remain open if the next step is designed to resolve them. Others change the project enough that you need an answer first. Record that judgment rather than applying the same rule to every unanswered question.
Preserve the version used for a decision
Once a brief supports an estimate or a delivery decision, preserve that version. If everyone continues editing the same document without a record, it becomes difficult to reconstruct which requirements were considered at the time.
Give the version a readable name and date. Keep the decision beside it: estimated, acknowledged for planning, approved for design, or another accurate description. Those states mean different things. Do not imply that a simple acknowledgment has the legal effect of a signed agreement.
When a requirement changes, explain the change and its effect. “Added a second language” may affect copy, navigation, review, and delivery dates. A version note should point to the affected work rather than merely saying “updated brief.”
The practical goal is retrieval. Months later, someone should be able to find the version used for the decision, understand its open questions, and see what changed afterward. Choose a version process that your team will consistently maintain.
Choose a workspace that supports the process
A document works well when the project has a small number of decisions and everyone follows a reliable review process. A spreadsheet can make gaps, owners, and statuses easier to scan. A dedicated app becomes useful when you regularly collect requirements, clarify missing answers, and preserve versions across many client projects.
Brievra is one option for this narrower workflow. Its first-party product information describes editable service templates, local gap review, version records, and Markdown export. It also describes an optional paid workflow for encrypted client links and response import. Check its current product information for the features and purchase options that fit your work.
Whichever tool you choose, test it with a completed project. Enter the original request, identify the questions that would have changed your estimate, and try to retrieve the version you would have used for the next decision. That exercise often reveals which fields are essential and which only create more administration.
Use the brief to make the next conversation better
Send the draft with a focused request. Instead of asking the client to “check everything,” point to the decisions that need attention: confirm the audience, review the deliverable list, and answer the three open questions that affect the estimate. A clear review request is easier to act on than an unstructured invitation to comment.
After the review, update the brief and preserve the version used for the next step. Keep it close to the estimate, proposal, or production plan it supports. The brief should remain part of the working process rather than becoming a document everyone forgets after kickoff.
For your next project, start with the nine sections above and remove anything that does not help a real decision. Add the fields your service genuinely requires. A useful brief earns its place by making the work clearer, especially where an unanswered question would otherwise become an expensive surprise.
Product reference: Brievra’s first-party product page. The repair-business example, template, and review method are original illustrations rather than a case study or a legal document.