ICBC YOY
UX Design Ops
Cliente
ICBC
Rol
UX Design Ops
Stakeholders
Producto, Créditos, Comercial, Marketing, Operaciones.
Tiempo
6 meses
CONTEXTO
YOY es la primera aplicación en Argentina diseñada para la generación Z, ofreciendo una variedad de contenidos interesantes y soluciones financieras sin comisiones. Dirigida a jóvenes mayores de 18 años, YOY proporciona una cuenta de ahorros y una tarjeta de débito virtual, junto con experiencias exclusivas en entretenimiento, viajes, gastronomía, moda, tecnología y gaming. La app permite comprar productos y servicios, pagar cuentas, obtener descuentos personalizados y realizar transferencias, todo ello con la opción de pagar con MODO. Además, ofrece beneficios exclusivos y contenido relevante para sus usuarios.
Video extraido del canal oficial de YOY en Youtube.
INVESTIGANDO Y DETECTANDO PAIN POINTS EN EL EQUIPO DE UX DESIGNERS
Analizando la distribucion
El equipo de UX-UI Designers y UX Writters se encontraba dividido en varias células multidisciplinarias. En cada célula, se trataba respectivamente a las diferentes funcionalidades de la aplicación:
Onboarding
Login
Lifestyle
Transferencias y pagos
Legales
Para una aplicación financiera, puede suponerse que solamente con un liderazgo a todos los diseñadores de experiencia, gestionando sus inquietudes y dandoles soporte era suficiente.
En contra partida, la situación era mayormente compleja. Añadiendo a lo antes mencionado, la app fue evolucionando a lo largo del tiempo en contenidos como en tecnología, a través del feedback de los usuarios, por lo cual, se requerían posibles nuevos features e interacciones por parte del usuario.
Paint points detectados
A lo largo de toda esa investigación, detectamos los siguientes puntos de dolor:
- Diseñadores y Writters que no tenian espacios para normalizar tanto diseño como experiencia de los usuarios en la app y por tanto, cada célula trabajaba a criterio propio, lo que vulneraba la consistencia y normalización del diseño y contenido end to end.
- Diseñadores y Writters que no tenian una documentación visual y técnica consolidada, validada y actualizada en un mismo lugar, por ende, en distintas oportunidades, se encontraban con inconvenientes para seleccionar diferentes componentes.
- En concordancia con el punto anterior, existía una muy sintetizada documentación de diseño del design system de Zeta, el sistema de diseño de la aplicación, complicando no solo la interpretación de uso, no uso, objetivos, entre otros, de los componentes, si no que además, imposibilitando a nuevos colaboradores entender la importancia y relevancia para el producto, del design system.
- Sistema de diseño con muchisimos componentes, que en gran cantidad de casos eran similares, tanto en diseño como en interacción, produciendo confusión a los mismos diseñadores a la hora de elegir el correcto para la experiencia. A su vez algunos de esos componentes no aportaban valor real al usuario.
- Solicitud de nuevos componentes al equipo de desarollo denominado Core Team (Quien dan manutención y desarrollo a los design system del banco: Lucy y Zeta) que en muchos casos requerían un gran desarrollo de los mismos, y en varias oportunidades no tenían racionales detrás.
- Desafíos para mantener la escalabilidad y flexibilidad del diseño a medida que la aplicación evolucionaba y se adaptaba a nuevas necesidades.
DEFINIMOS NECESIDADES Y POSIBLES SOLUCIONES
Construccion de un chapter de UX Design Ops para atender las consultas y requerimientos de los designers
Para asegurar que los diseñadores de UX puedan concentrarse en crear experiencias excepcionales, era crucial que dispusieran de un soporte robusto y eficiente para manejar sus consultas y requerimientos. Aquí es donde entra en juego la construcción de un Chapter de UX Design Ops.
Creacion de un proceso que permitiera un flujo de solicitud de requerimientos
Este proceso permitiría que las necesidades y requerimientos de diferentes partes interesadas se recojan, analicen y gestionen de manera sistemática, asegurando que los proyectos se ejecuten de acuerdo con las expectativas y objetivos establecidos.
Documentacion tecnica y visual unificada en un solo lugar
La documentación era escasa y estaba distribuida por diferentes archivos. Esto sucedía, no por que los diseñadores hayan sido desordenados, o bien no hayan sabido documentar correctamente, los motivos eran otros.
Cuando se inició el proyecto en el banco, el equipo de diseño fue tomando los requerimientos de sus células. El crecimiento exponencial del producto fue tan grande, y el time to market también (Empezó en ese momento el boom de billeteras virtuales en Argentina) que el equipo de diseñadores tuvo que estár abocado exclusivamente a los requerimientos. En consecuencia, se fue generando la documentación en un archivo de adobe XD con faltantes de racionales (Conociendo las desventajas de Adobe XD donde muchas veces se bugeaba el programa, produciendo que pocas personas pudieran ver correctamente lo antes mencionado), componentes creados con similitud de comportamientos y estadíos que no aportaban valor real al producto, no existía un repositorio oficial en alguna url donde los diseñadores tuvieran toda la explicación. La solución era evidente: Crear un repositorio que permitiera a los diseñadores poder obtener la informacion que necesitaban en pocos clics. Pero el desarrollo de esto, te lo cuento más adelante.
Creacion de un espacio para la consistencia del producto
La consistencia del producto era esencial para asegurar una experiencia de usuario coherente, consistente y satisfactoria. Para lograr esto, era fundamental que los equipos de diseño colaboraran de manera efectiva, compartieran conocimientos y revisaran mutuamente su trabajo.
Modificacion y manutencion de todo el UI Kit en Adobe XD
Rediseñar y mantener un UI Kit en Adobe XD nos aseguraba que todos los elementos de la interfaz estuvieran actualizados, fueran accesibles y cumplieran con los estándares de diseño de nuestro equipo-
Un chapter para gobernarlos a todos. Un chapter para encontrarlos, un chapter para atraerlos a todos y potenciarlos
Por si no te percataste, una frase icónica del Señor de los Anillos transformada a nuestro trabajo (Solo que nosotros no teniamos principios de maldad😁 si no todo lo contrario).
Con todos los pain points detectados, la primer decisión por parte del Head UX fue resolutiva: Hay que crear un Chapter que se encargue de dar soporte y manutención de todas las propuestas y posibles requerimientos que acontecieran.
Es ahí, cuando a través de la petición de los lideres del equipo, comencé a participar del equipo de UX Design Ops. En primera instancia, consolidamos el equipo junto a dos de los lideres UX del banco, Matias Mariperisena y Diego Pallanch, quienes me eligieron para la tarea operativa.
Como segundo paso, definimos estrategias, procesos, espacios, artefactos, y todo lo que correspondiera al chapter. Una vez concluido este proceso que demoró aproximadamente dos meses, iniciamos nuestra ejecución. A continuación, algunas de las labores que realizamos.
Creacion de un proceso que permitiera LA solicitud de requerimientos
Una vez creado el chapter, decidimos que los diseñadores tuvieran un orden a la hora de solicitar requerimientos al Core Team (Por si no comprendiste que es el Core Team, este equipo de desarrollo s un equipo que se dedica exclusivamente a la manutención y desarrollo de todos los componentes de todos los productos bancarios.) Bien, una vez puestos en marcha, construimos el siguiente flujo.
Entendimiento y feedback
En esta primer instancia, el UX Designer solicitaba una reunión para presentar una idea. Podía ser desde un componente, un ecosistema interlazado, una propuesta de comportamiento, etc.
En este caso, primeramente evaluabamos si lo que se estaba proponiendo era acorde a la identidad de la aplicación, desde una visión 360 (Componentes – comportamientos ya realizados; Concordancia con otras funcionalidades; Consistencia; Propuesta ya existente en el mercado o innovadora; Tiempos de desarrollo; Complejidad de uso). Además, estresabamos la propuesta planteando posibles escenarios de uso, con la vinculación de otras células de UX, respecto a las funcionalidades. Como preguntas anexas, consultabamos…¿Cual es el fin de esta propuesta? ¿En que va a beneficiar al usuario? ¿Produce realmente un valor añadido al producto? ¿Existe otra propuesta ya desarrollada que pueda solventar lo mismo que se está proponiendo? ¿Con que tiempo se cuenta en caso de avanzar la misma?
Si la propuesta era correcta desde todas las perspectivas, pasabamos a la siguiente instancia: Armado del requerimiento.
Por el contrario, si la propuesta carecía de fundamento o de rationals, brindabamos feedback de correción y volviamos a tener la instancia inicial.
En contados casos, las propuestas no avanzaron a una segunda instancia por que se podían solventar con otros componentes o interacciones similares.
*Un lineamiento clave era poder minimizar a nivel funcional el design system. Esto, como se mencionó en la primer etapa, era un gran dolor para los diseñadores, dado que a lo largo del producto y en la vorágine del mismo, se fueron solicitando distintos componentes que en su mayoría eran similares, o que cumplían la misma función. Esto hacía que cada vez que los diseñadores tenían que ir a elegir un componente, tenian severas dudas de cuales eran los mas apropiados.
Armado del requerimiento
Una vez superada la instancia inicial, la tarea del diseñador era simple. Armar la propuesta para presentar al Core Team. En las primeras presentaciones, los diseñadores armaban sus artefactos en conformidad. Posteriormente, optimizamos ese trabajo a través de un template de presentación.
En dicha presentación proponiamos a los diseñadores generar un archivo Adobe XD con la propuesta a solicitar, en caso de ser componentes, detallar las distintas variantes y estadíos, y aplicación en un caso de uso.
De la misma manera que en el primer paso, nos reuniamos con el UXer para revisar la propuesta. Si considerabamos que contenía todos los racionales de uso y técnicos, avanzabamos a la tercer instancia: Presentación del requerimiento al Core Team.
En caso contrario, señalabamos posibles ajustes para tener un próximo approach con lo solicitado. En este bucle, en algunas circunstancias optabamos por un email con la propuesta iterada para concluir esta etapa.
En muy pocos casos, en esta segunda instancia se lograba concenso para deprecar la propuesta, dado que se podía suplir con otro componente o comportamiento ya establecido.
Presentacion del requerimiento al Core Team
Una vez armado el requerimiento, avanzabamos a reunirnos con el Core Team. (En una weekly)
En principio, queríamos testear efectividades. Es por ello que al comienzo, los diseñadores asistían a la reunión para brindar detalles de la propuesta a incluir. Observamos que los espacios no eran efectivos, dado que el equipo de desarrollo, basicamente, hablaba en su lenguaje técnico y de ingeniería, muy ajeno a cualquier glosario de un diseñador de experiencias, más alla de las palabras ya conocidas. Detectamos que los espacios perdían los objetivos y por tanto, requeríamos retrabajar en reforzar la propuesta.
Después de entender las realidades, decidimos que el mejor camino era tener una mesa de pocas personas y directamente hablar en lenguaje técnico. Desde ese punto, el proceso fluyó automáticamente.
Finalmente, para concluir esta parte del flujo, el Core Team cargaba una tarjeta en Jira sobre el requerimiento con la información armada en la anterior etapa.
De la misma manera, algunas propuestas debían ser refactorizadas o minimizadas, por los racionales de desarrollo respecto a tiempos, complejidades, etc. (Estas variables eran claves para los diseñadores, ya que debían cubrir esa necesidad en uno o dos sprints.)
Desarrollo / Monitoreo del requerimiento
En esta cuarta etapa, nuestra labor se simplificó directamente al monitoreo del requerimiento. Es decir, eramos interlocutores entre los diseñadores y el CT.
Como tareas, dabamos seguimiento del avance de las tarjetas en Jira y consultar sobre su estado de desarrollo al equipo del CT.
Disponibilizacion en el Design System
Finalmente, si el desarrollo era un éxito (En todos los casos fué un éxito, el equipo del C.T. del ICBC es un G.O.A.T.) se agregaba al design system.
Allí comenzaba otra tarea para nosotros: Documentación técnica y visual unificada en un solo lugar.
Documentacion tecnica y visual unificada en un solo lugar
Algunos ejemplos de cómo los diseñadores documentaban en diferentes archivos, en la vorágine de crecimiento del producto.
Buscando la documentacion
Entendiendo el punto de dolor, la primer tarea que tuvimos que llevar adelante es realizar un scouting de toda la documentación que estaba repartida por diferentes archivos.
Realizar esa búsqueda no fué para nada fácil, dado que muchos archivos estaban dentro de las unidades de los diseñadores. Este proceso fue lento y burocrático, pero al final del camino, recaudamos todo lo que se había detallado respecto a componentes, y todo lo referido al producto.
Comparativa de los distintos contenidos y generacion de template
Como segundo paso, decidimos avanzar en un archivo de Adobe XD para comparar y generar un template que sea útil para los diseñadores. Para ello obtuvimos un patrón de estructura que se repetía en los distintos archivos.
La estructura finalmente se conformó de la siguiente manera:
- Título del componente y tipo: Básicamente, el nombre del componente y el tipo (Mólecula, Átomo, otro).
- Presentación del componente: Una breve intro sobre qué es el componente y objetivo.
- Para que se usa el componente: Racionales para el buen uso del componente.
- Como no se usa el componente: Racionales del mal uso del componente.
- De que se compone el componente: Cómo es la estructura del componente (¿Se compone de otros componentes?)
- Cómo se comporta: Como reacciona frente al uso de los usuarios.
- Variantes: De existir, posibles variantes del mismo componente.
- (OPCIONAL) Ubicación en pantalla: Dónde se ubica el componente y alineación.
- (OPCIONAL) Aspectos visuales - Diseño: Aspectos visuales más técnicos tales como clases css y js (hex-color, border, background-color, border-radius, entre otros)
- Componentes relacionados: Por lo general, hipervínculos de los componentes relaacionados al documentado.
Unificando toda la informacion en un solo lugar: Pestaña de Diseño en el Design System de YOY
Cómo última parte del proceso de unificación de la documentación técnica y visual, decidimos que no bastaba con tener un archivo en Adobe XD. Recibiamos feedback de los diseñadores de que la búsqueda no era tan amigable, y que al existir tantos componentes y tantos frames, la interacción con el archivo finalmente se volvía inutilizable.
Cuando percibimos que existía esa oportunidad de mejora a través del feedback, optamos por tomar el camino largo y dificil pero éxitoso: Subir toda la documentación a un repositorio en GitLab.
La documentación de un Design System es clave que esté en un repositorio. Allí se podrá encontrar todo al alcance de la mano. Para nuestra buena fortuna, el banco ya tenía un sitio web donde almacenaba el repositorio de Lucy (El design System mas “bancario”), con una estructura definida: Una pestaña de Diseño, donde existían todos los componentes con sus racionales, y una pestaña de desarrollo, con contenido técnico de implementación y deploy.
Para nuestra mala fortuna, documentar en GitLab, a través de una maquina virtual era una tortura.
Prepará los pochoclos por que acá comienza otra odisea.
Trabajar en un repositorio no es difícil, pero requiere su técnica.
La escritura se realiza con un lenguaje denominado Markdown enrriquecido, que es un lenguaje fácil de escribir, es utilizado en la mayoría de los repositorios a nivel mundial y permite que un repositorio pueda convertirse en una enciclopedia de contenidos.
Todo esto lo sabiamos, pero teniamos un obstaculo: La seguridad del banco.
Si has trabajado alguna vez en un banco sabrás a lo que me refiero. Si no lo has hecho, dejame que te cuente más. Un banco protege su información sensible (Con justa y lógica razón) y todos sus datos, incluyendo correos, sistemas, entre otros, a través de una plataforma que no se encuentra en una url pública, si no más bien dentro de una máquina virtual. Imaginate si tuvieras un emulador en tu pc y querés emular una maquina virtual. Esto es exactamente lo mismo, solo que con más parámetros de seguridad.
Bien, el repositorio al cual debiamos subir esa información estaba dentro de esa maquina virtual. Nuestra idea era simplemente convertir esos archivos XD a lenguaje Markdown Enrriquecido con CSS para darle estilos. Pero empezamos a tener complicaciones.
Por un lado, traducir todos los documentos al lenguaje markdown realmente es tedioso y un trabajo sumamente mecánico. Después de un arduo trabajo, logramos traducir casi cincuenta componentes, entre otros.
Por otro lado, al ingresar a la maquina virtual, la herramienta de repositorios GitLab, no nos permitía seleccionar todos los archivos de markdown y subirlos, si no que solo podiamos adjuntar un archivo. (Los permisos del banco eran super estrictos, y estaban bloqueadas las cargas múltiples).
Por suerte, con un final felíz, y después de un largo trabajo, pudimos llegar a la meta. Tener la documentación en el repositorio y disponibilizada para que los diseñadores pudieran consultarla.
Un espacio para potenciar el producto
Este es uno de los puntos que si bien estaba más desarrollado, faltaba ajustar algunos parámetros.
El equipo de diseño venía reuniendose en algunos encuentros donde consultaban acerca de usos de componentes, aplicaciones en las diferentes funcionalidades del producto, entre otros, pero no desde una visión holística del producto.
Esto hacía que cada uno, a criterio propio, desarrollara la experiencia del usuario, pero por otro lado, corriendo un riesgo considerable de que la aplicación fuera inconsistente por todos lados.
Nuestra solución fué fácil y efectiva, dado que en nuestra anterior experiencia habiamos tenido situaciones similares: Armar espacios de Jam UX para consultar lo antes mencionado, pero siempre con todos los actores involucrados en todas las funcionalidades. Desde un toast hasta una pantalla de pago, todas las células debían estar al tanto de una posible modificación o incorporación al design system y en que afectaría a su célula, respecto a alguna modificación, etc.
Durante los primeros encuentros, los diseñadores comenzaron a negociar sobre algunas experiencias que estaban dentro de la aplicación que eran inconsistentes. Por suerte, la gran mayoría de inconsistencias, eran simplemente cambiar algún color o bien alguna iconografía. Por supuesto tuvimos también algunos cambios menores, pero no generaron impacto negativo en la aplicación y en los usuarios, si no todo lo contrario. Posteriormente, los encuentros fluyeron tal como estaban construidos y parametrizados.
En conclusión, logramos un objetivo que tenía una resolución fácil pero que para nosotros era muy importante: Lograr que todos los diseñadores estén en la misma página a la hora de construir experiencias del usuario.
Modificacion y manutencion de todo el UI Kit en Adobe XD
Cómo última etapa de mi participación en este proyecto del chapter, restaba algo no menor a todo lo antes mencionado…El UI kit del Design System de la aplicación.
Algo tan simple pero laborioso como rearmar el ecosistema de componentes en Adobe XD, con su bienvenida, paleta de colores, iconos, ilustraciones y componentes, era vital para reordenar finalmente todo el trabajo de los diseñadores.
Para ello dividimos el proceso en dos fases:
– Assesment del UI KIT ya establecido y de todos los componentes creados, sus variantes y estadíos en concordancia con el design system.
– Rediseño del kit
Assesment del UI KIT
Esta primera parte del proceso fue la más laboriosa, dado que tuve que relevar alrededor de 50 componentes, con sus diferentes estadios y variantes.
Dentro de los grandes problemas, encontré lo que me esperaba. Inconsistencias en los nombres de las variantes, inconsistencias en el diseño de los componentes vs lo que estaba en el design system, faltantes de estadíos y variantes que en el repositorio estaban documentadas, entre otros inconvenientes.
Después de mapear los distintos problemas detectados, a través de un criticality map, nos pusimos manos a la obra.
Rediseño del kit
Lo primero en lo que comenzamos a trabajar fué en la corrección de los componentes. La modificación era clave: Modificar las inconsistencias y errores y actualizar para que todos los prototipos de los diseñadores estuvieran actualizados.
Pero…¿Y si los diseñadores “harddiseñaron” los componentes con otros colores y otros estilos?
Para ello, la solución fue simple: Creamos una versión del archivo de backup, realizamos las modificaciones, actualizamos, revisamos los masters de cada diseñador y…voilá! Detectamos solamente alrededor de 10 componentes que “rompieron” los prototipos de los diseñadores, en consecuencia de la modificación del componente padre.
Teniendo ya todos los componentes corregidos y consistentes con lo que estaba en el repositorio, lo próximo era darle vida al kit.
Esta fué la corona de todo un trabajo mancomunado dentro del chapter, dandole vida al UI KIT de los diseñadores de YOY.
Creando valor desde distintos frentes
UI KIT
Mejorar eficiencia y velocity de los designers
Documentación
Interlocutor entre UXers y Core Team
Valor al producto a través de la automatización de flujos y procesos
Algunos datos interesantes
Mejora cualitativa en todo el producto en base a la consistencia de UI
25% Reducción tiempos de ejecución del equipo
Ahorro de un 20% en tiempos de procesos
Se pudo optimizar el flujo de requerimientos
Mayor satisfacción de los diseñadores al tener las herramientas necesarias
¡Muchas gracias por leer!
Trabajemos juntos🚀
Me apasionan los nuevos desafíos. Si te gustaría reunirte y conocer más sobre mi trabajo, no dudes en escribirme por email. Te responderé a la brevedad.