How to Brief a Designer (and Get Better Work Back)

The quality of a design brief is the single biggest predictor of the quality of the design you get back. Designers can only solve the problem you describe — and most briefs describe the wrong problem, or no problem at all.

Bad briefs take two forms. The first is the underbrieft: "we need a dashboard redesign." No context, no users, no constraints, no definition of what good looks like. The designer invents all of those and produces something that is technically a dashboard but has nothing to do with your actual situation.

The second is the overbrieft: a 10-page document that specifies exactly what the interface should look like, where every element goes, and what color everything should be. This is requirements documentation, not a brief. It leaves no room for design thinking and turns the designer into a Figma operator.

Good briefing is a skill. Here's how to do it.

---

What Belongs in a Design Brief

A strong design brief answers six questions. You don't need a formal template — a well-structured Notion page, a short document, or even a well-written Slack message works. The information matters, not the format.

1. Context: What is this product and who uses it?

Before any design decision can be made, the designer needs to understand the product. Not the entire product history — just what's relevant to this task.

For a new feature brief: what part of the product does this live in? Who accesses this area? What does the user's job-to-be-done look like in this part of the product?

For a landing page brief: what is the company's positioning? Who is the primary buyer? What is the single thing the page needs the visitor to do?

A designer working on your product for the first time needs more context than one who has been working with you for months. Calibrate accordingly, but don't assume existing context if it hasn't been shared.

2. The User: Who is this for and what are they trying to accomplish?

This is where most briefs are weakest. Founders describe features without describing users. "We need a reporting module" tells the designer nothing. "Our primary user is a Head of Revenue at a 50-person B2B company. They need to pull weekly pipeline reports and share them with their CEO, but currently have to export to Excel and format them manually — which takes 2 hours each Friday" tells the designer everything they need to make good decisions.

If you have user research, quotes, or recordings — share them. If you know specific users who represent the target audience — describe them. If you're not sure who the user is — say that, and that uncertainty becomes part of what the designer needs to help you resolve.

3. The Problem: What is not working, and why does it matter?

Describe the problem, not the solution. This is the core discipline of a good brief.

"We need to add a sidebar navigation" is a solution. "Users are getting lost in the product after the first session and can't find features they've already discovered" is a problem.

The difference is significant because the designer may propose a solution you haven't considered — one that's better than what you imagined. If you brief the solution, you eliminate that possibility.

Describe:

• What is currently happening that shouldn't be?
• What are users unable to do that they should be able to do?
• What is the impact of this problem (churn, support volume, low adoption)?

4. Not Doing: What is explicitly out of scope?

"Not doing" is as important as "doing." It helps the designer avoid rabbit holes and focuses the work.

Common examples:

• "This doesn't need to work on mobile — desktop only for now"
• "We're not redesigning the navigation — just this screen"
• "We're not building this for enterprise tier users — focus on SMB"
• "We're not changing the underlying data model — the design needs to work with what we have"

Without "not doing," designers will often explore the right territory but also spend time on adjacent areas that aren't the priority.

5. Constraints: What must the design work within?

Constraints are not the enemy of good design — they're the definition of the problem space. Share all relevant constraints:

• Technical: "Our frontend is React. The component library we're using is [X]. We can't use custom animations."
• Timeline: "We need this in Figma by Thursday because engineering starts building Friday."
• Visual: "We have an existing design system — the design should use it rather than introduce new patterns."
• Business: "We can't show pricing in this flow — sales needs to handle that conversation."

A designer who doesn't know about a constraint will design around it freely and produce something that can't be built. That wastes both of your time.

6. Success: What does a good outcome look like?

Be specific about what "done" means and what "good" means. Both matter.

"Done" is delivery: Figma screens ready for engineering review, reviewed and approved.

"Good" is quality: the design needs to test well with two existing customers before we hand it to engineering. Or: the page needs to load fast, so heavy illustration is out. Or: the VP of Sales needs to be able to understand the UI without any training.

If you have a metric you're trying to move — activation rate, demo conversion, time-to-first-value — say it. Designers make different decisions when they know how their work will be evaluated.

---

Common Briefing Mistakes

Being too prescriptive about the solution

"Make a modal with a two-column layout, dropdown on the left, button on the right, blue CTA" is not a brief — it's a specification. You haven't told the designer what problem this is solving, who the user is, or what success looks like. The designer can execute this exactly, and you might still get something that doesn't work.

Give the designer the problem. Let them propose the interface.

