HTML en sistemas de diseño

Un sistema de diseño es una biblioteca compartida de componentes, tokens, patrones y directrices que se utiliza en los productos de una organización. La parte HTML del sistema encapsula las convenciones de marcado para que todos los productos representen estructuras coherentes de botones, modales, formularios y tarjetas.

Los tokens son valores atómicos de diseño (color: blue-500, spacing: 16px). Los componentes son unidades reutilizables de HTML+CSS+JS (Button, Modal, TextField). Los patrones son composiciones de nivel superior (formulario de inicio de sesión, tarjeta de contenido con avatar). La estructura HTML se fija en el nivel de componente; los patrones combinan componentes.

Los componentes incorporan buenas prácticas: cada Button utiliza el elemento <button> (no un div) con el atributo type adecuado. Cada Modal mantiene el foco, admite Escape y tiene los roles ARIA correctos. Adoptar componentes evita tener que volver a implementar la accesibilidad para cada funcionalidad del producto.

Storybook renderiza cada componente de forma aislada con distintas props y variantes. Los diseñadores y responsables de producto pueden ver los componentes disponibles sin leer código; los desarrolladores pueden consultar ejemplos de uso sin buscar en el código fuente. Es el estándar de facto para la documentación de sistemas de diseño.

Trate el sistema de diseño como un paquete publicado siguiendo semver. Los cambios incompatibles de HTML/CSS (cambiar el nombre de una clase CSS de la que dependen los consumidores, eliminar un slot de componente) incrementan la versión major. Los consumidores se actualizan intencionadamente según su propio calendario, no por sorpresa.

Las props, los slots y las partes expuestas de los componentes forman la API pública. Una vez publicados para los consumidores, considérelos costosos de cambiar. Retírelos gradualmente: añada la nueva API junto a la anterior, registre advertencias cuando se use la antigua y elimínela solo después de un periodo definido a partir de mediciones.

Los tokens permiten aplicar temas: cambie el mapa de tokens de color y cada componente adoptará la nueva paleta. La marca blanca (distintas marcas que comparten componentes con diferentes aspectos visuales) se vuelve trivial cuando todo se controla mediante tokens y los componentes hacen referencia a ellos en lugar de usar valores codificados de forma fija.

Para organizaciones que utilizan varios frameworks (React, Vue, Angular), los web components ofrecen una implementación que funciona en todas partes. Constrúyalos con Lit, FAST o JavaScript vanilla, y consúmalos de la misma forma en cualquier framework. La estructura HTML es el contrato, no el framework.

Los sistemas de diseño incorporan la accesibilidad una sola vez en cada componente: gestión del teclado, roles ARIA, gestión del foco y contraste de colores. Los equipos de producto que adoptan el sistema heredan la accesibilidad en lugar de crearla desde cero para cada funcionalidad; así se reducen de forma medible los errores de accesibilidad en toda la empresa.

Realice un seguimiento de qué productos utilizan cada versión del sistema de diseño. Herramientas como el catálogo de componentes de Backstage, bots de Slack personalizados que supervisan package.json o sencillos paneles internos muestran dónde aún no se ha incorporado la versión más reciente. Las métricas de adopción justifican mantener la inversión.

Decida quién puede añadir componentes: ¿solo un equipo central de sistemas de diseño? ¿Contribuciones federadas de los equipos de producto? Cada modelo tiene sus ventajas y desventajas. Los equipos centrales publican más despacio, pero mantienen la calidad; los equipos federados avanzan rápido, pero corren el riesgo de fragmentación. Elija conscientemente según la escala de la organización.

Los sistemas de diseño son productos vivos. Añada componentes cuando aparezcan nuevos patrones en los productos, retire los que ya no encajen y refactorice cuando sea necesario cambiar decisiones fundamentales. Trate el sistema como software con una hoja de ruta, no como un artefacto terminado.

¿Por qué se prefieren los tokens de diseño (como color: blue-500, spacing: 16px) a los valores codificados de forma fija dentro de los componentes?

Los sistemas de diseño agrupan tokens (valores atómicos), componentes (unidades HTML reutilizables) y patrones (composiciones de nivel superior) en una biblioteca versionada compartida entre productos. Utilice Storybook para la documentación, web components para el consumo entre frameworks y semver para mantener la estabilidad. Incorpore la accesibilidad en cada componente, realice un seguimiento de la adopción y evolucione el sistema como un producto vivo.