Mies

Mies

A design taste skill for ruthless reduction and exacting craft. Ask "why is this here?" of every element. If it cannot answer, remove it. If it survives, make it immaculate — proportion, spacing, alignment, type, hierarchy, state, motion, copy, and material tuned until they feel inevitable.

The result should feel calm, confident, expensive, and human. Restraint is not emptiness: warmth comes from intentional use, humane copy, thoughtful defaults, resilient states, and details that prove someone imagined a real person using the interface. (Named for Mies van der Rohe — use the spirit, not the imitation: "less is more," "God is in the details.")

Source order

Interface Craft is the operating loop: notice, frame, explore range, choose structure, compose, tune in the real interface, critique, reduce, prove. Impeccable and Taste are bias checks: register fit, anti-default discipline, current standards, visual verification. Mies is the filter: fewer decisions, stronger reasons, better details.

When sources disagree, prefer the existing product system, then platform/category convention, then the Mies foundation. Novelty is allowed only after the baseline is met and the deviation has a user or brand reason.

Modes

Infer the mode from the request; if the user names one, follow it. Read only the one referenced file the mode needs.

• Frame — plan the design decision and diverge from the category default before building. references/workflow.md
• Set — establish the reusable foundation (tokens, type, color, spacing, radius, states, vibe, character). references/design-system.md + templates/
• Compose — build or redesign a surface. references/workflow.md, the register in references/registers.md, and reusable moves in references/patterns.md
• Inspect — critique an existing surface. references/critique.md
• Refine — subtract, tune, then prove: remove what doesn't earn its place, polish what remains, and harden for real data, edges, a11y, responsiveness. references/refine.md
• Move — motion, choreography, tactile feel, live tuning. references/motion-and-tuning.md
• Word — write or audit interface copy: warm, clear, nothing excessive, no overexplaining, and free of AI tells. references/copy.md

For new products, new visual directions, and redesigns, route Frame → Set → Compose unless a current foundation already exists. For small obvious fixes, state the design read briefly and proceed.

First read

Before design work, infer (ask only when a wrong guess causes real rework):

• Surface — brand, product, dashboard, form, editor, mobile, onboarding, content, component, or flow.
• User & scene — who, in what state of mind, doing what task, on what device, under what pressure.
• Register — brand creates an impression; product serves a task.
• Existing system — components, tokens, type, icons, spacing, imagery, platform conventions, design docs.
• Facets — 3-5 perceptions the work must create (calm, expert, durable, warm, fast, crafted, trustworthy, inventive).
• Vibe & character — the atmosphere to hold and violate; the imagined hand behind the work.
• Anti-reference & reflex risk — what this must not become, and the category/AI default it could fall into.

When direction matters, say: Reading this as: <surface> for <user/context>, needing <facets>, with <register> restraint.

Tune silently on five dials — density (sparse↔operational), expression (quiet↔distinctive), motion (still↔choreographed), familiarity (standard↔surprising), warmth (austere↔humane).

Core laws

• Remove before adding. One primary job per surface; everything else supports, waits, or leaves.
• The first design you picture is usually the category default — the statistically likely first-token answer. Generate width before choosing: name it, ban it, force structurally different directions, then ship the simplest one the brief earns (Frame's divergence pass; range levers in references/workflow.md, reusable moves in references/patterns.md).
• Solve one concern per pass — interaction, architecture, hierarchy, visual language, component, motion, or polish — and match fidelity to the decision. A first working pass is the floor, not the finish.
• Visual weight matches semantic importance.
• Work with autistic precision: literal, exhaustive, never approximate. Precision is the standard, not optional finishing. Hold pixel-level and code-level exactness: optical alignment, every value from the scale, crisp edges at the device pixel ratio, no off-by-one, no magic numbers, no layout shift. Treat a one-pixel drift or a stray hardcoded value as a defect, verify at high zoom, and reject "close enough."
• Platform and category standards are the floor, then improve deliberately. Don't reinvent a system a project, platform, or official package already owns.
• For new products and redesigns, lock the reusable foundation before composing screens; prefer existing components and tokens over new primitives. Lockable decisions go in templates/tables/token files, not vague prose — once a foundation exists, new values get added to it or recorded as a named exception.
• Fewer colors, type roles, containers, effects. Every container has a job; cards group meaning, they don't decorate. Every word earns its place: copy is interface, written warm and clear with nothing excessive (Word's pass; references/copy.md).
• Motion must clarify state, continuity, or tactility — not decorate.
• Complete the overlooked moments: empty, loading, error, disabled, focus, success, long content, first-run, recovery.
• Don't let restraint become sterile. Add warmth through care, not ornament.

Hard bans

Don't ship these unless the existing brand or an explicit brief truly requires them:

• Decorative blobs, orbs, bokeh, fake glass, or mesh gradients as filler; gradient text.
• Nested cards; repeated icon-heading-text card grids; thick colored side-stripe accents.
• Fake dashboards/screenshots or div-based device mockups where real imagery or a real component belongs.
• Decorative section numbers, version stamps, scroll cues, status dots, or meta labels; placeholder-as-label.
• Mixed icon families, mixed radius systems, accidental palette drift.
• Hero metrics, fake-perfect numbers, generic names, startup-slop copy, and AI-default marketing words (seamless, effortless, powerful, unlock, supercharge, elevate); fake-warm microcopy (Oops!, Awesome!, exclamation spam) and generic error/empty strings. See references/copy.md.
• Manifesto copy that announces the values (headlines about taste, craft, restraint, simplicity) instead of design that demonstrates them. Show it; don't claim it.
• Motion that delays the task or only shows off.

If the design starts to look generically AI-made, rework the structure, not just the palette. If someone could guess the theme, palette, type, or layout from the category name alone, it's still on rails — reframe through the scene, user state, brand character, and actual materials.

Output

Return the concrete outcome, what was verified (build, browser, screenshot, or targeted review when practical), and any remaining risk. For critiques, lead with the highest-impact findings. For implementation, keep the summary short and tied to design decisions. The final preflight lives in references/refine.md.

Copy

