Design Systems: desmontando a tu cuñado.

Aunque ya llevan unos años con nosotros, “Design System” es sin duda uno de los hot topics de los últimos tiempos. Si te dedicas al diseño o al desarrollo front, tendrás una idea bastante clara de a qué hace referencia. Pero es fácil que algunas personas sólo hayan oído algunas cosas aquí y allá… Vamos a ver cómo podemos desmontar algunas ideas preconcebidas o poco acertadas que nuestro cuñado podría tener en la cabeza acerca de ellos.

“Es una guía de estilos”.

Falso. Una guía de estilos o una librería de componentes puede ser un buen punto de partida, pero es mucho más que eso.

Es cierto que existen desde hace mucho las guías de estilos. Son útiles cuando tienes que diseñar no sólo una cosa, sino un set completo de elementos gráficos que quieres que sean coherentes. Es algo muy antiguo y en diseño web se han usado durante muchos años.

Posteriormente, algunos frameworks como Bootstrap los evolucionaron aportando código reutilizable para construir de manera sencilla elementos UI consistentes como botones o dropdowns. Tener un UI kit está muy bien porque permite mantener coherentes todos esos pequeños componentes. Sin embargo, estas librerías generalmente no indican nada sobre cómo deben agruparse, sobre tu producto digital o sobre los conceptos que hay tras él.

Con los Design Systems se ha llevado el concepto más allá, aportando mayor racionalidad. Podemos decir que representan un Single Source of Truth para el diseño digital: se trata de un conjunto de guías que buscan hacer el diseño fácil de implementar, proveen consistencia entre los equipos de diseño e incrementan la calidad de los productos digitales. En otras palabras, debe permitir responder preguntas específicas y evitar cualquier confusión o ambigüedad indicando qué se debe usar para satisfacer cada necesidad de un diseño, el cómo y el por qué.

“Understanding not only the what, but the why, behind the design of a system is critical to creating an exceptional user experience. Defining and adhering to standards is how we create that understanding”, Marco Suárez, Product designer en InVision.

“Entonces es un catálogo de componentes” o “ Sólo incluye temas relativos al aspecto visual”.

Que nooo.

En cierto modo es normal que haya confusión, puesto que la guía de estilos o el catálogo de componentes son los outputs más visibles. Pero realmente estamos hablando de un ecosistema mayor en el que habitan esa guía de estilos y ese catálogo de componentes. Se trata de establecer reglas y dar contexto, que es lo que marca la diferencia. Dicho así suena un poco abstracto, pero nada más lejos de la realidad.

Seguramente esta ambigüedad se produce también porque nos fijamos en el continente más que en el contenido. Es cierto que no existe una convención general al respecto de los outputs que debe tener, pero es que ahora los límites entre unos y otros se diluyen bastante. Lo verdaderamente importante es que todo el contenido necesario esté disponible para los equipos de una manera cómoda. Así que, si nos centramos en el contenido sí podemos explicar (a grandes rasgos) a nuestro cuñado qué es lo que cualquier Design System que se precie debería cubrir:

Documentación.

Toda la información que los equipos puedan necesitar o que nos aporte contexto y ayude a comprender el por qué de las decisiones o indicaciones incluidas en el sistema:

• Activos de la marca: misión, valores, voz, tono…
• Principios de diseño: normas que nos permiten vincular el producto digital con la marca. Qué propósitos y valores tenemos respecto al mundo digital. Hay quien prepara incluso un design manifesto.
• Buenas prácticas y estándares: estándares de codificación que se usarán, QA, enfoque mobile first, accesibilidad, diseño atómico, ¿vamos a recomendar un Dark Mode?, etc.
• Pruebas, análisis o test en los que se apoyan determinadas decisiones.
• Metodologías y procesos: información relativa a mecanismos de contribución y versionado, política de releases, gobierno, formas de comunicación, etc.

Lenguaje visual.

Se trata de las características visuales que fundamentan nuestros productos. Incluirá cosas como: composición, colores, tipografías, etc. . La mayoría de estas características visuales se especifican mediante design tokens, que son entidades con nombre que representan atributos de diseño. A la postre se almacenan en un JSON o YAML por lo que son agnósticos al lenguaje que usen los proyectos. Son los que nos van a permitir cambiar el aspecto de los componentes de manera sencilla y consistente.

