Start with one observable problem
Describe what happens today, who is affected and what evidence shows the problem matters. For an illustrative multi-location provider, enquiries may arrive through several websites and require repeated manual entry. The initial problem is an unreliable handover, even if the eventual solution includes design, software and automation.
Record the current journey from the first audience question to a completed operational task. Include exceptions, alternative access routes and the people who handle failures. A digital brief should describe the service around the technology, including work that remains manual.
Choose the right combination of services
Brand and design establish how the organisation is understood and how its information is presented. Website work helps a visitor find the relevant service and take a clear next step. Marketing helps the appropriate audience discover that offer. Software, integrations and automation support the work after the initial interaction. Support keeps the resulting service usable as people, systems and requirements change.
Do not assume every project needs a new application or a full rebrand. Compare a process change, configuration of existing tools, an integration and a bespoke build against the same observed problem. Ask prospective suppliers to explain what they would leave alone and why their proposed scope addresses the need.
Write the first-release boundary
- Audience and task: who should be able to do what, and through which channels?
- Current evidence: what observations, enquiry patterns or operational records show the problem?
- Included scope: which pages, workflows, assets and integrations must change?
- Excluded scope: what is explicitly outside the first release, with an appropriate interim process?
- Dependencies: which accounts, supplier interfaces, approvals and internal decisions are required?
- Acceptance: what observable behaviour and evidence will demonstrate that the release works?
Keep assumptions separate from confirmed facts. If access to an external interface has not been established, record an investigation task and its owner before treating the integration as a priced certainty. If the intended use requires specialist clinical, legal, accessibility or security assessment, identify the appropriate review and its place in the delivery plan.
Connect public promises to operational delivery
Trace each public promise into an internal action. A website button that offers a callback needs a receiving team, a supported submission route, a failure message and a way to recognise unanswered requests. A downloadable service sheet needs an owner who can keep its facts current. A dashboard needs agreed event definitions and an explanation of missing information.
Use fictional records and authorised test environments to rehearse complete journeys. Include an unavailable dependency, an incomplete submission and the absence of the normal staff owner. These exercises reveal whether the project has delivered a dependable process or only its visible screens.
Agree ownership and running costs
Name the accountable business role and the people who approve factual content, accept delivered work and operate the service. Establish ownership of domains, accounts, code where applicable, design assets, configuration and documentation through the appropriate agreements.
Compare supplier proposals using the same scope and period. Include discovery, delivery, migration, testing, training, hosting, subscriptions, support and exit arrangements. An estimate should identify exclusions and uncertainty. Keep a decision record so later changes can be assessed against the original need.
Use the brief to make the next decision
End the brief with the smallest useful next step: research a workflow, verify an integration, test a prototype or deliver a bounded release. Name the person responsible, the evidence to collect and the date for reviewing the result.
After launch, compare the agreed measure with its baseline and record other changes that may affect the result. Use enquiries and operational feedback to identify improvements. Expand the service when the evidence and delivery capacity support the next stage, keeping the shared brief current as the scope develops.
Further reading
These primary sources provide additional context for the project decisions above.
Related decisions
Turn the brief into a working service
Kay & Co. can help you scope the work, design the experience and deliver the right solution for your organisation.