DEV Community: Héctor Garduño Real

Manual del Design System (parte 2)

Héctor Garduño Real — Sun, 20 Mar 2022 17:07:49 +0000

Este es un resumen del libro "Design System Handbook" de InVision, que puedes descargar aquí.

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)

Manual del Design System (parte 1)

Héctor Garduño Real — Fri, 11 Feb 2022 00:41:44 +0000

Este es un resumen del libro "Design System Handbook" de InVision, que puedes descargar aquí.

Los Sistemas de Diseño

Un Design System es una colección de componentes reusables guiado por estándares, que pueden ser empleados en conjunto para construir cualquier cantidad de aplicaciones.

Los estándares abarcan tanto al diseño como al desarrollo, por ejemplo usando convención de nombres, requerimientos de accesibilidad o estructura de archivos; también se estandarizan aspectos como el lenguaje visual, el cual define el propósito del estilo de los colores, formas, iconos o espacios. Todo ello con el fin de crear consistencia, prevenir errores y apegarse al _branding _de la marca y crear una Experiencia de Usuario (UX) consistente.

Los componentes son porciones de código reusables que funcionan como bloques de construcción de las interfaces de aplicación. Cuanto más reusables sean los componentes menor será necesario su mantenimiento y será más facil será escalar la aplicación.

Algunos de los beneficios de contar con un Design System son:

Reducir la deuda de diseño, lo cual acelera el crecimiento de la aplicación.
Mejorar la consistencia de diseño, haciendo más predecible y fácil de usar una aplicación. Esto permite dedicar menos tiempo al diseño y centrarse más en la UX.
Facilita la construcción y experimentación de un sinfín de prototipos y variantes ya que se requiere una menor cantidad de líneas de código.
Se mejora la usabilidad, pues al tener una librería de componentes las interfaces e interacciones entre elementos se mantienen unificados.
Se mejora la accesibilidad tanto básicas como las definidas por las leyes del país.

Creación de un sistema de diseño

La creación de un sistema de diseño efectivo involucra disciplinas como Diseñadores (definen los elementos visuales), Desarrolladores front-end (crean el código), Expertos de accesibilidad (aseguran cumplimiento de estándares como WCAG), Estrategas de contenido (definen el tono y voz del sistema), Investigadores (ayudan a entender necesidades del cliente), Expertos de desempeño (aseguran el óptimo funcionamiento del sistema), Gerente de producto (asegura que el sistema se apegue a las necesidades del cliente) y Líderes (apoyan y alinean la visión de la empresa).

1. Definir el modelo

Para comenzar a crear el sistema de diseño conviene definir el modelo a usar con base a los objetivos.

Si se quiere avanzar rápido el Modelo solitario es el adecuado inicialmente, sin embargo después se tiene que trabajar para que los demás equipos adopten el sistema.
Si se quiere avanzar rápido pero animando la participación desde el inicio, el Modelo centralizado es el mejor.
Sin embargo para tener una mayor participación y mejor adopción el Modelo federado es la mejor opción ya que involucra a distintos equipos desde el inicio.

En este proceso será necesario hablar con contribuidores potenciales y clientes que ayuden a descubrir los casos de uso que el Design System debe satisfacer. Además conviene obtener las ideas o preocupaciones de ejecutivos, líderes y gerentes para convertirlas en objetivos y métricas, ejemplo de ello puede ser la entrega rápida de características, mejor desempeño o mejoras en la calidad de la interfaz.

2. Crear el inventario

Una vez reunida la información será necesario crear el inventario de los atributos visuales (colores, tipografía, espaciado, etc.) e inventario de los elementos de interfaz (botones, cards, mensajes modales, etc.).

Es una buena práctica realizar una auditoría visual de las hojas de estilo actuales para conocer la cantidad de reglas, selectores, declaraciones y propiedades usadas. La herramienta CSS Stats puede ayudar a ello.

3. Crear el lenguaje visual de diseño

Para definir un lenguaje visual se debe estandarizar mínimamente colores, tipografías (como tamaño o tipo de letra), espaciado (como márgenes, posicionamiento o bordes) e imágenes (iconos o ilustraciones), y dependiendo las necesidades también se puede estandarizar la forma visual (profundidad, elevación, sombras, esquinas, textura, etc.), el movimiento o el sonido a usar, con el fin de unificar la experiencia de usuario.

La Interfaz de Usuario (UI) usa el color para dar feedback, transmitir información gráfica o mostrar jerarquía. Algunos consejos de uso del color son:

Incluir 1-3 colores que representen la marca de la empresa.
Usar el mismo color para links y botones.
Usar colores neutrales (usualmente grises) para fondos y bordes.
Contar con colores para estados, por ejemplo de error, éxito, o advertencia.
Mantener una paleta de colores simple (que incluya tonos y sombras) para evitar inconsistencias de diseño o usos incorrectos.

Respecto a la tipografía, se debe seleccionar teniendo en mente la legibilidad y manteniendo las fuentes comunes (como Helvetica, Times New Roman o Verdana). La cantidad de tipografías también es relevante pues impacta en el rendimiento, por ello la mayoría de Design Systems emplea 2, una para los encabezados y otra para el cuerpo. Algunos consejos de uso de tipografías son:

Usar las variantes "light" o "thin" solo en tamaños de texto grandes.
Asegurarse de tener una correcta legibilidad en diferentes tamaños de pantalla.
Definir el "line-height" de cada tipografía para mejorar la legibilidad, 1.5 es el recomendado.
Usar una escala de espaciado consistente para promover la mantenibilidad y que la tipografía se ajuste y alineé correctamente. Una escala base 4 es recomendada (por ejemplo en iconos usan esta base, por ello los tamaños son 16, 24, 32, etc.; o el navegador web tiene el tamaño de letra por defecto en 16). Para espaciado horizontal una base 8 funciona bien.

Para las imágenes algunos consejos son:

El formato vectorial (svg) funciona mejor al escalar y en diseño responsivo.
Definir pautas claras para usar iconografía e ilustraciones, por ejemplo si los iconos emplean múltiples colores, si son sólidos o si son minimalistas.

También deben definirse las pautas para estandarizar la forma visual, es decir, color de fondo, gradientes, texturas, sombras, elevaciones, esquinas redondeadas y bordes. De igual manera se deben definir las pautas de movimiento y sonido ya que tienen un alto impacto en la experiencia.

4. Crear una librería de UI

Una librería de interfaz de usuario se conforma de piezas tal como botones, listas, tarjetas, formularios, etc. La mayoría de Design Systems en su definición incluye el nombre del componente, descripción, ejemplo, código fuente e incluso histórico de versiones.

Se puede iniciar simplemente creando un inventario del producto en producción tomando screenshots de todos los elementos, para posteriormente categorizarlos, combinarlos y dividirlos en piezas más pequeñas, ya sea piezas básicas (átomos, por ejemplo botones o iconos), piezas compuestas (moléculas o componentes, por ejemplo formularios de búsqueda), conjunto de piezas compuestas (organismos o regiones, por ejemplo un sidebar de navegación) y disposición de conjuntos (layouts, por ejemplo un header seguido de un sidebar, un main content y un footer).

Crear un Design System no solo ayuda al equipo a generar una experiencia de usuario consistente, también permite crear puentes entre diseñadores y desarrolladores, se mejora la comunicación y se construyen interfaces de usuario más manejables, escalables y robustas.

Manual del Design System (parte 2)