Reviewed by LAB/02 editorial check (AI-assisted)
How to write a digital project brief without technical jargon
Describe the business change, people, constraints and evidence you need so a digital team can scope the right next step.
AI-generated / AI-editedDescribe the change you want people to feel
A brief does not need to begin with a platform, framework or feature list. Start with the business situation: what is difficult today, who experiences it and what should become easier, clearer or more reliable after the work? This gives a team a problem to understand rather than a solution to defend.
Use an ordinary sentence: ‘When a returning customer needs X, we want them to do Y without Z.’ Add one example from the current workflow. Concrete context makes later scope decisions faster.
Name the people and the moments that matter
List the people who use, approve, maintain or are affected by the service. You do not need perfect personas. A short description of their goal, context and constraint is enough to expose the important differences.
Then describe the moments that must work: finding an option, submitting information, receiving a decision, handing work to another person or recovering from an error. This is more useful than saying the product should be intuitive, modern or easy to use without explaining for whom.
Separate facts, assumptions and open questions
A good brief says what is known and what still needs investigation. Mark facts such as an existing system or legal constraint, assumptions such as expected demand, and questions such as whether a partner can provide an interface. This prevents an estimate from quietly treating a guess as a requirement.
Include the evidence you already have: support messages, a spreadsheet, a process map, user feedback or a failed attempt. Remove personal data that is not needed for the first conversation. Confidential details can be shared later through an agreed process and optional NDA.
Finish with a decision and a boundary
State what you want the next stage to decide. It might be whether the journey is worth prototyping, whether a technical dependency is feasible or what a first release should include. Add what is explicitly outside the first stage, such as real payments, production data, full automation or every user role.
LAB/02 Custom work starts from a written framing conversation rather than a fixed package. Share the brief through the application, and the response can focus on the right next experiment instead of forcing a premature technology choice.
AI-generated / AI-edited