nothing-design

name	nothing-design
description	Guides intentional Nothing-inspired UI and design-system work with typography, spacing, hierarchy, components, and platform-specific execution. Use when the user explicitly asks for Nothing style, Nothing design, or `/nothing-design`, not for generic UI or design tasks.
license	MIT
metadata	{"version":"3.0.0"}

Nothing-Inspired UI/UX Design System

A senior product designer's toolkit trained in Swiss typography, industrial design (Braun, Teenage Engineering), and modern interface craft. Monochromatic, typographically driven, information-dense without clutter. Dark and light mode with equal rigor.

Before starting any design work, declare which Google Fonts are required and how to load them ( see references/tokens.md Section 1). Never assume fonts are already available.

This skill is for intentional Nothing-inspired execution, not loose minimalism. Apply it when the user explicitly asks for Nothing design language or invokes /nothing-design.

---

1. DESIGN PHILOSOPHY

• Subtract, don't add. Every element must earn its pixel. Default to removal.
• Structure is ornament. Expose the grid, the data, the hierarchy itself.
• Monochrome is the canvas. Color is an event, not a default — except when encoding data status (see Section 3).
• Type does the heavy lifting. Scale, weight, and spacing create hierarchy — not color, not icons, not borders.
• Both modes are first-class. Dark mode: OLED black. Light mode: warm off-white. Neither is " derived" — both get full design attention. Ask the user which mode to start with.
• Industrial warmth. Technical and precise, but never cold. A human hand should be felt.

---

2. CRAFT RULES — HOW TO COMPOSE

2.1 Visual Hierarchy: The Three-Layer Rule

Every screen has exactly three layers of importance. Not two, not five. Three.

Layer	What	How
Primary	The ONE thing the user sees first. A number, a headline, a state.	Doto or Space Grotesk at display size. --text-display. 48–96px breathing room.
Secondary	Supporting context. Labels, descriptions, related data.	Space Grotesk at body/subheading. --text-primary. Grouped tight (8–16px) to the primary.
Tertiary	Metadata, navigation, system info. Visible but never competing.	Space Mono at caption/label. --text-secondary or --text-disabled. ALL CAPS. Pushed to edges or bottom.

The test: Squint at the screen. Can you still tell what's most important? If two things compete, one needs to shrink, fade, or move.

Common mistake: Making everything "secondary." Evenly-sized elements with even spacing = visual flatness. Be brave — make the primary absurdly large and the tertiary absurdly small. The contrast IS the hierarchy.

2.2 Font Discipline

Per screen, use maximum:

• 2 font families (Space Grotesk + Space Mono. Doto only for hero moments.)
• 3 font sizes (one large, one medium, one small)
• 2 font weights (Regular + one other — usually Light or Medium, rarely Bold)

Think of it as a budget. Every additional size/weight costs visual coherence. Before adding a new size, ask: can I create this distinction with spacing or color instead?

Decision	Size	Weight	Color
Heading vs. body	Yes	No	No
Label vs. value	No	No	Yes
Active vs. inactive nav	No	No	Yes
Hero number vs. unit	Yes	No	No
Section title vs. content	Yes	Optional	No

Rule of thumb: If reaching for a new font-size, it's probably a spacing problem. Add distance instead.

2.3 Spacing as Meaning

Spacing is the primary tool for communicating relationships.

Tight (4–8px)   = "These belong together" (icon + label, number + unit)
Medium (16px)    = "Same group, different items" (list items, form fields)
Wide (32–48px)   = "New group starts here" (section breaks)
Vast (64–96px)   = "This is a new context" (hero to content, major divisions)

If a divider line is needed, the spacing is probably wrong. Dividers are a symptom of insufficient spacing contrast. Use them only in data-dense lists where items are structurally identical.

2.4 Container Strategy (prefer top)

1. Spacing alone (proximity groups items)
2. A single divider line
3. A subtle border outline
4. A surface card with background change

Each step down adds visual weight. Use the lightest tool that works. Never box the most important element — let it float on the background.

2.5 Color as Hierarchy

In a monochrome system, the gray scale IS the hierarchy. Max 4 levels per screen:

--text-display (100%) → Hero numbers. One per screen.
--text-primary (90%)  → Body text, primary content.
--text-secondary (60%) → Labels, captions, metadata.
--text-disabled (40%) → Disabled, timestamps, hints.

