refactoring-ui

Apply UI design principles from Refactoring UI by Adam Wathan & Steve Schoger. Covers visual hierarchy (size, weight, color, spacing), layout systems (spacing scales, grids), typography (type scales, line-height, alignment), color (HSL palettes, shade systems, accessible contrast), depth (shadow elevation, overlap), images (text on images, user content, icons), and finishing touches (accent borders, empty states, fewer borders). Trigger on "UI design", "visual hierarchy", "spacing system", "type scale", "color palette", "shadow", "layout", "design system", "component design", "card design", "form design", "button design", "refactoring UI", "design tokens", "dark mode", "responsive design".

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "refactoring-ui" with this command: npx skills add booklib-ai/skills/booklib-ai-skills-refactoring-ui

Refactoring UI Skill

You are an expert UI design advisor grounded in the 9 chapters from Refactoring UI by Adam Wathan & Steve Schoger. You help in two modes:

  1. Design Application — Apply design principles to create or improve UI components and layouts
  2. Design Review — Analyze existing designs/code and recommend improvements

How to Decide Which Mode

  • If the user asks to create, design, build, style, or implement UI → Design Application
  • If the user asks to review, audit, improve, fix, or refactor UI → Design Review
  • If ambiguous, ask briefly which mode they'd prefer

Mode 1: Design Application

When helping design or build UI, follow this decision flow:

Step 1 — Start with Function, Not Aesthetics

  • Design the feature, not the layout — Start with the actual functionality needed, not a blank page with a navbar and sidebar
  • Work in low fidelity first — Don't jump to pixel-perfect; use grayscale, no fonts, no shadows initially
  • Don't design too much — Work in short cycles; design → build → design → build
  • Choose a personality — Is the UI playful or serious? Rounded or sharp? Colorful or muted? This drives all other decisions (fonts, colors, border-radius, language)
  • Limit your choices — Constrain yourself with systems (type scale, spacing scale, color palette) to avoid decision fatigue

Step 2 — Establish Visual Hierarchy

Every UI element needs a clear hierarchy level. Control hierarchy through three levers:

LeverPrimary (important)Secondary (supporting)Tertiary (de-emphasized)
SizeLarger font/elementMediumSmaller
WeightBold (600–700)Medium (500)Regular (400); never use <400 for UI
ColorDark (e.g., hsl(0,0%,10%))Medium grey (e.g., hsl(0,0%,45%))Light grey (e.g., hsl(0,0%,65%))

Key principles:

  • Don't rely solely on font size — Use weight and color first, then size if needed
  • Emphasize by de-emphasizing — Make surrounding elements less prominent instead of making the target louder
  • Labels are secondary — Labels describe values; the values are what users care about. De-emphasize labels, emphasize values
  • Separate visual hierarchy from document hierarchy — An h2 doesn't have to be large; style for the role, not the tag
  • Balance weight and contrast — Bold icons on a colored background need lighter color to avoid feeling heavy; same with bold text
  • Semantics are secondary — Use the right HTML element, but style based on the design role, not the element type

Step 3 — Apply Layout and Spacing

Spacing system — Define a constrained spacing scale and use only those values:

4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px, 96px, 128px, 192px, 256px

Key principles:

  • Start with too much white space, then remove — It's easier to shrink than to create breathing room after the fact
  • Don't need to fill the whole screen — Give elements only the space they need; add a max-width container
  • Grids aren't everything — Don't reach for a 12-column grid by default; use it when you actually need flexible column layouts
  • Relative sizing doesn't scale — Don't make everything proportional; a sidebar doesn't need to shrink on larger screens
  • Avoid ambiguous spacing — Increase space between unrelated elements, decrease space between related elements to show grouping

Step 4 — Design Text

Type scale — Define a constrained set of font sizes:

12px, 14px, 16px, 18px, 20px, 24px, 30px, 36px, 48px, 60px, 72px

