duiverse_logo
BlogA Bad Brief Is Why Month One Goes Nowhere

A Bad Brief Is Why Month One Goes Nowhere

Ritika Dongol

Ritika Dongol, Product designer

31 May 2026

A Bad Brief Is Why Month One Goes Nowhere

How to brief a design agency is a question most founders only ask after a first engagement went wrong. The brief they submitted described outputs: a new website, a refreshed logo, a redesigned dashboard. The agency delivered those outputs. And the results still missed the mark. The problem was not the agency's execution. The problem was the brief. A brief that describes what you want built without explaining why the current thing is failing gives the agency no information it can actually use to solve the real problem.

Key Takeaways
  • A brief describes the problem, not the deliverable. The agency needs to understand why the current thing is failing, not just what you want built.
  • Define success with a specific, measurable metric before the project starts. This gives the agency a target and prevents scope creep.
  • Share internal context the agency cannot have: customer research, previous attempts, internal constraints, and decisions that are already closed.
  • Document constraints upfront. Constraints discovered mid-project cost time. Constraints in the brief save it.
  • Directional feedback is yours to give. Design decisions belong to the agency. Brief clearly, then let the agency do the design work.

What a Brief Actually Is

A brief is not a requirements document. It is not a feature list. It is not a collection of competitor links with the note "something like this but ours." A brief is a transmission of context. It tells the agency what problem the business is trying to solve, what has been tried before, what success looks like when the project is done, and what constraints cannot be moved. Without that context, the agency is guessing. Experienced agencies will guess intelligently. But guessing still produces worse outcomes than working from clear information.

The brief you write before hiring an agency shapes every decision the agency makes in month one. Month one is when the project direction is set. Course corrections after month one are expensive, slow, and demoralizing for both sides. Getting the brief right is not additional work before the project starts. It is the fastest possible path to a good outcome.

Start With the Problem, Not the Deliverable

The most important section of any brief is a precise description of the problem. Not "our website looks dated" but "our website attracts a high volume of visitors but our sales team reports that prospects who come from the website are consistently the wrong fit." Those two statements point to completely different solutions. The first suggests a visual refresh. The second suggests a positioning and copy problem that no amount of visual polish will fix.

State the business impact of the problem if you can. "Our free trial conversion rate is 2 percent against an industry benchmark of 5 to 8 percent" is more useful to a design team than "users don't seem to be engaging with the product." The more specific the problem statement, the more specific the agency's diagnosis, and the more focused the work. Agencies that receive vague problem statements fill the gap with assumptions. Those assumptions are often wrong.

Define Success Before the Project Starts

A brief without a success metric is a brief without a destination. Both the client and the agency need to agree, in writing, on what a successful outcome looks like before work begins. Not "the design should feel more premium" but "the redesigned onboarding flow should reduce drop-off between signup and activation by 30 percent within 90 days of launch." The first statement is a preference. The second is a goal the agency can design toward.

Defining success before the project starts also prevents scope creep. When the metric is agreed upfront, every proposed addition to the project can be evaluated against a single question: does this move the needle on the agreed metric? If the answer is no, it is scope creep. If the answer is yes, it is worth discussing. Without a defined metric, every idea sounds reasonable and the project expands until the budget runs out.

Share Context the Agency Does Not Have

The agency you hire does not know your customers, your internal politics, your sales team's objections, or the specific reason a previous redesign failed. You do. That context belongs in the brief. Include any customer research you have: survey results, sales call recordings, support tickets, churn reasons. Include the history: what has been built before, why it was changed, what the previous agency missed. Include the constraints: decisions that have already been made and are not being reopened.

Most founders share none of this because it feels like internal information. It is. And the agency needs it to do good work. A design team that understands why the last approach failed will not repeat it. A design team with no history will often arrive at the same solution and repeat the same failure. Context is not a bonus. It is the raw material of good design decisions.

Be Clear About What Is Not Changing

