You did not hire a bad designer. You gave them an impossible brief. This is the most common source of creative project failure, and it almost never gets diagnosed correctly because by the time the project goes sideways, both sides are too frustrated to trace it back to the brief.

How to brief a designer is a question most founders search after the relationship has already started to break down. They are on revision round three, the outputs are not what they pictured, and they are convinced they hired the wrong person. The designer is equally frustrated, working from the same brief they were given, wondering why the client keeps rejecting work that matches the direction they were handed.

The problem, in almost every case, is the brief.

What a design brief actually is

A design brief is a written document that gives a designer everything they need to solve a specific business problem through visual work. It is not a list of aesthetic preferences. It is not a description of the deliverables you want. It is the strategic context that makes every design decision possible to evaluate correctly.

When a brief is complete, a designer can answer three questions before starting work: what problem is this solving, for whom, and what does a successful outcome look like? When a brief is incomplete, the designer fills the gaps with assumptions. Every assumption is a revision round waiting to happen.

A brief is also not a one-time document. It is the reference both sides return to when a review session produces disagreement. "This does not match the brief" is a productive conversation. "I just don't think it's right" is not.

Why your brief determines what you get back

Designers work inside the constraints you give them. If your constraint is "make it look professional and modern," you will get a professional and modern result that may have nothing to do with your actual business problem. If your constraint is "our prospective clients are skeptical service buyers who compare three vendors before choosing, and we need to communicate trust and specificity before they scroll past the headline," you will get work that is built around that reality.

Research by Nielsen Norman Group consistently shows that the quality of design outputs correlates directly with the quality of the problem statement given to the designer. This is not a judgment on designers. It is a structural fact: no one can solve a problem they were not told about.

The brief is where strategy becomes direction. Most founders skip the strategy layer and jump to direction, which is how you end up with a design that looks fine but does not convert, does not differentiate, or does not feel right in ways you cannot articulate.

If you are not sure whether your brand direction is clear enough to brief from, the post on [branding for non-technical founders](/blogs/branding-for-non-technical-founders-what-actually-works) covers how to establish that foundation before any design work begins.

What every design brief needs to include

A complete design brief covers six areas. Most briefs founders write cover two.

The business problem: what specific situation are you trying to change? Not "we need a new website" but "visitors are landing on our homepage and leaving without making contact, and we believe the positioning is unclear." The deliverable (website) is what you are building. The business problem is why you are building it.

The audience: who specifically are you designing for? Not "business owners" but "non-technical founders of established service businesses who have tried freelancers before and been burned." The more specific, the more useful. A designer designing for everyone designs for no one.

Success criteria: how will you know the design worked? "It looks good" is not a success criterion. "Visitors can describe what we do in 10 seconds" is. "Our existing clients say it feels like us" is. Give the designer something concrete to aim at.

Visual references with annotations: find three to five examples of design work you find relevant. Not necessarily competitors. Any brand, website, or visual that communicates a quality you want. For each, write one sentence explaining what specifically you are pointing at: "I want this level of visual restraint" or "this navigation feels frictionless to me." References without annotation become mandates. References with annotation become useful signals.

Constraints: timeline, budget, brand guidelines if they exist, technical limitations, stakeholders who have approval rights. These shape the solution space.

Deliverables: the specific outputs expected at the end of the project. Not too early in the brief, but they need to be there.

The 5 mistakes founders make when briefing designers

**Briefing on the output, not the problem.** "We need a homepage redesign" is a deliverable. It is not a brief. The designer needs to understand why the current homepage is failing before they can design a better one. Start with the business problem. Let the designer help determine the solution.

**Using aesthetic language that cannot be acted on.** "Clean," "modern," "professional," and "make it pop" describe a feeling, not a direction. They are not transferable. Two designers will interpret "clean and modern" and produce completely different work, both of which technically match the brief. Replace aesthetic language with specific references and concrete qualities.

**Sending references as mandates instead of signals.** When a founder sends a competitor's website and says "something like this," the designer hears "copy this visual approach." The founder usually means "I want this level of perceived authority." State what the reference represents, not just what it is.

