Escalando el Himalaya

Himalaya es el Design System de Ripio que sirve como única fuente de verdad para diseñar experiencias. En esta primera parte, compartimos los primeros pasos que dimos hacia el Himalaya.

Observando la Roca

Un Design System es un producto que comienza con una serie de necesidades reales de los usuarios. ¿Quiénes son los usuarios en un Design System? Los usuarios somos las mismas personas que integramos el equipo: diseñadores y desarrolladores. Y para ambos, ¿qué necesidades teníamos?

Las necesidades diarias de los diseñadores que observábamos eran las siguientes:

1. El equipo, a medida que los diferentes productos crecían, comenzaba a tener cierta dificultad en mantener la consistencia visual de la experiencia. A la par que los diferentes diseñadores se incorporaron a grupos de trabajo (squads), el diseñador iba, de a poco, perdiendo el sentido general de la experiencia, para enfocarse particularmete en el journey que ese squad atacaba. Contar un Design System iba a ayudar a tener una mirada global de la experiencia, permitiendo velar por la consistencia visual, y por ende, la calidad.
2. Las necesidades del equipo requerían que los diseñadores UX se enfocasen en otros aspectos de su flujo de trabajo: research, diseño de flujos, y casos de uso. Un Design System facilitaba que el equipo concentre sus esfuerzos en otras etapas del proceso de UX, sabiendo que la resolución de la interfaz estaría en manos de un equipo de especialistas.
3. El ingreso de nuevos colaboradores se hacía más cuesta arriba. El nuevo diseñador UX se encontraba con inconsistencias y guías visuales poco definidas. Un Design System facilitaba y agilizaba el onboarding del nuevo colaborador a los lineamientos visuales del ecosistema.

Podemos resumir las necesidades de los diseñadores UX en tres palabras: consistencia, foco y onboarding.

Para los desarrolladores, las necesidades eran otras:

1. El crecimiento del equipo, de la plataforma y de los productos implicó un gran esfuerzo por parte del equipo en desarrollar nuevas funcionalidades. En ese trabajo, muchos colaboradores se vieron implicados. Comenzaba así, naturalmente, la pérdida de consistencia en el desarrollo de la plataforma a nivel del código. Se creaban ad-hoc los mismos componentes (por ejemplo, el mismo botón, creado múltiples veces, y con múltiples estilos). Esta multiplicidad y repeteción generaba pérdida de agilidad, calidad y consistencia a la hora del armado de las interfaces por parte de los desarrolladores. En una industria como la del mundo cripto, ser ágiles a la hora de desarrollar nuevas funcionalidades es un objetivo importante. Un Design System iba a agilizar y facilitar el armado de nuevas funcionalidades.
2. Como consecuencia de lo anterior, la mantenibilidad de la plataforma era dificultosa. Un Design System iba a hacer más fácil la mantenibilidad, la corrección de bugs, y el reemplazo de código viejo por nuevo; resumiendo, permitía una mejor iterabilidad del producto.

Podemos resumir las necesidades de los desarrolladores en dos palabras: agilidad y mantenibilidad.

Estas necesidades nos indicaban un norte claro. La brújula nos orientaba hacia el Himalaya. Y hacia allá caminamos.

Al pie del Himalaya

Llegados al pie del Himalaya, nos encontramos con algo imponente. Nos preguntamos qué era semejante fenómeno.

El Himalaya es la cordillera más alta y grande del mundo. Como toda cordillera, es una sucesión de montañas enlazadas entre sí. En el Himalaya se encuentran las 14 montañas más altas del planeta, y atraviesa muchos países del lejano oriente. Además, observando su composición, descubrimos un patrón llamativo: el Himalaya se compone del pie, de la ladera, y de la cima.

Estas observaciones nos dieron ideas interesantes:

1. De la misma manera que el Himalaya se compone de una serie de montañas que, en su conjunto, forman algo más grande, así también nuestro Design System tenía que estar compuesto por partes pequeñas que conformen un todo más grande.
2. El llamativo patrón mencionado nos llevó a pensar el Design System en una estructura de tres niveles: el pie de la montaña serán los fundamentos, la ladera serán los componentes, y la cima, los organismos.
3. La multitud de países que atraviesa el Himalaya iba a ser la inspiración para pensar el Design System en grande. Tal como el Himalaya atraviesa diversos países y convive en el ambiente en cada uno de ellos, así el Design System iba a escalar, y servir como única fuente de verdad a los diferentes productos del ecosistema Ripio, pero siendo lo suficientemente flexible para no suprimir las particularidades de cada producto. De esta manera, seguimos distinguiendo a cada producto, pero que, en su conjunto, forman un ecosistema.

Himalaya se compone de tres niveles (fundamentos, componentes, y organismos), y atraviesa el ecosistema de productos de Ripio

La excursión

Esta aventura no iba a ser fácil. Requería, a la par de ver aquellas necesidades que antes mencionábamos, entender el impacto real que este producto iba a tener en el negocio. En una organización habituada a ofrecer sus productos a clientes externos, construir un producto interno, que iba a ser consumido por el equipo, parecía una pérdida de tiempo.

Pero entre los objetivos (OKRs) para el año 2022 dentro de la empresa, comunicados a comienzo de ese año, estaba lograr una mayor eficiencia en los procesos internos de trabajo en toda la organización.

Siguiendo ese objetivo, comenzábamos a organizar el área de DesignOps con un rol clave: velar por las personas del equipo, las buenas prácticas, la cultura de diseño, y los procesos, para así facilitar a los diseñadores su trabajo y de esta manera impactar, desde UX, en toda la organización. El Design System fue la primera iniciativa de DesignOps, permitiendonos avanzar dándole un soporte teórico y operativo dentro de la organización, y así también estar alineados a los objetivos del año.

De esta manera, pudimos ponernos en marcha hacia el Himalaya.

Los alpinistas

Antes mencionábamos que nos dirigíamos hacia el Himalaya. ¿Pero a quiénes nos referíamos? ¡A los alpinistas! Los que se animaron a armarse con los arneses, las sogas, la mochila y los pie de gato. Como líder de este producto, conformé este equipo teniendo en cuenta las fortalezas de los colaboradores, buscando y seleccionando roles especializados, y no generalistas. Diseñadores UI, diseñadores de contenidos, desarrolladores mobile y web, son los alpinistas que aceptaron el desafío de escalar el Himalaya. También vimos la necesidad de completar el equipo con el rol de consultor UI, cuyo objetivo es hacer de nexo entre el equipo del Design System y el resto de los diseñadores UX del equipo.

Los alpinistas del Himalaya: diseñadores UI, contendista, product manager y desarrolladores mobile & web

Antes de poner el pie

Llegados al pie del Himalaya, pero antes de dar el primer paso hacia su ascenso, necesitábamos entender de qué manera había que escalar esta enorme cordillera. Intentar subirla sin más, iba a hacer sinónimo de una rápida caída. Así es que establecimos una metodología ordenada y simple, para poder dar pequeños saltos y no caer en el intento. Compartimos brevemente la metodología adoptada:

1. Relevamiento
   Relevamos los componentes que hay en producción, identificamos sus casos de uso, y ponemos de relieve diversos problemas. A este relevamiento interno, sumamos el relevamiento externo, es decir, investigamos acerca de otros Design System.
2. Propuesta
   Luego de iteraciones con el equipo, proponemos las características visuales del componente, sus comportamientos y los diferentes estados. En esta iteración participan no sólo los alpinistas del Himalaya — incluidos los desarrolladores—, sino también el resto del equipo de UX, que son los que usarán estas definiciones en sus diseños. Cuanta mayor participación de todo el equipo se de en esta instancia, surgirán menores dudas y menos retrabajos al momento de hacer el hand-off con los diseñadores.
3. Documentación
   Proveemos, tanto a los diseñadores como a los desarrolladores, de información clara y completa que ayuda a entender y aplicar el componente de forma consistente.