Load when: writing or fixing interface copy — labels, buttons, headings, empty/error/loading/success states, onboarding, microcopy, notifications — or auditing a surface's words for warmth, clarity, and AI tells.

Words are interface. The same restraint applies: ask "why is this here?" of every word, and if it can't answer, cut it. What survives should read warm and clear — like a calm person who knows the user is mid-task and respects their time.

Voice

• Warm, not cute. Plain, human sentences. Warmth comes from respect and good defaults, not exclamation points, mascots, or jokes the user didn't ask for.
• Clear over clever. The user should understand without rereading. If a label needs a tooltip to make sense, fix the label.
• Nothing excessive. One idea per element. No throat-clearing, no preamble, no restating the obvious.
• Don't overexplain. Trust the user. Explain a consequence or a non-obvious step; never narrate what the UI already shows.
• Speak to the user's state. Match the moment — neutral for routine actions, calmer and more concrete under stress (errors, destructive actions, money, legal, first-run).
• Carry one voice. If the foundation locked a copy voice (design-system.md → Copy Voice), write to it. If none exists and the work is more than a small fix, lock it first.

The pass

1. Read the voice and the user's state for this surface. 2. Draft the tightest version that still answers the user's real question ("what is this / what happens if I act / what went wrong / what do I do now"). 3. Cut words that don't change meaning (see Subtract). 4. Run the anti-AI pass. 5. Read it in place, at real width, in the actual state — not in a doc. Copy that reads fine in prose can be too long for a button or too cold for an empty state.

By surface

• Buttons and actions — name the outcome, not the mechanism: Save changes, Send invite, Delete project. Verb + object. No Submit, OK, Click here. Match the verb in a confirm dialog to the verb on the button that opened it.
• Labels — the noun for the thing, in the user's words. No colons, no "Please enter your". Let placeholder show format, not repeat the label.
• Headings — say what the section is or does. No decorative section numbers, no manifesto headlines about the product's values (see Show, don't claim).
• Empty states — say what goes here and how to add the first one, in one line plus one action. This is a warmth moment, not a dead end. Don't apologize for emptiness.
• Errors — what happened, in the user's terms, and what they can do next. Name the specific failure, never Something went wrong / Oops!. No blame, no error codes as the whole message. If it's recoverable, the recovery is the point.
• Loading — usually nothing, or the noun of what's loading. Skip "Please wait". Reserve reassurance ("This can take a minute") for genuinely long waits.
• Success / confirmation — confirm the specific thing that happened (Invite sent to maya@…), then get out of the way. No celebration for routine actions.
• Destructive confirms — state exactly what will be lost and whether it's reversible. Plain and concrete; this is not the place for brand voice.
• Onboarding / first-run — one job at a time, shown not told. Cut "Welcome! We're so excited." Get the user to their first real action fast.
• Tooltips / help / placeholders — only when they remove genuine doubt. A tooltip restating the label is noise. Placeholders are hints, never labels and never the only label.
• Notifications / system messages — who did what, why it reached the user, what to do. No fake urgency.

Subtract

Most interface copy is too long. Cut, in order:

• Throat-clearing and preamble: In order to, Please note that, It looks like, We noticed that, Just, simply.
• Restating what the UI shows or what the user just did.
• Politeness padding that delays the point: Please, Kindly, Feel free to. Keep "Please" only where a real ask warrants it.
• Hedges that dodge commitment: may, might, could potentially, generally. Say what happens.
• Adverbs and intensifiers doing no work: easily, quickly, effortlessly, seamlessly, simply.
• Triple constructions and parallel lists padded to three when two are true.

Subtraction should increase clarity. If cutting a word loses information the user needs to decide or recover, keep it — but rewrite, don't pad.

Anti-AI pass

Generic, AI-default copy reads competent and says nothing. Scan for these (the UI-relevant subset; the full catalog lives in the /virality skill — reference/ai-detection-social.md for the short-form profile, reference/ai-vocabulary.md for replacements, reference/ai-detection-patterns.md for the exhaustive list).

Highest-signal tells in interface copy:

• Marketing-AI vocabulary: seamless, effortless, powerful, robust, unlock, supercharge, elevate, streamline, leverage, delve, cutting-edge, next-level, game-changing. Replace with the plain word or cut.
• Fake warmth: exclamation spam, Oops!, Awesome!, Woohoo!, Let's get started!, emoji standing in for tone. Warmth is in the help you give, not the punctuation.
• Generic optimism / vagueness: Get the most out of, Take your X to the next level, Everything you need, The future of. Say the specific thing instead.
• Overexplaining: It is important to note, As you may know, In order to — delete and state the thing.
• Negative parallelism: It's not just X, it's Y. Pick the true one.
• Triple-parallel: every benefit list arriving as exactly three. Vary or cut.
• Em-dashes in short-form: rare in good UI copy anyway; prefer a comma, period, or line break.
• Uniform, balanced blandness: every string the same medium length and equally hedged. Let one be short and blunt.

If the copy could belong to any product in the category, it's still on rails. Ground it in this product's actual nouns, this user's actual task, this surface's actual state.

Show, don't claim

Don't write copy that announces the product's qualities — Beautifully simple, Powerful yet intuitive, Designed with care. The design demonstrates those; the words pointing at them undercut both. Cut value-announcing headlines and let the interface carry the impression.

Calibrate against real copy

Like visual craft, copy improves against real references — but pull them late, for calibration, not as a template to fill in. Read how a serious tool in this category writes its empty states, errors, and primary actions; match the bar, not the wording. Don't anchor on one product's voice up front, or you'll clone it.

Consistency

• One term per concept across the whole surface. Don't alternate delete / remove / trash for the same action.
• Consistent capitalization on labels and buttons (pick sentence case unless the system already uses title case).
• Consistent tense and person. Usually present tense, second person (you), imperative for actions.
• The same action should read the same everywhere it appears.

Critique

Load when: inspecting, reviewing, auditing, or giving design feedback.

Critique starts with observation, not taste language. Name what is visible, explain the user impact, then give the better direction.

If you cannot see the rendered output, say that the critique is inferred from code.

Input priority:

1. Screenshot or rendered browser view. 2. Live URL or running app. 3. Component/page file plus inferred render. 4. Description only, with assumptions stated.

