Writing a useful brief for a digital project
From the starting situation to understandable acceptance: a working foundation for businesses, designers and developers.
A digital project often begins with a reasonable wish: update an ageing website, make enquiries easier or simplify a manual process. A brief turns that wish into a shared working foundation. It helps the business, designers and developers discuss the same problem rather than each filling the gaps with different assumptions.
The example is a fictional language-course provider. Prospective learners should find an appropriate offer and request a consultation. An enquiry is not a confirmed course booking. The provider also needs a dependable route for maintaining course information. The scenario contains no supposed customer results, market shares or measured improvement rates.
1. Describe an observable starting problem
A broad judgement of appearance provides limited direction. Saying the existing website is outdated leaves the required change unclear. Ask more precise questions in this example: are course times difficult to find, are course types confused and is information missing before consultation? Identify which statements have evidence and which remain assumptions.
Record the origin of important observations. Repeated questions handled by the service team can provide a useful signal. An internal opinion should remain identifiable as such. Do not copy sensitive contents from genuine enquiries indiscriminately. Extract the necessary patterns so the task becomes understandable and later decisions can refer back to them.
Include existing strengths too. Visitors may recognize the brand or find particular course descriptions helpful. Name those elements explicitly. The team can then decide what to retain and what to change. A technical restart does not automatically require discarding useful content or familiar relationships that already support the audience.
2. State the difference the project should make
The project objective describes a change relevant to both the business and its visitors. For this provider, prospective learners should understand course type, timing and the consultation route before sending their first message. This connects the task with a meaningful decision without prematurely prescribing a navigation pattern or software product.
Consider business benefit separately. Better-prepared conversations may be a desired benefit, but whether that happens needs suitable observation against a starting position. Do not turn it into a guaranteed increase in an enquiry percentage. Objectives, assumptions and later measurement each serve a different purpose in the brief.
The GOV.UK explanation of early project discovery emphasizes understanding the problem before implementation. This public methodology is a professional reference here rather than a compulsory process for every business. A small project may need only a concise shared investigation. The quality of its answers matters more than the label given to the phase.
3. Describe audiences through their tasks
Two groups matter in the example. New prospects need to judge whether an offer suits them. Course administrators need to keep descriptions and times current. They use the same website for different tasks. A broad age range alone does not explain those differences sufficiently for design or implementation.
Write a short situation for each group. One person needs a course matching prior knowledge and available time. A staff member must publish a changed starting time reliably. Identify information required, likely uncertainty and the next appropriate step. Invented biographies that contribute nothing to those decisions do not need a place in the brief.
Compare assumptions with suitable evidence. Existing conversations, content reviews and targeted work with actual users can help. GOV.UK's user-needs guidance provides a methodological starting point. The project still needs to establish which observations support its particular circumstances rather than assuming another service's audience behaves identically.
4. Prioritize a small set of core tasks
The first brief needs a recognizable order. Course selection, information checking and consultation enquiries lead this example. An internal learning area might be interesting later, but it does not automatically belong in the initial scope. Calling every request equally important removes the foundation for necessary tradeoffs.
| Task | Information required | Expected next step |
|---|---|---|
| K1: Assess a course offer | Course type, prerequisites and timing | Open an appropriate description |
| K2: Prepare a consultation | Desired offer and unresolved question | Submit a consultation enquiry |
| K3: Maintain information | Approved course details and responsibility | Publish a controlled update |
The identifiers support traceability in the example. An important decision can later be linked to its task. If a function lacks that relationship, clarify its purpose. This does not mean every aesthetic accent needs an identifier. Use the mapping for substantive requirements and decisions that affect the work.
5. Define the first scope intelligibly
The initial scope might contain a course overview, individual descriptions, consultation contact and suitable content administration. Include associated error and confirmation states. Listing successful screens alone underestimates the actual route. It should remain understandable when information is incomplete or transmission is unavailable.
Confirmed online booking, payment and a learning portal may remain outside the first scope. Record those boundaries calmly. Future development remains possible without being mistaken for work already included. When a boundary affects a core task, identify the dependency rather than hiding it in a list of exclusions.
Specify the maturity of the intended deliverable too. A clickable concept, a published website and a fully operated application are different outcomes. Identify the stage required and its accompanying documentation. The brief supplies a working foundation without replacing the commercial or legal arrangements necessary for the actual engagement.
6. Separate requirements from solution proposals
A requirement explains what should be possible. A solution proposal suggests how to achieve it. Making courses findable by suitable timing allows several designs. Specifying a particular filter at a fixed position already proposes a solution. Both may belong in the brief, provided their different status is recognizable.
Some solutions genuinely follow from existing systems. Record the technical or operational reason. A course-management system may supply data whose format needs investigation. A preference for a familiar interface has a different level of constraint. Those distinctions affect design freedom and the effort involved.
Keep an explicit section for open questions. Record an assumption and the next step for resolving it. An attractive concept screen does not establish that an uncertain integration works. Equally, not every minor sentence must be final before the project begins. What matters is the consequence of a decision remaining unresolved.
7. Plan content as part of the work
Course descriptions, images, contacts and guidance do not appear automatically alongside technical implementation. For each content group, identify what exists and who confirms its accuracy. The provider may own course prerequisites while an editor develops understandable wording. Both contributions belong in the plan.
Assess the quality of existing material too. A file containing course names is not a complete publishable description. Old dates and inconsistent terminology can require additional clarification. Record that work so a later delay is not mistakenly treated as a purely technical issue when its real dependency is content approval.
For several languages, specify maintenance and approval. A new German description should not silently contradict the English version. Establish image provenance, intended use and necessary permissions. This article supplies no blanket permission for third-party material. The actual project needs a dependable basis for the assets it publishes.
8. Expose dependencies before fixing a schedule
A preferred release date does not establish a dependable plan on its own. The team needs access, data, decisions and information about involved services. The consultation route cannot be fully checked before its actual handling is agreed. Designing a contact button does not resolve that operational dependency.
Give each important dependency a status and an owner. Is the recipient undecided, approved course data missing or an existing interface still unexamined? State the consequence and next action. A list without a route forward merely collects known uncertainty rather than helping the team manage it.
Include review and return routes in the schedule. Publication is a sequence rather than a single switch. Existing addresses, content and contact channels may need to remain coherent during a replacement. Determine the necessary measures through the actual baseline review and describe them concretely within the project.
9. Discuss budget and priorities together
A usable budget range supports realistic decisions. Consider it alongside scope, available content and the intended delivery stage. The brief need not invent a deceptively exact individual price. Where a figure is missing, establish which financial boundary the next decision needs and who can confirm it.
Priorities help when desired features exceed present capacity. Decide the first deliverable through the core tasks and identify later development as such. Arbitrarily cutting error handling would be a poor response because it can leave the contact process substantively incomplete. Tradeoffs need to preserve the integrity of the task being delivered.
Include ongoing work in the discussion. A low-cost starting point can create additional internal administration. Extensive automation may be unnecessary at a small scale. Describe the affected work and ownership so the choice is understandable. Do not turn the fictional example into a general recommendation to purchase a particular service.
10. Express acceptance as observable states
User-friendly is an understandable ambition but an imprecise acceptance criterion. For K1, specify that a course description presents course type, prerequisites and timing in an intelligible structure. Agree the actual content to examine with the relevant specialist rather than leaving reviewers to guess what the statement means.
For K2, describe success and failure separately. A valid enquiry reaches the agreed handling route. An invalid address receives understandable correction guidance. Failed transmission does not display success. Previously acceptable entries remain where feasible. Those states are distinguishable and can later be checked deliberately.
For K3, use an appropriate test role to review course editing and denial of unauthorized functions. The brief defines the required state. Implementation and actual acceptance must follow. A written criterion should never be presented as if the later application has already passed its test.
11. Plan accessibility and quality early
Keyboard operation, understandable forms and readable content belong in the planning of relevant tasks. They are not merely decorative final checks. WAI's planning guidance describes an approach spanning project responsibilities. This example uses that professional context without claiming full conformance for a website that has not been implemented.
Assess applicable standards and legal obligations for the actual offer separately. Identify the responsible role and review route. A general sentence demanding accessibility otherwise leaves scope and evidence unclear. The task needs understandable expectations for content, interaction and technical implementation.
Describe performance and supported environments in a reviewable way too. Instead of an arbitrary loading maximum without conditions, identify the subject and method of testing. The scope determines which device views and workflows matter most. One automated score cannot represent every aspect of service quality.
12. Make approval and collaboration explicit
Content, design and technical publication may have different owners. Record who consolidates feedback and who confirms decisions. Several uncoordinated comment lists can generate contradictory changes. An agreed shared state makes the work easier to follow and prevents accidental reopening of decisions without a clear reason.
Feedback should identify the issue and, where possible, its relationship to the task. Disliking a section gives little direction. Observing that course prerequisites appear only after the contact action is more specific. The team can investigate the cause and develop a suitable revision rather than merely mediating between personal preferences.
Record scope changes explicitly. Turning a consultation request into a confirmed booking materially changes the workflow. Examine new states, information and responsibilities. This is more than renaming a button. The shared foundation should evolve deliberately as the project changes rather than letting major commitments hide inside small interface edits.
13. Separate acceptance from later benefit
Acceptance reviews the agreed deliverable. Operational observation examines the benefit afterwards. They are related but different. A correctly functioning consultation request does not guarantee a particular volume of suitable prospects. The offer, demand and other contact routes also affect the result.
GOV.UK's metrics guidance connects a service's purpose with meaningful measurement. For the example, first define events and the starting situation. A form view, attempted submission and handled enquiry are different occurrences. Without those definitions, a seemingly precise percentage may be difficult to interpret or compare over time.
Qualitative feedback adds context. Repeated questions may reveal an unexplained prerequisite in a course description. Maintenance can then address a specific cause. State who gathers those observations and how they lead to a decision about further development rather than collecting feedback without any operational owner.
14. Use a concise briefing template
- Starting point: observed problems and existing strengths.
- Objective: intended change and relevant user tasks.
- Scope: initial functions and deliberately later additions.
- Content: existing material, gaps and professional ownership.
- Dependencies: data, access, services and unresolved decisions.
- Constraints: budget clarification, preferred timing and available contribution.
- Quality: specific criteria and planned review situations.
- Collaboration: contacts, feedback route and approval.
- Operation: maintenance, enquiry handling and later observation.
Fill the template with specific statements. A temporarily empty item can be acceptable when its status and next action are clear. An implementation-critical decision should not disappear unnoticed. The brief should provide an honest working foundation rather than simulate completeness through a long questionnaire that no one has meaningfully answered.
15. Check the relationships through the example
Link every core task to at least one acceptance criterion. K1 concerns course information, K2 the enquiry route and K3 maintenance. The accompanying editorial example actually checks those relationships for completeness. A missing owner or a reference to a nonexistent task is identified as a gap rather than accepted silently.
This confirms only the internal organization of the example. It does not demonstrate that a future website already meets the criteria. That boundary is part of useful planning: clarified expectations, planned evidence and actual results remain distinguishable. The team can then enter implementation with a shared understanding of what needs to be built and checked.
16. Preserve the reasoning when the brief changes
Keep a short decision record alongside the current brief. When a requirement changes, state the reason, affected task and decision owner. This does not require preserving every conversation. It provides enough context for a new participant to understand why an earlier option was replaced and which assumptions still need confirmation.
Review dependencies after each substantial change. Adding another language may affect content approval and maintenance. Adding direct booking may affect availability, confirmations and internal handling. A change that appears small on a screen can therefore alter several responsibilities. Update the shared foundation before treating the new request as part of the agreed deliverable.
Finally, make the current approved version easy to identify. Avoid asking teams to reconcile several unnamed copies during implementation. A clear record of what is decided and what remains open supports practical collaboration. The brief stays useful because it reflects the project accurately, not because it was frozen perfectly at the first meeting.
Sources and scope
Sources checked on 9 November 2026. These primary references were reviewed for discovery, user needs, performance metrics and accessibility planning. The course provider, template and task mapping are original conceptual examples.
