A software project brief should identify the people affected, the problem they face, the systems involved and the first useful outcome. Add timing, constraints and a way to judge whether the change works. You can begin with these facts before writing a technical specification.
What should become easier for someone when this work is done?
01 / Name the problem in everyday language.
Describe who is struggling, what they are trying to do, and what happens today. “Our operations team copies the same information into three systems” gives a team something concrete to investigate. A request for a new dashboard may leave the underlying problem unexplained.
The Government Digital Service’s discovery guidance recommends understanding the problem, users and constraints before committing to a build. Use that principle to start a conversation, even when the eventual solution appears obvious.
GOV.UK: How the discovery phase works (opens in a new tab)02 / Bring the starting point.
Write down the systems already involved and the people who use them. Include workarounds. A spreadsheet or a repeated email often explains more about the current process than a polished system diagram.
Separate what you have observed from what you assume. That distinction gives the team a useful list of questions to investigate. User research should examine the whole task someone is trying to complete, including the steps outside the software.
- Who does the work today?
- What information moves between people or systems?
- Where does the process slow down or break?
03 / Describe the first useful outcome.
A useful first outcome is small enough to assess and meaningful enough to matter. For the operations example, it might be moving one kind of record between two systems with a clear review step. The scope can then expand around what the team learns.
Choose an observable sign of progress. If reducing rework matters, understand the current level before deciding what improvement would count. GOV.UK’s measurement guidance makes the same distinction between a baseline and evidence of improvement.
GOV.UK: Measuring the benefits of your service (opens in a new tab)04 / Make the constraints visible.
Timing, budget, existing contracts, access to systems and internal dependencies can change the shape of a project. Share the constraints you know and mark the ones that are still open. You do not need to settle every tradeoff before speaking to an engineering partner.
Finish with five short lines. Bring those lines to the first conversation and use them to agree what needs investigation next.
- The person or team affected
- The problem they face
- The systems and people involved
- The first useful outcome
- The timing and constraints
An engineering brief, worked through
- The people
- An operations team reviewing new customer requests.
- The friction
- A request arrives by email. Someone copies its details into a customer record and creates a separate task.
- The first useful release
- Create a draft record and task from one request type, with a person reviewing them before anything is committed.
- What must be investigated
- Which system owns each field, who can approve a change, and what happens when a record already exists.
- How to evaluate it
- Try a complete request, missing information, an existing record and an unavailable system. Check the actual record and task, not only the on-screen message.