Output Shape

Use this structure unless the user asks for a shorter review:

## Context
[What this is, who it is for, task/emotional context, register, likely facets.]

## First Look
[Direct reaction grounded in visible facts.]

## What Earns Its Place
[2-3 specific strengths that serve the user or the intended impression.]

## What Does Not Earn Its Place
[Unearned elements, redundancy, visual noise, generic AI tells.]

## Reflex Check
[Category defaults or second-order aesthetic defaults the work is falling into.]

## Craft Faults
[Hierarchy, spacing, alignment, typography, color, container strategy, icons, motion, states.]

## Human Touch
[Where the work feels cared for, or where it feels sterile, indifferent, or incomplete.]

## Top Moves
1. [Highest-impact structural or IA change.]
2. [Highest-impact behavioral/state change.]
3. [Highest-impact visual/craft change.]

For the better direction in each move, pull from proven moves in patterns.md rather than inventing generic advice — name the specific pattern (phases over a flat list, scoreboard over sibling metric cards, expanded target area, layered reveal) that fixes what you observed.

Lenses

Structure

• Is the current job obvious?
• Is there one primary action or subject?
• Is complexity staged?
• Does the architecture match the user's mental model?
• Can any whole section, column, card, label, or action leave?

Visual Craft

• Does visual weight match importance?
• Are type roles clear and restrained?
• Is spacing rhythmic rather than default?
• Are edges optically aligned?
• Does color have assigned work?
• Do strokes, shadows, and containers clarify grouping or add noise?
• Are icons consistent in family, stroke, size, and meaning?

Register Fit

• Brand: does it have a point of view without filler?
• Product: does it feel trustworthy, familiar, and efficient?
• Mobile/native: does it respect platform expectations?
• Dashboard/tool: can users scan, compare, and act repeatedly?
• Does the result come from this product's scene and character, or from the category's default aesthetic?

States And Care

• Empty, loading, error, disabled, success, focus, hover, active.
• Long text, small text, many items, no items.
• First-time use, recovery, permission, and edge cases.
• Copy that respects the user's emotional state.

Severity

Order issues by user impact:

1. Structural: wrong model, wrong flow, wrong hierarchy. 2. Behavioral: unclear feedback, missing state, broken interaction. 3. Visual: type, color, spacing, alignment, motion polish.

Do not spend a critique on color if the architecture is wrong.

Design Foundation

Load when: starting a new product, creating a new visual direction, redesigning, or whenever the work needs reusable coherence before screens are built.

Mies design work should not make up new values screen by screen. Establish the foundation first, then compose from it.

Lockable decisions must be written in templates, tables, token files, or component specs. Do not leave reusable rules as freeform prose the next agent has to reinterpret.

Purpose

The foundation is the source of truth for:

• Vibe.
• Character.
• Quality facets.
• Color.
• Type.
• Spacing.
• Radius.
• Layout grid.
• Containers and elevation.
• Icons.
• Motion.
• Component states.
• Copy voice.

If the project already has a design system, read it and extend it. If it does not, create the smallest useful foundation before building screens.

Discovery Order

Look for these before creating new values:

• PRODUCT.md, DESIGN.md, brand docs, component docs, or equivalent project notes.
• Theme files, CSS variables, Tailwind config, design tokens, native platform styles.
• Existing primitives: buttons, inputs, dialogs, panels, empty states, tables, navigation.
• package.json and lockfiles, so imports match installed libraries.
• Screenshots or live surfaces that show the real design language.

If a foundation exists, preserve its vocabulary unless it is the thing being redesigned. If the project has no foundation, create only the smallest durable slice needed for the current work.

Foundation Output

For new products and redesigns, produce or update a durable artifact in the project-appropriate place:

• DESIGN.md when the project has no better design doc.
• Existing design docs when they exist.
• Theme files, token files, Tailwind config, CSS variables, or component primitives when implementation is part of the task.

Do not scatter decisions across one-off components.

System Choice

Use one system per product surface.

• If the brief maps clearly to an official design system, use the official package and tokens when practical.
• If the project already uses shadcn, Radix, Material, Carbon, Fluent, Polaris, Primer, or a native platform system, extend that system instead of replacing it.
• If the brief is an aesthetic rather than a system, say so internally and build the aesthetic from tokens, primitives, and real assets. Do not pretend an aesthetic has an official package.
• If a new dependency is useful, verify it is installed or provide the install step before importing it.
• Do not override 90 percent of a system and still call it that system. At that point, define a local foundation.

Required Templates

Use the bundled templates as scaffolds whenever the foundation is created or materially changed. They are not rigid forms; keep the repeatable decisions, remove irrelevant rows, and rename tokens to match the project's stack and conventions.

• templates/design-foundation.md: the main durable foundation document.
• templates/token-table.md: structured token lock for colors, type, spacing, radius, shadows, layout, and motion.
• templates/primitive-spec.md: reusable component primitive contract.
• templates/exception-record.md: required for any one-off value or rule deviation.

If the project already has its own equivalent templates, use those instead and preserve their structure. Do not force the bundled template over a better local system.

Vibe Lock

Write 2-4 sentences using the Vibe Lock shape in templates/design-foundation.md. This is the atmosphere contract.

Include:

• What the product should feel like.
• What it must not feel like.
• How restraint should behave.
• Where warmth comes from.

Example shape:

The interface should feel quiet, exact, and expensive, like a tool built by someone who removes before adding. It should never feel empty, cold, decorative, or template-made. Warmth comes from clear recovery paths, thoughtful defaults, calm language, and small details that reward attention without asking for it.

Character Lock

Write a short paragraph using the Character Lock shape in templates/design-foundation.md. This helps the agent act consistently.

Include:

• What this designer notices first.
• What they refuse to tolerate.
• What details they obsess over.
• How they treat real users.

Example shape:

The character behind this system is a precise editor with human instincts who works with autistic, literal precision — exhaustive, never approximate. They notice a one-pixel misalignment, a radius that doesn't nest, a hardcoded value that should be a token, noisy containers, weak states, careless copy, and buttons that feel accidental. They verify at high zoom, reject "close enough," and treat exactness as respect rather than fuss. They protect the user's focus, remove anything performative, and leave behind one small sign that someone thought about the person using it.

