How to write a digital project brief before you write a feature list

A feature list begins after several decisions have already been made

A dashboard, portal, chatbot or mobile app is a proposed answer. When a brief begins there, the delivery team inherits assumptions about the problem, user and technology without seeing the evidence that produced them. It can build every requested feature and still leave the difficult part of the work unchanged.

Mature service guidance begins earlier. The GOV.UK Service Manual asks teams to understand users, constraints and the underlying problem before committing to build. During an alpha phase, teams test risky assumptions with prototypes before deciding whether a production service is justified. The principle applies well beyond government: evidence should earn the solution.

A good brief does not need to be long. It needs to make the important uncertainty visible. It should help a product, design or engineering team understand the current situation, ask better questions and propose alternatives without losing the business reason for the project.

Begin with one difficult moment in the real workflow

Describe a specific person trying to complete a specific task. Name what starts the work, what information they have, the decision they need to make, where they wait and what happens next. If the work crosses teams or channels, follow the handoff far enough to show the wider consequence.

Use a real recent example where possible. Remove personal or confidential detail, but keep the sequence and friction intact. A statement such as managers need a better dashboard is weak. A statement such as a service manager waits until Friday for three spreadsheets, then spends two hours reconciling conflicting case totals before assigning support is something a team can investigate.

Do not force every observation into a requirement. Some details are evidence, some are assumptions and some are open questions. Label them. The distinction gives the delivery team permission to test the unknowns without reopening facts the organization has already verified.

• Actor: who is trying to complete the work?
• Trigger: what event or request starts it?
• Current path: what do they do and which systems or people are involved?
• Breakdown: where does the work wait, repeat, become unclear or fail?
• Consequence: what does the breakdown cost the user or organization?

Bring evidence that shows scale and consequence

The brief should explain why this problem deserves attention now. Useful evidence includes case volume, completion time, waiting time, rework, support questions, failure rate, customer feedback and the cost of the current operation. Where exact data is unavailable, provide the source of an estimate and state its uncertainty.

Choose evidence close to the work. A company wide revenue target may explain strategic importance, but it does not tell a designer what must improve in the workflow. Pair broad goals with operational measures such as time to a decision, successful completion, error prevention or fewer avoidable contacts.

Avoid inflated claims. A brief should not promise that a portal will transform the business or that AI will remove all manual work. It should state the observed problem and the improvement worth testing. The business case becomes stronger when the claim is narrow enough to verify.

State boundaries before they become late surprises

Constraints shape the space in which a good solution can exist. Name required systems, data sensitivity, retention rules, identity and access needs, accessibility obligations, operational hours, language needs, procurement limits and dates that are genuinely fixed. Explain why a constraint exists where that context affects the design.

Separate fixed constraints from preferences. A legal retention requirement is different from a stakeholder's preferred software. A public launch date tied to a policy change is different from a target selected for internal convenience. When everything is described as mandatory, the team cannot make informed tradeoffs.

Include what is outside the first scope, but do not pretend the excluded journey disappears. If a new interface stops at approval while another team completes fulfilment manually, record that handoff and its owner. A product boundary should not hide a service failure.

• Which data is read, created, changed, exported or deleted?
• Which people and systems must be able to exchange information?
• What failure would create customer, financial, security or operational harm?
• Which date, policy or technology constraint is genuinely immovable?
• Which parts of the wider journey are visible but outside the first release?

Define success and guardrails together

Success should describe a changed outcome, not the presence of a feature. Examples include reducing the median wait for a review, increasing successful completion, preventing an avoidable data error or making the responsible owner visible at every stage. State the current baseline if known and the period over which the change will be evaluated.

Add guardrails so one metric does not improve by harming another part of the service. Faster completion should not increase corrections. More form submissions should not reduce enquiry quality. Lower support volume should not come from making help harder to find. A balanced brief tells the team what must improve and what must not deteriorate.

Name the person responsible for accepting the result and the people who will run it after launch. Ownership affects permissions, documentation, training and support. A brief that leaves the future operator unnamed is postponing one of the most important design decisions.

Define the first proof before selecting the full scope

The first release should test one complete improvement for a real user. It might take a request from submission to a reviewed decision, connect an approved record to the next system or give a manager one trustworthy operational view. It should be small enough to learn from and complete enough to reveal whether the workflow works.

Prototype the riskiest assumption before investing in production where possible. That may mean testing whether users understand a new sequence, whether an integration exposes the required data, whether reviewers can make a decision with the proposed evidence or whether the organization can support the operating change.

Features can now be evaluated by contribution to the proof. If a requested notification, dashboard or AI summary does not help complete the first outcome or reduce a named risk, it can wait. This is prioritization with a reason, not an arbitrary reduction in scope.

• One real user or role can complete a meaningful path.
• The release tests the most important assumption or source of risk.
• The result can be measured against a known baseline or acceptance condition.
• The future operator can inspect, support and explain what was delivered.

A useful brief can fit on two pages

BharatXD structures the brief around nine items: the decision the organization must make, the person and task affected, a recent example, evidence of scale or harm, the current workflow, constraints, success measures, ownership and the first proof. Supporting research can sit behind the brief without turning its opening into a document archive.

The writing should be concrete enough that a delivery team can challenge it. Replace seamless experience with the exact handoff that should disappear. Replace user friendly with the task a person should complete without help. Replace robust platform with the failure the system must recover from and the person who responds.

The brief is ready when it creates a productive first conversation, not when it predicts every implementation detail. A strong brief gives the project a stable reason for existing and leaves room for research, design and engineering to find the most responsible answer.

Use the brief to protect the problem during delivery

Return to the brief during reviews. Ask whether the current release still improves the named difficult moment, whether new evidence changes the original assumptions and whether a requested feature supports the agreed outcome. Update the decision record when the team learns something important.

The brief should evolve without becoming a record of every meeting. Preserve the original evidence, document material decisions and keep the current success measure visible. This gives new stakeholders enough context to understand why the project looks the way it does.

A feature list tells a supplier what to produce. A good digital project brief helps a responsible team understand what must become better, for whom and under which constraints. That difference is where useful delivery begins.