Defining success before you brief anyone

Success has to be defined as something the finished site either does or does not do, checkable on the day of handover, before you write a single requirement. “A better website” is not a success measure because it cannot be checked; “a visitor can find our opening hours within one tap from the homepage on a phone” is, because on launch day you can open the site on a phone and find out whether it is true.

Why a scope-shaped success measure in a brief fails

The most common failure is defining success as a business outcome the site cannot control on its own — more leads, more sales, more brand awareness. Those are real goals, but a site built exactly to specification can still fail every one of them for reasons outside the build: a downturn in the market, a competitor undercutting on price, a phone number typed incorrectly into a Google listing, a slow response to the enquiries that do arrive. Judging the website’s success by a number it does not fully control means a well-built site can be blamed for a problem it did not cause, and a poorly built one can get credit for a market that happened to be good that quarter.

The distinction that matters: outcome versus artefact

An outcome is what the business wants in the world — more revenue, more bookings, a stronger reputation. An artefact is what the website itself does — displays certain information, performs certain functions, loads within a certain time, is usable on certain devices. A brief can only test the artefact directly; the outcome is downstream of the artefact plus everything else the business does. Stating success at the artefact level is not a lesser ambition, it is the level a brief can actually be checked against.

Examples of the same goal, stated two different ways

Business goal	Untestable version	Testable artefact-level version
Get more phone enquiries	“The website should generate more calls”	“The phone number is visible without scrolling on every page, on mobile and desktop”
Look more established	“The site should feel more professional”	“Every page includes a physical location, a business registration and at least one specific project detail”
Reduce time spent on email quoting	“Save the office time”	“A visitor can submit a quote request with the five details we currently ask for by phone”
Be findable locally	“Rank higher on Google”	“The site loads correctly, has a page per service, and each page names the suburbs served”

The right-hand column is what belongs in the brief. The left-hand column is worth keeping as context for why the project matters, but it should never be the only success statement, because nobody — including the supplier — can be held to it.

A success statement also settles arguments that have not happened yet

Projects rarely fall apart over the initial brief; they fall apart over a disagreement partway through about whether a proposed change is worth the extra cost or delay. A fixed success statement gives everyone involved a shared test to apply to that disagreement: does this change move the site closer to the stated, checkable outcome, or does it not. Without that test, the argument becomes a matter of taste between whoever is in the room at the time, which is a slower and less resolvable kind of disagreement than checking a proposed change against a sentence agreed before the project began.

Write the success statement in the brief before the requirements, not after

Requirements written without a prior success statement tend to accumulate: a feature gets added because it seems useful, not because it serves a defined test. A success statement fixed first acts as a filter — each proposed requirement can be checked against whether it actually moves the site toward that statement, and features that do not can be set aside rather than quietly inflating the brief and the quote along with it.

How many success statements a brief needs

One or two, stated plainly, is enough for most small-business sites. A longer list starts to function as a requirements document rather than a success test, and the two documents do different jobs: what a brief must contain is where the full requirement list belongs.

Checking the finished site against the statement you wrote

The other reason to write the success statement down, rather than keep it as a general intention, is so it can be checked once the site is actually delivered. On the day of handover, open the finished site and try to do the exact thing the statement describes — find the opening hours on a phone within one tap, submit a quote request with the details you specified, locate the business registration and physical address. If the test fails, that is a concrete, checkable defect a supplier can be asked to fix under the original brief, not a vague dissatisfaction that is harder to raise once an invoice has already been paid.

What a defined success statement has to do with briefing a designer

A defined success statement also changes the conversation with a supplier, because it gives a designer something concrete to design toward rather than a general brief document to interpret, and it is a useful constraint to state alongside the budget and timeline rather than instead of them. Small business website design covers what a small-business build typically needs to include, and reading it alongside a fixed success statement makes it much easier to tell which of those inclusions actually serve your test and which are being proposed because they are standard, not because your project needs them.

What to do next

Write one sentence describing what the finished site will let a visitor do that it cannot do today, stated so specifically that you could check it is true on the day the site goes live. Put that sentence at the top of the brief, before the requirements list, and treat every requirement that follows as something that either serves it or does not.