Esta parte es la que en algunos casos se denomina “Guía de estilos”.

Componentes y patrones.

Se trata de una recopilación de los componentes que el sistema tiene disponibles para la construcción de productos. Serán los “building blocks” de nuestras interfaces de usuario.

Hay 2 formas comunes de organizar los componentes:

• De manera estructurada: se estructuran los elementos de más sencillos a otros más complejos. Es habitual usar un enfoque de Diseño atómico donde los elementos son modelados de acuerdo a una jerarquía de 5 niveles: átomos, moléculas, organismos, templates y páginas.
• Usando páginas de patrones: agrupamos los componentes según su naturaleza o propósito creando una estructura plana.

En cualquier caso, cada componente debe disponer de una descripción visual, una librería para los diseñadores, una descripción funcional y el código necesario para su implementación. Se puede implementar además un sandbox que permita ver los componentes en funcionamiento.

Esta parte es la que en algunos casos se denomina “UI kit”, “catálogo de componentes” o “pattern library”.

“Esto no es nuevo. Ya existía pero ahora lo llaman de otra manera”.

No es cierto. Como hemos visto, algunos de los elementos sí existían anteriormente. Pero el uso de los Design Systems supone un cambio de paradigma, un cambio en la forma de hacer las cosas.

¿Por qué ahora? La aparición de nuevas y disruptivas tecnologías en la era digital ha supuesto un reto a la hora de desarrollar:

• Número de dispositivos, navegadores y entornos en aumento.
• Digitalización de más áreas de negocio.
• Ampliación del alcance de los productos digitales.
• Crecimiento de los equipos, donde varias personas podrían estar trabajando a la vez en un mismo diseño.
• Reducción del time to market, pero sin perder calidad.

Es complicado diseñar, prototipar y desarrollar nuevas funcionalidades con rapidez y que todo se mantenga homogéneo. Y sabemos que el diseño no escala con facilidad si no se dispone de estándares descritos en algún sitio. La necesidad de crear Design Systems reflexivos y consistentes que permitan escalar los diseños se ha vuelto más evidente que nunca. Ya no hay tiempo para el gap diseñador-desarrollador.

Por otro lado, teniendo por fin el diseño el peso que se merece en la transformación tecnológica, parece lógico que se hayan explorado nuevas formas de trabajo y colaboración entre los perfiles involucrados.

Por tanto, el momento era sin duda el idóneo para la aparición de estos sistemas de diseño.

“Todas las iniciativas digitales necesitan un Design System detrás” o “Sólo las compañías de tecnología o apps deberían apoyarse en uno”.

No. Un Design System es útil para cualquier compañía que tenga presencia digital. Pero esto no quiere decir que todas las empresas con presencia digital lo requieran.

Si se trata de una empresa pequeña que tan sólo tiene una web puede que no necesite construir algo tan elaborado. Pero si se trata de una empresa con múltiples productos digitales, sí le resultará útil disponer de uno que dé soporte a todos los equipos de trabajo, y que asegure la homogeneidad y consistencia del resultado.

“Una vez implementado en tu empresa, no será necesario contar con diseñadores”.

Falso. No es un proyecto con una implementación final, es un producto que sirve a otros productos. Aunque obviamente tiene outputs tangibles, está vivo, puede (y debe) ser mantenido y evolucionado. Por tanto, tendrá su roadmap y su backlog.

"Design Systems are always evolving, and the way you share and encourage adoption of new iterations will evolve along the way as well", Diana Mounter, Design Systems Manager en Github.

Pero no sólo eso. Cuando su madurez lo permita, debe compartirse y promoverse mediante demos o presentaciones, así como realizar comunicaciones de las actualizaciones que se realicen. También pueden proveerse mecanismos para que otros equipos puedan contribuir al mismo.

Es necesario disponer de un equipo multidisciplinar con dedicación a su mantenimiento, evolución y gobierno. Este equipo debe contar con diseñadores (incluyendo UX y visual), desarrolladores (generalmente front, pero pueden ser Full stack) y un product manager, siendo interesante también la presencia de perfiles de otras áreas como marketing o comunicación, especialistas en accesibilidad, researchers, QA...

