How do you write an application brief?

01

Explain the problem and the project’s objectives

Start with a simple description of your business, the current process and the difficulty you face. Who does what today? Which tools do they use? Where do users lose time or get stuck? This gives the features that follow a clear purpose.

Express objectives as observable outcomes: letting a customer book an available slot, avoiding repeated data entry or giving a team a shared view of requests. If you have baseline measurements, include their sources. Otherwise, explain what needs to be observed during discovery without inventing an expected benefit.

02

Identify users, their roles and their needs

Describe the people who will use the application and what they want to achieve. Base this on conversations, observations or actual requests rather than an imagined profile. The need should be understandable without already prescribing a screen or technical solution.

Then distinguish roles: customer, employee, partner, manager or administrator. Explain the information each person reads, the actions they perform and any approvals required. People who manage content and help users are also part of the product, even if their interface is less visible.

03

Describe journeys and acceptance criteria

Describe important journeys from start to finish. For a booking, this could run from finding a workshop to confirmation, then viewing or cancelling the reservation. Include exceptions: no available places, an interrupted connection, missing information or an unauthorised action.

A useful description connects a user, an action and their goal. Add criteria that let the team verify the result. “Manage bookings” is vague; “a participant can cancel their own reservation and the place becomes available again” describes behaviour the team can check.

04

Define the first release and what can wait

An exhaustive list of ideas is not yet a delivery scope. For each need, ask whether its absence prevents the user from completing the priority journey. Essential features form the first release; the rest can become options or improvements to consider after observing initial use.

In our example, browsing a workshop, booking, receiving confirmation and managing capacity could form a complete initial journey. A loyalty programme or personalised recommendations can wait. A feature whose need is uncertain should be recorded as a question rather than quietly included in a quote as a given.

05

Specify data, connections and usage constraints

List the information the application needs to create, read or import: accounts, content, bookings, documents or history. For each existing source, identify its owner, format and checks to perform. Add the tools to connect and the person who can confirm access options.

Document practical constraints: devices, languages, connection quality, any offline needs and periods of peak activity. Describe what users need to do in those situations. A preferred technology can be noted, but distinguish it from a constraint confirmed by your environment.

Accessibility should be planned during discovery and followed through design and validation. Describe access needs and expected checks, such as keyboard navigation for a web interface, readable content and understandable error messages.

06

Organise timing, approvals and deliverables

A brief should make project dependencies visible. Who provides content? Who prepares access to tools? Who approves designs and tests? A target date is more useful when its reason and the conditions needed to meet it are clear.

Also specify expected deliverables: journeys and designs as appropriate to the engagement, the application, an administration interface, documentation, environment access and launch support. For store publication, identify the accounts needed and responsibilities for preparation and submission. Maintenance and improvements after launch should be described separately.

If a working budget or scheduling constraint has already been set, share it with the team you consult. It helps them propose scope choices. Ask for assumptions, exclusions and options to be presented clearly so you can compare what each proposal actually covers.

07

An application brief structure you can reuse

Use the eight headings below to organise your first document. A few specific facts under each heading are more useful than a long general description. Attach existing materials and mark unknowns as “to confirm”, with a person or a step responsible for clarifying them.

Under each heading, distinguish facts, decisions already made and assumptions. Screenshots of an existing tool, a sample file or a journey sketch can support the text. Use examples suited to the design work without sharing personal information that is unnecessary at this stage.

08

Review the document and update it as the project develops

Before consulting an agency, ask someone who knows the business and someone who did not help write the brief to review it. The first can spot missing rules; the second reveals wording that still needs explaining. Reading it with a few future users also helps compare the proposed journeys with their experience.

During the project, keep a reference version and record decisions that change the scope. A change may be useful, but its effects on the work, dependencies and schedule need discussion. The document can then remain a basis for collaboration through acceptance and a reference for later releases.