Red (#D71921) is not part of the hierarchy. It's an interrupt — "look HERE, NOW." If nothing is urgent, no red on the screen.

Data status colors (success green, warning amber, accent red) are exempt from the "one accent" rule when encoding data values. Apply color to the value itself, not labels or row backgrounds. See references/tokens.md for the full color system.

2.6 Consistency vs. Variance

Be consistent in: Font families, label treatment (always Space Mono ALL CAPS), spacing rhythm, color roles, component shapes, alignment.

Break the pattern in exactly ONE place per screen: An oversized number, a circular widget among rectangles, a red accent among grays, a Doto headline, a vast gap where everything else is tight.

This single break IS the design. Without it: sterile grid. With more than one: visual chaos.

2.7 Compositional Balance

Asymmetry > symmetry. Centered layouts feel generic. Favor deliberately unbalanced composition:

• Large left, small right: Hero metric + metadata stack.
• Top-heavy: Big headline near top, sparse content below.
• Edge-anchored: Important elements pinned to screen edges, negative space in center.

Balance heavy elements with more empty space, not with more heavy elements.

2.8 The Nothing Vibe

1. Confidence through emptiness. Large uninterrupted background areas. Resist filling space.
2. Precision in the small things. Letter-spacing, exact gray values, 4px gaps. Micro-decisions compound into craft.
3. Data as beauty. 36GB/s in Space Mono at 48px IS the visual. No illustrations needed.
4. Mechanical honesty. Controls look like controls. A toggle = physical switch. A gauge = instrument.
5. One moment of surprise. A dot-matrix headline. A circular widget. A red dot. Restraint makes the one expressive moment powerful.
6. Percussive, not fluid. Imagine UI sounds: click not swoosh, tick not chime. Design transitions that feel mechanical and precise.

2.9 Visual Variety in Data-Dense Screens

When 3+ data sections appear on one screen, vary the visual form:

Form	Best for	Weight
Hero number (large Doto/Space Mono)	Single key metric	Heavy — use once
Segmented progress bar	Progress toward goal	Medium
Concentric rings / arcs	Multiple related percentages	Medium
Inline compact bar	Secondary metrics in rows	Light
Number-only with status color	Values without proportion	Lightest
Sparkline	Trends over time	Medium
Stat row (label + value)	Simple data points	Light

Lead section → heaviest treatment. Secondary → different form. Tertiary → lightest. The FORM varies, the VOICE stays the same.

---

3. ANTI-PATTERNS — WHAT TO NEVER DO

• No gradients in UI chrome
• No shadows. No blur. Flat surfaces, border separation.
• No skeleton loading screens. Use [LOADING...] text or segmented spinner.
• No toast popups. Use inline status text: [SAVED], [ERROR: ...]
• No sad-face illustrations, cute mascots, or multi-paragraph empty states
• No zebra striping in tables
• No filled icons, multi-color icons, or emoji as UI
• No parallax, scroll-jacking, or gratuitous animation
• No spring/bounce easing. Use subtle ease-out only.
• No border-radius > 16px on cards. Buttons are pill (999px) or technical (4–8px).
• Data visualization: differentiate with opacity (100%/60%/30%) or pattern ( solid/striped/dotted) before introducing color.

---

4. WORKFLOW

1. Declare fonts — tell the user which Google Fonts to load (see references/tokens.md)
2. Confirm mode — ask whether to start in dark or light mode if the user did not already specify it. Neither is default.
3. Sketch hierarchy — identify the 3 layers before writing any code
4. Choose platform output — HTML/CSS, React/Tailwind, SwiftUI, or design-tool language
5. Compose — apply craft rules (Sections 2.1–2.9)
6. Check tokens — consult references/tokens.md for exact values
7. Build components — consult references/components.md for patterns
8. Adapt to platform — consult references/platform-mapping.md for output conventions

---

5. REQUIRED RESPONSE CONTRACT

When this skill is used for any design or implementation request, structure the response in this order:

1. Fonts required
   • List exact Google Fonts needed
   • Show how to load them (<link> / @import / package import)
2. Mode
   • State whether the solution starts with dark or light mode
   • If unspecified, stop and ask before producing final UI code
3. Three-layer hierarchy
   • Primary
   • Secondary
   • Tertiary
4. Layout strategy
   • Main composition pattern
   • Spacing rhythm
   • Where the single expressive break appears
5. Component mapping
   • Which components/patterns are being used
   • Why they fit the hierarchy
6. Token mapping
   • Relevant typography, color, spacing, radius, and motion tokens
7. Final output
   • Design guidance, implementation code, or both depending on the user request

Do not jump straight into code without covering items 1 to 4 first.

---

6. ACCESSIBILITY BASELINE

Nothing-inspired does not mean inaccessible. Preserve the visual language while meeting these minimums:

• Maintain readable contrast for all text and interactive states; do not use --text-disabled for essential content
• Every interactive element needs a visible focus state; prefer border, underline, or inversion rather than glow/shadow
• Respect minimum touch target size of 44x44px for controls
• Provide reduced-motion-friendly behavior; if animation is used, keep it subtle and removable
• Use semantic labels and accessible names for icon-only buttons, toggles, segmented controls, and data widgets
• Do not communicate status with color alone; pair color with text, value, icon, pattern, or label

If a strict visual rule conflicts with accessibility, accessibility wins while staying as close as possible to the Nothing aesthetic.

---

7. PERMITTED ADAPTATIONS

These rules keep the style strong without making the skill brittle:

• No shadows by default, but a platform-native elevation cue is acceptable if needed for usability or system conventions
• No toast popups by default, but system-level confirmations are acceptable when the platform depends on them
• No gradients in UI chrome, but controlled data-visualization color ramps are acceptable when they encode meaning clearly
• No skeletons by default; if a product already mandates skeleton loading, simplify it to monochrome blocks with minimal visual noise
• No decorative accent red; status red is acceptable where the product genuinely needs urgent/error signaling

---

8. REFERENCE FILES

For detailed token values, component specs, and platform-specific guidance:

• references/tokens.md — Fonts, type scale, color system (dark + light), spacing scale, grid, motion, iconography, dot-matrix motif
• references/components.md — Cards, buttons, inputs, lists, tables, nav, tags, segmented controls, progress bars, charts, widgets, overlays, state patterns
• references/platform-mapping.md — HTML/CSS, SwiftUI, React/Tailwind, Paper output conventions
• references/examples.md — Complete response-shape examples, use cases, non-use cases, and implementation reminders

---

9. WHAT GOOD EXECUTION LOOKS LIKE

A strong Nothing-style response should feel:

• Confident — clear hierarchy, no decorative clutter
• Precise — exact spacing, exact casing, exact tone
• Technical — labels, values, and controls feel instrument-like
• Restrained — one expressive moment, not many
• Actionable — not just mood, but concrete structure and tokens

If the result looks like generic black minimalism, it failed. If it looks noisy, it also failed. The target is disciplined tension: sparse, sharp, human.