Design Brief Template for User Research

A PRD covers the full product requirements: problem, goals, user stories, functional requirements, technical considerations, and launch plan. A design brief is narrower. It focuses specifically on the design work needed: the UX problem, target users, constraints, success criteria, and deliverables. Think of the PRD as the full project plan and the design brief as the design-specific subset. Use the [PRD template](/templates/prd-template) for the complete requirements document.

The PM writes the brief, ideally after discussing the problem space with the designer informally. The designer should not see the brief for the first time in a cold handoff. A 15-minute conversation before the brief is written helps the PM frame the problem more clearly and gives the designer early context.

Include screenshots of the current experience and inspiration references. Do not include wireframes of the proposed solution. The brief frames the problem. The designer proposes solutions. If you include wireframes, you are anchoring the designer to your solution instead of letting them explore the full design space.

Be specific and exhaustive. List technical constraints (component library, supported browsers, API limitations), brand constraints (design system, accessibility), business constraints (legal, SEO, compliance), and timeline constraints (when wireframes and mockups are due). Every constraint the designer discovers mid-project is a constraint you should have surfaced in the brief.

That is a good sign. It means the designer is thinking critically about what "success" means for the user, not just the metric. Discuss the tension. The PM owns the business metrics, but the designer may identify qualitative success criteria (e.g., "users should not need documentation") that lead to better solutions. Use the Open Questions section to track unresolved disagreements and set a deadline for resolution. ---