Design — Research

Gather outside signal before inventing. Know the conventions users already expect (so you don't fight muscle memory) and the pains competitors leave on the table (so you can win on them). Good research turns "I think" into "users expect / competitors fail at".

When to use

• Designing a flow that others have solved (auth, onboarding, checkout, settings, dashboards).
• You need to know the convention before deciding whether to follow or break it.
• Looking for differentiation — where do incumbents frustrate users?
• Before design-ideate, to ground directions in evidence.

When NOT to use

• The brief isn't clear yet → design-get-context first.
• You're critiquing an existing UI of your own → design-audit.
• The pattern is trivial/obvious and research adds nothing — don't over-research.

Inputs

• ./design/context.md (goal, user, JTBD) if it exists.
• The specific flow/feature in question.