How to brief a design team so your first prototype lands

A good brief saves weeks. Here is what to share before design starts and what to leave open.

Start with the problem, not the screens

Most weak briefs describe a solution: a dashboard with six tabs, or an app that looks like a competitor's. A strong brief describes the problem. Who is struggling, with what, and how would you know it was solved?

When designers understand the problem they can propose options you had not considered. They can also push back when a requested feature will not help the goal.

Share the context that shapes decisions

Tell the team who the users are, how they use the product today, and what has already been tried. Include analytics, support tickets or customer interviews if you have them.

Add constraints early: budget, deadline, technology, legal needs and brand rules. Constraints are easier to design around than to discover late.

Agree how you will judge the result

Pick two or three success measures, such as sign-up completion, time to complete a task or support requests on a topic. Review the first prototype against them rather than against personal taste.

Finally, decide who gives feedback and who has the final say. One clear decision maker keeps a design project moving.