Jaw Dev Uiux Design

---
name: jaw-dev-uiux-design
description: "MUST USE for UI/UX direction and design judgment — vague visual briefs, onboarding, empty/error/loading states, layout vocabulary, typography breaks, favicons, logos, and brand identity choices. Triggers: make it look good, modern, clean, aesthetic, onboarding, empty state, error state, favicon, logo, design system, 깔끔하게, 모던하게, 감성적으로."
metadata:
  short-description: "Design judgment for vague briefs, UX states, typography, layout, logos, and brands."
  keywords: "design-intent, onboarding, empty-state, error-state, design-ism, product-personality, korean-ux, layout-patterns, typography-line-breaks, logo-trust-sections, favicon, logo, brand-identity, og-image, dark-mode-logo"
  last-verified: "2026-07-02"
---

# 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 `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: `dev-frontend` §5 / `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. `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 `dev-frontend` for concrete implementation.

> **Role boundary (canonical — identical in `dev` and `dev-frontend`):**
> `dev` owns universal process, evidence, and safety rules. `dev-uiux-design` owns
> design intent, direction, and concept judgment. `dev-frontend` owns concrete frontend
> implementation and rendered tell enforcement. Anti-slop has three layers: `dev` =
> output/process hygiene (FAMILY-SLOP-01), `dev-uiux-design` = concept/taste judgment
> (is this direction generic or domain-wrong?), `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 `dev` §0.0 Work Classifier + §0.1 Patch Fast-Path before reading references.

> **`dev` is canonical:** `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 `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, `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 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 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
- Marketing/landing → VARIANCE 4-7, MOTION 3-5, density D2-D3
- Creative/portfolio/editorial → VARIANCE 6-9, MOTION 4-7, density D1-D3
- Dashboard/SaaS/admin → VARIANCE 2-4, MOTION 1-2, density D4-D5
- "Complex" in brief → increase density profile (functional depth), NOT VARIANCE or MOTION
- "Simple" in brief → decrease all three proportionally

"복잡하다" = high DESIGN_VARIANCE is WRONG. Complexity means more features/data/flows, not more visual tricks (carousels, parallax, animations).
#### Dial Presets (UX-DIAL-PRESET-01, STYLE_SAMPLE)

Source: taste-skill v2, via codexclaw. Exact tuples for common use cases. Presets are
authoritative **specializations** that may exceed the inference ranges above — Agency
motion 8 exceeds the general landing 5-7 range on purpose. When a preset exists for the
exact use case, use it directly and adjust from the Design Read.

| Use case | Variance | Motion | Density | Notes |
|----------|---|---|---|-------|
| Landing (SaaS mainstream) | 7 | 6 | 4 | |
| Landing (agency/creative) | 9 | 8 | 3 | |
| Landing (premium consumer) | 7 | 6 | 3 | |
| Portfolio (designer/studio) | 8 | 7 | 3 | |
| Portfolio (developer) | 6 | 5 | 4 | |
| Editorial / blog | 6 | 4 | 3 | |
| Public-sector service | 3 | 2 | 4 | |
| Dashboard / SaaS admin | 3 | 2 | 5 | |
| Finance / ops | 2 | 1 | 7 | density D6-D7 |
| Game | 8 | 7 | 4 | domain-specific |
| Korean consumer app | 5 | 4 | 5 | CJK density |

**Redesign arithmetic (DEFAULT).** Score the existing surface with the preset rules
first, then move from it:

- Preserve: variance = match existing, motion = match + 1, density = match existing.
- Overhaul: variance = existing + 2, motion = existing + 2, density = match existing.
- "Complex" in the brief increases **density**, never variance or motion.
- "Simple" decreases variance and motion; density stays or increases.

Clamp all arithmetic to 1-10 and D1-D8. An existing SaaS surface at 7/6/4 preserves to
7/7/4 and overhauls to 9/8/4.

#### Audience-first ownership (UX-AUDIENCE-01, DEFAULT)

The **audience** picks the aesthetic, not the model's taste. When audience signal and
model preference conflict, audience wins. The presets above encode audience
expectations — a public-sector audience expects trust-first restraint, an agency
audience expects high variance — so reaching past a preset because the result feels
plain is the failure this rule names. Override with stated rationale only.


