Most project problems come not from a bad specialist but from a task defined in one sentence. "We need a site like our competitor's, only better" is a direction of thought, not an assignment. Everyone reads something different into it, and the difference surfaces at delivery, when fixing it is expensive.
A well-written task is the cheapest project management tool available. It shortens the timeline, lowers the price (because nobody has to price in uncertainty), removes most revisions, and — crucially — makes the result verifiable: there is something to check it against.
This article covers what such a task looks like: how a brief differs from a spec, what belongs in each, how to phrase goals and references, and a ready template you can copy.
A Brief and a Spec Are Different Documents
They get confused constantly, but they are two different stages.
A brief is input from the client. It answers "what do you want and why": the goal, audience, business context, constraints, references, budget and deadline. A brief does not describe a solution — it describes a problem. The client writes it, often prompted by the specialist's questions.
A technical spec describes the solution and is written after the brief. It answers "what exactly will be built": the list of screens or features, behavior, technical requirements, deliverable format, acceptance criteria. The specialist or a manager usually writes it and agrees it with the client.
A simple rule: the brief is "why and for whom," the spec is "what exactly and how we'll verify it." Writing a spec with no brief means locking in a solution without confirming it solves the right problem.
For small tasks (one video, one banner, a landing page) a good brief is enough. For big ones you need both.
What a Brief Must Contain
Nine blocks. Missing any of them forces the specialist to guess — and that is exactly where mismatches appear.
- The goal. Not "we need a website" but what should happen: generate leads, sell online, showcase a portfolio, replace an outdated site. The goal drives every later decision.
- The audience. Who these people are, where they come from, what matters to them, how familiar they are with the subject. Design for twenty-year-olds and design for factory owners are different products.
- What exists today. The current site, social pages, brand guidelines, logo, photos, copy, analytics. The specialist needs the starting point.
- Scope. What exactly must be produced: how many screens, pages or videos, which sections, which features are mandatory and which are nice to have.
- What is NOT included. The most valuable block and the most frequently skipped. State explicitly what is out of scope: "we write the copy ourselves," "no catalog population needed," "no mobile app."
- References. Examples with an explanation of what exactly you like. There is a section on this below.
- Constraints. Brand guide, mandatory colors and elements, legal requirements, technical limits, platforms that must be supported.
- Deadline and budget. Even approximate. A budget is not an invitation to charge more — it selects the class of solution: different budgets buy different things.
- Who makes decisions. One person or a committee? This directly affects the timeline and the number of revisions, and it is better known up front.
How to Phrase the Goal
The most common mistake is stating the goal as a solution. "We need a new design" is already a solution. The actual problem might be that people cannot find the order button, and a new design will not fix that.
A working format: "Right now [what happens], and we need [what should happen], because [why]."
❌ "Build us a modern website"
✅ "Right now clients call to ask about prices because they are not on the site. We need them to be able to calculate the cost themselves, which frees up our sales manager"
❌ "We need Reels"
✅ "We publish a blog but it generates no inquiries. We need short videos that explain the service in 30 seconds"
The second wording lets the specialist propose something better than you had in mind. That is what you are paying for.
References: How to Give Them Properly
"Here are five sites I like" is almost useless information. The specialist cannot tell what you liked: the structure, the colors, the typography, the animation or the photography.
- Explain every reference in one sentence. "I like the calm typography and the amount of whitespace here," "here it is how the catalog is presented, not the colors."
- Give anti-references. Examples of what definitely does not fit narrow the search faster than positive ones.
- Separate the layers. References for style, for structure and for tone of voice should be separate, or they get merged.
- Do not send twenty examples. Three to five with explanations are more informative than a large uncommented collection.
- Do not ask for "the same as our competitor." You do not know whether their site works — they may be complaining about it too.
What if I have no idea what I want visually?
That is normal, and more honest than inventing requirements. In that case your part of the brief is the goal, audience, constraints and examples of what you definitely dislike. Visual direction is the specialist's job — it is what you are hiring for. Ask for two or three rough directions up front (a moodboard or a rough layout of one screen) and pick a direction before detailed work begins. That costs a few hours and saves weeks of rework.
What a Technical Spec Must Contain
A spec is written after the brief, once the solution is clear. Minimum contents:
- A list of what gets built. Pages, screens, videos, features — numbered.
- Behavior. Not just "a contact form" but what happens after submission, which fields are required, where data goes, what the user sees on error.
- Technical requirements. Platforms, browsers, screen sizes, CMS, integrations, performance and accessibility requirements.
- Deliverable format. What you receive: source files, file formats, access credentials, documentation, usage rights.
- Stages and deadlines. What is delivered when, when you give feedback, and how much time is allocated for it.
- Revisions. How many iterations are included, what counts as a revision versus a new task.
- Acceptance criteria. The most important part: by what signs the work counts as complete. Without them, "done" is a matter of mood.
For website projects, much of the spec directly drives the price — the factors are broken down in How much does a website cost.
A Ready Brief Template
Copy it, fill it in and send it to specialists — 20 to 30 minutes.
The task
- What needs to be done (one sentence):
- Goal: right now … , we need … , because …
- How we'll know it worked:
About you
- Company / project:
- What you sell or offer:
- How you differ from competitors:
Audience
- Who these people are:
- What matters to them when choosing:
What already exists
- Site / social profiles:
- Brand guide, logo, colors, fonts:
- Copy, photos, video:
Scope
- Included:
- NOT included:
- Mandatory features:
- Nice to have, if the budget allows:
References
- Like: link + what exactly you like about it
- Dislike: link + why
Constraints
- Brand identity and mandatory elements:
- Technical requirements:
- Legal requirements:
Logistics
- Deadline and whether it is hard:
- Approximate budget:
- Who makes decisions:
- Who answers questions and how fast:
That last point is underrated: projects derail not only because of the specialist but because a clarifying question sat unanswered for a week.
Common Client Mistakes
- "Make it look good." Taste differs, and with no criteria you get the specialist's taste.
- A goal stated as a solution. "We need a redesign" instead of "people cannot find our prices."
- No "not included" section. The main source of conflict at delivery.
- Twenty references with no commentary. The specialist has to guess, and usually guesses wrong.
- Changing requirements after the start without revisiting time and cost. A new requirement is new work, not "a small tweak."
- A committee of five with different opinions. Nominate one person who makes the final call.
- Hiding the budget. It is not clever: with no anchor the specialist proposes the wrong class of solution and you both waste time.
- No acceptance criteria. Without them, "done" turns into endless revisions.
- Silence during the project. Feedback two weeks late costs more than any revision.
If You Are the Specialist and There Is No Brief
The reality: most clients do not arrive with one. That is not a problem — it is part of your job, and it is what separates a professional from someone who just does as told.
- Ask the questions yourself using the list above. A 20-minute call replaces a brief.
- Write the answers down and send them for confirmation. "Here's how I understood the task: …" is already a document that protects both sides.
- Always record what is not included. The cheapest insurance against endless revisions.
- Do not start work before scope and acceptance criteria are agreed.
- Give the client the template. Many will happily fill in a form — they simply did not know what to write.
The rest of the client agreements — payment, stages, revisions — are best settled at the same moment; approaches to finding and running clients are covered in How to get your first clients.
Key Takeaways
- The brief is "why and for whom" from the client; the spec is "what exactly and how we verify it," written afterwards.
- Phrase the goal as a problem, not a solution: "right now … , we need … , because …".
- The "NOT included" section prevents most conflicts at delivery.
- References only work with an explanation of what you like in them; anti-references are often more useful.
- A spec must include deliverable format, revision count and acceptance criteria.
- Name a budget and deadline — they define the class of solution, not the price.
- If the client gave no brief, extract one yourself in 20 minutes and send it for confirmation.
FAQ
What is the difference between a brief and a technical spec?
A brief is input from the client: goal, audience, context, constraints, references, budget and deadline. It describes the problem, not the solution. A technical spec is written after the brief and describes the solution itself: the list of screens or features, behavior, technical requirements, deliverable format and acceptance criteria. Small tasks need only a brief; large ones need both.
What must a brief contain?
Nine blocks: the goal, audience, what already exists, scope, what is NOT included, references with explanations, constraints, deadline and budget, and who makes decisions. The two most commonly skipped are the last one and the "not included" section — and those are exactly what causes conflict at delivery.
Should I state a budget in the brief?
Yes, at least approximately. A budget is not an invitation to charge more — it selects the class of solution, since different amounts buy different things. Without an anchor the specialist proposes something either too expensive or too basic, and both sides waste time. If you cannot name a figure, give a range or state which outcome is critical and what can be sacrificed.
How long does a proper brief take to write?
For a typical task, 20 to 30 minutes with a template. It is the highest-return time investment in the whole project: a clear brief narrows the spread of quotes, reduces revisions and makes the result verifiable. Uncertainty always gets priced into cost and schedule, so half an hour on a brief usually saves days of work.
What to Do Next
Take the template above and fill it in for your nearest task, even one that seems simple. The two most useful fields are the goal phrased as "right now … , we need …" and "what is NOT included."
Send the finished brief to two or three specialists and the difference in their replies will be immediately visible, because everyone will be pricing the same thing. Find specialists in the talent catalog and see real work in the project feed.
Ready to act?
- Find a specialist in the catalog: https://searchtalent.dev/en/talents
- Browse specialists' projects: https://searchtalent.dev/en/projects
- Skills and technologies catalog: https://searchtalent.dev/en/talents/skill
- More articles: https://searchtalent.dev/en/articles