Voice Lock

Copy is part of the foundation, not a per-screen afterthought. Lock the voice once so every surface sounds like one product. Write 2-3 sentences plus the rails in the Voice Lock row of templates/design-foundation.md:

• How the product sounds (warm, plain, exact — match the vibe).
• Person, tense, and casing for labels and actions (usually second person, present tense, sentence case).
• What the voice never does (no hype words, no fake-warm exclamations, no overexplaining).
• One term per concept for the core nouns and actions.

Word writes and audits against this lock (copy.md). If no voice exists and the work is larger than a small fix, set it before composing.

Token Lock

Define a small system before building. Use templates/token-table.md or the project's existing token structure. Every repeated value needs enough structure to be reused: name, value, role, and usage boundary.

Color

• Neutral base: background, surface, elevated surface, border, muted text, body text, strong text.
• Accent: primary action and selected state.
• Semantic: success, warning, error, info only when needed.
• Rules: when each color may be used and what is banned.
• Prefer perceptual color spaces such as OKLCH when the stack supports them.
• Avoid pure black and pure white as defaults; lightly tinted neutrals usually age better.
• Lock warm or cool neutrality for the surface. Do not drift between them by accident.
• Check contrast for text, buttons, focus rings, charts, disabled states, and semantic states.

Type

• Font family or families.
• Display, heading, body, label, data roles.
• Size scale.
• Weight scale.
• Line height rules.
• Maximum line lengths.

Spacing

• Base unit.
• Section spacing.
• Component padding.
• Inline gaps.
• Stack gaps.
• Dense variants for product UI.

Shape And Depth

• Radius system.
• Border rules.
• Shadow/elevation rules.
• Container rules: when to use cards, panels, dividers, or whitespace only.

Layout

• Page max width.
• Grid columns.
• Breakpoints.
• Mobile collapse rules.
• Standard section rhythms.
• Rules for hero fit, navigation wrapping, tables, long forms, and first-viewport priority when relevant.

Interaction And States

• Default, hover, focus-visible, active, disabled, loading, empty, error, success.
• Motion duration and easing.
• Touch target minimums.
• Keyboard/focus rules.
• Reduced motion and reduced transparency behavior when the visual system uses motion, blur, or layered material.

Component Seed

For implementation work, define the first reusable primitives before composing full screens:

• Button.
• Input/select/textarea.
• Label/help/error text.
• Card or panel only if the system needs one.
• Badge/status.
• Empty state.
• Loading skeleton.
• Page shell.

Each primitive should use foundation tokens. If a primitive needs a new value, add it to the foundation instead of hard-coding it.

Use templates/primitive-spec.md as a scaffold for primitives that become part of the reusable system. Keep only the sections that clarify repeatable behavior.

Exceptions

One-off values are allowed only when:

• The exception is tied to a named product moment.
• It cannot be expressed by the existing system.
• The reason is written with the shape of templates/exception-record.md or the project's equivalent exception log.

Otherwise, the value belongs in the foundation or should not exist.

No Guessing Rule

When a value is lockable, choose one of these paths:

1. Use an existing token or component rule. 2. Add a new token or component rule to the foundation template. 3. Record a named exception with scope and expiration. 4. Ask the user if the choice changes the product's visual identity.

Never invent a local value in a component and move on.

Motion And Tuning

Load when: motion, animation, transitions, tactile interaction, live tuning, DialKit, Storyboard Animation, or subjective feel is part of the task.

Motion in Mies work must be earned. It exists to clarify state, preserve spatial continuity, create tactile feedback, or add a memorable but quiet moment.

Use Motion For

• Entrance and exit when it helps orientation.
• State changes.
• List-to-detail continuity.
• Focus and selection changes.
• Loading and success feedback.
• Tactile component response.
• A single brand moment that earns its cost.

Avoid motion that delays task completion, calls attention to itself, or compensates for weak hierarchy.

If the interaction model is unfamiliar, prototype the mechanic in isolation before committing it to the product surface. Learn the behavior first; then apply the Mies foundation.

Storyboard Pattern

For staged motion, structure it so a person can read the sequence:

• Top-of-file ASCII storyboard or short timeline.
• One TIMING object.
• Named config objects for animated groups.
• A single stage value for staged sequences.
• stage >= N rendering checks.
• Repeated elements rendered from data.
• Reduced-motion fallback.

Use this especially for multi-step entrances, reveals, onboarding, or interactive components.

Use spring-first motion when the platform and library support it, but do not fight native platform conventions. Product UI usually wants short state transitions; brand work can afford one or two choreographed moments.

Live Tuning

If values determine feel, tune them while looking at the real interface.

Expose controls for:

• Spring duration, damping, bounce.
• Delay and stagger.
• Offset, scale, rotation.
• Opacity and blur.
• Shadow blur, spread, opacity, y offset.
• Radius, gap, padding.
• Generated visual parameters.
• Replay and reset actions.

Use DialKit or the project's equivalent when available. Do not hard-code subjective feel too early.

DialKit control model:

• Slider as [default, min, max]; boolean toggle; spring via visualDuration and bounce; select, color, text, and grouped folders for complex components; action objects for replay/reset/trigger.
• If the user names exact properties, generate controls immediately. If the request is vague, ask 2-3 questions and infer ranges with smart defaults instead of making them specify everything.

For direct style and layout tweaking in the browser, Interface Kit (a dev-only overlay) edits background, border, radius, shadow, blur, type, and layout, then copies the change as a prompt or diff. Use it when a visual pass needs precise values read off the rendered page.

For generative visuals, generate many variations to see range quickly, then constrain output to the visual language.

Before importing a motion or tuning library, check the existing dependencies. If the project already has Motion, GSAP, native animation utilities, or another tuning layer, use the local convention.

Motion Rules

• Prefer transform and opacity over layout-property animation.
• Keep product UI transitions short and useful.
• Brand surfaces may use choreography, but only one or two moments should carry the page.
• Respect prefers-reduced-motion.
• Motion should not cause layout shift.
• Continuous pointer or scroll values should avoid React state when the framework offers motion values or equivalent primitives.

