outsource
Searching for a design brief example usually means one of two things. Either a designer has asked for a brief and there is no template to hand, or a previous project went sideways and the post mortem pointed at the brief. The second case is the more common one, and it is the reason most blank templates do not help. A template asks for a list of headings. The project failed because two people had different pictures of what "modern" meant, and no heading catches that.
A brief is a decision record. Everything in it should be something that has been decided, by a named person, before work starts. Anything that has not been decided belongs in a short list of open questions with an owner and a date attached. That distinction is what separates a brief that holds up from a document that gets filed and ignored by week two.
Here is a brief for a small project, written at the level of detail that actually prevents rework. The subject is a marketing site for a business software product, five pages, working with one external designer.
Project. Rebuild the five public pages of the product site: home, features, pricing, comparison, contact. Existing content is mostly reusable. The application interface behind the login is out of scope.
Why now. The pricing page is the most visited page and the one people leave from. Sales calls repeatedly start with a question the pricing page was supposed to answer.
Decision maker. One named person signs off. Two other people review and can raise objections, but they do not approve.
Audience. Operations leads at companies of ten to fifty people who are comparing three or four tools in the same week. They arrive from search, they skim, and they have already seen competitors.
What success looks like. Fewer sales calls that open with a pricing question. A visitor can state the price for a team of eight without contacting anyone. Both are checkable within a month of launch.
Constraints. The existing typeface and logo stay. Load time on a phone must not get worse. The pages have to work in Japanese and English with the same layout, which rules out designs that depend on line lengths being similar.
Out of scope. Logo, brand colors, the blog template, anything behind the login.
What is supplied. Final copy for all five pages, a photo library, brand color values, access to the current analytics.
What is expected back. Desktop and phone layouts for five pages, a component list, and the source file. Not a working site.
Dates. First layouts for home and pricing in two weeks. One round of consolidated feedback within three working days of delivery. Final files four weeks from start.
Open questions. Whether the comparison page names competitors directly. Owner: the named decision maker. Answer needed before the second round.
That is roughly one page. The value is not in the headings, it is in the fact that each line names a decision and, where a decision is missing, names who owes it and when.
Run any brief against these. If one has no answer, that is where the project will lose time.
This is the question skipped most often and it costs the most. When three people can approve, the designer receives three contradictory rounds of feedback and resolves them by averaging, which produces work nobody likes. Name one approver. Give everyone else the role of reviewer, in writing, in the brief.
"Refresh the site" is not a problem. "Visitors cannot work out what they will pay" is. A brief that names an observable problem gives the designer something to argue with. A brief that names a deliverable gives them nothing to push back on, which sounds efficient and means the first review is the first time anyone thinks critically about the direction.
Constraints are a gift to whoever is doing the work. Existing typeface, an accessibility standard, a component library already in use, a page that has to keep its URL. Stating these up front removes entire branches of exploration. Leaving them out means discovering them in review, after the exploration has been paid for.
Scope creep rarely arrives as a request. It arrives as an assumption. The designer assumes the logo is fair game. The client assumes the email templates were included. Both assumptions are cheap to kill with a short list of things nobody is touching.
A brief with one date at the end has no dates. It needs the review points: when the first work appears, how long feedback takes, how many rounds are included. Feedback turnaround is the item worth negotiating hardest, because a delivery that sits for a week while five people find time to look at it moves every date after it.
Covered in its own section below, because this is where most briefs become decorative.
A brief that ends with "modern, clean, professional" has not stated criteria. Those words describe a feeling, and feelings cannot be reviewed, only reacted to. The result is a review meeting where the loudest reaction wins.
Three kinds of criteria hold up.
The first is behavioral. Something a visitor should be able to do, stated as an action. State the price for a team of eight without contacting anyone. Find the security page from the home page in one step. These can be tested by handing the layout to someone who has not seen it and watching.
The second is comparative. A set of three existing sites, with one sentence each on what specifically is being pointed at. "The way this pricing table handles the per user plus add-on case" is a criterion. "This general vibe" is not, because two people reading the same site pick different things to admire.
The third is exclusionary. A short list of things the result must not do. No carousel on the home page. No modal on first visit. No stock photography of people in meeting rooms. Negative criteria are unusually effective because they are unambiguous, and they are easy for a client to write honestly.
Where a subjective judgment genuinely applies, say so and name who makes it. "The approver decides whether the tone fits the brand, and that judgment is final" is an honest line in a brief. It is far better than pretending a taste call is an objective standard.
These four names get used interchangeably, which causes real confusion when a client and a supplier each mean a different document. The practical distinctions:
| Document | Answers | Written by | Typical length |
|---|---|---|---|
| Design brief | What is being designed, for whom, under what constraints, judged how | Client, often with the designer's help | One to two pages |
| Creative brief | What the message is and what feeling it should produce | Marketing, for a campaign | One page |
| Project brief | Why the project exists, what it costs, who is involved | Whoever is sponsoring the work | Two to four pages |
| Scope of work | What is delivered, when, for how much, with what revision limits | Supplier, attached to a contract | Varies, often several pages |
The overlap between a design brief and a scope of work is where disputes happen. A brief describes intent, a scope of work describes obligation. When only one of the two exists, whichever document exists ends up being read as the contract. Small projects can reasonably merge them, but the merged document has to include the commercial terms explicitly rather than implying them.
A design brief is also not a specification. A specification says what to build. A brief says what problem to solve and leaves the how to the person with the skill. Briefs that drift into specification produce work that matches the instructions and misses the point, and the client has no grounds to complain because they wrote the instructions.
Length is not a virtue here. Four things can be cut from most briefs.
Cut the company history. A paragraph on what the business does is useful. Three paragraphs on the founding story is padding that pushes the constraints onto page two, where they will not be read.
Cut the mood board that has not been discussed. Images attached without a sentence explaining what is being pointed at generate the wrong kind of alignment. Whoever is doing the work will pick a different feature of the image than the person who chose it.
Cut anything phrased as a preference when it is actually a requirement, and vice versa. "It would be nice if" attached to something mandatory is how mandatory things get dropped. Sort every line into must, should, or nice to have, and accept that a short must list is a sign of a good brief.
Cut the technical implementation detail unless it constrains the design. Which framework the site runs on usually does not. Which component library the team already has usually does, because reusing it saves a week.
A brief that lives in an email attachment is dead on arrival. Within two weeks there will be three versions, and the review meeting will be held against the wrong one.
Two practical rules help. The brief lives in one place with one address, and the open questions live where the work lives. The second half matters more than it sounds. Open questions in a document get read once. Open questions attached to the task they block get seen every time somebody looks at the task, which is what makes them get answered.
The same applies to feedback. Comments collected in a chat thread are impossible to reconcile against a delivery two rounds later, because chat has no notion of which version was being discussed. Comments attached to the item being reviewed stay attached to it. Teams that keep briefs, schedules and review comments in the same place rather than spread across a document tool, a chat tool and a calendar tend to notice the difference at the second round, not the first. Putting a brief, a schedule and the review conversation on one board removes the reconciliation work entirely, and it is also the reason teams comparing a document tool with a work tracker often end up looking at both kinds of tool side by side.
One more habit worth adopting: record decisions as they change the brief, in the brief, with a date. Six weeks into a project the question "was this agreed" comes up constantly, and an answer of "yes, on the fourteenth, by the approver" ends the conversation in a sentence.
Take the last brief that was sent and add two things: the name of the single person who approves, and three criteria a visitor's behavior can be measured against. Those two additions prevent more rework than every other change on this list combined.
Then move the brief out of email. Keeping the brief, the review comments and the dates in the same place as the work is what keeps them consistent, and Pinateca is free for up to five people and ten boards if a shared board is the missing piece.
One to two pages for most projects. Length is not the measure of quality, and briefs longer than that tend to bury the constraints behind background material. If it runs long, the usual cause is company history and mood board images that have no explanatory sentence attached.
The client owns the decisions in it, but the best briefs are written with the designer's help. A common and effective pattern is that the client writes a first draft, the designer returns it with the gaps marked, and the client fills those in before work starts. Gaps found at that stage are cheap. The same gaps found in review are not.
A brief describes intent: the problem, the audience, the constraints, how the result will be judged. A scope of work describes obligation: deliverables, dates, price, and how many revision rounds are included. When only one exists, it gets read as the contract, so small projects that merge them should state the commercial terms explicitly.
Use three types. Behavioral criteria describe something a visitor should be able to do. Comparative criteria point at specific features of specific existing work, with a sentence on what is being pointed at. Exclusionary criteria list what the result must not do. Where a genuine taste call remains, name the person who makes it and say the judgment is theirs.
Change it in place, note the date and who approved the change, and confirm what it does to the dates. Most schedule arguments late in a project are really arguments about whether a change was agreed. A dated line in the brief settles that in one sentence, which is why the brief needs to live somewhere with a single address rather than in an email thread.