Design System: cómo está potenciando nuestro workflow en Naranja
En esta nota quiero compartir la experiencia de desarrollar el Design System de Naranja. También, contar los beneficios que nos aporta, algunos tips y aprendizajes que tuvimos hasta el momento.
Pero antes de eso, empecemos con la definición de Design System.
Qué es y para qué sirve un Design System
No es solo una guía de estilos. Tampoco es algo que sirve para hacer interfaces bonitas. Es mucho más que eso.
Un Design System es un producto que contiene componentes reutilizables, documentados y publicados en un release, que pueden combinarse entre sí para construir interfaces.
Este producto sirve para desarrollar experiencias digitales más rápido, con más calidad y menor costo.
Se construye gracias al poder de Atomic Design
Un Design System se desarrolla a partir de los principios de Atomic Design.
Es una metodología que se compone de cinco partes que se pueden combinar para crear un sistema que permite diseñar interfaces de manera premeditada y jerárquica. Las partes son:
- Átomos.
- Moléculas.
- Organismos.
- Templates.
- Páginas.
Toma la naturaleza de nuestro planeta para definir sus principios. En el mundo, los átomos se combinan entre sí para formar moléculas y las moléculas se complementan para formar organismos más complejos.
Atomic Design funciona como Lego
¿Te acordás de los Lego? O como le decíamos en mi pueblo, los Rasti. Ese fantástico balde de bloques de construcción con los que podías armar casas, edificios y hasta autos. Bueno, un Design System funciona igual.
Siguiendo los principios de Atomic Design, los átomos son los bloques de construcción más simples. Llevado al diseño, algunos ejemplos son el control de un checkbox, un texto o una card.
Las moléculas son grupos de dos o más bloques o átomos que obtienen propiedades únicas y se tornan elementos más tangibles y operables, como pueden ser un textfield o un botón.
Y los organismos son moléculas ensambladas que funcionan juntas como una unidad. Un ejemplo puede ser el componente login.
Zumo, el Design System de Naranja
Ahora sí, después de haber definido qué es un Design System, hablemos de Zumo.
Por qué decidimos crearlo
Hace dos años, en Naranja decidimos digitalizar el pago de la tarjeta de crédito. Y como proyectábamos seguir apostando al mundo digital en todas las unidades de negocio, los componentes diseñados para ese flujo fueron pensados para que sean escalables y reutilizables en los productos futuros.
Entendimos que necesitábamos contar con un sistema de diseño que nos permita construir productos siguiendo una misma línea en cuanto a lenguaje, identidad y forma de uso de sus componentes. Así nació Zumo.
Tips antes de embarcarse en un Design System
No todos los productos o empresas lo necesitan. Te recomiendo invertir en uno cuando:
- El producto cuenta con muchas unidades de negocio y cuesta mantener consistencia entre los proyectos.
- El equipo es grande y está distribuido en diferentes lugares.
- Diseñadores y desarrolladores están diseñando e implementando lo mismo en diferentes proyectos una y otra vez.
Cómo comenzamos
Arrancamos con un diseñador a cargo de una librería de Sketch con todos los componentes. La librería estaba alojada en Google Drive y los demás diseñadores podíamos consumirla. Solo una persona a la vez podía editar ese archivo.
También teníamos una mínima documentación. Eso era todo, hasta ese momento solo agilizábamos el día a día de los diseñadores.
Cómo estamos hoy
Armamos un equipo interdisciplinario dedicado exclusivamente a desarrollar y dar soporte al Design System. Está conformado por diseñadores y desarrolladores front-end.
Nuestra librería Sketch ahora está alojada en Abstract, lo que nos permite editarla de forma colaborativa. También contamos con una librería front-end y documentación detallada. Comenzamos a afectar a todas las partes del desarrollo de nuestros productos, desde la ideación hasta producción.
Además, seteamos objetivos y diseñamos roadmaps para cada quarter del año.
Tips antes de comenzar a desarrollar un Design System
Es importante tener claro con qué objetivo se va a desarrollar, cuál será el alcance y el roadmap. Algunas preguntas disparadoras pueden ser:
- Cuáles y cuántas partes del producto se van a ver afectadas.
- A cuántos equipos se les va a dar soporte.
- Qué canales va a soportar. Web, Android, iOS.
- Con qué tecnologías se va a desarrollar.
- Qué componentes va a tener la primera versión.
- Cuándo se estima lanzar.
- Cuántas personas necesita el equipo y con qué perfiles.
Qué beneficios aporta Zumo a Naranja
Aporta beneficios tanto al equipo de diseño y desarrollo como así también al negocio. Los principales son:
Creatividad
En el equipo de Zumo invertimos en promedio 109 horas para desarrollar un componente. Esas horas que los demás equipos no consumen, las pueden invertir para mejorar la experiencia de sus productos, crear nuevas features y soluciones más disruptivas.
Velocidad
Los flujos de Naranja tienen, en promedio, 5 pantallas con 4 componentes cada una. A un desarrollador front-end le lleva aproximadamente 30 días hacer ese flujo. Eso incluye maquetas HTML, estilos CSS, funcionalidades y validaciones básicas en Javascript.
Con nuestro Design System podemos reducir 30 días de desarrollo a solo 1.
Actualizaciones instantáneas
Cuando lanzamos un nuevo release de nuestra librería Sketch, los diseñadores reciben una notificación con los nuevos cambios. Con un clic tienen todos sus componentes actualizados.
Los desarrolladores solo tienen que ejecutar el comando npm install zumo y en segundos tienen su proyecto actualizado con los nuevos cambios de la librería front-end.
Escalabilidad
Gracias a nuestro Design System, nuestro ecosistema de productos está mejor preparado para adaptarse y reaccionar a los diferentes contextos, seguir creciendo y hacerlo sin perder calidad.
Robustez
Ahora los demás equipos pueden estar enfocados exclusivamente en sus propios productos y así lograr experiencias y desarrollos de mayor calidad.
Predictibilidad
Con Zumo nos aseguramos de que cada componente se vea y se comporte igual en todos nuestros productos. Esto nos hace más predecibles y reduce la curva de aprendizaje de nuestros usuarios.
Experiencia omnicanal unificada
Tenemos múltiples productos diseñados para diferentes canales y devices. Nuestro objetivo es que los usuarios nunca dejen de sentir que están dentro del mismo mundo Naranja.
Aprendizajes hasta el momento
A lo largo de estos meses identificamos aprendizajes que nos sirvieron para mejorar el día a día y setear expectativas más claras para el proyecto.
Un Design System es mucho más que una librería de Sketch
Una librería de Sketch le resuelve el problema al equipo de diseño. Un Design System debe afectar a todas las etapas de desarrollo de un producto, optimizando cada una de ellas, aumentando la eficiencia y la productividad.
Es un producto en sí mismo
Para que entregue valor real, se lo tiene que tratar como a un producto. Debe formarse un equipo de trabajo enfocado en el proyecto, tener objetivos medibles que impacten al flujo de trabajo de los otros equipos y al negocio.
No soluciona todos los problemas
Repetilo en voz alta, no soluciona todos los problemas. Brinda soluciones de diseño comunes a todos los proyectos. Resuelve los componentes y patrones convencionales. Pero no hace magia. Siempre habrá ocasiones en que los equipos necesiten resolver algo puntual que el Design System no cubre.
Es un proyecto a largo plazo
Hay que entender que cada equipo tiene sus propios objetivos de negocio y la adopción del Design System no tiene que afectar eso, sino ser parte de esos objetivos. Es necesario sentarse con esos equipos a programar un roadmap de adopción y acompañarlos en ese proceso.
Esto es todo por hoy
Espero que mi experiencia te ayude y me cuentes si pudiste aplicarla en tus proyectos. Si te gustó la nota te invito a que me dejes unos 👏. Podés encontrarme en LinkedIn y también seguir al equipo de Naranja UX.
En la próxima nota voy a compartir:
- Cómo se compone Zumo.
- Cómo es el workflow de nuestro equipo.
- Con qué tools lo construimos.
Te dejo notas y libros donde podés encontrar más información:
- Design Systems Handbook, by InVision.
- Modular Web Design, by Nathan Curtis.
- Atomic Design, by Brad Frost.
