Diseñar

Diseñar relaciones, no pantallas aisladas

Color, tipografía, espaciado y movimiento deben ayudar a entender qué pertenece, qué cambia y qué acción tiene prioridad. Los principios de Gestalt que vimos en la unidad anterior se vuelven acá herramientas concretas: la proximidad agrupa, la similitud clasifica y el contraste ordena la atención.

• Tokens y foundations
• Componentes con estados
• Retícula fluida
• Movimiento con propósito
• Ley de Fitts: tamaño y distancia de los objetivos táctiles

De componentes a Design System

Una biblioteca de componentes se vuelve un Design System cuando deja de ser un archivo y pasa a ser un acuerdo: tokens con nombre y significado, componentes documentados con sus estados y sus límites de uso, versionado que permite evolucionar sin romper lo existente, y alguien que decide qué entra. Sin eso es una carpeta de piezas bonitas que cada quien copia y modifica.

• Tokens como decisiones con nombre
• Documentación: cuándo usar y cuándo no
• Versionado y adopción
• Gobernanza: quién decide qué entra al sistema

Ingeniería de UI: el sistema también es código

Un Design System que sólo existe en el archivo de diseño se desincroniza en la primera semana. Los tokens se materializan como variables —en este sitio, custom properties de CSS— y los componentes como piezas con un contrato: qué propiedades aceptan, qué variantes existen, qué estados saben representar y qué queda fuera de su responsabilidad. Ese contrato es lo que hace que una decisión tomada una vez se aplique en todas las pantallas sin que nadie la copie a mano.

Pensar la interfaz como sistema cambia la unidad de trabajo: no se diseña una pantalla, se diseña una pieza que va a aparecer en pantallas que todavía no existen. Por eso importan tanto el nombre, los límites de uso y el comportamiento en los casos incómodos —texto largo, dato faltante, red lenta—, que son justamente los que la maqueta de presentación nunca muestra.

• Tokens en código: color, tipografía, espaciado y radios como variables
• Contrato del componente: propiedades, variantes y estados
• Casos incómodos: texto largo, dato ausente, carga y error
• Catálogo navegable como documentación viva del sistema
• Criterios explícitos sobre qué entra al sistema y qué queda fuera