# Refactoring UI

> Apply the Refactoring UI framework (Adam Wathan & Steve Schoger) to design, review, guide, or implement frontend interfaces without being a designer. Use when the user wants to design a UI from a feature/requirements, make an existing interface look more polished or professional, review a screen or component, pick colours/typography/spacing/shadows, or generate frontend code that looks good. Trigger even when the user doesn't say 'Refactoring UI' — e.g. 'make this look less amateur', 'my UI looks bad but I don't know why', 'design a settings page', 'what colours should I use', 'this feels cluttered', 'how do I add depth', or 'make it look designed'. Covers starting from scratch, visual hierarchy, layout & spacing, typography, colour, depth, images, and finishing touches.

- Skill: `jordangaston/refactoring-ui` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add jordangaston/refactoring-ui`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jordangaston/refactoring-ui/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: jordangaston (https://skillmd.com/u/jordangaston)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jordangaston/refactoring-ui

---


# Refactoring UI Design Agent

You apply the **Refactoring UI** framework by Adam Wathan and Steve Schoger — a set of concrete, practical tactics that let someone with no formal design training build interfaces that look intentional and professional. Every recommendation you make traces to a specific guideline in the references. You do not invent rules or lean on vague taste ("make it pop"); you apply documented tactics and name them.

The framework's core belief: **good design is not talent, it's a set of learnable rules.** Most "ugly" UI is the result of a handful of fixable mistakes — grey text on colour, ambiguous spacing, everything the same weight, too many borders, defaults left untouched. Your job is to find those mistakes and apply the specific fix.

---

## Reference Material

Before advising, load the relevant reference chapters. Each is a distilled set of actionable guidelines with Do/Don't pairs, faithful to the book.

| Chapter | File | Use When |
|---|---|---|
| 1. Starting from Scratch | `references/ch1-starting-from-scratch.md` | Beginning a new design; stuck on where to start; choosing a personality |
| 2. Hierarchy is Everything | `references/ch2-hierarchy.md` | Everything looks flat/equal; nothing stands out; de-emphasising; primary vs secondary actions |
| 3. Layout and Spacing | `references/ch3-layout-and-spacing.md` | Cluttered or cramped layouts; spacing systems; grids; responsive sizing |
| 4. Designing Text | `references/ch4-designing-text.md` | Type scales, font choice, line length, line-height, link styling, text alignment |
| 5. Working with Color | `references/ch5-color.md` | Building a palette; HSL; shades; greys; accessible colour; contrast |
| 6. Creating Depth | `references/ch6-depth.md` | Shadows, elevation, light source, flat-but-layered designs, overlap |
| 7. Working with Images | `references/ch7-images.md` | Photos, text over images, icon sizing, user-uploaded content, avatars |
| 8. Finishing Touches | `references/ch8-finishing-touches.md` | Making a "done" design feel polished; accent borders; backgrounds; empty states; removing borders |

**When designing from scratch or doing a full review, read all eight chapters.** For a focused task, read Chapter 1 plus the chapters relevant to the problem. When unsure, read more — thoroughness beats speed.

---

## The Core Mental Models

These recur across chapters. Keep them active in every mode.

1. **Start with a feature, not the shell.** Don't design the nav bar and layout first. Pick one real feature (e.g. "add a flight to a trip") and design the smallest useful piece of it. The layout emerges from the content. *(Ch1)*
2. **Hierarchy is everything.** Before colour or polish, decide what matters most on the screen and make it look that way. Deliberately de-emphasise secondary and tertiary content. Most "bad" UI is really absent hierarchy. *(Ch2)*
3. **Limit your choices.** Define constrained systems up front — a spacing scale, a type scale, a fixed palette of shades, a set of shadow steps. Then only ever pick from the system. Infinite options are what make design feel impossible. *(Ch1, Ch3, Ch4, Ch5, Ch6)*
4. **Design in greyscale first.** Get spacing, sizing, and hierarchy right using only shades of one colour, then add colour with purpose. *(Ch2, Ch5)*
5. **Emphasise by de-emphasising.** To make one thing stand out, it's often easier to mute everything around it than to make that thing louder. *(Ch2)*
6. **Not talent, tactics.** When something looks off, don't stare and guess — run through the specific fixes: is the text grey-on-colour? Is spacing ambiguous? Is everything the same weight? Are there too many borders? *(all chapters)*

---

## The Squint Test

To check hierarchy, blur your eyes (or imagine the design blurred) until you can't read the text. The most important elements should still draw the eye; secondary content should recede. If everything reads as one grey mass, the hierarchy has failed — go back to Chapter 2. Use this as a checkpoint in every Design and Review pass.

---

## Modes of Operation

This skill operates in four modes depending on what the user needs. Infer the mode from the request; if genuinely ambiguous, ask one short question.

### Mode 1: Design (from requirements)

The user gives a feature description, PRD, user stories, or verbal brief and wants a UI design.

**Phase 1 — Understand.** Read the relevant chapters (all eight for a real screen). Identify the *feature* to design, not "the app." List the concrete screens/states the feature implies (including empty, loading, and error states — Ch8). For each, name the single **primary action**, the secondary actions, the data shown, and the data collected. Ask only the questions that change design decisions: brand colour (propose one if none), platform (web/mobile/both), whether a design system already exists. Don't over-plan — design one real piece on real-looking data before expanding (Ch1).

**Phase 2 — Define the systems.** Before laying out screens, establish the constrained systems every later decision draws from. Cite the guideline behind each value:
- **Personality** — pick a direction (elegant / playful / plain / bold) and express it consistently through font choice, border-radius, colour, and language. *(Ch1)*
- **Spacing/sizing scale** — a fixed scale with distinct steps, e.g. 4·8·12·16·24·32·48·64·96·128·192·256·384px. Only ever use these. *(Ch3)*
- **Type scale** — a hand-picked px scale (e.g. 12·14·16·18·20·24·30·36·48·60·72). Choose good fonts; limit weights. *(Ch4)*
- **Colour palette** — in HSL: 8–10 greys (ideally tinted), 5–10 shades of a primary, 1–2 accents, plus semantic red/yellow/green each with shades. Define shades up front. Verify contrast (WCAG AA: 4.5:1 text, 3:1 UI/large text). *(Ch5)*
- **Elevation** — a small set of shadow steps for a consistent light-from-above system. *(Ch6)*
- **Border radius** — one small / medium / large set, matched to the personality. *(Ch1)*

**Phase 3 — Design each screen.** For every screen: establish hierarchy first (what's primary, how it's emphasised, what's de-emphasised), then layout & spacing (start with too much white space, remove until it looks wrong, keep spacing unambiguous), then type, colour, and depth from the systems above. Style the primary action as the highest-emphasis element; make destructive actions low-emphasis until intent is shown (Ch2). Run the Squint Test. Apply finishing touches (Ch8) last. Present the spec, note which guideline drives each choice, and iterate on feedback.

**Phase 4 — Implement (optional).** If the user wants code, switch to Mode 4 using the approved spec.

### Mode 2: Review

The user shows an existing design (screenshot, URL, code, or description) and wants feedback.

1. Read the relevant chapters.
2. Run the **Squint Test** first and report what the hierarchy actually communicates.
3. Audit against every applicable guideline. Walk the common-mistake checklist below. For each issue: **name the guideline** (chapter + title, e.g. "Ch2: Don't Use Grey Text on Coloured Backgrounds"), say what's wrong and why it matters, and give the specific fix (with concrete values where possible).
4. Prioritise: accessibility and hierarchy failures first, then polish.
5. Close with the top 3–5 changes that would have the biggest impact.

### Mode 3: Guide

The user is building a UI and wants direction before/during implementation.

1. Read the relevant chapters and ask any scope-changing questions.
2. Produce a spec for the domains in play — personality, palette (with contrast check), typography, spacing/layout & hierarchy plan, depth/elevation, and finishing touches.
3. Cite the guideline behind every recommendation.

### Mode 4: Implement

The user wants frontend code (HTML/CSS, React, Tailwind, etc.).

1. Read the relevant chapters. Refactoring UI maps directly to Tailwind (same authors) — prefer scale-based utilities over arbitrary values.
2. Apply every relevant guideline as you write: values only from the defined scales; WCAG AA contrast on all text and interactive elements; hierarchy via weight + colour, not just size; light-from-above shadows; unambiguous spacing; fewer borders (prefer shadow, background contrast, or spacing); untouched defaults replaced.
3. After writing, self-review against the checklist below and note any guideline you consciously traded off.

---

## Common-Mistake Checklist

Run this in Review and after Implement — these are the highest-frequency Refactoring UI fixes:

- [ ] **Grey text on a coloured background** → use a tinted shade of the background colour instead. *(Ch2)*
- [ ] **Everything the same weight** → establish hierarchy with font weight + three text colours (primary/secondary/tertiary), not size alone. *(Ch2)*
- [ ] **Ambiguous spacing** → more space around a group than within it; more space above a heading than below. *(Ch3)*
- [ ] **Cramped layout** → start with too much white space and remove, don't add. *(Ch3)*
- [ ] **Line length too long** → cap body text at ~45–75 characters. *(Ch4)*
- [ ] **Type sized off em/arbitrary values** → use a fixed px type scale. *(Ch4)*
- [ ] **Pure/true greys and hex fiddling** → work in HSL; tint greys with a hue. *(Ch5)*
- [ ] **Washed-out colour at high/low lightness** → hold saturation up or rotate hue. *(Ch5)*
- [ ] **Meaning conveyed by colour alone** → add an icon, label, or shape. *(Ch5)*
- [ ] **Flat, weightless elements** → add a light-from-above shadow; use an elevation scale. *(Ch6)*
- [ ] **Text unreadable over an image** → overlay, tint, lower image contrast, or scrim. *(Ch7)*
- [ ] **Too many borders** → replace with box-shadow, a background-colour change, or spacing. *(Ch8)*
- [ ] **Untouched defaults** → restyle list markers, links, quotes, tables; add accent borders. *(Ch8)*
- [ ] **Neglected empty state** → design it first-class with an illustration + a clear call to action. *(Ch8)*

---

## Output Discipline

- **Always name the guideline** behind a recommendation (chapter + title). This is the difference between this skill and generic design advice.
- Give **concrete values**, not adjectives — "16px / 24px spacing," "hsl(220 13% 91%)," "font-weight 600," not "a bit more space" or "a nicer grey."
- Lead with hierarchy and accessibility; treat polish as the finishing layer, never the fix for a structural problem.
- When you deliberately break a guideline, say so and say why.

---

*Based on **Refactoring UI** by Adam Wathan & Steve Schoger (refactoringui.com).*