A continuación os compartimos las dudas que le planteamos y las explicaciones que nos devolvió:
Después de todo este tiempo con Design Systems, ¿qué es un sistema de diseño para ti?
No hay una respuesta única, todo depende de la organización, proyecto y equipo. Las definiciones pueden ir desde algunas muy genéricas como:
An interconnected set of elements that is coherently organized in a way that achieves something.” — Donella Meadows, Thinking in Systems.
a otras más específicas como:
A design system is a set of rules, documentation, processes, and encoded decisions that guide the creation of one or more applications.” — Mae Capozzi, What is a design system.
En mi opinión, diría que un sistema de diseño debe estar compuesto por, al menos:
- Un conjunto de especificaciones de diseño sobre piezas reutilizables. Por ejemplo, un fichero de Figma que contenga la especificación sobre colores, tipografía, espaciado, etc. Todo esto puede codificarse como tokens. Luego, estos tokens se combinarán para crear especificaciones de componentes, también en Figma, por ejemplo.
- Documentación sobre cómo usar estas piezas reutilizables para construir interfaces: tokens, componentes, patrones, etc.
- Un proceso en el cual estas especificaciones son implementadas, es decir, trasladar a código las decisiones que se han tomado en el punto 1 y que se se han documentado en el punto 2.
Cada sistema de diseño puede tener unos requerimientos diferentes.
¿Cuándo podemos empezar a llamar Sistema de diseño a un Sistema de diseño?
No soy muy de dogmas, pero creo que en cuanto haya unas guías claras sobre cómo construir interfaces de usuario y un conjunto de assets (tokens, componentes, documentación, etc.) que los desarrolladores puedan usar para construir interfaces de usuario. Este último punto lo considero muy importante: si no existe el mecanismo para que las decisiones de diseño acaben implementadas, el sistema de diseño no cumple su función.
¿Qué tipo de productos necesitan un sistema de diseño?
Cualquier producto se puede beneficiar de uno para mejorar el flujo diseño <> desarrollo, incrementar la calidad, aumentar la consistencia, ahorrar costes, etc. Esto puede ser un producto (como podría ser el caso de Vercel), un e-commerce (Amazon), una web de contenido puramente estático (Smashing Magazine), un blog (joshwcomeau.com), etc. Incluso una landing podría hacer uso de un sistema de diseño “marca blanca” (como Reshaped.so) para crear algo más rápido y consistente añadiendo una capa de personalización. Todo depende del proyecto.
¿Cuándo sabes que tu producto necesita un sistema de diseño?
Cuando empiezas a ver que muchas piezas de la interfaz empiezan a repetirse, los esfuerzos se duplican, la calidad baja, etc. También cuando quieres escalar la construcción de interfaces de usuario.
Se suelen relacionar con productos longevos pero lo bueno de los sistemas de diseño es que pueden funcionar a todos los niveles. Por ejemplo, una agencia puede crearse o usar un sistema de diseño de bajo nivel ("marca blanca", como Reshaped.so) que no imponga opiniones a alto nivel (por ejemplo, no definirá patrones grandes como un hero pero sí un acordeón), de manera que este sistema de diseño se podría reutilizar y mejorar en cada proyecto.
Imagina que no sabes nada de sistemas de diseño, ¿qué consejos te darías a ti mismo con lo que sabes hoy?
No intentes aplicar procesos o técnicas de los grandes sistemas de diseño sin tener sus mismos problemas. Cada equipo/organización es diferente y querer ir rápido y ser como los “pros” es una fuente de frustración y problemas. Céntrate en resolver los problemas que tiene tu organización/producto/web, aprendiendo de los pros pero sin intentar imitarlos en lo que no es imitable.
¿Cuáles son los retos más comunes a los que te enfrentas cuando ofreces tus servicios?
En mi caso se trata de un equipo dedicado manteniendo un sistema de diseño para todos los equipos de New Relic. En este sentido, nuestros retos son:
- Convencer a los equipos de por qué deberían usar lo que proveemos.
- Encontrar el nivel adecuado de flexibilidad vs consistencia en los componentes y los patrones que creamos.
- Saber convivir con una inmensa cantidad de deuda técnica.
- Aportar valor en medio de grandes cambios internos a nivel de código y diseño.
¿Qué errores has cometido y qué has aprendido sobre ello (en DS)?
- Querer correr antes de andar. Esto tiene mucho que ver con lo de los “pros” de una respuesta anterior.
- Intentar ser muy dogmático centrándome en la calidad técnica en vez de solucionar los problemas que tengo hoy. Hay que conseguir ser muy iterativo y aportar valor desde el principio, aunque crees deuda técnica, o quizás no haya sistema de diseño el día de mañana por falta de ROI.
- Tratar de crear componentes complejos desde cero si el equipo no está preparado. Recomiendo comenzar con librerías que sean headless para los equipos que están empezando a crear un sistema de diseño y no tienen el conocimiento o experiencia para crear componentes accesibles de gran calidad.
¿Podrías explicar el proceso completo (y fases si las hay) a la hora de crear un sistema de diseño (o producto)?
Cada caso es diferente. Lo primero es auditar el producto/equipo/web y ver qué se busca del sistema de diseño. En nuestro caso no es tanto la creación (¡no creamos un sistema de diseño cada mes!) sino mantener el sistema de diseño en una empresa de la escala de New Relic.
¿Cuáles son los retos de diseño (UX y UI)?
- Incluir a desarrollo en el proceso de definición y creación de componentes.
- Ser consciente de las limitaciones del medio en el que se crearán/consumirán los componentes. La web es salvaje y muy compleja.
- Pensar de manera genérica y no en un caso de uso concreto.
- Tener en cuenta la accesibilidad.
¿Cuáles son los retos de los maquetadores?
- Similares a los problemas de los UX/UI.
- A la hora de crear componentes de un sistema de diseño, no veo separación entre un maquetador y un desarrollador. En mi opinión las mismas personas deberían hacer ambas cosas. No es lo mismo que trabajar en un producto, cuando puedes separar mucho más fácil la capa de lógica de negocio de la UI pura.
¿Cuáles son los retos de los desarrolladores?
- Pensar de manera genérica y no en un caso de uso concreto, teniendo el sistema en tu mente en cada decisión que tomas. La mayoría de desarrolladores lo pasan muy mal para llegar a pensar así. Muchos no lo consiguen, en mi experiencia. El trabajo en producto vs sistema de diseño es muy diferente y la adaptación puede ser dura.
- Otro reto es avanzar lentamente para hacerlo bien. La gente que viene de agencia/producto lo pasa mal porque quieren construir y lanzar cosas muy rápido, como es lógico. Se siente bien al ir rápido. Todo depende de la escala de la organización, pero por lo general el trabajo en sistemas de diseño es mucho más lento. Los desarrolladores, y todo el mundo en un sistema de diseño, tiene que encontrar la satisfacción haciendo las cosas bien, que escalen y perduren en el tiempo, en vez de centrarse en lanzar cosas. Me gusta muchísimo esta frase de Sid Kshetrapal, que trabaja en el sistema de diseño de GitHub: “Our team has to be intentionally slow” (fuente).
¿Qué tipo de software utilizas para la documentación entre equipos?
- Figma para las especificaciones de diseño y exploraciones.
- Custom site en Gatsby para la documentación de todo el sistema de diseño: fundaciones (tokens), componentes, patrones, etc. con live examples, docs sobre las props, cómo usar los componentes, etc.
¿Quién tiene que liderar un sistema de diseño?
Alguien que entienda muy bien el problema que se intenta resolver y que le guste muchísimo. La pasión es clave. Aunque suene a tópico, sin esa pasión es imposible que una persona pueda liderar un proyecto tan complejo como un sistema de diseño, especialmente a escala. Da igual que sea ingeniero, diseñador o manager. Es muy importante establecer la filosofía del sistema de diseño, que es única en cada empresa/producto, y no cambiar el rumbo aunque todo el mundo a tu alrededor pierda la fe.
¿Hay algún manual de buenas prácticas?
Hay muchos recursos para iniciarse. Todos malos o buenos, según como los mires. Algunas recomendaciones pueden ser:
- designsystemchecklist.com: es imposible cumplir todo, pero como guía no está mal.
- designsystemsrepo.com: hay webs de este tipo si buscas algo en particular.
- Libros: Design Systems de Alla Kholmatova, Laying the Foundations de Andrew Couldwell y Building Design Systems de Sarrah Vesselov & Taurie Davis.
¿Qué referencias públicas de buenos design systems podrías facilitarnos?
Con código open source:
Sólo documentación pública:
Muchos más aquí.
¿Qué es verdad y qué es mentira sobre los sistemas de diseño?
- No te creas nada de lo que dicen pero aprende de todo lo que dicen. Traslada todo a tu contexto y traduce las soluciones a las que han llegado otros a tu organización/proyecto solo si tienes el mismo problema.
- Hay mucho humo pero si sabes seleccionar puedes encontrar gente increíble de la que aprender.