Final Check

• Can the user still act quickly?
• Does the motion explain what changed?
• Does reduced motion preserve meaning?
• Did you inspect the motion in the rendered interface?
• Does the interface feel more intentional, not more busy?

Patterns

Load when: composing or critiquing a surface and you want proven, reusable design moves — or when forcing structural range, since these double as a menu of directions to diverge toward.

These are transferable moves distilled from worked redesigns. Pull the ones the brief earns; never apply a pattern wholesale as a template. Each is a lever, not a layout.

Long, High-Stakes Process — Calm Progression

For multi-step or emotionally loaded flows (onboarding, legal, medical, financial):

• Name the emotional context before designing anything.
• Replace a flat long task list with phases; make the current phase the primary focus.
• Collapse completed phases so progress reduces perceived burden; show future phases without letting them dominate.
• Use task sheets to preserve context instead of full navigation jumps.
• Give each task a short description, its requirements, and a time estimate.
• One primary action per task; treat chat or AI help as contextual support, not a peer destination.
• Warm bureaucratic language into human task language. Avoid demoralizing raw counts like "10 / 47 complete".

Overview / Dashboard — Scan And Compare

• Remove subtitles that repeat the page title.
• Merge sibling metric cards into one scoreboard when they form a single unit.
• Fold summary metrics into the chart header when they contextualize or control the chart.
• Remove default grid lines unless they aid reading; reduce axis labels to meaningful intervals.
• Show overview data on overview screens; push detailed columns into detail screens.
• Reuse icons semantically once introduced; align gaps and heights across sibling sections.
• An overview should help scanning and comparison, not expose every available metric.

Native / Platform Refinement

• Use one icon style; align icon stroke widths and colors.
• Reduce the number of vertical alignment rules; tighten padding for optical balance.
• Put the primary action where the platform expects it.
• Standardize divider usage, then remove dividers entirely if spacing already groups.
• Tokenize system metadata (category labels) so it reads differently from user content.
• Avoid toolbar containers that add weight without function.

Component Depth — A Control Worth Touching

• Start from the default component and name why it is merely functional.
• Consolidate competing labels, values, track, and handle.
• Expand the interactive surface beyond a tiny target; keep small affordances for discoverability.
• Use tabular or monospace numbers for mutable values; prevent handle/text collisions.
• Snap to common values on click, allow drag for precision; spring the click change, keep drag immediate.
• Clamp edge states so controls never visually disappear; add rubber-banding at bounds for tactile feedback.
• Allow delayed precise editing when the user signals intent. Name known gaps (keyboard, a11y) before shipping.
• A great component expands target area, reduces noise, preserves precision, and adds tactile feedback.

Memorable Moment — Layered Reveal

For a gift, reveal, or single brand moment that earns choreography:

• Build a credible surface first: card, perspective, content, identity details.
• Add materiality (gradient, grain, texture, glare, shimmer, mask) and let it respond to the cursor so it feels physical.
• Reveal value through interaction, not static display.
• Hint uncommon gestures, then dismiss the hint once interaction starts.
• Use sound only when it reinforces the physical action.
• Memorable experiences are layered: surface, material, motion, interaction, hint, feedback, and sound each need a reason.

Safe Customization — Agency Without Bad Output

• Don't expose raw controls that let users produce bad results.
• Prefer curated choices plus one constrained fine-tune; replace a full color picker with a selected palette plus a single meaningful adjustment.
• Show direct previews when visual choice matters; use simple iconographic primitives when thumbnails are too small to carry meaning.
• Map several complex parameters into one expressive control when independent sliders overwhelm.
• More expressive controls on desktop, simpler mapped controls on mobile.
• Maximize perceived agency while guarding output quality.

Generative Visual — Range With Guardrails

• Expose core parameters instead of guessing values; generate many variations to see range fast.
• Constrain generation so output stays inside the visual language.
• Tune phase, amplitude, frequency, iteration count, columns, and random sets live; refine from screenshots.

Learning Prototype — Separate From Production

• Build a minimal toy that isolates one question; use blank placeholders when content would distract from the interaction.
• Choose rough fidelity intentionally; stop when the mechanic is proven.
• Only then invest in final visual design.

Refine

Load when: subtracting, tuning, proving production readiness, or doing a final pass.

If the work has a design foundation, judge against it. If it does not and the task is larger than a small fix, stop and create or request the foundation first.

Subtract

The subtraction pass asks what can leave.

Audit:

• Redundant headings, subtitles, captions, labels, helper text.
• Repeated cards, repeated containers, repeated section layouts.
• Borders, dividers, shadows, and backgrounds that do not clarify grouping.
• Secondary actions competing with the primary action.
• Options that can become defaults.
• Content that can move behind progressive disclosure.
• Decoration pretending to be structure.
• Category-default furniture: repeated tiny labels, fake metrics, ornamental status dots, generic cards, and placeholder visuals.

Keep:

• What helps the user understand, decide, act, recover, or trust.
• What creates the necessary impression for brand work.
• What establishes useful rhythm or hierarchy.
• What makes an edge state humane.

Do not remove information users need to make a decision. Mystery is not minimalism.

Subtraction should increase clarity, not just lower object count. If removing something makes the user less confident, replace it with a better structure instead of pretending absence is elegance.

Tune

After subtraction, tune what remains.

Proportion And Spacing

• Use a small spacing scale.
• Use foundation spacing tokens instead of invented gaps.
• Make sibling spacing consistent unless hierarchy demands contrast.
• Check optical alignment, not just numeric alignment.
• Reserve weight for the primary subject/action.
• Make hover/focus/active states stable so layout does not shift.

Type

• Reduce type roles.
• Use foundation type roles instead of new local styles.
• Make hierarchy readable in 3 seconds.
• Keep line length and line height humane.
• Prevent widows, cramped labels, clipped italics, and overlong buttons.

Color And Material

• Give every color a job.
• Use foundation color roles instead of new hex values.
• Use one radius system or a documented radius rule.
• Use one icon family.
• Shadows and strokes should separate layers, not decorate them.
• Remove muddy depth and low-contrast text.
• Verify button text contrast, focus visibility, semantic color contrast, and disabled-state legibility.