**Delegating brief-writing to someone who was not in the strategic conversation.** Founders often hand brief-writing to a PM, marketing hire, or ops lead who was not part of the original thinking. The designer then works from a document the decision-maker never fully reviewed. When the output comes back, the decision-maker rejects it for reasons that were never captured in the brief. This is the most common and most preventable cause of revision cycles on larger projects.

**Treating the brief as a one-shot document.** Briefs evolve as the project develops and new constraints emerge. A brief that is never updated becomes misleading. The best projects keep the brief as a live document that both sides reference during every review, updated when scope or direction meaningfully changes.

What a bad brief looks like versus a good one

Most founders, writing their first design brief, produce something like this:

"We need a new website. We want it to look clean and modern. Our company does marketing for small businesses. We want it to look professional and be easy to navigate. We liked the design of [competitor site]. Budget is flexible, we just want it done right."

This brief contains a deliverable (website), one vague aesthetic direction (clean and modern), one vague audience (small businesses), one reference without annotation, and a non-constraint on budget. It gives a designer almost nothing to build from. Every decision becomes an assumption.

A brief that works sounds more like this:

"We are a marketing agency for non-technical business owners who have no internal marketing team and no time to manage multiple vendors. Our clients are skeptical — they have been burned before and they compare us carefully against competitors. The website needs to communicate that we are accountable, specific, and not another generic agency. The biggest thing we want visitors to feel in 10 seconds is 'these people understand my problem.' We found [Site A] useful as a reference for restraint and confidence in the layout, and [Site B] for the way they write about their clients rather than their services. Timeline is 6 weeks. Budget is confirmed. Key constraint: the managing director approves the final design and she has strong opinions about the visual direction, so we need her in the review at each stage."

The second brief gives a designer enough information to make decisions without guessing. The business problem is clear. The audience is specific. The success criterion is stated. The references are annotated. The constraints are real.

How to give feedback that does not start the project over

Even with a strong brief, design review sessions can unravel quickly if feedback is not structured well. Most revision cycles happen not because the work is wrong but because feedback was given in the wrong frame.

Evaluate every piece of feedback against the brief. Ask: does this feedback come from the brief, or from personal preference? If a design choice conflicts with a stated goal in the brief, that is valid feedback. If a design choice simply does not match your taste, the question to ask is whether your taste is relevant to the audience you are designing for.

Useful feedback sounds like: "This headline does not communicate the specific audience we described in the brief" or "This layout buries the CTA that we said needs to be above the fold." It gives the designer a specific problem and an anchor in the shared agreement.

Feedback that derails projects sounds like: "I'm not sure, something feels off" or "let's try a completely different direction." Without a reference point, this feedback requires the designer to guess again, which is how you end up in a revision loop that burns hours without producing clarity.

If you find yourself giving feedback in the second category, go back to the brief. Either the brief captures the direction you want and the current design does not match it, or the brief does not capture the direction you want and it needs to be updated before any more design happens.

A design brief template you can use right now

Here is a working template for briefing any brand or website design project.

Business problem: What specific situation are you trying to change? What is not working today?

Audience: Who specifically are we designing for? Describe them by behavior and context, not just demographics.

Success criteria: How will we know this worked? What should a first-time visitor understand, feel, or do?

Visual references: List three to five examples of design work you find useful. For each: what specifically does this reference represent for you?

Constraints: Timeline, budget, brand assets that must be used, stakeholders with approval authority.

Deliverables: The specific outputs expected at the end of the project.

Write this before any creative work starts. Share it with the designer before the kickoff call. Return to it in every review session.

Conclusion

Most design projects that fail do not fail because of the designer. They fail because the brief never gave the designer enough to work from. Revision cycles, misaligned outputs, and "this isn't quite right" conversations are almost always traceable back to a problem statement that was never clearly written.

A brief does not need to be long. It needs to be specific. The difference between "we need a professional website" and "we need a website that earns the trust of skeptical buyers in 10 seconds" is the difference between a designer guessing and a designer solving.

Write the brief before any creative work starts. Review it together. Update it when direction changes. That single habit will do more for the quality of your design work than any other change you can make.

If your brand direction is not clear enough to write a brief from, that is the problem to solve first. [That is exactly what our Brand Foundation process exists to do](/services/branding-marketing). Start there, and every piece of design work that follows becomes dramatically faster and easier to evaluate.