intive Argentina Blog

Crear un sistema de diseño para una FinTech conservadora

¿Cómo empezó todo?

Al principio, todo era caos. Y, en realidad, eso no estuvo tan mal. 😊

A comienzos del año pasado, comencé a trabajar en un proyecto enorme para una empresa financiera. Tenían una aplicación web muy específica, grande y compleja, que contaba con muchas secciones y que gestionaba miles de documentos. Era de esperar que muchos de los componentes visuales estuvieran duplicados, es decir, se veían parecidos pero no eran iguales, o tenían distintos estilos para la misma ventana emergente o el mismo botón en distintas partes de la app.

Cuando me uní al proyecto, solo había un diseñador UX y eso ya era bastante, porque antes no había ningún diseñador. Los propietarios del producto solían bosquejar algunos diseños en PowerPoint a las apuradas o utilizaban capturas de pantallas en las que agregaban todas las notas. Les explicaban las funciones que necesitaban directamente al equipo de desarrolladores y, algunas veces, no tenían muy en claro qué querían o no tenían en cuenta las pautas de look & feel.

Venderle el sistema de diseño al cliente

El equipo de UX se dio cuenta de que, para una aplicación de ese tamaño, era fundamental contar con “una sola fuente de información”. El líder del proyecto preparó una presentación increíble para los gerentes de la empresa, en la que explicaba en qué consistía un sistema de diseño y cómo podía ayudarlos. En la presentación, comentó que “esa fuente de información” iba a registrar todo, no solo el estilo, sino también los comportamientos, las nuevas funciones y demás.

Por suerte, el cliente aceptó. Sospecho que, además de que nuestro líder fue muy convincente a la hora de hablar, los gerentes ya sabían que existían incongruencias en toda la app.

Armar el equipo

Una vez que el cliente nos dio luz verde, tuvimos que armar el equipo central para trabajar en el sistema de diseño.

En ese momento, éramos dos personas: el líder y yo. Después de un tiempo, se sumó otro diseñador sénior. Mientras los otros dos diseñadores se encargaban de desarrollar proyectos nuevos dentro de la app, a mí me tocó diseñar y mantener el nuevo sistema de diseño.

Trabajamos codo a codo, llegamos a acuerdos sobre los componentes y los validamos. Además, los tres podíamos crear algunos componentes cuando teníamos tiempo.

Al final, también sumamos al equipo a un propietario del producto de parte del cliente; esa persona estaba a cargo de validar los componentes nuevos y comunicar los aspectos del sistema de diseño al resto de la organización.

Primero, un poco de investigación

Antes de empezar a trabajar en el sistema de diseño, tuvimos varias entrevistas con los propietarios del producto, el equipo de desarrolladores y los miembros de QA, ya que queríamos saber cómo registraban los movimientos de la app y qué esperaban del sistema de diseño.

Luego, realizamos un inventario de todos los componentes visuales de la app, y el lugar y la forma en que se utilizaban. Usamos los principios de diseño atómico como base para definir los componentes: átomos, moléculas, organismos y plantillas.

Crear el sistema de diseño: nuestra biblioteca de Sketch

En el equipo de sistema de diseño, analizamos y perfeccionamos cada componente auditado. Luego, lo registramos en detalle en un solo archivo de Sketch que pudiéramos vincular con otros archivos, como una biblioteca. Los componentes principales estaban todos: desde botones, pestañas e información sobre herramientas, hasta ventanas emergentes y filas de tabla, incluidos también íconos, colores y estilos de fuente.

Lanzar el sistema de diseño

¡Ya estábamos listos! Cuando la biblioteca estuvo lista, construimos un CMS para corroborar los distintos componentes. El sitio web incluyó documentación y recomendaciones respecto del estilo, el uso, el espacio y más.

Además, podíamos recurrir a información sobre los componentes en una biblioteca de Zeplin. En el caso de los componentes que tenían su complemento en el repositorio de React, agregamos enlaces para cada uno en Storybook.

El sitio web también tenía documentación técnica para el equipo de desarrolladores, como entornos, mejores prácticas de programación, etc.

Luego, la debacle

Con el sistema de diseño actualizado y en marcha, parecía que se venía el final feliz, pero, bueno, pasaron cosas.

Primero, algunos diseñadores se fueron de la empresa. Luego, comenzaron algunos proyectos nuevos de alta prioridad. Había mucho menos tiempo y menos recursos disponibles, y quedó claro que el sistema de diseño no era una prioridad para el cliente. Aunque el equipo de diseñadores lo siguiera usando y manteniendo bastante, a la gran mayoría no le importaba, así que no lo revisaban ni lo usaban. Lo mismo pasó con el equipo de QA y los propietarios del producto. El sistema de diseño seguía ahí, pero a nadie le importaba.

