How to brief a product designer so the first concept is right

The first concept a designer sends back is right or wrong in proportion to the brief, and most briefs fail the same way: they describe a solution. "Add a filter dropdown to the reports page" tells the designer what to draw and nothing about why, so they draw it, and the third round of revisions is where you both discover that what you needed was a saved-view system.

A good brief for a single screen or flow is five short parts and takes about ten minutes to write. This is the shape we ask for on every request, and it works just as well for an in-house designer or a freelancer.

1. What the screen is for

One or two sentences on the job the screen does for the user, in the user's terms. Not "the reports page", but "where an account manager checks whether a client's usage dropped this week, and finds out why".

This is the sentence the designer will design against. If you cannot write it, the screen is not ready to be designed, and that is useful to know before anyone opens Figma.

2. Who uses it, and when

Who the person is, what they are in the middle of, and what device they are on. "Account managers, three or four times a week, usually from a laptop between calls, occasionally from a phone when a client emails them."

Include the realistic worst case: the account with 400 sub-accounts, the user who has never set anything up, the Arabic-speaking customer on a right-to-left layout. Designers can only design for the states they know about.

3. What done looks like

The outcome, as something you could check. "The account manager can see the drop, see which feature caused it, and start an email to the client from the same screen, in under a minute." If there is a number you care about, write it down; if there is not, say so rather than inventing one.

This is also where you say what you are going to do with the design: build it next sprint, show it to investors, test it with five users. Each of those wants a different level of finish.

4. The constraints

Everything the designer must work inside:

• The design system. Which components exist and where the file is. Whether new components are welcome or should be avoided.
• The platform. Web, iOS, Android, all three. Minimum viewport. Anything the engineering stack cannot do cheaply.
• The data. What is actually available. A screen designed around a field the API does not have is a screen designed twice.
• Languages. Whether the screen ships in Arabic, and if so whether there is existing Arabic copy to work from.
• Brand. Anything that is fixed: the palette, the type, the tone of voice, the legal line that has to appear.

5. What you already know

What you have tried and why it did not work, what the support tickets say, what must not change because a customer depends on it. Two or three bullets. This is the part that saves a round of revisions, because it stops the designer from re-proposing the thing you rejected in March.

An example brief

A brief for a settings page, written in the five parts. It is about 150 words, which is typical.

For: where a workspace admin manages who is in the workspace and what each person can do.

Who, when: admins, a few times a month, on desktop, usually after someone joins or leaves. Workspaces range from two people to about 300. Roughly a fifth of our admins use the Arabic interface.

Done: an admin can invite someone, change a role and remove someone without leaving the page, and can tell at a glance who has not accepted their invite. We will build it in the next sprint.

Constraints: use the existing table and dialog components in the Figma library, linked below. Web only, minimum 1024 wide. Roles are fixed at Owner, Admin and Member. The Arabic version ships at the same time.

Already known: the current page hides pending invites in a separate tab and nobody finds them. Bulk actions were tried in 2024 and confused people; leave them out. The "transfer ownership" flow must keep its confirmation step for legal reasons.

Notice what is not in it: no layout, no component names beyond "the existing ones", no adjectives. The designer knows the job, the person, the target, the fences and the history. The first concept will be close.

What to attach

Attachments do more than adjectives:

• A link to the live screen, or a screenshot if there is no live screen, with a login the designer can use.
• The Figma library or the design system file.
• Real data: a sample of the actual records, including the longest name and the emptiest account.
• Any support tickets, session recordings or research notes that touch the screen.
• The strings, if the copy already exists, in every language it ships in.

What to leave out

• The solution. If you already know exactly what it should look like, you need a production designer, not a product designer, and you should say so.
• Reference sites, unless you say what you like about them. "Make it like Linear" means five different things to five people. "Linear's keyboard-first table" is a brief.
• Multiple screens in one request. One screen or one flow per brief. A flow is fine when the screens only make sense together, like a checkout.
• Deadlines without reasons. "By Thursday" is a constraint; "by Thursday because the release cuts Friday" lets the designer decide what to cut if Thursday is tight.

How this runs on a subscription

On a Recast plan, the request form asks for exactly these five parts and nothing else. The designer reads the brief, asks at most one round of questions in the thread, and sends two directions within 48 hours on Starter, or 24 to 48 on Growth. Revisions run in Figma comments until you are happy, and the finished screen comes back at every state with a spec frame and a short walkthrough video. There is no separate discovery phase, because the brief is the discovery.

If you want to try the brief on a real screen before committing to a plan, the $490 pilot sprint takes one screen from your product through this exact process in five working days.