### Anti-Default Discipline
Do not default to: warm beige backgrounds, centered hero, three equal feature cards, generic glassmorphism, Inter + slate-900, card-based everything. These are LLM defaults. Reach past them BASED ON the design read.

If the brief is ambiguous, ask ONE clarifying question. Not a multi-question dump.

### DESIGN.md persistence
### Image-First Direction Discovery (UX-IMAGE-FIRST-01, DEFAULT)

Fires when the brief has **no** named ism, product reference, or concrete design
direction. Generate 5 maximally different ism directions, varying layout family,
palette, type stance, material, and hero grammar. Every prompt must be detailed enough
to reconstruct the layout.

Compare candidates on hero composition, palette coherence, typographic voice, and
density fit. **Pick the winning ism, not the winning image** — the render is evidence
for a direction, and treating it as the deliverable is how a one-off composition becomes
an accidental design system.

Then synthesize rather than crowning one candidate. Build an element ledger recording,
per token, which variant did it best and why:

| Token | Best variant | Rationale | Locked value |
|-------|-------------|-----------|--------------|
| Palette | #3 | warmest coherence | primary + accent |
| Hero | #1 | strongest asymmetric composition | editorial offset |
| Type | #2 | best weight contrast | heading 300, body 400 |

**The synthesis IS the direction lock**: it assembles the best tokens from several
candidates into one coherent set, and the lock is that assembled set rather than any
single render. Refine the locked direction with 2-4 variants afterwards.

When a human is in the loop they pick the ism; running unattended, state the selection
reasoning in the record.

## 2.6 Asset Production Handoff (UX-ASSET-GEN-01, DEFAULT)

Once the concept direction is locked, asset work belongs to
`jaw-dev-frontend/references/core/asset-requirements.md` — generation, background removal
(FE-ASSET-BG-01), batching, selection, and integration. This section exists to mark the
handoff rather than to duplicate it: the direction is decided here, the assets are
produced there, and blurring the two is how an unlocked direction gets 40 generated
images spent on it.

## 2.7 Icon Strategy (UX-ICON-01, DEFAULT)

Choose iconography during the Design Read, **before** frontend implementation. Select
the domain-correct default from the density matrix; an explicit `DESIGN.md`
`iconography` block overrides it. Do not ask the user unless icon direction is a
material brand decision that cannot be inferred from the brief.

| Density | Typical surface | Recommended library | Why |
|---|---|---|---|
| D1 | Editorial, campaign, sparse portfolio | Iconoir | Airy 1.5px linework suits low-density art-directed composition |
| D2 | Marketing site, premium consumer landing | Phosphor or Iconoir | Phosphor adds expressive weights; Iconoir stays restrained |
| D3 | Consumer product, content app | Phosphor | Broad semantics plus regular/fill/duotone hierarchy |
| D4 | SaaS product, general app UI | Phosphor | Default balance of clarity, coverage, personality |
| D5 | Korean consumer app, feature-rich mobile | Phosphor + custom domain layer | System clarity plus colorful product-specific concepts |
| D6 | Dense admin, B2B workflow | Hugeicons or Untitled UI | Higher coverage, neutral precise forms |
| D7 | Finance, ops, analytics | Untitled UI or Hugeicons | Controlled neutral geometry at high information density |
| D8 | Developer tool, expert control surface | Hugeicons or Lucide | Maximum coverage; Lucide only when ecosystem fit is intentional |

Routing:

1. Set the system library from the matrix and the product's visual language. Phosphor is
   the general default, not a universal mandate.
2. Respect an explicit user choice or an existing `DESIGN.md` value over the inferred
   default.
3. Use the library for routine system semantics — navigation, actions, status, search,
   disclosure, utility controls.
4. Generate a custom icon when a domain concept has no clear library glyph, when forcing
   an approximate glyph would reduce comprehension, or when the brief requires a
   brand-specific visual style. A licensed premium set is the alternative when it
   already supplies a coherent domain vocabulary.

Three visual layers, kept distinct:

- **System icons (library)** — routine interface semantics, one coherent library and
  weight language.
- **Domain icons (custom or premium)** — product concepts, categories, KPIs, services,
  objects that generic libraries cannot represent precisely.
- **Brand icons (custom)** — identity-bearing marks, characters, mascots, signature
  illustrations. Never substitute a generic stroke icon for a logo.

