jaw-dev-uiux-design

# UI/UX Design: Intent Discovery, Patterns & Product Vocabulary Activates by change surface when: - User's design direction is vague ("깔끔하게", "모던하게", "just make it look good") - Building onboarding, empty state, error state, or loading state UI - User references a product aesthetic ("Notion 느낌", "Linear처럼") - Starting a new design system or generating a color palette - Choosing layout patterns or navigation architecture - Setting up favicons, product logos, or brand identity elements - Handling logo dark mode variants, OG images, or social sharing meta Read this before style-specific references when the user cannot articulate a clear design direction. For rendered anti-slop tell detection and implementation-level banned patterns, defer to `../jaw-dev-frontend/references/core/anti-slop.md`. This skill owns concept/taste-level anti-slop judgment (is this direction generic or domain-wrong?). **Emoji ban (stub):** no emoji as UI visual elements (STRICT). Canonical rule, scope, and exemptions: `jaw-dev-frontend` §5 / `../jaw-dev-frontend/references/core/anti-slop.md § Emoji Slop`. **Role separation:** This skill owns design judgment: intent discovery, information architecture, UX state meaning, typography/color/layout direction, product personality, brand vocabulary, anti-slop concept/taste judgment, and design-system decisions. `jaw-dev-frontend` owns implementation: HTML/CSS/components, responsive mechanics, accessibility wiring, runtime behavior, rendered tell detection, and rendered verification. After choosing the design direction here, load `jaw-dev-frontend` for concrete implementation. > **Role boundary (canonical — identical in `jaw-dev` and `jaw-dev-frontend`):** > `jaw-dev` owns universal process, evidence, and safety rules. `jaw-dev-uiux-design` owns > design intent, direction, and concept judgment. `jaw-dev-frontend` owns concrete frontend > implementation and rendered tell enforcement. Anti-slop has three layers: `jaw-dev` = > output/process hygiene (FAMILY-SLOP-01), `jaw-dev-uiux-design` = concept/taste judgment > (is this direction generic or domain-wrong?), `jaw-dev-frontend` = rendered implementation > tell detection and removal (FE-AI-TELL-01). **External/current design evidence:** For live product-reference claims, current design-system docs, browser API behavior, accessibility guidance that may have changed, or browser-rendered source evidence, read the active `search` skill and follow its query-rewrite, source-fetch, and evidence-status rules. Use browser fetch/open/text/get-dom/snapshot only after candidate URLs exist. > **C0/C1 work (small local patches):** See `jaw-dev` §0.0 Work Classifier + §0.1 Patch Fast-Path before reading references. > **`jaw-dev` is canonical:** `jaw-dev` §0.2 Rule Classes, §3 Verification Gate, and §5 Safety Rules apply to all work governed by this skill. > **Rule class note (UX-STYLE-01):** Everything in this skill that expresses taste — > product personalities, design-isms, preset tokens, aesthetic vocabulary — is > `STYLE_SAMPLE`: examples to draw from, never universal requirements. Objective UX > correctness (state coverage, accessibility, readability) is owned by `jaw-dev-frontend` > §1.5 and stays STRICT/DEFAULT. ## Modular References | File | When to Read | What It Covers | |------|-------------|----------------| | `references/design-isms.md` | User names a style/movement | 11 design movements with CSS signatures | | `references/compositional-patterns.md` | Choosing what a page DOES structurally | 15 pattern families (hero, navigation, motion, continuation, content) with frequency, maturity, gates, examples — orthogonal to isms | | `references/design-trends.md` | Checking whether a technique is currently stable | Dated axis prevalence and implementation-sensitive signals (2026-07-14 crawl); never promote a dated signal into an ism | | `references/design-award-sources.md` | Before setting a visual direction | Gallery selection by lookup axis, domain/type retrieval families, evidence thresholds for promoting a pattern | | `references/design-read-example.md` | Learning or reviewing Design Read format | Filled-in Design Read + dial setting example | | `references/intent-discovery-ladder.md` | One clarifying fork was not enough, or the user wants guided exploration | Binary/ternary ladder (mood → density → …) anchored on recognizable products | | `references/korean-design-vocabulary.md` | Korean design descriptors (깔끔하게, 모던하게, 감성적으로) | Descriptor → concrete token translation table + per-term clarifying questions | | `references/product-personalities.md` | User references a product | 8 product DNA profiles with exact tokens | | `references/layout-macrostructures.md` | Choosing page/component layout | Component layouts + page-level compositions | | `references/ux-states.md` | Building any stateful UI | Onboarding, empty, error, loading, progressive disclosure | | `references/color-system.md` | Generating colors/palette | OKLCH-based palette generation, dark mode, accessibility | | `references/design-system-bootstrap.md` | New project / design system | Token architecture, component hierarchy, **DESIGN.md format** (google-labs-code/design.md) | | `references/responsive-nav.md` | Responsive or navigation work | Breakpoints, container queries, nav patterns by density | | `references/ux-preflight.md` | **Before delivery** | UX state verification checklist | | `references/typography-line-breaks.md` | **Always for text-heavy UI** | Heading break quality, **short descriptor category** (hero subtitle, card desc — use `balance` not `pretty`), orphan prevention, `ch` units, Korean orphan criteria, `-webkit-line-clamp` conflict | | `references/favicon-logo.md` | **Favicon, product logo, or brand identity work** | Favicon file set, SVG dark mode, logo in nav/footer, dark mode variants, OG images, brand tokens, common mistakes | | `references/logo-trust-sections.md` | Integration/partner/client logos | Marquee vs grid decision, anti-patterns, grayscale treatment, placement | | `references/visual-hierarchy.md` | Any layout / composition decision | 6 levers: size scale, weight contrast, color emphasis, spacing, position, density | | `references/form-patterns.md` | Forms, wizards, auth, file upload | Validation timing, multi-step, password UX, file upload, search/filter | | `references/mobile-native-ux.md` | Native mobile app UX decisions | iOS HIG vs Material 3, gestures, deep linking, Korean privacy, app store UX | | `references/anti-rationalization.md` | Before accepting your own shortcut | Five common agent rationalizations with rebuttal, red flag, and the verification that closes each gap | --- ## Lazy-User Gate (UX-LAZY-01, DEFAULT — ponytail discipline applied to UX) Design for the cognitively frugal user: users don't read, they scan; they satisfice; they will trade choice for one obvious next action. Before shipping any user-facing decision point — option, setting, step, confirmation, input field, mode — justify its existence the ponytail way, in order: 1. **Do nothing**: can a correct default remove this decision entirely? (A settings page is a collection of defaults you failed to choose.) 2. **Delete**: does the step/field earn its completion-rate cost? Every added decision point taxes conversion and comprehension (Hick's law). 3. **Absorb**: can the system take the complexity instead of the user (Tesler's law) — auto-detect, infer, remember last choice? 4. **Demote**: still needed for some users → progressive disclosure (advanced section, "more options"), never a top-level fork. Every screen has ONE primary action. If two actions compete visually, the design has not decided what the screen is for. **Surface-conditional (do not over-apply):** laziness means *fewer decisions* on consumer/one-shot flows (D1-D3), but *fewer repeated motions* on repeated-work tools (D4-D8: density, keyboard paths, batch actions — collapsing an expert's controls into wizards is the inverse failure). Route by the product-density profile first. **STRICT exemptions (never one-click away):** destructive/irreversible actions, consent/privacy/legal choices, payments confirmation, and accessibility affordances are never collapsed into magic defaults. ## UX State Contract (UX-STATE-01) For onboarding, empty, loading, error, or progressive-disclosure work, answer the state meaning before styling. Deep patterns live in `references/ux-states.md`. - Onboarding teaches the first meaningful action, not the whole product. - Empty explains why the state exists and names the next action. - Loading chooses skeleton for known structure, spinner/progress for short unknown waits, and avoids fake completion. - Error exposes retry, recovery, or escalation; never dead-end the user. - Progressive disclosure names what stays hidden, why, and where it becomes available. ## IA Chooser (UX-IA-01) Default navigation architecture by work shape; read `references/responsive-nav.md` for responsive details. | Work shape | Default IA | |------------|------------| | Dense desktop repeated work | Sidebar + command palette | | Medium sectioned work | Tabs or segmented navigation | | Mobile-primary consumer flow | Bottom nav, sheet, or thumb-zone actions | | Wizard/auth/setup | Stepper or stacked linear flow | ## 1. User Intent Discovery Protocol When the user's design request is vague ("깔끔하게 해줘", "모던하게", "just make it look good"), do not produce generic output. Run the compact ambiguity flow (UX-INTENT-01): 1. Produce the Design Read from §2 using available signals. 2. If one decision still blocks the direction, ask ONE best clarifying fork with binary/ternary choices. 3. Proceed from the answer; if the user does not answer and the task can continue, choose the most domain-correct default and state the assumption. > Skip this section if the user provided explicit design specs or this is a ≤5-line patch. **Optional deepening:** use the ladder below only when the first fork fails or the user explicitly wants guided exploration. - Use binary/ternary choices, not open-ended questions. - Reference known products — users recognize what they want faster than they articulate it. - If the diagram skill is available, offer: "참고로 스타일 비교를 다이어그램으로 보여드릴 수도 있어요." - If the user names a specific product reference, skip remaining steps and map directly via `references/product-personalities.md`. ### Step 1 — Mood Ask: "전체적인 분위기가 어떤 느낌이면 좋을까요?" / "What overall feeling should the product have?" | Option | Signals | Product References | |--------|---------|-------------------| | 전문적/신뢰감 (Professional) | swiss, flat, restrained | Linear, Vercel, GitHub | | 따뜻한/친근한 (Warm/Friendly) | rounded, warm-neutrals, illustrations | Notion, Airbnb, Toss | | 고급스러운/세련된 (Premium) | generous-whitespace, thin-type, restrained-color | Apple, Stripe, Aesop | | 재미있는/활기찬 (Fun/Energetic) | bright-colors, playful-shapes, bold-type | Figma, Discord | | 대담한/독특한 (Bold/Distinctive) | brutalism, asymmetry, experimental | Gumroad, Nothing | ### Step 2 — Lightness Ask: "밝은 화면이 좋으신가요, 어두운 화면이 좋으신가요?" / "Light or dark background?" | Option | CSS | |--------|-----| | 밝은 배경 (Light) | `bg-white text-gray-900` | | 어두운 배경 (Dark) | `bg-gray-950 text-gray-100` | | 둘 다 (Both / auto) | `prefers-color-scheme` aware | ### Step 3 — Density Ask: "화면에 정보가 많이 보이는 게 좋으신가요, 여유롭게 보이는 게 좋으신가요?" / "Dense or spacious?" | Option | VISUAL_DENSITY | Tokens | |--------|---------------|--------| | 빽빽하게 (Dense) | 8–10 | `text-sm py-1 px-2 gap-1` | | 보통 (Normal) | 4–7 | `text-base py-3 px-4 gap-4` | | 여유롭게 (Spacious) | 1–3 | `text-lg py-8 px-8 gap-8` | ### Step 4 — Shape Ask: "모서리가 각진 느낌이 좋으신가요, 둥근 느낌이 좋으신가요?" / "Sharp or rounded?" | Option | CSS | Signals | |--------|-----|---------| | 각진 (Sharp) | `rounded-none` / 0–2px | Vercel, brutalism, swiss | | 살짝 둥근 (Slightly rounded) | `rounded-md` / 6–8px | Linear, Notion, material | | 많이 둥근 (Very rounded) | `rounded-2xl` / 16–24px | Figma, iOS, Toss | ### Step 5 — Viewport Priority Ask: "주로 어떤 화면에서 볼 건가요?" / "What's the primary viewing device?" | Option | Responsive Strategy | Key Constraint | |--------|-------------------|----------------| | 데스크탑 위주 (Desktop-first) | Desktop layout → tablet → mobile collapse | Data density OK, hover interactions OK | | 모바일 위주 (Mobile-first) | Mobile layout → tablet → desktop expansion | Thumb zone, touch targets, minimal density | | 둘 다 중요 (Both equally) | Design mobile AND desktop as separate compositions, not one adapted from the other | Most work — section order/composition may differ | Cross-ref: `references/responsive-nav.md` for canonical breakpoints and container query patterns, `../jaw-dev-frontend/references/core/mobile-ux.md` for mobile-specific composition rules. ### Step 6 — Reference Ask: "혹시 '이런 느낌이면 좋겠다' 하는 사이트나 앱이 있으신가요?" / "Any website or app that feels like what you want?" This single question often resolves all ambiguity. If the user names a product, map it via `references/product-personalities.md`. ### Vague Request Disambiguation When the user gives feedback without specifics, translate: | User says | Action | |-----------|--------| | "더 좋게" / "make it better" | Ask: "레이아웃? 색상? 타이포? 여백?" — identify the dimension | | "더 전문적으로" / "more professional" | Increase whitespace, reduce color count to 2–3, tighten grid alignment | | "더 모던하게" / "more modern" | Negative letter-spacing on headings, offer dark mode, reduce radius to 8px | | "더 재미있게" / "more exciting" | Add one bold accent color, increase type contrast, add micro-animation on hover | | "너무 심심해" / "too boring" | Add asymmetric layout, introduce one unexpected element, vary section rhythm | | "너무 복잡해" / "too busy" | Reduce element count, increase whitespace, limit to 2 colors | --- ## 2. Design Read (MANDATORY for new pages, components, or layouts. Optional for ≤5-line patches — see jaw-dev §0.1 Patch Fast-Path.) Before generating ANY frontend code, produce a Design Read. If the project has a `DESIGN.md` file, read it first — its tokens and prose override everything below. ### Output format (mini DESIGN.md) Filled-in example: `references/design-read-example.md`. ```yaml --- name: <project-name> colors: primary: "<hex>" accent: "<hex>" background: "<hex>" typography: heading: { fontFamily: <font>, fontSize: <size> } body: { fontFamily: <font>, fontSize: <size> } --- ``` Reading this as: <page kind> for <audience>, with a <vibe> language. <1-2 sentences: specific reference, not adjectives. "1970s lecture handout" > "modern and clean"> Do's: <context-specific positive from brief> Don'ts: <context-specific ban from brief> ### Signals to read 1. Page kind — landing (SaaS/consumer/agency/event), portfolio, redesign, editorial, app UI, tool UI 2. Vibe words — what the user said or implied 3. Reference signals — URLs, screenshots, brands named 4. Audience — B2B procurement vs design-conscious consumer vs recruiter 5. Existing brand assets — logo, color, type, photography 6. Quiet constraints — accessibility-first, public-sector, regulated, kids ### Dial Setting (MANDATORY — immediately after Design Read) From the Design Read, derive and declare three dials before any code: ``` DESIGN_VARIANCE: <1-10> MOTION_INTENSITY: <1-10> Product density profile: <D1-D8> (see ../jaw-dev-frontend/references/core/product-density.md) Reasoning: <one sentence explaining why these values match the brief> ``` Inference rules: - Corporate/gov/utility → VARIANCE 2-4, MOTION 1-3, density D2-D3