dev-uiux-design

name: dev-uiux-design description: "UI/UX intent discovery, design vocabulary, product personalities, UX state patterns, typography line break judgment, favicon/product logo design, and logo trust section design. Use when user design direction is vague, when building onboarding/empty/error states, when setting up favicons or product logos, or when referencing a product aesthetic." 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]

UI/UX Design: Intent Discovery, Patterns & Product Vocabulary

Use this skill 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 aesthetics.md when the user cannot articulate a clear design direction. For anti-slop detection and banned patterns, defer to dev-frontend/references/core/anti-slop.md.

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 provides design judgment (when/why). dev-frontend provides implementation (CSS/HTML how). When both have a reference on the same topic (e.g., typography, logos), read this skill first for the decision, then dev-frontend for the code.

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.

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

1. User Intent Discovery Protocol

When the user's design request is vague ("깔끔하게 해줘", "모던하게", "just make it look good"), run this 6-step Socratic Scaffolding flow before generating any UI. Never produce generic output from vague input.

Skip this section if the user provided explicit design specs or this is a ≤5-line patch.

Rules:

• Ask a maximum of 6 questions before proposing a concrete direction.
• 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?"

Step 2 — Lightness

Ask: "밝은 화면이 좋으신가요, 어두운 화면이 좋으신가요?" / "Light or dark background?"

Step 3 — Density

Ask: "화면에 정보가 많이 보이는 게 좋으신가요, 여유롭게 보이는 게 좋으신가요?" / "Dense or spacious?"

Step 4 — Shape

Ask: "모서리가 각진 느낌이 좋으신가요, 둥근 느낌이 좋으신가요?" / "Sharp or rounded?"

Step 5 — Viewport Priority

Ask: "주로 어떤 화면에서 볼 건가요?" / "What's the primary viewing device?"

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:

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)

---
name: <project-name>
colors:
  primary: "<hex>"
  accent: "<hex>"
  background: "<hex>"
typography:
  heading: { fontFamily: <font>, fontSize: <size> }
  body: { fontFamily: <font>, fontSize: <size> }
---

Reading this as: for , with a language. <1-2 sentences: specific reference, not adjectives. "1970s lecture handout" > "modern and clean">

Do's: Don'ts:

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).

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

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.

Clarifying questions per term:

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

4. Quick-Match Table

Rapid lookup: user word → concrete starting point.

Font Selection Guidelines

• Primary default: Geist (modern SaaS, Vercel ecosystem)
• Korean-first: Pretendard (한글 최적화, Toss/당근 등 국내 서비스 표준)
• Warm/editorial: Outfit or Cabinet Grotesk
• Premium/luxury: Satoshi or system thin weights
• Avoid defaulting to Inter (DEFAULT) — it is the #1 AI-generated UI tell. Use it when the user explicitly requests it or the project already uses it.