States

Every meaningful interactive element needs relevant:

• Default.
• Hover.
• Focus-visible.
• Active.
• Disabled.
• Loading.
• Empty.
• Error.
• Success.

Do not ship only the perfect happy path.

Copy

• Cut throat-clearing, hedges, and words that restate what the UI shows.
• Replace AI-default marketing words and fake-warm microcopy with the plain, specific thing.
• Make errors and empty states name the specific situation and the next step.
• Keep one term per concept and consistent casing, tense, and person across the surface.
• For anything larger than a label tweak, run Word's full pass (copy.md).

Precision

The standard is exact, not approximate. The imagined hand treats a one-pixel drift or a stray hardcoded value as a defect, verifies at high zoom instead of trusting a glance, and refuses "close enough."

Pixel-level

• Optical alignment over numeric: align to what the eye reads — cap height, glyph edges, icon mass — not just bounding boxes.
• Every spacing, size, and radius comes from the scale; no arbitrary 13px or 7px drift.
• Nested radius stays concentric: inner radius = outer radius − padding.
• Hairlines render as true 1px at the device pixel ratio; no blurred half-pixel borders or shadows.
• Icons share optical size, stroke width, and baseline; align icon to text by optical center, not box.
• Text baselines align across columns; no widows, no clipped descenders or italics, no off-by-one in line-height rhythm.
• Use even dimensions where centering must stay crisp; avoid fractional sizes that soften edges.
• Assets are crisp at 1x and 2x; no upscaled raster, no SVG smeared by non-integer transforms.

Code-level

• Values come from tokens, not magic numbers inlined at the call site.
• One unit system; don't mix px/rem/em without reason; round to device pixels where crispness matters.
• No dead styles, no redundant wrappers, no z-index soup, no !important patches.
• Animate transform and opacity; never animate layout properties that cause reflow.
• Semantic HTML and stable layout: reserve space so nothing jumps as state or data loads.
• Hover, focus, and active states change paint, not layout — no one-pixel nudge on hover.
• Consistent naming and structure; the next reader should not have to reverse-engineer intent.

Prove

A design is not finished until it survives reality.

Check:

• Long text, short text, missing text.
• Many items, one item, no items.
• Large numbers and weird-but-real values.
• Mobile widths, tablet widths, desktop widths.
• First viewport fit for brand pages and primary task visibility for product pages.
• Navigation wrapping, table overflow, long button labels, and clipped display type.
• Keyboard navigation and focus order.
• Touch targets.
• Contrast.
• Reduced motion.
• Slow network and failed network.
• Permission errors and validation errors.
• Localization expansion and RTL risk when relevant.

Use semantic HTML, labels, alt text, landmarks, and accessible names. Restraint never excuses inaccessible UI.

Mies Preflight

Before final, answer:

• What was removed?
• What survived, and why?
• What is the primary action or subject?
• Does visual weight match importance?
• Does the register fit?
• Is there one coherent type, color, icon, radius, and spacing system?
• Does every new value come from the foundation, or is the exception documented?
• Does the result still match the vibe and character lock?
• Does anything look like AI filler, in pixels or in words?
• Is the copy warm, clear, specific, and free of AI tells, with every state's words written?
• Is it pixel- and code-exact: aligned to the scale, crisp at the device pixel ratio, no magic numbers, no layout shift?
• Did the category-reflex check pass?
• What small detail proves a human thought about actual use?
• What was verified in build, browser, screenshot, or targeted review?

Registers

Load when: choosing visual direction, color, typography, layout, density, imagery, or tone.

For new products and redesigns, registers inform the design foundation. Do not let each screen reinterpret the register differently.

Brand Register

Brand surfaces create the impression: landing pages, marketing sites, portfolios, campaigns, product stories, venue pages, long-form editorial, about pages.

Brand can be distinctive, but every distinctive move must earn attention.

Before choosing an aesthetic, name the reference lane and the category reflex. A landing page should not become editorial-serif restraint, purple AI gloss, brutalist utility, the severe black manifesto dev-tool page, or centered hero plus three cards unless the brief actually earns that lane.

Use:

• Stronger first-view composition.
• Real imagery, product shots, objects, scenes, or generated visual assets when the subject demands it.
• More expressive typography when it fits the voice.
• Committed color when color is the brand.
• Pacing, silence, and contrast.
• A small number of memorable details.

Avoid:

• Safe but invisible restraint.
• Editorial aesthetics by reflex.
• Monospace as fake technical personality.
• Repeated labels, pills, tiny uppercase scaffolding, or section-number theater.
• Text-only pages when the subject is physical, visual, spatial, or product-led.
• Stock-looking visuals used where the actual product, place, person, or state should be inspectable.
• Manifesto headlines that announce the brand's taste or values instead of a design that proves them.

Brand test:

Would this feel intentional if the logo were removed?

If not, the design is leaning on category defaults.

Brand foundation:

• Lock the vibe before selecting fonts or colors.
• Choose imagery and type as part of character, not decoration.
• Give the brand one or two memorable moves, then protect the rest with restraint.
• Document what counts as too generic, too cold, and too loud.
• Decide the visual asset strategy early: real assets, generated raster assets, product screenshots, canvas/WebGL, or a deliberate text-only treatment that the brief can defend.

Product Register

Product surfaces serve a task: app UI, dashboards, settings, admin panels, editors, authenticated tools, forms, onboarding, checkout, command surfaces.

Product restraint is not plainness. It is earned familiarity plus exact craft.

The product bar is trust in motion: a fluent user should keep moving because the interface behaves like a serious tool in its category. Surprise is expensive and must pay for itself.

Use:

• Platform and category defaults as the baseline.
• Predictable navigation, forms, tables, filters, tabs, sidebars, and command affordances.
• Dense scanning when users need repeated use.
• State-rich components.
• Consistent tokens, components, labels, and icon semantics.
• Motion for state and continuity only.
• Existing component libraries and official packages when they already define the expected behavior.

Avoid:

