Menu
Use when starting a new UI, page, screen, or feature from scratch โ design real features before chrome, work in low fidelity, ship the smallest version, pick a deliberate personality, and design from constrained systems instead of an open palette.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when defining a color palette, picking shades, fixing washed-out colors, choosing greys, hitting accessibility contrast, or coloring data visualizations. Covers HSL over hex, palette breadth (~10 colors ร 5โ10 shades), defining shades upfront, hue-rotation tricks for brightness, warm/cool greys, accessible contrast, and not relying on color alone.
Use when adding shadows, working out elevation, making elements feel raised or inset, designing flat UIs with subtle depth, or layering components for visual interest. Covers light-from-above, shadow elevation systems, two-part shadows (direct + ambient), depth in flat designs via lightness, and overlapping elements to create layers.
Use when a UI is functionally complete but feels generic or unfinished โ needs polish before shipping. Covers superchargeable defaults, accent borders, decorated backgrounds, empty-state-as-onboarding, fewer borders, and breaking out of conventional component shapes.
Use when a UI feels noisy, when nothing stands out, when buttons/nav/sections all compete for attention, or when you need to decide which element is primary vs secondary vs tertiary. Covers emphasis through weight and color (not just size), the grey-on-color trap, de-emphasizing competitors, label minimization, weight/contrast counterbalance, and action hierarchy.
Use when working with photos, icons, screenshots, or user-uploaded images. Covers picking quality photography, getting consistent text contrast over hero images, respecting an image's intended size (don't scale icons up, don't scale screenshots down), and defending layouts against unpredictable user-uploaded content.
Use when a layout feels cramped or arbitrary, when whitespace is being added by guesswork, when grids are forcing awkward sizes, when content groups feel ambiguous (which label belongs to which input), or when every screen size needs different magic numbers. Covers spacing scales, max-widths, grid escape hatches, mobile-first sizing, and the "more around than within" rule.
| name | starting-fresh |
| description | Use when starting a new UI, page, screen, or feature from scratch โ design real features before chrome, work in low fidelity, ship the smallest version, pick a deliberate personality, and design from constrained systems instead of an open palette. |
A UI is a collection of features. Design the smallest real feature first; the shell, navigation, and overall layout fall out of what those features need.
1. Feature first, shell last. Don't start with the nav bar, sidebar, or logo placement. Pick one concrete user task ("search for a flight", "add a comment", "view an invoice") and design that. You don't have enough information to decide layout questions until 2โ3 features exist.
2. Stay low fidelity. Sharpie sketches, paper, or grayscale wireframes. Real type, real color, real shadows tempt you into detail work before structure is locked. Designing in grayscale forces hierarchy through size, weight, contrast, and spacing โ the things that actually do the work.
3. Cycle, don't pre-design. Design the smallest useful slice โ build it โ return for the next slice. Edge cases ("what if there are 2000 items?", "where does the error go?") surface faster in a live UI than in your imagination.
4. Be a pessimist. Don't put functionality in mockups you're not committed to building. If "attachments" is a nice-to-have, leave it out of the comment box; a simple shipped feature beats an ambitious blocked one.
5. Pick a personality, then commit. Personality is the sum of small consistent choices:
To pick a direction, look at what your audience already uses and lean similar. Don't directly copy a competitor.
6. Design out of a constrained system, not an open palette. When any value is allowed, no value is right. Predefine sets:
To pick from a system, sample 3 adjacent values; the middle is usually right. If an outer wins, slide one step and repeat.
Heuristics distilled from Refactoring UI by Adam Wathan & Steve Schoger (https://refactoringui.com). Independent skill package; not affiliated with or endorsed by the authors.