4. Desarrollo
   Desarrollamos el componente, garantizando su óptima construcción, siguiendo la propuesta y la documentación.
5. Implementación
   Una vez desarrollado el componente, comenzamos a implementarlo en la plataforma, donde vemos su impacto real en el producto y en los usuarios.
6. Adopción
   Comunicamos las novedades del Design System, y medimos el nivel de adopción en los equipos de diseño y desarrollo.

Tabla donde llevamos registro del estado del componente

La identidad de Himalaya

Contemplando el Himalaya, veíamos que tenía ciertas características: las formas de las montañas eran diversas, las alturas sobresalían, los colores radiantes, los relieves particulares, y los reflejos luminosos. Es decir, el Himalaya tenía una identidad muy diferenciada con respecto a otras cordilleras. Antes mencionábamos que el Design System es un producto, y no un proyecto. Por eso, como todo producto, tenía que tener su identidad.

El Design System es un producto, no un proyecto (Fuente: https://eightshapes.com/articles/a-design-system-isn-t-a-project-it-s-a-product-serving-products/)

Trabajamos con el equipo de Branding para definir una identidad de nuestro Design System, tomando, por todo lo que venimos diciendo, el Himalaya como modelo e inspiración. Es importante invertir tiempo en generar una identidad sólida, tanto visual como discursiva, de un Design System, ya que lo revestirá de solidez y favorecerá la adopción hacia otras áreas de la organización.

Parte del proceso de diseño de la identidad de Himalaya

Sistema de portadas que presentan la documentación (componentes Tag y Chip)

El mapa

Dibujamos un mapa que fue nuestro guía para escalar, paso a paso, el Himalaya. Es por eso que pensamos un itinerario mensual para organizar esta subida. Esto nos permitió avanzar de manera realista, y dar visibilidad al resto del equipo en lo que se estaba trabajando dentro del Design System. Esto es importante para que todo el equipo conozca lo que se está trabajando ahora, qué próximamente, y qué en un futuro cercano; y así poder cubrir las necesidades de los diferentes squads.

Roadmap de Himalaya

Los kilómetros escalados

Aunque nos falte mucho para llegar a la cima del Himalaya, podemos comenzar a ver, tomándonos un momento de descanso en esta ardua escalada, los kilómetros recorridos.

Estos son algunos de los impactos que estamos viendo:

1. Mejora en la calidad y consistencia de la UI.
2. Contribución a una cultura de la documentación en el equipo.
3. Contribución a una mayor definición de los procesos de UX.
4. Contribución a una cultura más colaborativa de trabajo en el equipo.
5. Contribución a la especialización de roles dentro del equipo.
6. Mayor agilidad en el desarrollo de la interfaz.
7. Mayor limpieza del código.
8. Interés por parte del equipo de desarrollo en una mejora de la calidad final de la interface.

Impacto de Himalaya en la mejora de calidad y consistencia en los flujos de la app

Lo que falta por escalar

Como decíamos, en esta escalada, nos falta mucho por subir. Pero por suerte, los alpinistas del Himalaya siguen con las mismas fuerzas para continuar esta subida y superar los siguientes obstáculos:

1. Seguir mostrando el valor que tiene un Design System en una organización de producto y así impulsar una mayor adopción.
2. Mejorar las dinámicas con desarrollo para una mayor agilidad en la implementación de Himalaya.
3. Explorar el involucramiento de un QA visual al equipo de Himalaya.

En el siguiente artículo, contaremos algunos aspectos más detallados de nuestro día a día, las ceremonias que tenemos, y los procesos que llevamos a cabo para definir una propuesta y documentarla.

· · ·

Mi nombre es Juan Pablo, y soy parte del equipo de UX @Ripio. Podés ver más de lo que hacemos en Instagram. Si te entusiasmó lo que leíste, y querés sumarte al equipo, escribime por Linkedin.

Si consideraste este artículo valioso, ¡deja un aplauso! 👏 👏 👏