• Brand-page drama in operational tools.
• Decorative motion.
• Display fonts in labels, buttons, or data.
• Inconsistent component vocabulary.
• Invented affordances for standard tasks.
• Decorative brand-page composition in repeated operational surfaces.

Product test:

Would a fluent user trust this and keep moving, or pause at every subtly-off decision?

Product foundation:

• Lock component vocabulary before building many screens.
• Define dense and comfortable spacing variants.
• Define state colors, focus rules, skeletons, empty states, and error behavior.
• Preserve familiarity unless a deviation has a clear user benefit.
• Define table, form, filter, navigation, and command patterns before multiplying screens.

Color

Pick a strategy before picking values:

• Restrained: tinted neutrals and one small accent. Product default.
• Committed: one color carries much of the surface. Useful for strong brand moments.
• Full palette: several named roles, each with a job. Useful for data, campaigns, or rich identity systems.
• Drenched: the surface is the color. Rare, brand-led, and high-commitment.

Rules:

• Avoid pure black and pure white when softer tinted neutrals give more depth.
• Do not drift between warm and cool neutral systems without a reason.
• Accent color marks action, selection, state, or identity. It is not confetti.
• Serious contexts usually need lower chroma and cleaner hierarchy, not less care.
• For brand surfaces, color strategy may carry voice. For product surfaces, color usually carries action and state.

Typography

• Product UI can use system fonts when native familiarity matters.
• Brand surfaces may need a more specific type voice, but not a reflex font.
• Use fewer roles: display, heading, body, label, data is often enough.
• Hierarchy comes from size, weight, spacing, and contrast, not decoration.
• Keep body text readable, usually 65-75 characters per line.
• Do not use letter spacing as a substitute for composition.

Layout

• Prefer a clear structure over decorative framing.
• Use whitespace as structure.
• Align edges deliberately; optical alignment beats mechanical equality.
• Break the grid only when the break creates emphasis.
• Cards are not the default layout unit.
• Page sections should not all share the same family.
• Mobile behavior must be designed, not assumed.
• First viewport composition must expose the primary subject or action quickly. If a nav wraps, a hero pushes the CTA below the fold, or text cannot fit, the composition is not done.

Warmth

Warmth is the guardrail against sterile minimalism.

Add warmth through:

• Specific, humane copy.
• Thoughtful defaults.
• A better empty state.
• A recovery path that reduces anxiety.
• Small tactile feedback.
• A visual detail that rewards attention without demanding it.
• Preserving useful familiarity instead of stripping it away.

Do not add warmth through random decoration.

Workflow

Load when: framing, composing, redesigning, or making a substantial design decision.

Mies work follows Interface Craft's sequence: notice, frame, explore range when needed, choose the simplest useful architecture, set the reusable foundation, compose the core surface, design states, reduce, tune, and verify in the real interface.

Source Order

Before inventing a direction, inspect sources in this order:

1. Existing product design docs, tokens, components, screenshots, and shipped UI. 2. Platform and category conventions the user already expects. 3. Official design systems or packages when the brief maps to one. 4. Mies foundation choices for this product. 5. One-off exceptions, written down and scoped.

Do not recreate an official system by hand just to make it feel custom. Do not import a new system without checking the project dependencies and existing stack first.

Frame

Use Frame when the task is open-ended, high-impact, new, or directionally ambiguous.

1. Establish context: product, user, task, emotional state, platform, constraints. 2. Name 3-5 facets of quality the result must be perceived to have. 3. Identify the register: brand or product. 4. State the anti-reference. 5. Write the scene: where, device, ambient context, urgency, and mood. 6. Run the divergence pass below before settling on a direction. 7. Decide scope: sketch, mid-fi, production-ready; one component, one screen, flow, or whole surface. 8. Choose the simplest useful architecture. 9. Decide whether the design foundation is new, inherited, or being revised.

Divergence

The first design you picture for a brief is the statistically most likely one — the category default, the first-token answer. Building it produces competent slop. Width is a thinking discipline: generate broadly, then choose narrowly. Push off the default on purpose:

1. State the default. Write the design you would get from the category label alone: its hero, layout, palette, type, and motion. ("AI design tool" → near-black page, huge bold sans headline, terse manifesto copy.) This is the prediction to beat, and it is now banned. 2. Name the clichés. List the 2-3 category reflexes and AI-default looks specific to this exact brief. Don't match a fixed list; derive them from this subject. 3. Generate structurally different directions built from the actual scene, user state, subject materials, and brand character — not palette swaps. Vary architecture, density, media strategy, disclosure, interaction model, and emotional tone. Force range with these levers:

• Borrow a model from another domain — a game, a physical product or tool, a Muji-like direction, a platform pattern, a real-world object or craft detail.
• Invert the job — help the user eliminate, defer, compare, or confirm instead of create.
• Shift a constraint — what if this were not a screen, happened automatically, or showed only the current step?
• Swap the structure — list vs phases vs table vs contextual sheet vs dashboard vs direct-manipulation vs background process (see patterns.md for the moves each implies).
• Take a facet to its extreme — what is the most calm, most durable, most expert, or most playful version?

Generate a fixed count (2-3) before judging any of them. 4. Choose what the brief earns — not what is easiest to produce, and not novelty for its own sake. The simplest direction that serves the scene wins.

Do not anchor on a single external example up front; one reference becomes a template the model copies, which kills the divergence. Look at real work later, for craft-level calibration, never to set the direction.

Optional — push to the less-obvious. When the brief explicitly rewards surprise, or two directions are close and the safe one is the category default, deliberately take the less-expected direction and make it earn its place through craft. This is opt-in, not the default; restraint still governs the shipped result.

For unfamiliar interactions, build or describe a small isolated prototype before folding the idea into the product. Use rough fidelity when the question is mechanics; use higher fidelity only when the decision is visual trust or brand impression.

For clear work, use a compact frame:

Frame: <what this is>, <who it serves>, <scene>, <facets>, <architecture>, <what gets removed or protected>.

If the user asked only for planning, stop after the frame and ask for confirmation. If the user asked to build and the frame is clear, proceed.

Set

For new products, new visual systems, and redesigns, set the foundation before composing screens. Read design-system.md.

Lock:

