A strong website or application brief explains context, objectives, users, priority journeys, content, data, integrations, constraints, governance and success criteria. It does not need to prescribe every screen. The goal is to reduce hidden assumptions, make proposals comparable and give the delivery team enough room to justify the right architecture.
Why the project exists comes before the feature list.
Not every request belongs in version 1.
The solution can be evaluated after launch.
Context
Explain the current process, tools, problems and impact.
What this changes in practice
In practice, this step should connect to Context and Users. Explain what happens today and why change is needed now. Name audiences, roles and needs. This turns a preference into a testable project decision.
Bring Must-haves into the same review. Prioritise the flows that must work in version 1. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Measurable outcomes
Replace “modernise” with leads, time saved, online sales or fewer errors.
What this changes in practice
In practice, this step should connect to Users and Must-haves. Name audiences, roles and needs. Prioritise the flows that must work in version 1. This turns a preference into a testable project decision.
Bring Content and data into the same review. Separate copy, media and business data. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
| Dimension | Question to ask | Good signal |
|---|---|---|
| Context | Explain what happens today and why change is needed now. | A third party understands the problem quickly. |
| Users | Name audiences, roles and needs. | Journeys belong to real user groups. |
| Must-haves | Prioritise the flows that must work in version 1. | Not every feature is labelled critical. |
| Content and data | Separate copy, media and business data. | Owners and sources are identified. |
| Integrations | List systems, APIs, dependencies and unknowns. | Risks are visible instead of hidden. |
| Governance | Set budget range, timeline, decision makers and KPIs. | The approval process is clear. |
Users
Describe profiles, knowledge and main actions.
What this changes in practice
In practice, this step should connect to Must-haves and Content and data. Prioritise the flows that must work in version 1. Separate copy, media and business data. This turns a preference into a testable project decision.
Bring Integrations into the same review. List systems, APIs, dependencies and unknowns. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Content and integrations
Languages, migration, personal data, CRM, ERP, Microsoft 365 and payments.
What this changes in practice
In practice, this step should connect to Content and data and Integrations. Separate copy, media and business data. List systems, APIs, dependencies and unknowns. This turns a preference into a testable project decision.
Bring Governance into the same review. Set budget range, timeline, decision makers and KPIs. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Priorities
Separate must-have, important and later.
What this changes in practice
In practice, this step should connect to Integrations and Governance. List systems, APIs, dependencies and unknowns. Set budget range, timeline, decision makers and KPIs. This turns a preference into a testable project decision.
Bring Context into the same review. Explain what happens today and why change is needed now. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
The brief becomes the first version of the backlog.
After discovery, objectives and journeys are translated into user stories, acceptance criteria, priorities and a delivery plan.
See our product approach ↗Budget and governance
Provide an order of magnitude, deadline, decision makers and reviewers.
What this changes in practice
In practice, this step should connect to Governance and Context. Set budget range, timeline, decision makers and KPIs. Explain what happens today and why change is needed now. This turns a preference into a testable project decision.
Bring Users into the same review. Name audiences, roles and needs. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Questions to settle before you start
Make the main unknowns visible before committing budget. An unanswered question is not a problem when it is explicit; it becomes a risk when it is hidden inside a supplier assumption and discovered during development.
Answer these questions with the people who will use, sell or operate the solution. Discovery then becomes an internal decision tool, not just a document sent to a supplier.
- How is context handled today, and what should measurably improve after the change?
- How is users handled today, and what should measurably improve after the change?
- How is must-haves handled today, and what should measurably improve after the change?
- How is content and data handled today, and what should measurably improve after the change?
- How is integrations handled today, and what should measurably improve after the change?
- How is governance handled today, and what should measurably improve after the change?
Common failure patterns and warning signs
The failure patterns below all push important decisions towards the end of the project, where change is more expensive. A strong process makes these risks visible early.
Use the warning signs as review criteria. If several appear at once, reduce scope, add discovery or validate a prototype before investing further.
- Leaving context until the solution has already been built
- Leaving users until the solution has already been built
- Leaving must-haves until the solution has already been built
- Leaving content and data until the solution has already been built
- Leaving integrations until the solution has already been built
- Leaving governance until the solution has already been built
Recommended action plan
A good decision should be measurable after launch. Establish a baseline, an owner and a review cadence, then compare the same indicators after launch.
A useful roadmap separates launch from evolution. Prioritise later work from usage data, leads, support tickets and operational gains instead of an old pre-project wish list.
- 1. Discovery — Goals, users and the current process.
- 2. Scope — Must-haves, assumptions and risks.
- 3. Prototype — Critical journey and key decisions.
- 4. Build — Content, data, technology and integrations.
- 5. Launch — Testing, analytics and ownership.
- 6. Improve — Usage, feedback and KPIs drive the roadmap.
Build the business case before comparing proposals
A project involving Website or application brief: a practical specification template is easier to govern when it is framed as an investment rather than a feature list. Start with one measurable outcome: more qualified enquiries, less manual re-entry, a shorter sales cycle, greater user self-service or lower operational risk. Use that outcome to judge every scope decision that follows.
The first layer of the business case connects Context with Users. Explain what happens today and why change is needed now. Name audiences, roles and needs. Quantify the current state where possible: enquiries per month, minutes per task, drop-off, licence cost, error volume or average cycle time. A reasonable baseline is more useful than a vague objective such as ‘modernisation’.
The second layer includes costs that appear after launch. Integrations and Governance therefore belong in the same decision as design and development. List systems, APIs, dependencies and unknowns. Set budget range, timeline, decision makers and KPIs. A cheaper initial proposal can become more expensive if it leaves heavy manual work, unexpected licences or an architecture that is difficult to evolve.
Finally, assign value to risk reduction. Must-haves and Content and data often affect total cost more than expected. Prioritise the flows that must work in version 1. Separate copy, media and business data. The right question is not only ‘how much does it cost?’, but ‘what level of investment is proportionate to the outcome, the risk and the expected useful life?’.
Three scope scenarios to make the decision concrete
These scenarios are not price packages. They separate the essential need from medium-term ambition. A good proposal makes the layers visible so functions can be postponed without breaking the logic of the product.
Compare proposals without comparing apples and oranges
Two proposals with the same headline deliverable can cover very different realities. Ask suppliers to respond to the same scope, assumptions and definition of ‘done’. Price then becomes a consequence of visible choices instead of a number that is impossible to interpret.
Make responsibilities explicit as well: who provides content, who approves, who configures access, who migrates data, who tests, who hosts and who responds after launch? Grey areas are often the first source of budget and timeline overruns.
| Criterion | What to review | Evidence to expect |
|---|---|---|
| Context | Explain what happens today and why change is needed now. | A third party understands the problem quickly. |
| Users | Name audiences, roles and needs. | Journeys belong to real user groups. |
| Must-haves | Prioritise the flows that must work in version 1. | Not every feature is labelled critical. |
| Content and data | Separate copy, media and business data. | Owners and sources are identified. |
| Integrations | List systems, APIs, dependencies and unknowns. | Risks are visible instead of hidden. |
| Governance | Set budget range, timeline, decision makers and KPIs. | The approval process is clear. |
Measure value after launch
Measurement starts before launch. Choose two to four KPIs that come directly from the business case, record the current baseline and assign someone to review them after 30, 60 and 90 days. For Context and Users, favour indicators that show changed behaviour or business outcomes rather than traffic alone.
Add quality indicators around Must-haves and Content and data. A product can convert more while creating more errors or support demand; an automation can save time without improving the experience. Use several dimensions of value rather than a single vanity metric.
Finally, connect Integrations and Governance to operating cost: licences, administration time, tickets, maintenance and required enhancements. After a few months you will have enough evidence to decide whether to invest further, simplify or expand the solution.
- Conversion or adoption
- Time saved
- Quality / error rate
- Cycle time
- Operating cost
- User satisfaction
A reusable brief structure
Are you ready to move forward?
Frequently asked questions
Specify technology?+
Only when a real constraint requires it.
How long should it be?+
A few clear pages are often enough.
Can I add examples?+
Yes, explain exactly what you like about them.
How large should the first release be?+
Large enough to support one valuable journey end to end, small enough to test and improve quickly.
What needs to happen after launch?+
Monitoring, support, ownership and a roadmap are part of the solution, not just the delivery project.