Lo más común es encontrarse con una de estas opciones:

• Modelo centralizado, en el que existe un equipo que se encarga exclusivamente de él.
• Modelo distribuido, en el que algunos miembros de los equipos de producto tienen una dedicación parcial a la evolución y mantenimiento.
• Modelo mixto en el que además de existir un equipo dedicado, se dan colaboraciones y contribuciones desde otros equipos.

Por tanto, puede que en el equipo de un proyecto determinado se decida no contar con diseñadores para hacer uso del Design System (mal, los diseñadores UX hacemos mucho más que “poner las cosas bonitas”), pero estos siempre estarán involucrados en su mantenimiento.

“Implementarlo es muy sencillo”.

Todo depende de las necesidades que tengamos, pero a priori no es una tarea sencilla.

• El primer paso es analizar dónde estamos y hacia dónde queremos ir. Analizar la marca y realizar una auditoría visual de nuestra presencia digital, ya contemos con productos o guías. Si partimos totalmente de cero, debemos analizar cuáles son las necesidades actuales y enfocarnos en las mismas como punto de partida. Este análisis inicial nos permitirá priorizar el esfuerzo a realizar.
• Definir el equipo necesario, trazar un roadmap y crear el backlog.
• Establecer cuáles serán nuestras reglas y principios de diseño.
• Crear el lenguaje visual.
• Crear la librería UI. Catalogar los componentes que se están usando ahora mismo (teniendo en cuenta prioridades). Dividir, fusionar y eliminar lo inservible para tener un catálogo de componentes básicos (no es necesario crear el catálogo completo desde el principio). Cada componente debe tener diseñados todos sus estados y estar codificado en base a los estándares que hayamos definido.
• Documentar el comportamiento y el aspecto de cada componente, indicando cuándo se debe usar y cómo. Es uno de su principales valores
• Lanzar, medir, iterar...

Y, todo esto, teniendo en cuenta el impacto de cualquier cambio que propongamos sobre los productos actuales (la creación de un Design System provocará rediseños casi con toda seguridad).

No es algo que pueda realizar un único perfil en poco tiempo. Como hemos visto antes, su construcción requiere un esfuerzo inicial y el trabajo posterior constante de un equipo multidisciplinar con experiencia.

“Es imposible medir el beneficio que aporta”.

Aquí te toca discutir un poco con tu cuñado.

Lo primero que debemos aclarar es que un Design System es una inversión a largo plazo. Sus beneficios son mayores cuanto más maduro es el sistema.

¿Pero cuáles son estos beneficios? Hace que sea más fácil prototipar, liberar, probar, mantener, evolucionar y medir tus experiencias digitales, reduciendo tiempos y la posibilidad de cometer determinados errores.

Todos esos patrones similares que tenemos se pueden actualizar en menos tiempo y con la frecuencia que se desee. Además, aseguramos la calidad al estar todos los elementos probados y codificados siguiendo estándares, pudiendo ser modificados de manera rápida y sencilla mediante design tokens. De esta manera se mitiga la deuda técnica y de diseño que podríamos arrastrar sin un sistema centralizado.

También nos permite experimentar más, pudiendo idear nuevos layouts y funcionalidades sobre un sandbox con los componentes existentes. También nos va a permitir crear más variantes y versiones, haciendo más sencillo el A/B testing… Los beneficios son muchos.

Como es lógico, a todos los clientes les apasiona el ahorro de tiempo y disponer de releases cuanto antes y con la mayor calidad posible. Así que ahí es donde podemos poner foco. La frecuencia de despliegue de releases de nuestros productos es un valor fácilmente medible. Y también podemos echar un vistazo a la variación que se produce en cuanto a bugs relativos al front.

Por otro lado, el disponer de componentes codificados centralizados nos permite analizar y evaluar su uso de una manera más precisa. Y así podríamos prestar atención también a la reutilización de los mismos dentro de la compañía. En este artículo podemos ver cómo en BBVA han medido el beneficio de la reutilización de los componentes desde la propia herramienta de diseño.

Pero aún hay más: mejorará la experiencia de usuario de nuestros productos y mejorará la imagen de nuestra marca. Para medir el grado de cumplimiento de estos beneficios, tendremos que establecer los KPIs oportunos y usar las técnicas adecuadas (test de usuarios, midiendo la reducción del número de errores en determinados procesos, usando System Usability Scale, Net Promoter Score, etc.).

