Priorización en equipo de componentes de un Design System
Hace unos meses llevamos adelante con el team de diseño de Naranja UX una dinámica de priorización de componentes para nuestro Design System.
Zumo, el Design System de Naranja lleva más de un año de desarrollo, período en el cual diseñamos y construimos alrededor de 20 componentes, además de haber sentado las bases del sistema. Ahora, nos encontramos en el punto en el que todos los equipos piden nuevas adiciones (modificaciones de elementos existentes, ampliación de opciones o funcionalidades, nuevos componentes) y como somos un equipo chico, tenemos que encontrar la forma de poder ordenar y priorizar las incorporaciones.
Para hacer de esto una tarea colaborativa, y sabiendo lo complicado que es coordinar las agendas de personas que trabajan con equipos diferentes, propuse una dinámica que nos permitió trabajar independientemente con cada equipo, pero obteniendo datos procesables y comparables.
1 . En primer lugar, realizamos un relevamiento de módulos y componentes potenciales, tanto en los flows existentes (que en algunos casos hacen uso de componentes fuera del sistema pero necesarios), otros design systems que tomamos de referencia y sitios/apps en estado productivo del mundo real (no necesariamente de nuestro mismo vertical).
Herramientas: Abstract (usado como repositorio compartido, nos ayuda a llevar un registro actualizado de todos nuestros flows), Adele by UXPin (un completo repositorio de design systems, muy útil para buscar referencias de mercado), Sketch (Software de diseño UI que usamos para recopilar las capturas que obteníamos), Notion.so (toma de notas, generación de tablas filtrables y ordenables)
2 . A las capturas y notas de todos los elementos que nos parecían interesantes, las fuimos refinando (sacando patrones y componentes repetidos) y condensando (agrupando aquellos elementos que visualmente eran algo distintos, pero cumplían la misma función). Después de ese trabajo (que en muchos momentos requirió consultas con otros diseñadores y desarrolladores), llegamos a un listado de 40 componentes “potenciales”. Herramientas: Sketch, Notion.so
3. Por cada uno de los 40 potenciales, hicimos una tarjeta de identidad que contenía el nombre del componente (no es una cuestión trivial), una pequeña descripción (mínima, del largo de un tweet) y una imagen ilustrativa (no una propuesta de diseño concreta, sino una referencia tomada de los screenshots de la investigación original, con el fin de evitar confusiones). Herramientas: Sketch (Sketch nos permitió trabajar directamente con los datos obtenidos en las tablas de Notion y generar todas las tarjetas automáticamente)
4 . Convocamos reuniones con los diferentes squads de diseño, teniendo en cuenta sus agendas, y después de una introducción general sobre el objetivo del taller, les pedimos que ordenaran los diferentes componentes en 4 columnas de acuerdo a su prioridad: Muy alta, Alta, Media y Baja. En estas reuniones, intenté usar el teléfono sólo para tomar fotos de registro y no llevar la compu. Las notas las tomaba en papel, lo que me permitía estar atento a lo que pasaba en el momento y no distraerme con redes/chat/etc. Por otra parte, nos mantuvimos lo más alejados posible de su proceso de decisión y ordenamiento, sólo respondiendo preguntas que tenían que ver con el significado de los componentes que proponíamos.
5 . Una vez que completaban ese proceso, les otorgábamos 2 “balas de plata” por persona. Una marca para que apliquen en aquellos componentes que, entre los de mayor prioridad, consideraban imprescindibles para el flow en el que estaban trabajando en ese momento. Además, mientras charlábamos en el cierre de la reunión, les dábamos post-its en blanco para que completen con los componentes que creían necesarios y que no habíamos contemplado.
6 . Con todos los equipos de diseño entrevistados, repetí la dinámica con el equipo de desarrollo encargado de Zumo, pero en lugar de pedirles priorización en uso de los componentes, les pedí que los ordenen de acuerdo a su dificultad de desarrollo: S, M, L, XL (dejando en claro que es una estimación a grosso modo, ya que no estaban definidas la estética ni las funcionalidades de cada uno de los componentes).
7 . Con todos los interesados habiendo opinado, volví al listado original de componentes potenciales en Notion.so y cargué los datos de cada equipo en una tabla, asignando valores numéricos de acuerdo a la prioridad (Baja = 1; Media = 2; Alta = 3; Muy alta = 4; Imprescindible = +1). Finalmente, ordené la tabla según ese criterio, y ¡obtuvimos nuestra lista de componentes ordenados de acuerdo a la prioridad del equipo!
8 . A partir de ese listado, armamos una matriz de impacto/esfuerzo para incluir en la ecuación la visión del equipo de desarrollo, y poder llevar a cabo una estructuración de nuestros próximos pasos.
Algunos aprendizajes que surgieron de esta dinámica
Los nombre de algunos componentes no se entendían. Por querer usar denominaciones que usan otros design systems, o por intentar ser lo más semánticamente correcto posible, hubo títulos que la mayoría no entendió.
Siempre tener a mano una respuesta, a veces la traducción del nombre es suficiente para aclararlo o, también funciona muy bien la referencia a ejemplos reales de otras aplicaciones (“es como lo que usa Spotify en su lista de Recently Played”). A tener muy en cuenta al momento de nombrar esos componentes en el mundo real; si un componente no puede ser encontrado, no puede ser usado.
Los diseñadores no leen (tampoco). Así como los diseñadores nos quejamos de que “la gente no lee”, acá pasó lo mismo pero con diseñadores. En muchos casos, miraban la imagen ilustrativa, suponían un componente y su uso, y avanzaban. Estar siempre atento y ante la duda, preguntar: ¿Estás seguro que en tu flow no vas a necesitar eso? ¿En que caso te parece útil? ¿Te fijaste lo que dice la descripción?
No incluir componentes que de antemano sabemos que no vamos a usar. En mi afán de no dejarme llevar sólo por mi criterio personal y de relevar todos los posibles componentes, traté de no dejar nada afuera e incluí cosas que claramente nadie iba a necesitar. Esto generó que hubiera un par de componentes que cada diseñador con quien hablé preguntó ¿qué es esto? ¿para qué lo usaríamos? ¿en serio vamos a invertir tiempo en hacer esto?, disparando conversaciones que no tenían utilidad porque giraban alrededor de elementos intrascendentes.
No salirse del foco de la dinámica. Recordar siempre que el objetivo es ordenar un listado cerrado. Al ver todos los componentes juntos, es normal que se generen charlas sobre cuándo vamos a incluir esto o por qué no rediseñamos aquello, que hacen perder el norte de lo que queremos lograr. Dejar siempre lugar a las charlas, que suelen dar mucha información útil, pero estar atentos a retomar el camino cuando estas digresiones se hacen muy extensas o intrascendentes.
La actividad manual ayuda a la concentración. A todos les pareció entretenida y didáctica la dinámica, y creo que tiene que ver con que incluía cartas, post-its y marcadores. La misma actividad podía reproducirse perfectamente con medios digitales, con un tablero de Mural, o con un documento compartido de Notion o Google Spreadsheets. Son reemplazos perfectamente válidos para equipos distribuidos, pero el hecho de ir a una sala de reuniones, desplegar un tablero sobre la mesa y mostrar un mazo de cartas, hacía que los participantes se involucren de una manera distinta con la actividad. Una vez que empezaban, tenían que leer las cartas en voz alta, compartir con sus compañeros y debatir la ubicación de cada elemento, generando discusiones de gran valor que, estoy convencido, no se hubieran generado de haber ido por la alternativa digital.
Fue la primera vez que hicimos esta actividad, y la verdad es que nos fue muy útil para confirmar algunas de nuestras suposiciones y para descubrir algunas cosas que se nos estaban pasando por alto.
Si llegás a usar esta técnica, me contás y entre todos vamos mejorando las herramientas con las que contamos para construir Design Systems. Y si querés seguir leyendo contenido de diseño, podés encontrarme en LinkedIn y seguir al equipo de Naranja UX en Medium.