No context about the actual users

"Our users are SaaS companies" is not enough. Age range, job title, technical level, how often they use the product, on what device, in what context — these details change design decisions. A finance operations analyst using a dashboard daily at a desktop is designed for differently than a CMO who checks a summary view once a week on their phone.

If you don't know the user well, be honest about that. "We haven't done formal research but our best understanding is..." is more useful than vague audience descriptions.

Attaching too many reference images and saying "like this"

References are valuable — they help calibrate visual direction and functional expectations. But "like this" said about 12 different references sends conflicting signals. Each reference example has dozens of design decisions embedded in it, and if they conflict with each other, the designer can't satisfy all of them simultaneously.

Use references intentionally: say what you like about each one and why. "This landing page hero works for us because the value proposition is clear in the first 5 seconds" is useful. "This is the vibe" is not.

No timeline

A brief without a timeline will be deprioritized against briefs that have one. Tell the designer when you need this — not just "ASAP," but a specific date and why it matters (engineering starts Friday, investor meeting next Thursday, launch next week).

Briefing by committee

When multiple stakeholders contribute to a brief without a single decision-maker, the designer gets conflicting signals. "The CEO wants X but the VP of Product wants Y" is a problem you need to resolve before briefing, not after. Unresolved internal disagreements land in the designer's lap as conflicting feedback, which produces worse work and slower iteration.

One person should own the brief and be responsible for resolving internal disagreements before the brief goes to the designer.

---

How to Share References Without Boxing the Designer In

References are good. Prescriptive use of references is not.

The right way to use references:

Share with commentary. "This sidebar pattern from Linear works for us because it stays out of the way until you need it. We want the same sense of space in our nav, but our structure is different so don't copy the layout directly."

Separate inspiration from specification. "These are screenshots of products we admire for their visual quality — we want our product to feel this polished. They're not structural references." vs. "This is specifically the table pattern we want to follow because our data structure is similar."

Allow for "what not to do" references. "This is our current design. What doesn't work: the sidebar is too dominant, the primary action gets lost, and the empty state is confusing. We want to solve these specifically."

The goal is to give the designer a direction, not a destination. A good designer will use your references to understand your preferences and then find solutions you haven't thought of yet.

---

What to Leave Out of a Brief

Some things that feel helpful in a brief actually add noise:

Detailed UI specifications. If you're writing layout specs (put this 16px from the edge, this button is 44px height), you're doing the design work. Write the constraint if it's a real constraint ("the sidebar must not exceed 280px because of our existing layout"), not if it's a preference.

Long company history. The designer doesn't need the full origin story. Three sentences of relevant context is enough.

Every feature request at once. A brief for one thing is a brief. A brief that lists 12 problems is a product backlog. Prioritize, then brief.

How you think the design should look. Share references. Describe the feel you want. But don't describe the interface — that's the designer's job.

---

A Short Brief That Works

Here's an example of a brief that gives enough to do good work without over-specifying:

Task: Redesign the onboarding flow for new users (first login through first meaningful action).

User: B2B SaaS buyer who evaluated and signed up after a demo. Technical enough to set up integrations, but hasn't used our product before. May be setting up on behalf of a team.

Problem: 60% of new signups don't reach the first key action (connecting their first integration) within 7 days. We've talked to some of these users and the feedback is: they land in the product and don't know where to start. There's no guidance about what to do first.

Not doing: Not changing the connection UI itself — just the flow that leads users to it. Not mobile — desktop only.

Constraints: Must use our existing component library. Engineering has 2 weeks to build after Figma handoff.

Success: A user who follows the new onboarding flow should complete their first integration in under 15 minutes without any support intervention. Internally, we want to review this with our two most experienced customer success managers before handoff.

Timeline: Figma screens ready for review by next Friday.

That's 180 words. It tells the designer everything they need and leaves them room to solve the problem.

---

Briefing for Async Design Work

If you're working with a design subscription or a remote designer in a different timezone, the brief is even more critical because there's no real-time discussion to fill in gaps. Write your brief assuming the designer will start work without being able to ask you clarifying questions first.

For async work specifically:

• Include screenshots or Loom recordings of the current state if relevant
• Be explicit about the response format you want (wireframes first, or straight to high-fidelity?)
• State your feedback deadline so the designer knows when to expect it

Designpixil's design subscription is built for async work — and the first thing we ask new subscribers to do is walk through how to write a brief that sets up the work for success.

---

Frequently Asked Questions