Por último, si lo que deseamos es medir el éxito del Design System en la organización, podemos fijarnos en el número de productos que lo están usando, el número de contribuciones que recibe, el número de componentes deprecados o propiedades CSS específicas que aún existen, etc.

“Es un recurso privado”.

Nada más lejos de la realidad.

Ya hemos visto que su éxito se mide en gran medida en función del número de productos que lo usan y las contribuciones que otros equipos hacen al mismo. Por tanto, es fundamental compartirlo con otras áreas de la empresa y darlo a conocer internamente.

Pero vamos más allá. Muchas de las grandes empresas hacen públicos sus sistemas de diseño. ¿Por qué deberíamos hacerlo?

• Por gratitud y solidaridad: el entorno digital evoluciona muy rápido y es habitual que muchos profesionales aprendamos gracias a la generosidad de otras empresas que publican su trabajo.
• Porque puede reforzar determinados valores de nuestra marca como la transparencia.
• Porque puede ser más cómodo si nuestra empresa trabaja con diseñadores y desarrolladores de terceros.
• Porque si estamos orgullosos de nuestro trabajo, ¿por qué no mostrar al mundo lo bien que sabemos hacer las cosas?

“Limitan la creatividad”, “Con un Design System todas las webs y aplicaciones parecen iguales” o “En el futuro, el diseño de interfaces se convertirá en algo monótono”.

Uy, tu cuñado se está poniendo duro…

Uno de los objetivos que se persigue con la implantación de un Design System es precisamente la homogeneidad. Todas las páginas o pantallas de nuestro producto deben ser similares en aspecto y comportamiento, y nuestra marca debe ser reconocible en ellas. ¿Dónde queda la creatividad? Bien, tiene su espacio en el momento de su construcción y lo tiene también en la evolución del mismo a medida que se definen nuevos componentes (recordemos que en nuestro sistema pueden existir componentes tan complejos como páginas).

¿Acaso la presencia digital de Banco Santander se parece a la de Airbnb? ¿La de Uber se parece a la de Google? Cada una tiene sus particularidades. Seguro que comparten muchos de los componentes más básicos, pero se diferencian en el estilo, en los componentes más complejos y en la manera en que éstos se armonizan.

Por otro lado, pueden existir excepciones a todo lo descrito. No hay problema con ello siempre que estén especificadas y no exista duda sobre cuándo está realmente justificado salirnos de la norma. Aquí deberíamos prestar mucha atención a cuál es el objetivo que se persigue en cada caso. Imaginemos que Nike tiene su Design System. Si se desea hacer un microsite para el lanzamiento de unas nuevas zapatillas ¿Estamos seguros de que tenemos que ajustarnos 100% a todo lo que se indica allí? Que se identifique la marca sí, pero ¿es necesario que este microsite se parezca a la web corporativa o a sus herramientas online de backoffice? Seguramente no.

Sí es cierto que como diseñador puedes encontrarte en la situación de tener que trabajar con Design Systems maduros en los que (por el motivo que sea) no tengas muchas opciones para evolucionarlo y por tanto no puedas ser muy creativo. Esto pasaba ya en cierto modo con las guías de estilo más férreas y seguirá pasando ahora. Pero también existirán otros proyectos en los que sí puedas hacerlo o en los que no se usen. Entonces, ¿estamos limitando la creatividad con este nuevo enfoque? Pues un poco sí, pero en teoría es por un bien mayor.

Respecto al futuro, hay quien apunta que estamos viendo sólo la punta del iceberg con esto de los Design System, y que la tendencia será que éstos trasciendan los límites de las empresas para convertirse en estándares compartidos y herramientas customizables que evitarán tener que crear sistemas desde cero. Pero si los desvinculamos de su implementación, si extraemos el contexto y no hablan de nuestra marca… ¿No acabaremos construyendo productos robóticos y sin alma, quedando la creatividad relegada a trabajos muy puntuales?

Nadie sabe con certeza lo que vendrá en el futuro, pero si no quieres verte envuelto en una discusión sin fin con tu cuñado, mejor invítale a una cerveza y cambia de tema.