reph

Templates · Design

Design brief template

Problem, audience, constraints and success criteria for a design project

Start with this template →Sign in

Opens on reph with the template ready to start. No account needed; sign in to keep your document.

Use it when

A design project is about to start and the designer, PM and engineering need one agreed problem, audience, constraint list and finish line

Who it's for

DesignerProduct manager

Filled example

The template filled in for a made-up company, so you can see what good looks like.

Design brief: Self-serve refunds for clinic receptionists

Author: Maya Torres · Date: 22 September 2026

Background

Carewell clinics issue about 3,000 refunds a month. Today a receptionist cannot refund a card payment herself; she raises a support ticket and waits on average 26 hours. A 2025 attempt added a refund button for clinic owners only, but owners are rarely at the front desk, so usage stayed under 5%. Refunds are now the single largest source of billing tickets (31%), and the new Billing squad has made them its first project.

Problem statement

Receptionists need to give a patient their money back while the patient is still at the desk, without waiting on support or the clinic owner.

Audience

Front desk receptionists at small and mid sized clinics (1 to 8 practitioners), usually working on a shared desktop between patient arrivals. Clinic owners matter as approvers, not daily users.

Goals

  • A receptionist completes a full or partial card refund in under two minutes, with the patient present.
  • Owners stay in control through limits they set, not approvals they must click.

Non-goals

  • Insurer claim reversals (next project).
  • Refunds to a different card than the one charged.

Constraints

  • Brand: existing Carewell design system; new money input patterns go into the system.
  • Technical: the payment provider allows partial refunds but not cancelling a refund once sent, so confirmation must be explicit.
  • Accessibility: WCAG 2.1 AA minimum; full keyboard support, since many desks have no mouse space.

Deliverables

Flows for full and partial refunds, owner limit settings, hi-fi Figma mocks, a clickable prototype for testing, and a handoff spec with all error states.

Success criteria

Baselines from the August support and product data; targets for 60 days after launch.

Refunds done without support
6%
target 80%
Time to refund
26 h
target 2 min
Refund support tickets
2,790 / month
target 840 / month (-70%)

Timeline

Checkpoint Date Owner
Kickoff 29 September Maya
Concept review 13 October Maya, Jonas
Final review 3 November Maya
Handoff 10 November Maya, Priya

References

  • 2025 owner refund button postmortem
  • Research synthesis: "Front desk money moments" (August 2026)
  • Competitor refund flows collected in the Billing Figma file, page "Prior art"

Review

Review by: 26 September 2026

Reviewer Role Status
Jonas Berg PM Approved
Ana Lima Design lead Approved
Priya Raman Engineering lead Approved with notes

Decision record

Decision Date Decided by Notes
Owner set limits instead of per refund approval 26 September 2026 Jonas, Ana, Priya Default limit £150 per refund; revisit after 30 days of data

The template

Show the blank template

Design brief

Author: [your name] · Date: [date]

Background

The context a designer joining today wouldn't otherwise have: prior attempts, related work, why this is happening now.

Problem statement

One or two sentences framed around the user's problem, not a solution already baked in.

Audience

Who this is for: persona, segment, or specific customer accounts if this is bespoke work.

Goals

  • What good looks like when this ships

Non-goals

What this project will deliberately not solve, so scope arguments happen now and not at final review.

Constraints

Brand, technical and accessibility constraints the design must work within. Say which are hard limits vs. preferences.

  • Brand:
  • Technical:
  • Accessibility: WCAG 2.1 AA minimum

Deliverables

What design will hand off (flows, hi-fi mocks, a prototype, a spec) and in what format.

Success criteria

How you'll know the design worked, ideally something measurable post-launch, not just "stakeholders liked it." Record today's baseline so the target means something.

Task completion
0%
target 0%
Time to complete
0 min
target 0 min
Related support tickets
0 / month
target 0 / month

Timeline

Key checkpoints: kickoff, concept review, final review, handoff.

Checkpoint Date Owner
Kickoff
Concept review
Final review
Handoff

References

Prior art, competitor patterns, inspiration. Link, don't paste screenshots inline.

Review

Who must agree to this brief before design starts, and by when.

Review by: [date]

Reviewer Role Status
PM Pending
Design lead Pending
Engineering lead Pending

Decision record

Decision Date Decided by Notes

Questions

How long should a brief be?
One to two pages, enough to start without a meeting and short enough to reread at every review
Can the brief change after kickoff?
Yes, but record the change and get the same reviewers to sign off again
Who signs off?
The PM and the design lead at minimum, plus engineering when technical constraints are hard limits

Fill it with your agent

Connect Claude to reph over MCP, then paste this. The draft arrives as suggestions you accept or reject section by section. How to connect Claude.

Find my reph doc "Design brief" with search_docs, then read it with read_doc. Draft Background, Problem statement and Audience from the PRD, research synthesis and support tickets I link in chat, framed around the user, not a solution. Take success metrics only from numbers in those sources. File it with suggest_edit, one replace_section op per section (heading line kept) so each can be accepted alone. Ask each open question (scope, hard constraints, who signs off) with add_comment quoting that section's heading line, then call request_review with a one-line summary.

Related templates

Design critique notes

Structured feedback on a design review

DesignerProduct manager

Usability test script

Moderator script with tasks and observation notes

ResearcherDesigner

UX research plan

Research questions, method, participants and timeline

ResearcherDesignerProduct manager

Start with this template →Sign in