ux-design-baseline

name

ux-design-baseline

description

PRODUCE the design intent for a UI feature that does not yet exist — the design thinking BEFORE code. Frames the job-to-be-done (what user behavior change, measured how), grounds in the repo's DESIGN.md + FLOWMAP, audits the current-state surfaces with a severity-scored findings table + cognitive walkthrough, DECIDES craft forks with conviction (north-star default shown — never dumps an a/b menu on the user), and produces a durable design.md (9-section template, slim/full tier). Repo-agnostic: each repo's DESIGN.md owns tone, each repo's FLOWMAP owns the flow map. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to FIGURE OUT the design for something to be built, including indirect signals: a feature request that needs design thinking before code ("이 기능 만들어줘", "이 화면 추가하자"), a "how should this work?" question about user flow, a request for a wireframe or design doc, any moment where the user wants to decide what to build before building it. NOT for judging an already-rendered surface (that is design-craft-rubric) and NOT for a repeated improvement loop (that is ui-iterate).

UX design baseline — procedure + template + cognitive walkthrough + severity

The producer-side UX knowledge for designing a feature before code. Lifted into a skill so the procedure loads only when actually designing. Repo-agnostic — works on any repo; each repo's DESIGN.md owns tone, each repo's FLOWMAP.md (if present) owns the flow map. The procedure itself is universal.

Why this skill exists (the failure it prevents)

Three failure modes that happen even when every mechanical step is right:

1. Research → defer, not conviction. After deep research the main context hands a design-craft fork back to the user ("우측 패널을 어떻게 처리할까요?"). The research already pointed at the answer. → decide craft forks with conviction.
2. Surface plumbing, flow-incomplete. Page A redesigned but adjacent page B stayed stale. → every affected flow surface accounted for.
3. Design = ephemeral chat prose. Died at compaction boundaries. → durable design.md.

The 5-step design procedure (mandatory)

Ground first — never infer the current state from code alone.

(a) Framing — JTBD + measurable success metric + current friction

JTBD in one line: 사용자가 ___ 할 때 ___ 하고 싶다, because ___ + a measurable success metric + the current drop-off / friction point. No measurement → "확인 불가"; do not guess a number.

• Outcome-not-output HARD REJECT. If the root goal is a feature / output ("슬라이드쇼 모드 추가") rather than a measurable user BEHAVIOR change ("사용자가 한 세션에 영상을 publish 한다"), REJECT and reframe before any UI sketch. The design.md §① 3 blanks (business objective / measurable result / which user problem) cannot be left empty.
• POV + reframed HMW. One-line user-context POV (누가 / 어떤 상황에서 / 무엇이 필요한데 왜 못 채우나) + ≥1 reframed How-Might-We that does NOT pre-commit to the current (broken) UI — reframe the problem, not the existing plumbing.

(b) Grounded research — existing context FIRST, WebSearch for delta ONLY

Read the matching DESIGN.md (the repo's tone definition), the matching FLOWMAP.md (if present — the repo's flow map), and any related spec/design.md or existing design docs in that repo. THEN WebSearch only the industry-standard / pattern pieces not already in that context. Re-running a full research sweep every call is BANNED. Cite every finding (URL / doc / file:line).

• Evidence vs assumption split. Separate "evidence I have" (cite repo log / transcript / DB / analytics — real usage) from "assumptions I am making" (untested). External research numbers are borrowed analogies — label them "borrowed, unproven on this repo", never canon.

(c) Current-state audit — QUALITY DIAGNOSTIC, not reuse inventory

Output is a severity-scored findings TABLE (one finding per row), not prose:

[finding | surface:location (file:route) | evidence (cite FLOWMAP node /
 DESIGN.md token / grep) | severity 0-4 | proposed fix]

Severity anchors (observables, not vibes):

Score	Meaning
0	cosmetic
1	minor friction with a workaround
2	noticeable friction, user fumbles
3	partially blocks the task or forces a retry
4	blocks the user from completing the task

