diseño-sin-sobras

Diseño sin sobras

Tres partes: qué arreglar (checklist.md, cada arreglo con su motivo), cómo orquestarlo (process.md, rondas con revisores y desarrolladores en paralelo) y casos y fuentes (references.md: los cinco antes/después que iniciaron esta habilidad y un mapa de Refactoring UI). La ficha de especificaciones que cada revisor llena está en spec-card.md. Las notas por plataforma (SwiftUI, Compose, web, widgets, watch, car) viven en platforms.md. Lee la que necesites, no todas.

Principios (no negociables)

1. Un arreglo es una regla, no un ajuste. Cada cambio se envía como un token o componente (espaciado, tamaño de fuente, peso, rol de color, radio, sombra, botón), nunca como un literal en la vista. Si falta el token, créalo en el mismo cambio. Elige valores por eliminación dentro de la escala (prueba el valor y sus dos vecinos; el del medio gana o repites), nunca píxel a píxel.
2. Jerarquía antes que color. La pantalla tiene que funcionar en escala de grises: el espaciado, el tamaño, el peso y el contraste hacen el trabajo; el color viene después y solo para significar algo. Si no está claro en gris qué importa, el color no lo arreglará.
3. Lo primero que lees es la respuesta. Un número heroico por pantalla (el saldo, el precio, el progreso de hoy); todo lo demás pasa a segundo plano. Enfatiza des-enfatizando la competencia, no inflando al héroe. Como máximo una superficie oscura/heroica por pantalla, y ninguna en hojas o modales.
4. El color dice una cosa. Un acento de marca para la acción o el número heroico; todo lo demás es un rol con significado (dinero/éxito, subida/peligro, estado, recompensa) y gris para lo que solo navega. Color decorativo = sobra. El color nunca funciona solo: una forma o una palabra lo acompañan.
5. Contraste medido, no supuesto. WCAG AA (4.5:1 texto, 3:1 texto grande e iconos) calculado a partir de los valores hex reales contra los fondos reales, modo claro y oscuro. El blanco sobre un color de marca verde/amarillo casi nunca pasa; el texto gris sobre fondo de color tampoco (elige un tono del mismo matiz).
6. Nada que la pantalla no pueda mostrar. Sin números inventados, sin proyecciones presentadas como datos, sin funcionalidades implícitas que no existen, sin estados vacíos que mientan. Diseña la versión más pequeña que realmente puedas enviar.
7. Un gesto de firma único, tomado del dominio. Un detalle de marca nacido de lo que muestra la aplicación (un precio de tablero de precios con el último dígito más pequeño, números de matriz de puntos en una app de running), no una nueva fuente o efecto; y se degrada con gracia donde no aplica. Todo lo demás es nativo: no pelees con la barra de pestañas, interruptores u hojas del sistema.
8. Las plataformas se envían juntas. Si el proyecto tiene iOS y Android (o app y web), el cambio va a ambas en el mismo PR, en cada idioma.
9. Verifica lo que el usuario ve. Capturas de pantalla en modo claro y oscuro, tamaño de texto más grande, una moneda/idioma no predeterminado, datos reales (nombres largos, vacío, 2.000 elementos). Lo que no se pueda compilar en tu entorno se audita mediante lectura, y el PR lo indica.

Cualquier agente (Claude Code, Codex, Cursor, Copilot, Gemini…)

Las reglas son las mismas en todas partes. Donde dice "agentes", usa lo que tu herramienta tenga: subagentes si los tiene (Claude Code, Codex…), con un worktree de git cada uno para los desarrolladores. Sin subagentes, ejecuta los revisores uno tras otro, cada uno con su propia instrucción, y mantén sus salidas separadas antes del paso de jurado. Donde dice "publicar", Claude Code publica un artefacto; otros agentes escriben un archivo HTML que el usuario abre. En una aplicación de chat sin una base de código, detente después de la propuesta de antes/después.

Acuerdo de trabajo (valores predeterminados)

• Revisores = senior product designers y desarrolladores = senior devs, como agentes (usa el modelo que el usuario pida). El orquestador no construye las áreas: hace el trabajo compartido, integra y audita.
• Cada decisión viene con una recomendación explícita y accionable.
• Antes de implementar, publica el antes/después y espera el "sí" del usuario.
• Cada ronda también revisa lo que las rondas anteriores enviaron y todos los videos/capturas recibidos, no solo los más recientes.
• Cuando se permite fusionar una vez que CI esté en verde: cierra con una lista de qué verificar al compilar (riesgos concretos) y, si no hay Mac/simulador, un prompt autocontenido para una sesión local.
• Ante "¿está todo hecho?": hecho (con PRs) · pendiente de ti · omitido a propósito.
• Después de la última ronda, actualiza el sistema de diseño del proyecto.

Flujo breve

1. Inventario: fotogramas de los videos (process.md § 1), pantallas y estados, y cada pantalla localizada en el código.
2. Sistema: verifica (o crea) las escalas de espaciado, tipografía, color y elevación (checklist.md § Sistema). Sin escalas, los revisores juzgan a ojo.
3. Pase en escala de grises + revisores en paralelo (3-4, uno por área) contra checklist.md, aplicando arreglos uno a la vez.
4. Propuesta ganadora: una página HTML con antes/después, la ficha de especificaciones y la lista de decisiones; el usuario elige.
5. Desarrolladores por área en worktrees aislados con una instrucción cerrada; integra, compila, audita, PR, responde a bots de revisión, fusiona cuando esté en verde.
6. Finalmente: actualiza el sistema de diseño del proyecto (doc + tokens + su propia habilidad) con lo nuevo.

Si el proyecto ya tiene su propia habilidad de diseño

Úsala para tokens y componentes concretos; esta aporta el método y la lista de verificación general. Si una regla aquí choca con una decisión escrita del proyecto, gana el proyecto y la propuesta lo señala.