Process

The project brief: how to describe a task so it's understood

A brief isn't a list of pages or a wish to "make it look nice". What it should contain so that contractor and client understand the scope of work the same way.

Most conflicts between client and contractor begin not with bad work but with the two sides understanding the task differently. One meant one thing, the other built another, and formally both are right — it wasn't in the document. A project brief exists precisely so that such discrepancies surface before work begins, not at acceptance.

What a brief is and what it isn't

A brief is a description of what should be produced, in wording that can be verified. The key word is verified. If you can't say unambiguously "done" or "not done" about an item, it's not a brief item but a wish.

What a brief isn't:

  • Not a list of pages. A list of "home, about us, services, contacts" doesn't describe a single task. It doesn't say what a person does on those pages or what counts as the work being done.
  • Not a design mock-up. A mock-up shows what the result looks like. A brief explains why it should look that way and what happens in states the mock-up doesn't show: an empty list, a loading error, a product name that's too long.
  • Not a set of taste requirements. "Modern", "premium", "like a competitor's but better" — these aren't requirements. They can neither be fulfilled nor disputed.

"Make it look nice" doesn't work for a simple reason: beauty isn't a property of the result but the opinion of a particular person on a particular day. If the acceptance criterion is someone's opinion, acceptance turns into endless negotiation. What replaces it: a described task, a described audience and references with an explanation of what exactly you like about them — structure, density, typography, the style of illustrations.

Mandatory sections

The business goal

It all starts not with the website but with why it's needed. Collect service requests. Relieve the sales team of repetitive questions. Sell products without a manager's involvement. Present the company to tender committees. The goal determines everything else: from the structure to which metrics will later count as success.

It also helps to state the negative — what the website shouldn't do. That constraint saves more money than any feature list.

User scenarios

The most useful part of a brief. A scenario is a short description of a path: who arrived, from where, what they want to do, what steps they take, how it ends.

For example: "A client arrives from a search for the service name. Reads the description, looks at the scope and process, leaves a request with a phone number and a convenient time to call. The request goes to the department's email and the CRM." In this form it's immediately clear which pages are needed, which fields go in the form and where the data goes.

There are usually few scenarios — three to five main ones and a few secondary ones. If a scenario can't be described, the task hasn't been thought through yet, and development won't clarify it.

Scope

Everything countable is recorded here: the number of page types, language versions, user roles, email templates. Types, not instances — ten service pages on one template and ten unique pages differ in effort many times over.

Responsiveness should be specified separately: which devices are supported, whether there's separate behaviour for mobile, which browsers are considered targets.

Integrations

Every external system is a separate risk, and it should be described concretely: what the system is, which direction data flows, whether it has a documented interface, who provides access and a test environment. Payments, CRM, inventory, delivery services, messengers, analytics — all of these often turn out to be harder than the website itself.

If an integration is required for launch, say so directly. Otherwise there's a chance of getting a finished website that can't be switched on.

Who provides what

The section forgotten more often than others, and the one that derails timelines most reliably. Texts, photos, the logo in source files, legal documents, access to the domain and hosting, payment provider details, a contact person to answer questions. Every item needs an owner.

A project doesn't stall because of a complex feature. It stalls because for three weeks nobody is available to write descriptions of twelve services.

How to pin down the boundaries of the work

The boundary is where the contractor's responsibility ends. It's described not in general terms but as a list of what's not included: content beyond the agreed volume, post-launch improvements, brand identity development, photo shoots, running ads, copywriting.

Next you need a change mechanism. Requirements always change, and that's normal; what's not normal is pretending they don't. The agreements should state how a new requirement is recorded, who assesses its impact on timeline and cost, and who makes the decision. It's worth discussing this in advance, while nobody is emotionally invested in a particular change.

Likewise, agree in advance on the format for reviewing interim results: in what form they're presented, who on the client side is entitled to give feedback and how that feedback is collected. Feedback from five people in five messengers is a guaranteed conflict, and not the contractor's fault.

On the level of detail

An overly detailed brief does as much harm as a superficial one. If the document describes the colour of every button, the work turns into redrawing the document rather than solving the task. A sensible line runs like this: the client describes what and why; the contractor is responsible for how.

There are exceptions — places where the "how" has legal, financial or technical consequences: personal data processing, document retention requirements, a specific version of the platform the rest of the company's infrastructure runs on. Such things are fixed firmly.

If the task is large and not fully understood, it's more honest to split it: first describe and build the core, then refine the rest along the way. For complex systems this is often the only workable path — we discuss it in the section on web applications.

Checklist: check your brief

Go through these points before sending the document to a contractor.

  1. The business goal is stated, not a wish list.
  2. The main user scenarios are described — the full path from entry to result.
  3. Page types, roles and language versions are counted.
  4. All external systems are listed, with who provides access to them.
  5. Every material — texts, photos, documents — has an owner and a deadline.
  6. What's not included in the work is written down.
  7. The procedure for making changes and collecting feedback is described.
  8. For every item, you can answer "done" or "not done" without arguing about taste.

If there's no answer on some point, that's no reason to postpone the project. It's a reason to discuss it with the contractor before signing: a good contractor will help finish the brief and tell you where you're creating problems for yourself. You can discuss your task via the contact form.