Cuando oímos hablar de desarrollo frontend, la mayoría de las veces pensaremos en la parte puramente relacionada con la codificación, pero… ¿Qué hay de la experiencia de usuario?, ¿de la usabilidad?, ¿de ese efecto “wow!” que le queremos dar a nuestra aplicación? ¿Cómo se refleja eso en una documentación? Y lo más importante, ¿Cómo es la continua comunicación entre diseño y desarrollo?, para eso tenemos los sistemas de diseño, pero…
Un sistema de diseño es la guía que se utilizará por parte de todos los implicados en la creación de un nuevo producto (diseño, negocio y equipos de desarrollo/arquitectos) desde la fase de conceptualización hasta la de desarrollo.
Este sistema va a contener desde la guía de estilos (colores, fuentes, espaciados, iconografía, etc) hasta los componentes básicos (building blocks) con los que se podrán construir componentes más complejos.
Un sistema de diseño está basado en la metodología Atomic Design ideada por Brad Frost e inspirada a su vez en la química donde nos podemos encontrar grupos de átomos que conforman moléculas y grupos de moléculas que forman organismos. Esto, si lo trasladamos a un sistema de diseño nos encontraríamos con los componentes building blocks que serían lo equivalente a los átomos, que unidos pueden conformar componentes más complejos (moléculas) y así sucesivamente hasta tener la página que ve el usuario, el producto final.
Pongamos el caso de que para un producto surge una necesidad nueva, esta necesidad tiene que pasar primero por el equipo de diseño para que decida si todo o parte de esa funcionalidad puede ser incorporada como transversal al sistema de diseño y que incluso que el desarrollo de esos componentes transversales los asuma otro equipo. Una vez se hace esto y el equipo de diseño conviene que con lo que hay en el sistema se puede desarrollar la nueva necesidad, el equipo de desarrollo ya puede comenzar con la implementación.
Si volvemos al concepto de atomic design podríamos decir que los design tokens son una especie de partículas subatómicas dentro de nuestro sistema de diseño que nos ayudan a construir el lenguaje visual y mantener la coherencia.
En base a nuestro sistema de diseño podemos construir productos para diferentes plataformas (web, iOS, Android…) y todos ellos compartirán el mismo lenguaje visual. Lo que no comparten estas plataformas es la manera en la que trasladamos al código fuente todo lo que contiene el sistema de diseño, entonces… ¿Cómo lo solucionamos?, ¿Cómo hacemos que esto sea mantenible?
Para eso tenemos nuestros design tokens, se acabó buscar y reemplazar valores “hardcodeados” en los productos!. El nombre de un token va a hacer siempre referencia a un valor que en un determinado momento puede cambiar, pero solo tenemos una parte donde vamos a modificar este valor, el sistema de diseño.
Estos tokens pueden ser almacenados en un fichero con un formato estándar como puede ser un fichero JSON para posteriormente generar los recursos que necesitemos para el lenguaje/plataforma que estemos utilizando en nuestras aplicaciones.
A continuación, mostramos un ejemplo de esto utilizando Style Dictionary, donde creamos un fichero que contiene tokens de color y de tamaño que posteriormente, utilizando un cliente de su librería podemos transformar a variables en la plataforma que necesitamos, en este caso transformado a formato CSS.
Los componentes son piezas reutilizables dentro de nuestro sistema de diseño que harán que nuestros productos sean consistentes y mantenibles.
Podemos encontrarnos las piezas más básicas a las que llamaremos “Building blocks” y con las que podremos construir otras piezas más complejas, pero igualmente reutilizables.
En el siguiente ejemplo podemos ver un ejemplo del building block botón sacado del sistema de diseño de Atlassian.
En este otro ejemplo de un componente dropdown formado por átomos proveniente del mismo sistema de diseño:
Un patrón en un sistema de diseño es una solución que se da a un problema común. Esta solución se encontrará utilizando componentes y templates del propio sistema.
Un ejemplo de patrón es el que mostramos a continuación del sistema de diseño de Atlassian mencionado anteriormente para componentes y donde se puede ver la solución encontrada para el desarrollo de formularios.
La inversión de tiempo en la construcción de un sistema de diseño sólido aporta grandes beneficios a los ciclos de desarrollo de software: