Start the brief with an observable outcome
“We need an admin panel” does not explain which task should improve. State who needs an outcome, in which situation, and what prevents it today. The GDS discovery guide similarly places understanding users, the problem, and constraints before committing to a build. This article prepares inputs for discovery; the separate buying guide addresses the choice between packaged and custom software.
Technical sources for this section: Government Digital Service [1]
Follow one actual case from start to finish
As an illustrative example, imagine a distributor routing discount requests between sales, a sales manager, and finance. Record where the request originates, who decides, and when it becomes an order. Include corrections, an absent approver, and cancellation alongside the normal path. Combine interviews with observation of anonymized cases and forms. Differences between a manager’s account and a user’s daily work are discovery findings.
- For each step, record its input, owner, output, and current system.
- Separate active work from waiting time; record the observation period and measurement method.
- Identify problems that process changes could solve and those requiring software capabilities.
A brief template for decisions that affect delivery
Use this proposed template for an initial discussion. Answers need not all be final: give each unknown an owner and identify the evidence needed to resolve it. Budget and a target date are constraints; they do not define a deliverable scope on their own. Protect confidentiality by removing identifiers and sensitive data from examples before sharing them.
| Topic | What to record |
|---|---|
| Outcome | Which user completes which task, with what observable change? |
| Ownership | Who sets priorities and who confirms acceptance? |
| Scope | First-release workflow, its users, and explicit exclusions |
| Data | System of record, sensitivity, quality, and correction owner |
| Integration | Target system, access owner, and evidence of an API or file interface |
| Operations | Critical periods, support owner, and downtime constraints |
Turn requirements into acceptance scenarios
Each requirement needs behavior that users and the delivery team can observe. In the illustrative discount workflow, successfully saving a form is only one condition. Specify the starting state, action, and expected result. For response time or capacity, agree a threshold, dataset size, and measurement environment: “make it fast” is not an acceptance criterion.
- A complete request receives a unique identifier; resubmitting the same request does not create another case.
- A user from another business unit cannot view or approve a request outside their access scope.
- When finance is unavailable, the uncertain state and next action are clear to the user and support team.
- Check field errors, keyboard use, and Persian mobile presentation in the main journey.
Resolve integration and migration uncertainty before estimating
A system name or a promise that “it has an API” is insufficient evidence for an estimate. Ask for a sample response, authentication method, request limits, support owner, and test environment. Decide which system owns customers or orders and in which direction changes flow. For migration, inspect sample data and identifier matching rules. A file import facility does not establish that a complete, reversible migration is possible.
- Define a state and resolution owner for outages, duplicate messages, and incomplete data.
- Record data excluded from migration and how users will access older records.
- Choose record counts and suitable control totals for a trial reconciliation before and after transfer.
Bound the first release around a complete workflow
For discount requests, submission, review, decision, notification, and status visibility could form a useful workflow. Multiple dashboards before that journey works may delay learning. Separate needs into those essential to run the workflow, those that can wait, and hypotheses requiring a test. If connectivity to finance is the largest uncertainty, a limited integration investigation may precede detailed screen design. That investigation does not establish production readiness.
Discovery outputs should enable the next decision
Ask for a versioned brief, workflow map, uncertainty register, and acceptance criteria. An estimate should state assumptions, exclusions, access dependencies, and ownership of changes. Where evidence remains insufficient, further research or stopping is a valid decision. For an initial request, one specific workflow and an anonymized example are more useful than a long feature list.
- Are the main user and acceptance owner involved?
- Does the first release complete a task without the deferred features?
- Are data, integration, and operational owners named?
- Does every material uncertainty have a next test or decision?