Trabajo / Front-end / Design System EdG
Este portfolio, desmontado en 37 piezas
Proyecto 12 de 28 del archivo 03 de 08 en Desarrollo front-end Ver la disciplina completa ↗
Ábrela y úsala: 37 componentes con su código listo para copiar
La web de documentación completa, con el buscador, los dos temas y los tres anchos. Se abre en una pestaña nueva y trae su propio botón para volver aquí.
Un sistema de diseño que solo vive en Figma no es un sistema
La auditoría de este portfolio terminó en un archivo de Figma con la paleta, la rampa tipográfica y los componentes puestos en orden. Es exactamente donde mueren la mayoría de los sistemas de diseño: bonitos en el canvas y sin traducción al navegador.
Quien maqueta no abre Figma para saber cuántos píxeles mide un radio. Abre el inspector de otra página y copia. Y al tercer copiado el sistema ya no existe.
Así que el sistema se escribió en código: los mismos tokens, los mismos componentes y los mismos estados, en archivos que se pueden enlazar. Esta web está construida con ellos, y la librería es la prueba.
Componentes documentados
En siete grupos, de fundamentos a formularioTokens en tokens.css
Líneas de librería
200 de tokens · 1.068 de componentes · 317 de JSTemas completos
Oscuro canónico y claro, sin duplicar un componenteLa regla que decide todo lo demás
Ningún componente tiene un color o un tamaño escrito a mano. Todos leen variables de tokens.css. Cambiar un token cambia la librería entera, y eso es lo que separa un sistema de una carpeta de fragmentos.
Tres ideas y ni una excepción
Un sistema pequeño aguanta si tiene pocas reglas y no se salta ninguna. Estas son las tres, y están escritas en el README antes que en ningún componente.
01 · Todo sale de los tokens
Los tokens son semánticos, no descriptivos: --bg, no «negro». Eso permite dos modos completos —oscuro canónico y claro— sin duplicar un solo componente. Ojo con el claro: el acento principal no es el verde, es azul #1f4dff, y el texto sobre acento pasa a blanco.
Figma · 01 Foundations — Palettecss/tokens.css
02 · El acento se hereda
Poner data-disc="ux | front | graphic" en un componente —o en cualquier ancestro— reasigna --accent, y con él el filete, el chip, los puntos y los estados hover de todo lo que haya dentro. Un atributo en una sección recolorea la sección entera.
Es la razón de que el archivo de trabajo pueda pintar tres disciplinas con un único juego de componentes en lugar de con tres.
Tres acentos · UX · Front · GraphicUn solo componente
03 · El responsive vive en los tokens
Figma define tres modos de medida —Desktop 1440, Tablet 834 y Mobile 390—. En código son dos media queries en tokens.css que reescriben la rampa tipográfica y el espaciado. Nada más.
Los componentes solo añaden media queries cuando cambian de estructura: la cabecera saca el burger, el pie colapsa columnas, la fila del archivo se apila. El resto baja solo.
Cortes · ≤900px · ≤620px--t-h2 86 → 59 → 40
El ejemplo y el código son el mismo archivo
La trampa clásica de documentar componentes es que el ejemplo se dibuja a mano y el snippet se escribe aparte: al tercer cambio, mienten los dos. Aquí el HTML del catálogo es a la vez lo que se renderiza y lo que se copia. Si el ejemplo funciona, el snippet es correcto. No hay otra forma de que no coincidan.
Y cada ejemplo se pinta dentro de un iframe con su propio viewport, cargando exactamente los mismos tokens.css, components.css y edg-ds.js que se le entregan al equipo. Al ser un ancho de verdad, las media queries responden: los botones Desktop / Tablet / Mobile enseñan el comportamiento real, no una maqueta de él.
Lo que trae cada ficha
Nombre del componente, sus clases, el nodo exacto del Figma del que sale, la descripción de para qué sirve, la tabla de variantes tal y como están en el archivo de diseño, el ejemplo con todas sus combinaciones y el código en tres pestañas: el marcado, el bloque real de components.css y el JavaScript que hace falta llamar, si hace falta alguno.
El CSS que se enseña no es una copia: se lee de los marcadores /* @c: id */ … /* @end */ del propio archivo de componentes en el momento de construir. Tampoco puede desincronizarse.
El estado vive en ARIA, no en clases sueltas
Los chips, el conmutador de vista y el de idioma llevan su estado en aria-pressed; la navegación en aria-current="page"; el burger y el acordeón en aria-expanded; el contador del archivo en aria-live. El CSS se engancha a esos atributos. Un componente no puede parecer activo sin estarlo, porque es el mismo atributo el que lo pinta y el que lo anuncia.
El resto viene detrás: iconos decorativos con aria-hidden, anillo propio de :focus-visible en el acento, y marquesina, pulso y reglas animadas detenidos con prefers-reduced-motion.
Un logotipo, un archivo
La marca no se coloca como imagen sino como máscara: el archivo vive en el token --logo y el componente lo pinta con background: currentColor. Un único archivo se pone blanco sobre oscuro, negro sobre claro y se tiñe con el acento de disciplina cuando toca, sin mantener tres versiones del mismo logo.
La librería, funcionando
Aquí debajo está la web de documentación entera: busca un componente, cámbiale el tema, estrecha el ejemplo a tableta o a móvil y copia el código. Todo lo que se ve es la librería usándose a sí misma.
Un marco es buen sitio para demostrar que algo existe y mal sitio para usarlo. Para recorrerla de verdad, ábrela en una pestaña — y desde allí, el botón Volver al portfolio de la barra superior te trae de vuelta a esta ficha.
También en inglés · un solo archivo autocontenido de 344 KB
De dónde sale
Este proyecto tiene tres partes y viven en disciplinas distintas. El diagnóstico, el research y el diseño del sistema están en la ficha de producto UX/UI: la auditoría de este portfolio. Lo que estás leyendo es la segunda: ese sistema escrito en código y documentado para que lo use alguien que no sea yo. Y la tercera es la que lo saca de la pantalla: la tarjeta de visita, impresa con estos mismos tokens.
El control de la derecha salta entre las tres.
Siguiente en Desarrollo front-end
Kacho Cano
