# Refactoring Ui > Diseña y mejora UIs con las reglas de Refactoring UI: escalas fijas de spacing/tipo/color/sombra, jerarquía por peso y color, y profundidad con luz emulada. Fuente: https://skillsagentes.com/skills/s0xdk/refactoring-ui-skill/refactoring-ui Markdown: https://skillsagentes.com/skills/s0xdk/refactoring-ui-skill/refactoring-ui.md Repositorio: https://github.com/s0xDk/refactoring-ui-skill Autor: s0xDk Licencia: NOASSERTION Actualizado: anteayer Coste de contexto: 144 tok instalada, 3.5k tok al activarse, 12.8k tok con todos los archivos del bundle Bundle: 7 archivos, 50 KB Permisos que pide: ninguno declarado ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add s0xDk/refactoring-ui-skill --agent claude-code # Cursor npx -y skills add s0xDk/refactoring-ui-skill --agent cursor # Codex npx -y skills add s0xDk/refactoring-ui-skill --agent codex # Gemini CLI npx -y skills add s0xDk/refactoring-ui-skill --agent gemini # Windsurf npx -y skills add s0xDk/refactoring-ui-skill --agent windsurf # Cline npx -y skills add s0xDk/refactoring-ui-skill --agent cline ``` ## Qué hace - Obliga a elegir spacing, tipo, peso, color, sombra y radio de escalas fijas, nunca valores ad hoc. - Construye jerarquía con peso y color, no hinchando el font-size; máximo tres colores de texto. - Diagnostica quejas vagas («se ve cutre», «parece amateur») en fallos mecánicos vía `references/diagnose.md`. - Aplica reglas duras: nada de gris sobre color, nada de `em` en la escala tipográfica, contraste 4.5:1. ## Cuándo usarla - Al construir o estilar cualquier UI, o al elegir tamaños, spacing, colores, sombras o radios. - Al diseñar una paleta o tokens, o cuando alguien dice que «se ve mal», «parece amateur» o «haz que se vea mejor». ## Qué la activa - "Haz que este dashboard no se vea amateur" - "Elige spacing y tipo de una escala, no a ojo" - "Esta UI se siente barata, ¿qué arreglo?" - "Diseña la paleta y los tokens de este producto" ## Archivos - LICENSE — 1 KB - README.md — 3 KB - SKILL.md — 14 KB - assets/tokens.css — 8 KB - references/diagnose.md — 6 KB - references/systems.md — 7 KB - references/techniques.md — 11 KB ## SKILL.md Reproducido tal cual desde s0xDk/refactoring-ui-skill bajo NOASSERTION. Esta sección es el documento original y está en inglés. # Refactoring UI Visual design is not talent. It is a small set of systems decisions made **once**, plus a handful of techniques for creating hierarchy. This skill is those systems and those techniques. The single biggest cause of amateur-looking UI is picking values ad hoc — 17px here, `#3B82F6` there, `lighten(5%)` for a hover state. Design *from a scale*, always. --- ## The systems — use these, do not re-derive them Pick from these lists. Never invent a value that isn't on one. ### Spacing and sizing Base 16px, built from factors and multiples of it: ``` 4 8 12 16 24 32 48 64 96 128 192 256 384 512 640 768 ``` Tight at the small end, spreading out at the large end. **No two adjacent values may be closer than ~25%** — that is what makes the choice obvious. A linear "multiples of 4" scale fails: it does not help you decide between 120px and 124px. Use it for margin, padding, width, height, icon sizes, border width — everything spatial. Fix a small set of opacity values too (e.g. `.05 .1 .2 .4 .6 .8`) for disabled states, overlays and hover tints, rather than eyeballing a slider each time. Same logic as the other scales: decide once, reuse everywhere. ### Type scale ``` 12 14 16 18 20 24 30 36 48 60 72 ``` Not a modular scale built from a ratio (4:5, 2:3, golden ratio). Those produce fractional pixel values that round inconsistently across browsers and are too sparse for interface density — hand-picked values, chosen for how they feel, win instead. **Units: `px` or `rem` only. Never `em`.** `em` is relative to the current font size, so a `.875em` inside a `1.25em` parent computes to 17.5px — a value not in your scale. The scale silently stops existing. ### Font weight Two weights is enough: - **400 or 500** — body and most UI text - **600 or 700** — anything emphasized Nothing below 400 in UI. To de-emphasize, use a lighter *color* or smaller *size* — never a lighter weight. ### Color You need far more colors than a five-swatch palette generator gives you. - **Greys: 8–10 shades.** Almost all of a UI is grey — text, backgrounds, panels, borders, form controls. Three or four shades always runs out. Start at a very dark grey, not true black (true black looks unnatural). - **Primary: 5–10 shades**, one or maybe two primaries. - **Accents: 5–10 shades each** — destructive red, warning yellow, positive green, plus whatever else the product needs to distinguish (chart series, calendar events, tags). Ten colors × 5–10 shades is normal for a complex UI. Name them `100` (lightest) → `900` (darkest), base `500`. **Build the scale in this order:** pick `500` first (for a primary/accent, it should be a shade that works as a button background). Then find the edges — `900` is usually your text color, `100` a background tint; an alert component uses both, so design one and read the two values off it. Then fill `700` and `300` as the perfect compromise between their neighbours, then `800 600 400 200` the same way. **Write colors as HSL, not hex.** `hsl(220, 95%, 34%)` and `hsl(220, 65%, 61%)` are visibly related; `#03369E` and `#507DD7` are not. **Never generate shades at runtime** with `lighten()` / `darken()`. That is how you end up with 35 slightly different blues. ### Shadows — five elevations ```css 0 1px 3px hsla(0,0%,0%,.2) /* barely raised — buttons */ 0 4px 6px hsla(0,0%,0%,.2) /* dropdowns */ 0 5px 15px hsla(0,0%,0%,.2) 0 10px 24px hsla(0,0%,0%,.2) 0 15px 35px hsla(0,0%,0%,.2) /* modals */ ``` Choose by asking *where on the z-axis does this sit?*, not *what shadow looks nice?*. Closer to the user = more attention. Shrinking a button's shadow on `:active` makes it feel pressed; growing a list item's shadow when it's picked up for drag-to-reorder does the reverse — it reads as "now above its siblings" and doubles as the drag affordance itself. These five are the default and are fine everywhere. `references/techniques.md` gives a refined **two-part** version of the same scale — parallel, but not identical values (its top step is heavier). Use it when shadows are prominent in the design; use these when they aren't. Don't mix the two in one project. ### Line-height and line length Line-height is **inversely** proportional to font size, and proportional to line width: - small text / wide columns → `1.5` to `2` - large headlines → `1` is fine Line length: **45–75 characters**, i.e. `max-width: 20em–35em`. This applies to the paragraph even when the container around it is wider — mixed widths in one content area look more polished, not less. (`em` is correct *here* — measure should scale with the text it wraps. The "never `em`" rule is scoped to the *type scale*, where `em` compounds through nesting. Don't "fix" this.) ### Border radius Pick one and stay consistent. Small radius = neutral. Large radius = playful. None = serious/formal. Mixing square and rounded corners in one interface always looks worse. --- ## The procedure **1. Start with a feature, not a layout.** Don't design "the app" — you cannot decide between top nav and sidebar before you know what's in the product. Design one real piece of functionality (the search form, the message composer), and let the shell emerge. **2. Detail comes later.** Ignore typefaces, shadows and icons early. Work in **grayscale first** — it forces hierarchy to come from spacing, contrast and size rather than color. Add color once the layout works. **3. Don't over-invest in low fidelity.** Sketches, wireframes and mockups are disposable — nobody can use a static picture of an app. They exist to explore ideas; abandon them once the decision is made and go build the real thing. **4. Design the smallest useful version, then build it.** Work in short design→code cycles. Don't imply functionality you aren't ready to build — a comment box with an attachments zone you can't ship yet blocks the whole feature. Nice-to-haves get designed later. **5. Choose by elimination.** When picking a value from a scale: guess the one you think is right, then compare it against the neighbour on each side. Two will be obviously wrong. If an outer option wins, re-run the comparison with that as the new middle. **6. Start with too much white space and remove it.** Adding space until something stops looking bad gives you the minimum. Starting generous and trimming gives you the right amount. Dense UIs (dashboards) are legitimate — but as a deliberate decision, not a default. **7. Shrink the canvas.** A small component designed on a 1400px artboard tends to sprawl, because the space is there to fill. Start at ~400px and design the mobile layout first, where the constraints are real — then bring it to a large screen and relax only what genuinely felt cramped. You will change less than you expect. --- ## Hierarchy — the technique that does the most work Everything on screen sits in a pyramid: primary, secondary, tertiary. When everything competes, the UI reads as noise. This is what makes a design look "designed" — not styling. **Size isn't everything.** Leaning on font size alone gives you primary content that's too big and secondary content that's too small. Use **weight** and **color** to carry emphasis instead, and keep sizes reasonable. **Three text colors, maximum:** - dark — primary content - grey — secondary content - lighter grey — tertiary (footnotes, copyright) All three carry real body-size text, so all three need 4.5:1. "Lighter grey" means the lightest shade that still clears it — roughly the middle of a 9-step ramp, not the pale end. The pale shades are for disabled states and large text only. **Emphasize by de-emphasizing.** When the important element won't stand out and there's nothing left to add to it, soften what competes with it instead. Fade the inactive nav items; drop the sidebar's background color so the main content sits forward. **Actions:** style by hierarchy, not by semantics. - Primary → solid, high contrast. Usually exactly one per page. - Secondary → outline, or a low-contrast background. - Tertiary → styled like a link. Destructive ≠ big red button. If "Delete" isn't the primary action on the page, give it tertiary treatment — then make it a big red primary button *inside the confirmation dialog*, where it genuinely is the primary action. **Labels are a last resort.** `label: value` gives every piece of data equal weight. Most data identifies itself by format (`$19.99`, an email address) or by context. Where a label is genuinely needed, fold it into the value ("12 left in stock", not "In stock: 12"), or add it as visibly *secondary* content. Exception: on spec-sheet-style pages where users scan *for the label*, emphasize the label instead. **Balance weight against contrast.** Solid icons are visually heavy and will out-shout the text beside them — soften their color to compensate. It works in reverse too: when a 1px border is too subtle in a soft color but too harsh once you darken it, keep the soft color and go to 2px. Add weight to fix low contrast; reduce contrast to fix excess weight. **Visual hierarchy ≠ document hierarchy.** Semantic markup and visual weight are separate decisions. Section titles are usually *labels*, not headlines — an `h1` at 16px is fine, and sometimes the title should be visually hidden entirely because the content speaks for itself. --- ## Hard rules Deviating from these produces a specific, recognizable failure. 1. **Never grey text on a colored background.** Grey-on-white works because it *reduces contrast*; grey on color just looks dirty. White-at-reduced-opacity looks washed out and disabled, and lets patterns show through the glyphs. Hand-pick a color with the background's hue, adjusting saturation and lightness. 2. **Never `em` for the type scale.** `px` or `rem`. 3. **Never generate shades at runtime.** Define them up front. 4. **Never use a percentage width for something that shouldn't scale.** Sidebars get fixed widths; the main area flexes. Elements get a `max-width` and only shrink when the screen is actually smaller — a login card shouldn't be *wider* at medium screens than at large. 5. **Never scale things proportionally across breakpoints.** Large elements must shrink *faster* than small ones. A 2.5em headline sitting on 14px mobile body copy computes to 35px — far too big; it wants to be 20–24px there. Likewise a button's padding should get proportionally tighter as the button shrinks, not scale with its font size. 6. **Always more space around a group than within it.** This is the fix for "which label belongs to which field", cramped bullet lists, and headings that look attached to the wrong paragraph. Ambiguous spacing is a functional bug, not just an ugly one. 7. **Never use color as the only signal.** Add an icon, a shape, or a text cue. For charts, distinguish series by *contrast* (light→dark shades of one color) rather than by hue — colorblind users read lightness reliably, hue not so much. 8. **Contrast minimums:** 4.5:1 for normal text. The 3:1 allowance applies only to *large* text, which WCAG defines as **24px regular or 18.66px bold** — not 18px. Assume 4.5:1 unless the text is genuinely that large. When white-on-color fails, flip it: dark colored text on a light colored tint (see `references/systems.md`). Separately, **3:1 applies to non-text too** (WCAG 1.4.11): if a border is the only thing identifying a control — an input outline, a checkbox edge — it needs 3:1 against its background. A hairline that merely divides content does not. Those are two different tokens, not one. 9. **Never scale an icon far from its intended size.** A 16–24px icon at 48px looks chunky and detail-starved. Put it inside a colored circle instead. --- ## References **`assets/tokens.css`** — a complete, contrast-verified starting set of all the above as CSS custom properties: spacing, type, weights, border width, a fixed opacity scale, a 9-shade cool grey ramp, a 9-shade primary, three accent trios, five elevations, a **semantic role layer** (`--surface`, `--text-primary`, `--action`…) and a **dark-mode block** that overrides only those roles. Copy it in and retune the hues rather than re-deriving the scales from this prose. Reference the roles in components, not the raw ramps — that is what makes the dark mode work. Every text/surface pair is verified ≥4.5:1 in both modes and every functional border ≥3:1; the deliberate sub-threshold shades (disabled, decorative dividers, the large-text-only step) are exempt by criterion and commented inline. Load these when the work calls for them: - **`references/systems.md`** — building a palette from scratch: choosing the base color, keeping saturation alive at the light and dark ends, hue rotation, warm/cool greys, and the two escape hatches for hitting contrast ratios without ugly color. - **`references/diagnose.md`** — symptom → fix table. Load first whenever the task is *improving existing UI* rather than building new. - **`references/techniques.md`** — depth and light simulation, two-part shadows, baseline alignment, letter-spacing, breaking out of default component shapes, and handling user-uploaded images. ## Dónde encaja - Categoría: [Diseño y UI](https://skillsagentes.com/categorias/diseno-ui.md) — Sistemas de diseño, trabajo con componentes y acabado visual. - Creador: [s0xDk](https://skillsagentes.com/creators/s0xdk.md) — 1 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Skills relacionadas - [Canvas Design](https://skillsagentes.com/skills/anthropics/skills/canvas-design.md): Crea arte visual en documentos .png y .pdf partiendo de una filosofía de diseño. Úsalo cuando pidan un póster, una pieza de arte, un diseño u otra pieza estática. - [Frontend Design](https://skillsagentes.com/skills/anthropics/claude-code/frontend-design.md): Guía para un diseño visual distintivo e intencional al crear o rediseñar una UI: dirección estética, tipografía y decisiones que no parezcan defaults templados. - [Design Consultation](https://skillsagentes.com/skills/garrytan/gstack/design-consultation.md): Consultoría de diseño: entiende tu producto, investiga el panorama, propone un sistema de diseño completo y genera vistas previas de tipografía y color. - [Design Html](https://skillsagentes.com/skills/garrytan/gstack/design-html.md): Finalización de diseño: genera HTML/CSS de calidad de producción nativo de Pretext, con texto que realmente reordena y layouts dinámicos. (gstack) - [Plan Design Review](https://skillsagentes.com/skills/garrytan/gstack/plan-design-review.md): Revisión de planes con ojo de diseñador — interactiva, al estilo de las revisiones de CEO e Ingeniería. (gstack) --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)