El renacer del fénix

Un año después, alguien se acordó de que el sistema de diseño existía. El propietario de producto de diseño por parte del cliente anunció que había interés en relanzar el sistema, ya que estaba incluido en las metas de gestión de ese año. El equipo de UX estaba contento de poder trabajar en el sistema de diseño otra vez, así que armó una hoja de ruta para el relanzamiento en un abrir y cerrar de ojos.

El plan

Como estaba claro que no se estaba usando, decidimos hacer lo siguiente:

  • Sondear a todo el equipo: propietarios del producto, desarrolladores y QA.
  • Organizar reuniones periódicas con algunos colaboradores clave.
  • Definir (y redefinir) las herramientas que se deberían usar para hospedar el sistema de diseño, herramientas que a todos les gustaran y que fueran a utilizar.

El resultado

Después de los sondeos, las reuniones y las charlas, confirmamos lo siguiente:

  • La mayoría de los miembros del equipo no usaban el sistema de diseño.
  • Muchos no tenían ni idea de que existía ni sabían cómo encontrarlo.

También descubrimos que al equipo de desarrollo no le importaba demasiado los detalles del diseño o su registro, solo querían tener un repositorio central de códigos con los componentes apropiados. Se daba por sentado que los componentes de React debían tener el estilo correcto. Después de charlarlo en las reuniones, decidimos usar Zeplin como herramienta principal para las especificaciones de diseño y el repositorio de React para los desarrolladores.

Como había diferencias entre el componente de React y la versión documentada de Sketch, decidimos invertir algunas horas de desarrollo para trabajar en el repositorio y verificar los componentes.

¿Fin de la historia?

Al final, aunque el cliente manifestó su interés en trabajar con el sistema de diseño, cuando le pedimos que asignara algunas horas de desarrollo, no pudo destinar los recursos necesarios, ya que todavía no era una prioridad.

¿O no? ¿Qué puede hacer un diseñador UX?

Aunque el resultado fue desalentador, decidimos insistir con la implementación del sistema de diseño. Ya va a llegar el momento. Por ahora, nuestro plan de acción es el siguiente:

  • Seguir manteniendo el sistema de diseño, de modo que esté listo para aplicar a los componentes de React cuando sea necesario.
  • Registrarlo en Zeplin para que se pueda encontrar y usar fácilmente (por ahora).
  • Seguir insistiendo con las horas de desarrollo cuando finalicen los proyectos urgentes, si es que finalizan.

¿Qué aprendimos?

Fue un camino largo y lleno de obstáculos, y aprendimos un montón.

  • Ningún sistema de diseño va a tener éxito si solo el equipo de diseño lo concibe.Todo el equipo debe conocerlo y saber cuáles son sus beneficios, no importa el trabajo que hagan (QA, desarrolladores/as, propietario de producto, gerente, etc.).
  • Es importante que un equipo multidisciplinario esté a cargo de crear el sistema de diseño, no solo los/as diseñadores/as. Todas las áreas deben participar en la creación y el mantenimiento, porque todos tienen aportes valiosos que quizá a los diseñadores se les escapan. Así, también se genera aceptación del producto.
  • El sistema de diseño debe estar en un lugar que sea fácil de encontrar y mantener para todos los miembros.En lugar de crear un sitio nuevo o presentar una herramienta novedosa, es mejor agregar documentación para las herramientas que el equipo ya conoce y que usa con frecuencia: Zeplin, tickets de Jira, Confluence, etc.
  • Comunicación y más comunicación.El equipo debe saber acerca de los cambios y las actualizaciones del sistema de diseño. Utiliza un canal que ya esté en uso y que sea confiable. Está bien estar presente, pero no abrumar al cliente.

Así termina nuestra historia. Les dije que no había estado tan mal, ¿no? Ahora cuéntanos tu experiencia. ¿Has pasado por algo similar? ¿Cuál es tu historia?

Vanina Greco

Vanina Greco es diseñadora UX en intive Argentina desde junio del 2019. Licenciada en Marketing de la École Supérieure de Commerce et de Marketing de Paris, Vanina además cuenta con una maestría en Comercio Internacional de la Université de Cergy-Pontoise. En 2016 decidió aventurarse y realizar un cambio de rumbo profesional, con el cual pasó de trabajar full time en marketing al universo UX. Fan del diseño, en su tiempo libre a Vanina le gusta arreglar ropa, escribir y hacer yoga. Su punto débil: Pilu, la gata persa más linda del mundo.

Deja un comentario