How to write a website or app project brief

Describe an observable outcome

“A modern website” describes a preference, not a deliverable. A clearer goal is: visitors find three services, explore an example and submit an enquiry from a phone. For an app: an operator records an issue, a manager assigns it and the person who raised it sees the new status.

Choose one main outcome. Separate technical behaviour from business results. A working form can be tested; future customer numbers cannot be guaranteed by development alone.

Map people, data and journeys

List roles and one journey for each. Identify permissions, data sources, ownership and missing-data behaviour. Use fictional examples in an initial enquiry, without passwords or personal records.

• Who uses the product, on which devices and how frequently?
• Which action starts the process and which completes it?
• What data is read, edited or exported?
• Which existing tools must communicate with the product?

Separate the first release from later ideas

Make two lists: essential for the first usable release and desirable later. Essential should have a concrete consequence: without assignment, nobody knows who handles a request. An additional reporting view may wait.

For a 3D website, describe the main interaction and available assets. A visual reference is not permission to copy text, images or brands. Identify ownership and anything that needs producing or purchasing.

Agree five acceptance checks

Describe checks a person can perform: open a page on a phone, reach contact without a mouse, pause motion, enter invalid data and receive an explanation, or find a record after signing in again. Include only relevant checks.

Add agreed devices and browsers, one valid example and one invalid example. Name who approves delivery and allow time to collect feedback. This reduces ambiguity about what finished means.

Budget, materials and maintenance

State a budget or limit and explain any deadline. List text, images, models, translations and access you can provide, with realistic availability dates. Ask for one-off and recurring costs, included revisions and out-of-scope changes to be separated.

At handover, clarify account ownership, source code, instructions, backups and responsibility for updates. A brief does not replace an agreement: it provides information for a verifiable proposal. Retain the version shared with your supplier.

Explore an example

ImportGuard documents synthetic inputs, anomalies and verifiable outputs. It illustrates acceptance even if your own project solves a different problem.