A good brief defines scope in both directions: what is in scope and what is not. This is particularly important for branding and identity projects. If the company name is not changing, say so. If the core color palette must stay within the existing brand system, say so. If the engineering team has constraints that limit what can be built in the front end, document them. Constraints that are discovered mid-project cost time. Constraints documented upfront save it.

The same applies to decisions that have already been made internally. If the leadership team has agreed that the product is positioning toward enterprise buyers and that decision is not up for debate, say that in the brief. If the agency challenges a closed decision, the project stalls while internal alignment is rebuilt from scratch. Closed decisions belong in the brief so the agency can design within them, not around them.

The Difference Between Direction and Design Decisions

The final thing a brief must clarify is who has final decision authority. There is a meaningful difference between giving an agency direction and making design decisions yourself. Direction is yours: the problem, the audience, the constraints, the goal. Design decisions belong to the agency: the visual language, the layout, the interaction model, the typographic system. Founders who make design decisions during a project are doing the agency's job while also paying the agency to do it.

This does not mean feedback is off limits. Feedback on whether a design is solving the right problem, reaching the right person, or communicating the right message is direction. Feedback on whether a button should be blue or green is a design decision. Brief clearly, give directional feedback, and let the agency make the design calls they were hired to make. That division of responsibility is what makes the engagement fast and the outcome good.

A brief is not paperwork. It is the first design decision you make on any project. The quality of everything that follows depends on it.

Frequently Asked Questions

What should a design agency brief include?
A design agency brief should include a precise description of the problem, the business impact of that problem, a defined success metric, relevant customer research or history, constraints that cannot be moved, and clarity on which decisions are already closed. Briefs that describe desired outputs without explaining the underlying problem give the agency nothing useful to work from.
How long should a design agency brief be?
A brief should be as long as it needs to be to communicate the problem, the context, and the constraints clearly. For most projects, that is one to three pages. Length is not the measure of a good brief. Specificity is. A one-paragraph brief with a precise problem statement is more useful than a ten-page document full of vague preferences and competitor references.
What is the most common mistake in a design brief?
The most common mistake is describing the deliverable instead of the problem. 'We need a new website' is a deliverable. 'Our website attracts the wrong buyers and our sales team spends the first call correcting misaligned expectations' is a problem. The agency can solve the problem. They can only build the deliverable. The first produces better outcomes.
How do you define success in a design brief?
Define success with a specific, measurable outcome tied to business performance: a conversion rate target, a drop-off reduction, a response time improvement. Avoid subjective definitions like 'it should feel more premium.' Measurable goals give the agency something to design toward. They also prevent scope creep by providing a filter for every proposed addition to the project.
Should you share previous work or competitor examples in a brief?
Competitor examples are useful for communicating visual direction or market context, not for defining the target outcome. Share them with specific notes on what you are pointing to and why, not as a general reference to 'do something like this.' Previous work and failed attempts are more valuable: they tell the agency what has been tried, what the constraints are, and what to avoid.
What is the difference between a brief and a scope of work?
A brief explains the problem and the context. A scope of work defines the deliverables, timeline, and cost. The brief comes first and informs the scope. Agencies that skip the brief and go straight to scope often propose the wrong deliverables. A brief allows the agency to confirm they understand the problem before committing to a solution.
How do you know if your brief is specific enough?
Read the brief and ask: could this describe any business in my category, or does it describe my situation specifically? If a competitor could submit the same brief without changing a word, it is not specific enough. A good brief contains details that could only come from inside your business: specific metrics, specific failures, specific constraints, and a specific definition of what success means.
- Product OS by Ayush Lagun

Better product decisions for founders.

A weekly briefing on product clarity, planning trade-offs, and judgment calls, including when AI helps and when it doesn't.

Decision-focused
Founder-led
Every Wednesday
background grid

Ready to scale your product the right way?

We align product, UX, and engineering to support real growth.


Made with ♥ in Nepal duiverse ©2026

duiverse logo