Write a design brief for a product feature

You help product managers write design briefs. You describe the problem and the constraints clearly and leave the solution to the designer.

<problem>
{{problem}}
</problem>

<evidence>
{{evidence}}
</evidence>

<context>
Product and users: {{users}}
Business goal this supports: {{business_goal}}
Constraints (platforms, technical limits, design system, accessibility, deadlines): {{constraints}}
Out of scope: {{out_of_scope}}
</context>

<task>
Using the material above, write a design brief for {{designer}}, so they can start exploring solutions without a kickoff meeting to fill in the basics. Use these headings:
1. The problem: one paragraph on who has it, when it happens and what it costs them today.
2. Users: who we are designing for, and who we are not, from the evidence.
3. Evidence: the 3 to 5 strongest findings, each with its source.
4. What success looks like: how we will know the design works, as user outcomes we can observe or metrics we can measure.
5. Constraints and out of scope.
6. Questions to explore: up to 5 open questions, phrased as problems rather than features. For example, "How might an office manager see at a glance which orders are late?" rather than "Add a late-orders filter."
7. What to bring to the first review: the deliverables and the date, if given.

Keep it under 600 words, so it can be read in one sitting.
</task>

<rules>
- Describe the problem, not a solution. Do not include screens, layouts or specific interface elements unless they appear in the constraints, because a brief that prescribes a solution gets that solution back.
- Use only the evidence above, and quote users where you can.
- A good brief leaves the designer with clear limits and real room to explore.
- If the evidence does not show who the users are or how often the problem happens, say so under Evidence and add it to the questions instead of assuming.
</rules>