Planning & delivery
Write a useful brief for a website or application
A project brief records the decisions needed to design and validate a website or application. Its value comes from clear requirements rather than its length. Start with a concise document, then explore the areas with the greatest uncertainty or operational risk.
Explain the problem and the change you need
Introduce the organisation, the people involved and their existing tools. Describe observable difficulties: requests arriving through several channels, repeated data entry or documents that cannot be found. Include anonymised examples. “Give each request an owner and a status” provides a more useful starting point than “modernise our operations”.
Choose a few priorities and explain how an improvement could be observed. You might need to see a case status without asking a colleague. If no baseline measurement exists, make that clear. Inventing a performance figure would weaken later decisions and make acceptance less meaningful.
Describe roles and complete user journeys
For each role, explain its actions, visible information and permissions. Customers, operators and managers may need different views. Describe a journey from start to finish, including a missing document, a rejected approval or someone leaving the organisation. Exceptional situations often expose requirements that the ideal journey hides.
A scenario can remain plain and practical: a manager receives a request, checks the attachments, returns it if something is missing and assigns it to an operator. Add notification requirements and rules for changes after approval. This narrative becomes a basis for both interface design and acceptance testing.
Inventory information and integrations
List the records involved, such as customers, orders, cases, documents and products. For each, identify its source, essential fields, attachments and the person allowed to update it. Review existing data early. Duplicates, missing values and inconsistent file names can make migration a substantial part of the work.
When another system must connect to the future application, provide its documentation and a technical contact. Define the direction and expected frequency of exchanges. “Synchronise orders” is incomplete without knowing which system owns the record, which statuses are exchanged and how failures will be recovered.
Separate the initial release from later work
Group requirements into launch essentials, later improvements and areas needing investigation. Set a clear boundary for the first release. One country, one case type or a pilot team may be enough to validate the workflow. This makes trade-offs more manageable when budget and schedule do not allow everything at once.
Record known constraints: devices, languages, hosting, authentication, staff availability and external deadlines. Separate actual constraints from preferences. A technology requirement without an operational reason can rule out a useful solution, while an overlooked contractual dependency can prevent an otherwise finished system from launching.
Specify how the result will be accepted
For each critical journey, define sample input and the expected result. An unauthorised user should be denied access; an approved order should reach its destination; an incorrect attachment should produce an understandable message. Name the person who can approve acceptance and the environment in which testing will happen.
Finish with handover requirements: accounts, source code under the agreed terms, operating instructions, backup procedures and training. The brief can evolve, but changes must remain visible. Agreeing amendments in writing prevents different people from continuing to work from incompatible versions of the same requirement.
Your checklist
- Explain a concrete problem and the systems already in use.
- Describe roles, normal journeys and exceptions.
- Provide an anonymised sample of data to migrate.
- Identify dependencies and unresolved decisions.
- Define acceptance criteria and handover deliverables.
Frequently asked questions
Must I choose a technology before writing the brief?
No. Start with tasks and constraints. The technical choice can follow from planning, provided existing systems and future maintenance skills are considered.
Does the brief have to be final?
It needs to be clear enough to commission a defined stage. Discoveries may change it. Maintain a reference version and explicitly agree any changes to scope, cost or schedule.
A project to explore
Blagapro
The Blagapro presentation connects product configuration, artwork approval, order preparation and workshop operations. These handovers illustrate the journeys a project brief needs to explain.
Explore the project