Brief for a product designer: a free template and the 7 questions I ask founders on the first call

Short answer: A good product design brief fits on one page and describes decisions, not screens: who the product is for, the first moment it becomes useful, what already exists, the one metric that matters, the constraints, what is out of scope and who makes the final call. Copy the template below, fill it in 30 minutes, and send it before the first call.

I have read a lot of briefs over 12 years of working with startups. The longest ones are rarely the useful ones. A 20-page document with every feature listed usually means nobody has decided what the product is yet. A half-page brief with a clear "we are not building this" section usually means the founder has done the hard part already, and my job is to make it real.

Here is the template I ask founders to fill in.

What should a product design brief include?

Ten blocks. If you can't answer one of them, write "don't know yet". That is useful information too, and much better than a confident guess.

# Product design brief

## 1. The product in one sentence
[Who] uses [product] to [do what], instead of [what they do today].

## 2. User and job to be done
- Primary user (one specific person, not "everyone"):
- What job are they hiring the product for:
- What they use today instead (app, spreadsheet, chat, nothing):
- Why that is not good enough:

## 3. First value moment
- The moment the user first thinks "ok, this is useful":
- How many steps / minutes it takes to get there today:
- What has to happen before it (sign-up, permissions, data, invite):

## 4. What exists already
- Prototype (Lovable / v0 / Cursor / other), link:
- Figma files, link:
- Live app (store links, web URL):
- Analytics (tool, access available? yes/no):
- User research, interviews, support tickets, reviews:

## 5. The metric that matters
- One number that tells us the design worked:
- Current value (if known):
- Target and by when:

## 6. Constraints
- Deadline and why it is fixed (launch, investor meeting, store review):
- Budget range:
- Team (who builds, who decides, who tests):
- Tech stack and platforms (iOS / Android / web, frameworks):
- Things that can't change (brand, legal, existing users):

## 7. Out of scope
- What will NOT be in this version:
- What we are deliberately leaving for later:

## 8. Decision-maker
- Who gives the final yes:
- Who else has opinions that matter:
- How fast can feedback come back (hours / days):

## 9. References and anti-references
- 2–3 products whose feel or logic you like, and what exactly:
- 2–3 products you do NOT want to resemble, and why:

## 10. Communication
- Your timezone and working hours:
- Preferred channel (Slack, Telegram, email):
- Rhythm (daily async update, weekly call):

How do I fill in the brief without overthinking it?

A few notes on the blocks founders usually struggle with.

The one sentence. If it contains "platform", "ecosystem" or "all-in-one", rewrite it. Name a person and an action.

The job to be done. People don't want your app, they want progress in some part of their life. This idea is old and well explained in Christensen's HBR article on jobs to be done. For a brief, one honest line is enough: what is the person trying to get done when they open your product?

First value moment. This is the block I care about most. Most of my work has been in onboarding, activation and retention, and almost every problem there comes down to the distance between "installed" and "useful". If you don't know where that moment is, say so. Finding it is part of the work.

Out of scope. Founders skip this one. It is the most important line in the document, because a product is defined as much by what it refuses to do.

Anti-references. "Like Linear but warmer" tells me something. "Not like a bank app, not like a dating app" often tells me more.

What should I prepare before hiring a product designer?

Besides the brief, have these ready so the first week is spent on decisions and not on access requests:

• Links to everything that exists, with view access already granted.
• Access to analytics, even read-only. A screenshot of the funnel is a fine start.
• 5–10 real user quotes: reviews, support tickets, interview notes.
• A list of what you already tried and dropped, and why.
• The budget range. Hiding it doesn't get you a better price, it gets you a proposal for the wrong scope.

The 7 questions I ask founders on the first call

I no longer start projects in Figma. Figma makes you think in screens, and a product is something else: what happens, in which order, and what will not be in it. These seven questions are how I get to those three decisions before the first frame.

1. Who is this for, and what do they use today instead?

Why it matters: your real competitor is usually a habit, a WhatsApp group or a spreadsheet. The design has to beat that, not another startup.

Good answer: "Parents of kids aged 7–12 who currently call the child five times a day." Worrying answer: "Everyone who wants to be more productive."

