No todo cabe en un Design System: ni sabiéndolo acomodar, ¡créanme!
La trampa de querer sobre sistematizar.
Ed. 70
Esta semana acabo de terminar la tercera edición de mi curso de Sistemas de Diseño: Estrategia y fundamentos prácticos en Edison. Dicho sea de paso, el cohorte fue muy chévere, y me la pasé bomba con la clase de dudas que tienen, otorgando frescura y dinamismo a cada sesión. Algunas de las dudas recurrentes inspiraron este post.
La obsesión con sistematizar
Muchos de los diseñadores que estamos enfocados en Sistemas de Diseño, tenemos claro cómo la eficiencia y consistencia son métricas claves para valorar el éxito de esta iniciativa.
Sistematizar, de forma inconsciente, nos da una cierta paz que hace contrapeso a la incertidumbre y al cambio constante que el crear servicios y productos digitales tiene. Decisiones de diseño que se toman una vez, bien pensadas, y se reutilizan de ahora en adelante.
Es tentador sistematizar hasta en lo más mínimo en nuestro sistema de diseño, la ilusión es que si todo se sistematiza es controlable, es manejable y es predecible.
Pero la realidad tiene la costumbre de ser compleja. Si bien un sistema de diseño puede contar con foundations, que permiten hacer componentes atómicos, luego construir composites, moléculas, organismos y templates. Habrá elementos con los que construimos interfaz que no necesariamente formarán parte de nuestro sistema y, tenderán a ser más personalizados y por lo mismo menos genérico y reutilizables.
Fotografías e Ilustraciones
Las colecciones de ilustraciones y fotografías son muestra de ello, aunque de manera genérica podemos crear backgrounds o momentos memorables con detalles personalizados en componentes, e incluso incluir lógica para hacerlos dinámicos dependiendo de por ejemplo, el clima, la estación de año o la temporalidad de la marca; lo que es un hecho, es que muchos otros casos las ilustraciones y fotografías tienen a servir a propósitos más específicos y únicos, donde una ilustración genérica quedaría corta.
Lo mismo pasa con las fotografías, donde incluso la reutilización de las mismas puede jugarnos en contra, restando dinamismo, frescura y espontaneidad en momentos memorables.
Una alternativa es definir principios que nos permitan la construcción consistente, pero no siempre sistémica, otorgando libertad creativa para centrarnos en momentos específicos, que no siempre serán reutilizados, pero que nos permiten extender la consistencia que ya tenemos en nuestro sistema de diseño.
Entendiendo la velocidad: experimentar en productos y no en tu Sistema de Diseño.
Cuando trabajamos en productos digitales, el cambio es constante y la iteratividad es lo que nos permite validar rápidamente para encontrar modelos de negocios.
En el mismo afán de sistematizar podemos caer en el error de intentar incluir experimentos en nuestro sistema de diseño, esto puede ocasionar que el Sistema de Diseño sea un cuello de botella, porque los cambios requeridos siempre superaran la capacidad del equipo de diseño.
En este caso, como lo menciona Josh Clark en su artículo Ship Faster by Building Design Systems Slower, que los sistemas de diseño se muevan más lentos puede ser una ventaja, ya que puede aprender de los cambios y las evoluciones que producto tiene y cuando estas sean estables, puede ser tomadas, avaluadas y sistematizadas por el sistema de diseño. }}
“Esto también aplica a componentes o patrones que el equipo del sistema de diseño planea incluir en la biblioteca en el futuro, pero que no puede comprometerse a desarrollar de inmediato sin comprometer los estándares de calidad del sistema ni considerar todos los contextos más allá de la necesidad inmediata del producto”
Cuando un equipo de producto necesita una solución que el sistema de diseño aún no ofrece, existen esta opción:
El equipo de producto crea su propia solución, usando elementos como átomos, del sistema de diseño para crearla.
El equipo de sistemas de diseño lo agrega a su backlog garantizando su revisión y su inclusión en la librería
El equipo de producto mantiene su responsabilidad en el componente hasta que el equipo de sistemas de diseño lo incluya en la librería.
Por esta razón, los experimentos para validar hipótesis no se sistematizan. Los sistemas de diseño avanzan a un ritmo más lento porque sirven como fuente de verdad para soluciones a largo plazo.
Hasta ahora, estos son algunos ejemplos de elementos que impactan nuestro diseño pero permanecen fuera del sistema. Algunos fundamentos pueden guiar la dirección visual, pero eso no significa que estos elementos deban incluirse en el sistema de diseño.
Cuando se trata de experimentos e iteraciones en productos digitales, los equipos de diseño de sistemas deben comprender su capacidad y reconocer que su objetivo principal es construir y lanzar productos digitales que resuelvan las necesidades de los usuarios. El proceso iterativo avanza más rápido porque su meta es alcanzar el ajuste al mercado (market fit). El sistema de diseño puede aprovechar esa evolución para sistematizar solo las soluciones comprobadas.
Además, animo a los diseñadores de sistemas de diseño a comprender sus organizaciones, evaluar sus necesidades y encontrar el equilibrio adecuado en su proceso. Las decisiones deben basarse más en las necesidades específicas y el contexto que en recomendaciones de artículos. Estas pueden servir como guía, pero nunca deben tomarse como reglas estrictas.
En tu opinión, ¿qué otros elementos crees que pueden quedar fuera de un sistema de diseño pero aún se usan comúnmente para construir interfaces?
Nos vemos en la siguiente edición…
Para leer 📖
Simplify your product design — borrow familiar patterns
Ami Vora explora cómo la simplicidad en el diseño de productos no solo es deseable, sino una ventaja competitiva. Un producto se considera "simple" cuando es familiar e intuitivo, permitiendo a los usuarios interactuar con él sin esfuerzo.