Korean consumer apps often carry more information and rely on colorful domain category
and KPI icons for fast scanning. For D4-D6 Korean-first apps, prefer a restrained system
library plus a coherent colored domain layer over forcing every concept into monochrome
outline icons.

If the project needs persistent design tokens across sessions, save the Design Read as a full `DESIGN.md` in the project root. Format spec: `references/design-system-bootstrap.md § DESIGN.md Format`.

---

## 3. Korean Request Translation

Map common Korean design descriptors to concrete tokens. When the user uses these words, translate before implementing.

| Korean | Literal | CSS/Token Translation |
|--------|---------|----------------------|
| 깔끔하게 | cleanly | Generous whitespace (24-48px gaps), strict grid, max 2-3 colors, saturation < 60%, 1px borders or none, 4-8px radius, single font, no/subtle shadows |
| 모던하게 | modern | Geometric sans-serif (Geist/Outfit), negative letter-spacing on headings, dark mode or high-contrast light, 8-16px radius, spring micro-interactions |
| 고급스럽게 | luxurious | Very generous whitespace (48-96px padding), thin weights (300-400), serif for headings, low-saturation palette, slow animations (800ms+), 0-4px radius |
| 심플하게 | simply | Max 3-4 element types per screen, 1-2 colors, single font, 2-3 size steps, hidden/minimal navigation, zero decoration |
| 트렌디하게 | trendy | Glassmorphism, bento grid, gradient mesh, variable fonts — ask for a reference site |
| 따뜻하게 | warmly | Warm hue range (stone/amber/orange), 12-20px radius, warm-tinted shadows rgba(180,140,100,0.1), serif or rounded sans |
| 차가운 | cold/cool | Cool grays (slate/zinc), blue-tinted whites, geometric sans, thin weights, 0-8px radius |
| 감성적으로 | emotionally | Editorial/lifestyle, serif display + sans body, muted/pastel colors, generous line-height, photography-heavy |

**Clarifying questions per term:**
- 깔끔: "Notion처럼 따뜻한 깔끔함인지, Vercel처럼 차가운 깔끔함인지요?"
- 모던: "다크 모드 + 날카로움(Linear)인지, 화이트 + 미니멀(Vercel)인지요?"
- 고급: "브랜드 고급감(Apple/Stripe)인지, 패션 럭셔리(Art Deco)인지요?"
- 심플: "기능이 적은 건지, 기능은 많지만 화면이 심플해 보이길 원하는 건지요?"

---

## 4. Quick-Match Table

Rapid lookup: user word → concrete starting point.

| User (KO) | User (EN) | Start From | Dark? | Radius | Density | Font |
|------------|-----------|------------|-------|--------|---------|------|
| 깔끔하게 | Clean | Notion or Vercel | No | 8px | 4–7 | Geist / Pretendard |
| 모던하게 | Modern | Linear or Vercel | Yes | 6px | 4–7 | Geist / Outfit |
| 고급스럽게 | Premium | Apple or Stripe | Either | 0–4px | 1–3 | Satoshi / system thin-300 |
| 심플하게 | Simple | Vercel | Either | 0px | 1–3 | Geist |
| 따뜻하게 | Warm | Notion or Toss | No | 12px | 4–7 | Pretendard / Cabinet Grotesk |
| 재미있게 | Fun | Figma | No | 16px+ | 4–7 | Custom grotesque |
| 전문적으로 | Professional | Linear or GitHub | Either | 6px | 4–7 | Geist / Outfit |
| 대담하게 | Bold | Neobrutalism | No | 0px | 4–7 | Black 900 |
| 감성적으로 | Aesthetic | Editorial | No | 0–4px | 1–3 | Serif display |
| 트렌디하게 | Trendy | Ask for reference | Either | 12px | 4–7 | Variable font |

### Font Selection Guidelines (STYLE_SAMPLE)

- **Primary default**: Geist (modern SaaS, Vercel ecosystem)
- **Korean-first**: Pretendard — strong Korean-first default (Pretendard Variable
  available); verify brand/product font rules before claiming any specific Korean
  company standard
- **Warm/editorial**: Outfit or Cabinet Grotesk
- **Premium/luxury**: Satoshi or system thin weights
- **Avoid defaulting to Inter** (DEFAULT) — a widely recognized AI-generated-UI tell
  (judgment rule, not a measured fact). Use it when the user requests it or the project
  already uses it.