A brief gives your team and potential supplier the same starting point. It describes the problem and constraints; the agreed contract and specification determine the final scope. A useful brief can contain open questions without pretending every technical decision has already been made.
Fifteen Questions to Answer
- What business task should the website support?
- Who are the main users, and what are they trying to do?
- Which actions matter most: enquire, book, buy, apply or find information?
- What evidence describes the current problem?
- Which services, products and page types must be covered?
- Who supplies, approves and maintains text, images and translations?
- Who needs to edit content, and what should that workflow allow?
- Which forms, accounts, payments or other functions are required?
- Which systems must connect, and what access or documentation is available?
- Which languages, devices and accessibility needs must be supported?
- What personal or confidential data will be processed?
- Which brand materials or examples are relevant, and why?
- What budget basis and operating costs should be considered?
- Which dates are constraints, and which depend on other work?
- Who approves decisions, and how will the work be accepted?
Describe a user’s need rather than relying on demographic assumptions. If you do not know the available integration or suitable technology, state the question and ask the supplier to assess it.
A Copyable Brief Template
Context: company, offer, current site and reason for the project.
Users and tasks: main journeys, barriers and available evidence.
Launch scope: required page types, functions, languages and content.
Later scope: ideas that are useful but not required for the first release.
Content and brand: owners, source materials, rights and approvals.
Systems and data: integrations, accounts, access, privacy and security needs.
Working arrangements: decision-maker, reviewers, dependencies and communication.
Budget and dates: assumptions, tax basis, recurring costs and fixed constraints.
Acceptance and operation: tests, documentation, training, maintenance and handover.
Make Examples Specific
If you like another website, explain whether the useful feature is its navigation, readable service page or booking flow. An instruction to “make it like Apple” does not describe a requirement. Use examples to explain intent, while respecting other parties’ intellectual property.
For performance, specify the user journey, devices and measurement conditions. For business outcomes, distinguish an intended target from a contractual guarantee; traffic and sales depend on factors beyond the build.
Keep the Brief Connected to Delivery
Review the supplier’s interpretation before contracting. Record what enters the agreed scope and how new requests will be assessed. Not every comment is an additional paid feature: corrections against approved work and new requirements need to be distinguished.
Update the decision record throughout the project. The brief remains useful when it connects the original need with the work that is actually accepted.
Working with Q-Dev
Q-Dev is QA10’s software house offering. Scope, price and schedule are agreed for each project. Four gates cover design, MVP, deployment, and training with the start of maintenance. Each gate has a review meeting and an agreed corrections document; after approval, two further rounds of changes to completed work are available at that gate. Changes may affect timing; price changes only outside the contract scope. The first six months of maintenance are included. Code rights transfer after full project payment.
Describe your website project.
Frequently Asked Questions
How long should a brief be?
Long enough to explain the task, scope and constraints clearly. Completeness and explicit unknowns matter more than a fixed page count.
Must we select the technology?
No. Describe functional, editing, integration and operational needs, then ask the supplier to explain a suitable implementation.
Is the brief a contract?
Not automatically. The parties should specify which documents form the contract and how scope, acceptance and changes are governed.