Gate the full table to redesigns touching ≥2 flow surfaces (failure-#2 class); single-component tweak skips it. Single-rater (self-score) — do NOT mandate two-pass + affinity clustering or 3-rater mean.

The findings are GENERATED by a cognitive-walkthrough: draw the first-time-user persona + happy-path action sequence FROM THE REAL FLOWMAP (not invented). At each step ask the 4 questions:

1. Will they try the right action?
2. Will they notice it's available?
3. Will they associate it with their goal?
4. After acting, will they see progress (feedback)?

Each "no" = one row in the table, feeding design.md §④ + §⑤. Then inventory reusable components — a "new component" is allowed only after you prove no existing one fits.

(d) Decide with conviction — north-star default + consequence check

Commit a north-star default and show it (ASCII wireframe / component tree / render instruction). Do not hand craft forks back to the user as a vague a/b menu.

Default-consequence check: if executing the default makes a new paid/external call, loses/drops data, changes a pricing/availability/brand claim, or is irreversible → it is genuine, escalate — even if it looks like layout/copy/transition/empty-state craft. Otherwise escalate ONLY a genuine fork (business / brand / data-model / irreversible). Handing a harmless design-craft fork ("which panel layout?") back to the user is BANNED — that is failure #1.

§5.1 consequence-override checklist (auditable): per committed north-star default, write a row in design.md §5.1 (4-column Y/N grid → craft-decided / ESCALATED). An unrecorded "escalate: none" is not acceptable. Mandatory in BOTH tiers — a tiny change can still trigger a paid call.

Decide by RANKING, not absolute scoring. Rank ≥2 clearly-different directions with conviction. BANNED: emitting or thresholding any single absolute LLM numeric quality score (e.g. "이 디자인 8.5/10"). HARD BANNED: NO final verdict on cross-screen flow journeys — cross-flow judgment defers to FLOWMAP.md + runtime verification. Diagnose and rank within a surface.

(e) Produce design.md — 9-section template + tier selection

Fill all 9 sections (tier gates which ones). Silent omission of an adjacent surface is BANNED (failure #2). Every severity 3-4 finding must be resolved by the design (§5) + appear as an acceptance criterion (§8), OR be explicitly scoped-out (§9).

design.md — durable artifact

Deliverable: a design doc that shares the repo's spec lifecycle. Convention varies by repo (specs/<slug>/design.md, docs/design/<feature>.md, or repo-specific). When unsure, ask the user or follow the repo's existing pattern.

9 fixed sections:

§	Section	Notes
①	Problem & JTBD	outcome-not-output 3 blanks
②	Success metric	ODI shape bound to real FLOWMAP node or analytics event
③	Research findings	cited
④	Current-state audit	diagnostic findings table (severity 0-4) + 4-question walkthrough + component inventory
⑤	The design	IA / flow before→after asserted vs DESIGN.md token + FLOWMAP / layout / component reuse map / new-component justification / all states incl. empty·error·edge
§5.1	consequence-override checklist	both tiers, the safety field
⑥	Alternatives rejected	falsifiable — ≥1 rejected OR explicit forced-solution line
⑦	Accessibility	WCAG, N/total split, honest N=0 where no tool
⑧	Acceptance criteria	severity 3-4 findings each map here or scope-out
⑨	Flow-surface checklist	every affected FLOWMAP surface marked redesign or scope-out (if no FLOWMAP, every affected route)

Tier selection:

• Slim tier (single-surface change / internal experiment): fill §1 + §4 (key findings — full table NOT required) + §5 + §5.1 (always). Mark the rest "N/A — slim tier".
• Full tier (gate: redesign touches ≥2 flow surfaces OR any public-facing surface = real users): all 9 sections, full severity table, full §9 checklist.
• §5.1 consequence-override checklist is mandatory in BOTH tiers.

Output format

BLUF header mandatory:

결론 (3줄)
- JTBD / 성공지표: <1줄>
- 채택 디자인 (north-star): <1줄 — 보여준 것>
- escalate fork: <genuine fork N건 또는 "없음 — 전부 디자인이 결정">

The escalate-fork count MUST be backed by the §5.1 consequence-override checklist — a bare "escalate: 없음" without the filled checklist is not acceptable. Then the 9-section design.md body inline. Concrete only — "대비비 3.2:1 (AA 4.5:1 미달)" not "대비 낮아 보임". No design-craft fork dumped on the user.

BANNED

1. Edit UI code or DESIGN.md / FLOWMAP.md. You produce the design; the builder builds it. You read DESIGN.md / FLOWMAP.md as compliance references, you do not rewrite them.
2. Defer a layout / scroll / button-reachability problem as "위험" — core requirement.
3. Dump a design-craft fork on the user. Craft forks are decided with conviction and shown. Only genuine forks (business / brand / data-model / irreversible) escalate.
4. Emit a single aggregate design score. A rolled-up number is not actionable — per-dimension PASS/FAIL + a fix list is.