Este es un resumen del libro "Design System Handbook" de InVision, que puedes descargar aquí.
Manual del Design System (parte 1)
Construyendo tu Design System
La creación de un Design System exitoso implica que deban aplicarse los principios de consistencia, auto-contenido, reusabilidad, accesibilidad y robustez.
Consistencia
Los componentes deben construirse bajo un patrón predecible, por ello la primera y más importante de las tareas será definir las reglas del sistema, documentarlas y asegurarse que todos las sigan.
También es recomendable crear una Guía de estilo de código que defina las reglas gramaticales, de sintaxis, semánticas y de formato del código fuente. Ejemplos de esto podrían ser que las llaves deben ir en una nueva línea, o que se deben colocar las propiedades CSS en orden alfabético.
Un buen punto de partida para crear la guía es basarse en el cuestionario de Brad Frost y recopilar ideas de reglas a implementar, las guías css y javascript de airbnb son buen ejemplo de implementación. También se puede definir como regla la correcta escritura de código apoyándose de herramientas como EditorConfig, linters como CSSLint, StyleLint, JSHint, ESLint e inclusive para asegurar las buenas prácticas en git con Git Hooks.
Auto-contenido
El Design System debe ser tratado como una dependencia independiente y debe vivir en un repositorio de control de versiones, es decir, no debe formar parte del código fuente de la aplicación. Hacerlo así trae beneficios como el mantener distintas versiones, compartir código entre distintos equipos o aislar los componentes para permitir distintos casos de uso.
Reusabilidad
Los componentes construidos deben poderse reutilizar en distintos contextos y para lograrlo deben ser:
- Modulares: Deben ser auto-contenidos y no tener dependencias.
- Acoplables: Deben poderse combinar para crear nuevos patrones.
- Genéricos: Deben poderse usar un cualquier caso de uso.
- Flexibles: Deben poderse modificar y extender para trabajar en distintos contextos.
Cuando dos diferentes piezas de código realizan la misma función se duplica la posibilidad de obtener errores, por eso el objetivo a seguir en nuestro Design System es usar el principio DRY (Don't Repeat Yourself).
Una recomendación para mejorar la reusabilidad en CSS es usar sistemas como SMACSS, OOCSS, BEM o Styled Components. Otra recomendación en CSS es usar cortos namespace prefixes para reducir el conflicto entre librerías o si se trabaja con código legacy (obsoleto), por ejemplo '.[prefix]-[component]', es decir '.ds-btn'.
Accesibilidad
Las aplicaciones construidas con el Design System deben poder usarse por la mayor cantidad de personas posible, sin importar cómo ingresen. Mejorar la accesibilidad no solo beneficia a ese 15% de la población, ya que por ejemplo también mejora el SEO.
Un buen punto de partida para aprender es a11y, WAI y WebAIM, o herramientas como Tota11y.
Para asegurar que todos en la organización desarrollen sitios, características y aplicaciones accesibles se deben hacer cumplir las siguientes buenas prácticas:
- Probar el contraste de color. 📖 Contrast Grid, WebAIM Contrast Checker
- Crear componentes para que el teclado y el lector de pantalla sean accesibles de forma predeterminada. 📖 eBay MIND Patterns
- Incluir en la documentación estándares y guías apegadas a a11y, como el uso de tamaños de texto más grandes y legibles, etiquetas asociadas a campos de formularios o asociar textos alternativos a las imágenes mediante el atributo "alt". 📖 Salesforce Lightning DS, Shopify Polaris DS
Robustez
Debe funcionar correctamente y con mínimos errores sin importar el producto o plataforma en donde es aplicado, por lo que debe haber una sólida base de pruebas detrás del Design System. La recomendación es probar el Design System en lugar de probar una complicada interfaz de usuario, y para ello se deben mantener los tests actualizados para páginas, aplicaciones y características, ya que los tests quedan desactualizados rápidamente.
Hay cuatro tipos de tests usados:
- Unit testing: Verifican que las pequeñas unidades de código (generalmente funciones de JavaScript individuales) se comportan como se esperaba. 📖 Mocha, Jasmine, Jest
- Functional testing: Verifican que los ejemplos de código o características (fixtures) se ejecutan en un navegador virtual, luego se prueban realizando acciones de usuario simuladas y verificando el nuevo estado del navegador para obtener el resultado esperado. 📖 Nightwatch, Protractor, Casper
- Visual regression testing: Verifican cambios visuales no deseados en los estilos de los componentes. El framework toma capturas de pantalla de las características (fixtures) antes y después de los cambios, luego los compara usando un algoritmo para detectar diferencias visuales. 📖 Wraith, Gemini, BackstopJS, Applitools, Percy.io
- Automated accessibility testing: Se realizan pruebas automatizasas aprovechando las herramientas de accesibilidad. 📖 AATT, a11y, aXe
Desafíos comunes
Ningún sistema es perfecto, podrás tomar decisiones de las que luego te arrepentirás sin importar el tiempo dedicado. Sin embargo, se pueden anticipar los problemas a medida que crece el sistema, evitando o mitigando su efecto.
Mantenimiento de la documentación
Cuando la documentación y el código comparten ubicación, es más probable que se recuerde actualizar la documentación cuando se cambia un componente. Una recomendación es crear un pre-commit hook al repositorio del Design System para advertir si el código no contiene documentación actualizada.
Se puede comenzar por documentar el Design System utilizando archivos simples y legibles por humanos escritos en Markdown, ubicados junto con cada componente, pues es posible que no se necesite un sitio web llamativo, y si se decide crear un sitio web de documentación con todas las funciones se puede usar una herramienta de auto-generación de documentación para reducir el tiempo dedicado a crearlo y mantenerlo como por ejemplo Cupper.
Si buscas mejorar el performance del CSS puedes usar herramientas como UnCSS o Critical path CSS.
La forma incorrecta: Duplicación
Al refactorizar componentes se suele seguir escenarios como estos, por ejemplo para que el componente "Tab" sea totalmente accesible se crea un nuevo componente llamado "Tabs2" y se descarta "Tabs" con la esperanza de que los equipos asuman el trabajo de actualizar su código. Pero sin una guía clara sobre cómo, por qué y un cronograma que indique cuándo actualizar, la mayoría no lo hará y el mantenimiento del código se hará más y más complejo.La forma correcta: Versionamiento
Los cambios importantes son más fáciles de administrar si se almacena el código del Desig System en el propio repositorio del código fuente. Se puede usar el SemVer para definir el versionamiento.
Poblemas de desempeño
Más de la mitad de los visitantes móviles abandonarán las páginas que tardan más de 3 segundos en cargarse, sin embargo, la mayoría de los sitios móviles tardan más de 10 segundos en cargarse.
La mejor forma de evitar problemas de desempeño es adoptando un enfoque mobile first y construir teniendo en cuenta la modularidad, después se debe probar temprano y con frecuencia en dispositivos reales, con hardware real y una conexión de red real para así comprender las experiencias de los usuarios reales.
La sistematización del código beneficia a todos en la organización, los desarrolladores se mueven más rápido, los diseñadores no tienen que reinventar la rueda y, en última instancia, los usuarios tienen una mejor experiencia. Un Design System flexible, mantenible, estable, escalable y exitoso comienza con una base sólida que va más allá de los marcos o las herramientas.
Manual del Design System (parte 3) (Próximamente)
Top comments (0)