| name | design-get-context |
| description | Clarify the brief BEFORE any design work to avoid building the wrong thing. Interrogates goal, user, constraints, success criteria, and scope, then writes a short context doc the other design skills consume. Use when the user says "let's design X", "build a UI for Y", "get context", "clarify the brief", or kicks off any product-design task without a clear spec. First stage of the Product Design set — highest leverage for reducing rework. |
Design — Get Context
De-risk the whole design effort by nailing the brief first. The cheapest fix is the question you ask before building. This skill produces ./design/context.md — the single source of truth every other design skill reads. Skipping it is the #1 cause of "that's not what I meant" rework.
When to use
- Any new design/UI task where the spec isn't already crisp.
- The request is a one-liner ("design a settings page") with implicit, unstated requirements.
- Before
design-research, design-audit, design-ideate, or any build skill.
When NOT to use
- A solid
./design/context.md (or equivalent spec) already exists → proceed to the next skill.
- A pure visual-asset task with no UX → that's the Creative Production set.
What to interrogate (ask the gaps, don't dump all at once)
- Goal: what outcome or behavior change is this UI for? (not "a page" — why)
- User: who uses it, their context, tech comfort, frequency.
- Job-to-be-done: the core task the screen must make effortless.
- Constraints: existing stack, design system, brand, platform, deadline.
- Success criteria: how we'll know it worked — ideally measurable.
- Scope: must-have vs nice-to-have for v1; explicit non-goals.
Ask only the questions whose answers would change the design. If something's already given, don't re-ask. If the user can't answer "success criteria", propose 2-3 candidates and let them pick.
Workflow
- Identify the critical unknowns (the ones that would change what you build).
- Ask them concisely, grouped, not as a 20-question interrogation.
- If the user's framing seems flawed (wrong problem, contradictory constraints), raise it and propose an alternative before proceeding.
- Write
./design/context.md with answers + explicitly flagged assumptions + risks.
- Hand off to
design-research, design-audit, or design-ideate.
Output: ./design/context.md
# Context
goal: cut onboarding drop-off (currently 40% abandon at step 2)
user: first-time SaaS trial users, mixed tech comfort, on desktop
JTBD: get to "first value" (a created project) in under 2 minutes
constraints: stack=Next.js + Tailwind DS=internal "Aurora" platform=web deadline=2wk
success: step-2 completion ↑ from 60% → 80%; time-to-first-project < 2min
scope v1: [3-step wizard, skip-able, progress saved]
non-goals: [mobile layout, SSO, team invites]
open assumptions: [users have a use case in mind on arrival]
⚠ risks: [if drop-off is a value problem not a UX problem, redesign won't fix it]
Quality bar
- Goal, user, and success criteria are all present (or explicitly deferred by the user).
- Success criteria are concrete enough to QA against later (
design-qa reads these).
- Every guess is labeled an assumption — nothing is silently invented.
- Non-goals are stated so scope can't creep unnoticed.
Common pitfalls
- Starting to design before the brief is clear — the entire point of this skill is to prevent that.
- Question-dumping — 20 questions at once stalls the user. Ask the few that matter.
- Burying a guess as a fact — if you assumed it, say "assumption:".
- Accepting a flawed framing silently — if the user's asking for the wrong thing, surface it now (cheap) not after building (expensive).
Handoff
context.md → design-research (gather outside signal), design-audit (if improving existing UI), or design-ideate (go straight to directions). Every downstream skill reads this file.
Tooling
None required — this is a conversation + a written artifact.
