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

---

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

1. Delete: does the step/field earn its completion-rate cost? Every added decision

point taxes conversion and comprehension (Hick's law).

1. Absorb: can the system take the complexity instead of the user (Tesler's law) —

auto-detect, infer, remember last choice?

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

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. On EXPRESSIVE surfaces (landing/consumer/creative/AI-product), that default is the No-Brief Default Direction below (UX-DEFAULT-ISM-01); quiet surfaces keep quiet domain-correct defaults.

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

No-Brief Default Direction (UX-DEFAULT-ISM-01, DEFAULT — kit content STYLE_SAMPLE)

This is the UX-INTENT-01 step-3 FALLBACK, never a bypass: it fires only after

the Design Read and after the one blocking fork is resolved or unanswered, and

the applied direction is ALWAYS stated as an explicit assumption in the

deliverable. A named, specific, domain-gated direction replaces generic LLM

defaults; it must NOT reintroduce generic glassmorphism / centered-card /

beige-default taste under a new label.

Default kit for expressive surfaces: Liquid Editorial (2026 composite,

decided 2026-07-07 from Tier-2 trend research — see references/design-isms.md

§1.13 for the full signature):

• Structure: type-led editorial composition (oversized authored headline

scale, grotesk default, serif display only with editorial rationale per

UX-TYPE-01), tactile/photographic texture over flat gradient washes,

asymmetric content-weighted layout.

• Material accent: Liquid Glass or near-opaque pill chrome ONLY on floating

functional layers (nav/toolbars/chip clusters); pill-chip content units;

content layer stays solid (dev-frontend FE-LIQUID-LAYER-01).

• Motion: feedback baseline + exactly ONE signature moment

(pointer-proximity chips or scroll-driven reveal), per motion domain gates.

• Color: OKLCH-derived single accent + tinted neutrals (hue budget,

references/color-system.md).

Domain gate (STRICT): dashboards, admin, ops, finance, gov, B2B repeated-work

tools NEVER receive this kit by default — "fancy" never overrides domain

correctness (§ IA Chooser + dev-frontend product-density profiles).

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?"

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)

Filled-in example: references/design-read-example.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: <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).

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 (STYLE_SAMPLE)

• Typography stance (UX-TYPE-01): sans by default; serif only with brief/brand/editorial rationale. When justified (AI-product/editorial/research/trust surfaces), use the three-role system — display serif at light weights 330-400 + sans UI + mono accent — never serif-everywhere or as a bare AI-premium shortcut ("tasteslop", 2026); gates in dev-frontend aesthetics.md § Serif Discipline.

• 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
• Korean serif display: MaruBuri (Naver 명조/부리) 400-600 for editorial Hangul headlines, paired with Pretendard UI — see dev-frontend korea-2026.md § Korean Serif / Myeongjo Display
• 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.