2. When does a new user first get value, and how far is that from the download?

Why it matters: this is where most products lose people. Every step between install and value needs a reason to exist.

Good answer: "When they see the first result, currently after sign-up, three permissions and a tutorial. We think that's too long." Worrying answer: "After they explore all the features."

3. What will not be in this product?

Why it matters: after building with AI tools for a while, I noticed they never say "this is a bad idea". They execute everything. A bad decision built well looks like progress. Somebody has to say no, and I'd rather we do it on the first call than after a month of building.

Good answer: a specific list, ideally with features someone on the team really wanted. Worrying answer: "Let's include everything and see what users like."

4. What exists already, and what did it teach you?

Why it matters: many founders now come with a weekend MVP built in Lovable or v0. Those prototypes are often beautiful and look identical to each other. They are great evidence of intent and a weak spec. I want to know what you learned from showing it to people.

Good answer: "We showed it to 12 users, everyone got stuck at the same step." Worrying answer: "It's basically done, it just needs to look nicer."

5. Which one number will tell us this worked?

Why it matters: design without a metric turns into a debate about taste. One number keeps every decision honest.

Good answer: "Share of new users who complete setup in the first session." Worrying answer: "Downloads", or five metrics at once.

6. What happens when things go wrong?

Why it matters: a demo has to work once, while its author is watching. A product has to work when nobody is: an empty account, a 40-character name, the connection dropping mid-payment. AI made the first, visible part of the work fast. States, empty screens and edge cases did not go anywhere, and that is where users quietly leave.

Good answer: "We haven't thought about it, can you map it?" (honest and fixable) Worrying answer: "Users won't do that."

7. Who gives the final yes, and how fast?

Why it matters: most redesigns don't happen because something looked bad. They happen because a decision was never actually made, and someone with authority saw the work late.

Good answer: "Me. Feedback within 24 hours." Worrying answer: "We'll collect feedback from the investors, the advisors and a few friends, then decide."

Common mistakes in design briefs

• A screen list instead of a problem. "We need 25 screens" says nothing about which five matter.
• "Everyone" as the user. Designing for everyone produces an interface that fits no one in particular.
• No out-of-scope section. Scope will grow by default. Only a written "no" stops it.
• Only references, no anti-references. You get the internet average with your logo on it.
• A vanity metric. Downloads and sign-ups measure marketing. Activation and retention measure the product.
• The prototype as the spec. A working prototype shows what was built, not what was decided.
• No word about interface text. One phrase on a button can move conversion more than a redrawn screen. If copy is "someone else's job", say whose.
• Hidden decision-maker. If the person who will veto the work isn't on the call, the brief isn't finished.

FAQ

What is a design brief for an app or MVP?

It is a one-page document that tells a designer who the product is for, what problem it solves, what exists already, what success looks like and what the limits are. A good brief describes decisions and constraints, not a list of screens.

How long should a product design brief be?

One to two pages. If it is longer, it usually mixes the brief with a feature wishlist. Put the wishlist in a separate document and keep the brief focused on the user, the first value moment, the metric and the scope.

Should I share my budget in the brief?

Yes, at least as a range. Without it, a designer has to guess the scope, and you get proposals that are either far too big or too thin. A range lets them tell you honestly what is realistic.

Do I need a prototype before hiring a product designer?

No, but if you have one, share it. A prototype built in Lovable, v0 or Cursor is useful evidence of what you want. Just don't treat it as finished design: states, edge cases and onboarding logic are usually still missing.

What is a UX design brief example for a startup?

Use the ten-block template above: product sentence, user and job to be done, first value moment, what exists, metric, constraints, out of scope, decision-maker, references and anti-references, communication. Fill each block in two or three lines.

---

Alla Kuchynskaya is a Senior Product Designer and AI Product Designer & Builder with 12+ years in startups, strongest in onboarding, activation and retention. At Findmykids (55M+ downloads) she redesigned onboarding and the parent-child connection flow, contributing to +18% retention. Based in Bali (GMT+8), she works part-time, full-time or per project with teams worldwide. Portfolio: alla.studio, Telegram: @aladesigner.