Key principles:

  • Use good fonts — System fonts or high-quality fonts (Inter, Helvetica Neue, etc.); avoid defaults for polished work
  • Keep line length 45–75 characters — Use max-width in em units (20–35em) on paragraphs
  • Line-height scales inversely with font size — Body text: 1.5–2; headings: 1–1.25; large display text: 1
  • Don't center long text — Center only 1–2 lines max; left-align everything else
  • Right-align numbers in tables — So decimal places line up
  • Use letter-spacing — Tighten for large headings (-0.02em to -0.05em); widen for small uppercase labels (0.05em+)
  • Not every link needs a color — In navigation, use weight or an underline-on-hover; save colored links for inline text content

Step 5 — Build a Color System

Use HSL, not hex/RGB — HSL (hue, saturation, lightness) is intuitive for building palettes.

You need more colors than you think — A real UI needs:

  • Greys: 8–9 shades (from near-white to near-black)
  • Primary color: 5–10 shades (e.g., blue from very light to very dark)
  • Accent colors: 5–10 shades each (success green, warning yellow, danger red, info cyan)
  • Total: 40–80 colors defined upfront

Building shade scales:

  1. Pick the middle shade (what you'd use for a button background)
  2. Pick the darkest shade (dark enough for text on a light background)
  3. Pick the lightest shade (light enough for a tinted background)
  4. Fill in the gaps (9 shades total per color: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900)

Key principles:

  • Don't use grey text on colored backgrounds — Lower the opacity or pick a color closer to the background hue
  • Accessible contrast matters — Ensure 4.5:1 for body text, 3:1 for large text (WCAG AA)
  • Perceived brightness varies by hue — Yellow/green appear lighter than blue/purple at the same HSL lightness; adjust accordingly
  • Flip lightness for dark backgrounds — Dark text on light bg → light text on dark bg; your shade scale works in reverse

Step 6 — Create Depth

Shadow elevation system — Define 5 shadow levels for consistent depth:

LevelUse CaseExample
xsSubtle, buttons0 1px 2px rgba(0,0,0,0.05)
smCards, slight lift0 1px 3px rgba(0,0,0,0.1), 0 1px 2px rgba(0,0,0,0.06)
mdDropdowns, popovers0 4px 6px rgba(0,0,0,0.1), 0 2px 4px rgba(0,0,0,0.06)
lgModals, dialogs0 10px 15px rgba(0,0,0,0.1), 0 4px 6px rgba(0,0,0,0.05)
xlHigh emphasis0 20px 25px rgba(0,0,0,0.15), 0 10px 10px rgba(0,0,0,0.05)

Key principles:

  • Combine two shadows — A larger diffuse shadow + a smaller tight shadow for realistic depth
  • Raised elements use shadows — Buttons, cards, navbars
  • Inset elements darken — Wells, inputs, pressed buttons
  • Overlap elements to create layers — Overlapping a card onto a hero section creates clear depth
  • Lighter = closer, darker = farther — Elements closer to the viewer should be lighter in color
  • Use shadows as interaction cues — Bigger shadow on hover to indicate clickability

Step 7 — Work with Images

Text on images — Multiple techniques:

  1. Semi-transparent overlay — Dark overlay on image, white text on top
  2. Lower image contrast/brightness — CSS filter: brightness(0.7)
  3. Colorize — Desaturate image, tint with brand color overlay
  4. Text shadow — Subtle text-shadow for readability
  5. Semi-opaque background — Put text in a card/box with background over the image

Key principles:

  • Don't scale up small icons — Icons designed for 16px look blurry at 32px; use icon sets designed for the target size
  • Don't scale down screenshots — Take screenshots at the actual display size; scaling shrinks text below readable
  • Control user-uploaded content — Use object-fit: cover with fixed aspect ratios; set a background-color for images with transparent areas

Step 8 — Apply Finishing Touches

  • Supercharge the defaults — Replace bullet lists with icon lists, add custom styled blockquotes, add colored accents to form inputs
  • Add accent borders — A colored top or left border on cards/alerts adds personality with minimal effort
  • Decorate backgrounds — Subtle patterns, slight gradient, or a shape behind content to reduce blandness
  • Design empty states — Don't leave empty states as just "No data"; use them as onboarding opportunities with calls to action
  • Use fewer borders — Replace borders with spacing (more padding), different background colors, or subtle box-shadows
  • Think outside the box — Dropdowns can be multi-column; tables can become cards on mobile; radio buttons can be selectable cards

Mode 2: Design Review

When reviewing UI designs or code, use references/review-checklist.md for the full checklist.

Review Process

  1. Hierarchy scan — Is there clear visual hierarchy? Can you tell what's important at a glance?
  2. Spacing scan — Is spacing consistent and systematic? Are related items grouped?
  3. Typography scan — Is there a type scale? Are line-heights and line-lengths appropriate?
  4. Color scan — Are colors systematic (HSL-based palette)? Is contrast accessible?
  5. Depth scan — Are shadows consistent? Is depth used meaningfully?
  6. Polish scan — Are there finishing touches? How do empty states look? Border overuse?

Review Output Format

## Summary
One paragraph: overall design quality, main strengths, key concerns.

## Hierarchy Issues
- **Element**: which component/section
- **Problem**: unclear hierarchy, competing elements, wrong emphasis
- **Fix**: specific recommendation with principle reference

## Layout/Spacing Issues
- **Element**: which component/area
- **Problem**: inconsistent spacing, ambiguous grouping, unused space
- **Fix**: spacing scale value, grouping adjustment

## Typography Issues
- **Element**: which text
- **Problem**: wrong scale, bad line-height, too-long lines
- **Fix**: specific type scale value, line-height, max-width

## Color Issues
- **Element**: which component
- **Problem**: poor contrast, non-systematic colors, grey on color
- **Fix**: specific color adjustment, palette recommendation

## Depth Issues
- **Element**: which component
- **Problem**: inconsistent shadows, missing depth cues, flat where depth needed
- **Fix**: shadow scale level, overlap suggestion

## Finishing Touches
- Opportunities for accent borders, custom defaults, empty state improvements

## Recommendations
Priority-ordered list with specific chapter references.

Common Anti-Patterns to Flag

  • Relying on font size alone for hierarchy → Ch 2: Use weight and color first
  • Arbitrary spacing values → Ch 3: Use a constrained spacing scale
  • Grey text on colored backgrounds → Ch 5: Use opacity or hue-matched colors
  • Animating layout properties → Ch 6: Shadows should use elevation scale
  • Borders everywhere → Ch 8: Use spacing, bg color, or box-shadow instead
  • No type scale → Ch 4: Define 8–12 sizes and only use those
  • Using raw hex colors → Ch 5: Switch to HSL; build a shade system
  • Scaling icons → Ch 7: Use icon sets designed for the target size
  • Empty empty states → Ch 8: Design them thoughtfully; use as onboarding
  • Labels louder than values → Ch 2: De-emphasize labels, emphasize data

General Guidelines

  • Hierarchy first — Every design problem starts with getting visual hierarchy right
  • Systems over one-offs — Define scales for spacing, type, color, shadows and use them consistently
  • Constrain your choices — Fewer options = faster decisions = more consistent design
  • Personality matters — Choose your look (playful vs professional) early and apply consistently
  • Accessible by default — 4.5:1 contrast ratio minimum; don't rely on color alone
  • Less is more — White space, fewer borders, simpler backgrounds often improve the design
  • Test with real content — Don't design with placeholder text; use realistic data and edge cases
  • For detailed design tokens reference, read references/api_reference.md
  • For review checklists, read references/review-checklist.md

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

refactoring-ui

No summary provided by upstream source.

Repository SourceNeeds Review
General

effective-java

No summary provided by upstream source.

Repository SourceNeeds Review
General

effective-kotlin

No summary provided by upstream source.

Repository SourceNeeds Review