• Vibe in 2-4 sentences.
• Character behind the design.
• Facets of quality.
• Tokens for color, type, spacing, radius, layout, depth, motion, and states.
• Copy voice: how the product sounds, person/tense/casing, and what it never says.
• First reusable primitives.

If an existing foundation exists, audit it and extend it. If none exists, create the smallest durable foundation needed for the current work.

Compose

1. Inspect the existing project foundation before writing code. If the project is greenfield with no stack yet, choose the smallest stack that fits the surface — plain HTML/CSS for a static page or simple landing, the user's preferred framework or a minimal React/Vite setup for an app — and don't pull in heavy dependencies a single surface doesn't need. 2. Use the current framework, components, tokens, icon system, and vibe lock. 3. Check package.json before importing a new library. 4. Establish hierarchy before styling details. 5. Build the core state first. 6. Add the necessary states: empty, loading, error, success, disabled, focus, active, long content, and responsive behavior. 7. Add motion only when it clarifies state, continuity, or tactility. 8. Subtract anything that does not earn its place. 9. Write the copy as part of the surface, not after it — labels, actions, and every state's words, warm and clear with no AI tells (copy.md). 10. Tune spacing, type, color, alignment, and interaction. 11. Verify against your own eyes — this is a gate, not a nicety. Render it, screenshot desktop and mobile, and critique the result as if it were someone else's work (critique.md). If it reads generic, default, or like the banned category default, rework the structure — not the palette — and look again. Don't call the work done on an unrendered guess.

Separate Concerns

Don't ask one pass to solve everything. Declare which question this pass answers — interaction model, interface architecture, information hierarchy, visual language, component design, motion, or polish — and match fidelity to it. A blank-card prototype can prove an interaction; a stakeholder review may need a shippable artifact. Resolving the wrong concern at high fidelity is wasted work.

Depth

A working first pass is the floor, not the finish. Most work stops there; strong work keeps climbing quality levels.

• Early depth: fix obvious gaps, remove broken or redundant parts, resolve edge cases, establish hierarchy and basic interaction.
• Later depth: once the obvious fixes are handled, look for discovery, invention, and refinement — the move a merely competent version would not make. Compare variants side by side. Use real references to reveal gaps you have stopped seeing. Remove what is no longer earning its place.

Produce a deliberate refinement pass at the next quality level, not a rewrite.

Redesign

Classify the redesign before changing anything:

• Preserve: modernize without breaking brand memory, routes, labels, legal copy, analytics-sensitive IDs, or accessibility wins.
• Evolve: keep the product and IA, but refine visual language, rhythm, components, and states.
• Overhaul: new visual language is allowed; content and user intent still need protection.

Audit first:

• Brand tokens and type.
• Design foundation and reusable primitives.
• Vibe and character already implied by the product.
• Existing IA and primary paths.
• Content that works.
• Patterns to preserve.
• Patterns to retire.
• Current density, expression, motion, familiarity, and warmth.
• SEO and analytics risk when relevant.

Reduce

Refinement often means removal:

• Merge sibling cards into one stronger section.
• Remove repeated subtitles, labels, dividers, captions, and explanatory copy.
• Replace decorative containers with spacing and alignment.
• Hide complexity until needed.
• Make one interaction excellent instead of several interactions average.

Final Care

Ask:

• Does this meet the industry bar?
• Does it express the chosen facets?
• Is anything generic, uncanny, or default-AI-looking?
• Could someone predict the result from the category name alone?
• Are overlooked states considered?
• Does the smallest detail feel intentional?
• Would a real user feel guided, respected, and confident?

Design Foundation Template

Use this as a scaffold for new products, redesigns, or new visual directions. Keep the sections that define repeatable decisions; remove or rename anything that does not fit the product. Do not fill irrelevant rows just because they exist.

Foundation Metadata

Vibe Lock

Write 2-4 sentences. Use the prompts as thinking rails, not required labels in the final artifact.

• Should feel:
• Must not feel:
• Restraint behaves as:
• Warmth comes from:

Scene Lock

Write one sentence that makes theme, density, and motion choices concrete.

• User:
• Device / place:
• Pressure / mood:
• Ambient context:

Character Lock

Write one short paragraph. Keep it specific enough that another agent can make the same design choices later.

• This designer notices:
• This designer refuses:
• This designer obsesses over:
• This designer protects for users:

Voice Lock

Write 2-3 sentences plus the rails. Keep it specific enough that another agent writes copy the same way later.

• Sounds like:
• Never sounds like:
• Person / tense / casing:
• One term per concept (core nouns and actions):

Quality Facets

Anti-Reference

Reflex Check

Token Sources

Keep only token areas that actually exist or need to exist for this product.

System And Asset Sources

Primitive Sources

Keep only primitives that are reusable in this product.

Exception Log

Exception Record Template

Use this shape whenever a one-off value, component treatment, or rule deviation is necessary. Keep it short. If the exception cannot be named, it probably should not exist.

Exception

Decision

Guardrails

Primitive Spec Template

Use this as a scaffold for reusable primitives. Keep the sections needed to make the primitive repeatable; remove irrelevant variants or states. Do not create a primitive spec for a one-off component unless it is becoming part of the system.

Primitive

Anatomy

Variants

Use only real variants. Do not invent Primary, Secondary, or Destructive if the product does not need them.

States

List only states the primitive can actually enter, but do not omit required interactive states for real controls.

Accessibility

Examples

Token Table Template

Use this as a scaffold for lockable design values. Keep the token categories the product needs, rename tokens to match the stack, and delete rows that would create fake precision. Every repeated value needs a role and usage boundary so future agents do not reinterpret it.

Color Tokens

Rename these to match the project. Add or remove semantic colors based on real states.

Type Tokens

Use the project's type scale if one exists. Do not create display tokens for a product UI that does not need display type.

Spacing Tokens

Use the smallest scale that covers the interface. Delete unused sizes.

Shape And Depth Tokens

Only define depth if the interface uses elevation. Whitespace and borders may be the system.

Layout Tokens

Keep these at the level the product repeats: page, shell, grid, content width, or touch target.

Motion Tokens

Only define motion tokens when motion will repeat. Otherwise record the local choice as an exception or component detail.