Abogando por un rediseño completo del producto

Persuadir a mi equipo para que rediseñe los Fabric Crashlytics en Firebase

Crashlytics en Fabric (izquierda), Crashlytics rediseñado en Firebase (derecha)

Recientemente tuve la oportunidad de rediseñar Crashlytics, una herramienta de informe de fallas que ayuda a los desarrolladores de aplicaciones móviles a comprender por qué sus aplicaciones fallan. (¿Alguna vez ha tenido un bloqueo de la aplicación? Crashlytics ayuda a los desarrolladores a solucionarlo).

Mi equipo se unió a Firebase en Google en enero de 2017 como parte de la adquisición de Fabric. Uno de los objetivos de la adquisición era llevar Crashlytics a Firebase. Esto significó rediseñar y reconstruir nuestro producto en Firebase, que usa Material Design y tiene un sistema de diseño visual muy diferente.

Dado que necesitábamos hacer una actualización de diseño visual de Crashlytics, decidí que era una gran oportunidad para repensar toda la experiencia del usuario, en lugar de solo transferir las características tal como están. Crashlytics es un producto muy querido pero había acumulado una gran deuda de diseño desde su creación en 2011. Escuchamos a muchos usuarios que tenían dificultades para usar funciones o que no podían encontrar una función que ya teníamos. A nuestro equipo también le resultaba difícil saber dónde colocar las nuevas funciones porque el producto no tenía una jerarquía de información clara, tanto para nosotros como para nuestros usuarios. Era hora de un rediseño.

Pero primero, necesitaba construir mi caso.

Uno no comienza simplemente a rediseñar un producto. Lleva tiempo comprender a los usuarios, cómo usan su producto y los problemas que tienen. Es fundamental obtener todas estas ideas antes de embarcarse en el rediseño para asegurarse de que el equipo esté resolviendo los problemas correctos y alineado con los objetivos del proyecto.

Paso 1: Comprenda a sus usuarios

Empecé reuniendo información. Hablé con los compañeros de equipo de Crashlytics que habían trabajado en el producto durante muchos años, nuestro equipo de relaciones con desarrolladores, investigadores de usuarios y, por supuesto, nuestros usuarios. Necesitaba entender por qué y cómo las personas usan Crashlytics antes de poder descubrir cómo mejorar su experiencia de usuario.

Afortunadamente, Jason St. Pierre, mi gerente de producto, había trabajado en Crashlytics durante más de 5 años y habló con los usuarios a menudo, por lo que tenía un profundo conocimiento de cómo una variedad de personas usan Crashlytics. Identificó los 4 viajes de usuario más críticos de Crashlytics:

  1. Supervisión de la estabilidad de una versión de aplicación recién lanzada
  2. Comprobación de la estabilidad de la aplicación
  3. Priorizar qué bloqueos solucionar
  4. Depuración de un problema del cliente
El viaje de usuario más crítico en Crashlytics: monitorear la estabilidad de una versión de aplicación recién lanzada

Mapeé cada uno de esos viajes de usuario en flujos usando personas, lo que reveló un micro-viaje consistente entre los 4 viajes: el flujo de "investigar y arreglar". Compartí estos viajes con el equipo y revisé los flujos según fuera necesario. Estos flujos alinearon al equipo de Crashlytics en una comprensión compartida y fundamental de cómo los usuarios usan nuestro producto.

El flujo de

Paso 2: comprende sus puntos débiles

Una vez que estuvimos alineados sobre cómo las personas usan nuestro producto, necesitábamos comprender sus puntos débiles con la UX existente. El equipo de Crashlytics es extremadamente colaborativo y todos invertimos en crear una gran experiencia para nuestros usuarios. Quería una forma de involucrarlos en el proceso de rediseño que fuera más colaborativo que yo compartiendo conceptos y recibiendo sus comentarios. El equipo también tuvo mucho contexto valioso sobre el producto que sería útil para aprovechar el rediseño, ya que muchos de ellos han estado trabajando en el producto durante años.

Muchas personas en el equipo de Crashlytics mencionaron que varios aspectos del tablero necesitaban mejoras. Para aprovechar su conocimiento, decidí realizar una serie de estudios de usuarios internos. Mi objetivo era comprender cuáles eran los puntos débiles más importantes en la experiencia del usuario, según lo que habíamos escuchado de los clientes a lo largo de los años.

Imprimí y corté el tablero de Crashlytics y configuré sesiones individuales con compañeros de equipo donde les pedí que reorganizaran las piezas y rediseñaran el tablero, hablando en voz alta para explicar su pensamiento.

Compañeros de equipo que se divierten rediseñando Crashlytics con recortes de papelAlgunos de los paneles rediseñados: algunas personas también agregaron nuevas características con post-its

Esto fue tremendamente útil. No solo fue divertido (¿con qué frecuencia los diseñadores digitales juegan hoy en día con papel real?), También pude ver lo que cada persona identificó como puntos débiles sin que nadie más los sesgara. Esto me facilitó la identificación de temas recurrentes. Por ejemplo, cada persona se centró en mejorar los filtros y mejorar la jerarquía de la información. También aprendí del equipo de relaciones con los desarrolladores qué características eran difíciles de usar y encontrar.

Compartí estos aprendizajes con el equipo en un mazo continuo que catalogó el esfuerzo de rediseño. También configuré controles de diseño semanales con el equipo para compartir actualizaciones de diseño y llevarlos a lo largo del viaje de rediseño.

Una diapositiva del mazo de procesos de rediseño que describe los temas recurrentes en la página Descripción general de Crashlytics

Paso 3: definir los problemas del usuario

Después de comprender los objetivos y los puntos débiles de nuestros usuarios, los problemas del usuario se volvieron mucho más claros. Tomé todos mis aprendizajes de las sesiones de recortes de papel y las conversaciones con los usuarios y el equipo, luego me limité a nuestros principales problemas de usuario:

Problema 1: a los usuarios les resultó difícil acceder a la información que realmente les interesaba

Lo primero que hicieron la mayoría de los usuarios en nuestro tablero fue desplazarse hacia abajo. La información que buscaban estaba más abajo en la página o requería múltiples clics para acceder. Fue enterrado detrás de características menos importantes.

La página de detalles del problema en Fabric Crashlytics

Problema 2: los usuarios no sabían que existían funciones

Una vez, un usuario me preguntó acerca de agregar una función para registrar lo que sucedió en la aplicación que condujo a un bloqueo. Esta característica ya existía en nuestro panel de control, solo estaba enterrada en la interfaz de usuario. Nuestro equipo de soporte escuchó muchos casos similares de los usuarios también. Este problema también fue reflejo del problema que enfrentó nuestro propio equipo: dificultad para saber dónde colocar las funciones.

La página de detalles de las sesiones en Fabric Crashlytics

El tema general que surgió fue que la jerarquía de información de nuestro producto no estaba clara, lo que expuse a las partes interesadas como el principal problema que deberíamos resolver. Como habían sido parte del proceso de diseño todo el tiempo, fue fácil alinearse y obtener la aceptación.

Cómo funcionó todo

El equipo admitió oficialmente la necesidad de un rediseño. Entendieron los problemas que tenían los usuarios y acordaron qué partes de la experiencia del usuario necesitaban mejoras. ¡Éxito! Los siguientes pasos fueron rediseñar el tablero, lo que sucedió en los próximos meses a través de una gran cantidad de lluvia de ideas, colaboración, visitas y pruebas de usuarios.

Construir un caso para un rediseño implica una tonelada de contexto. Como diseñador, puede estar claro que un producto necesita un rediseño, pero uno no puede ir muy lejos solo. El rediseño de un producto es un esfuerzo de equipo, y es importante que el equipo se alinee sobre por qué es necesario un rediseño. También es imposible rediseñar algo si no comprende cómo se usa actualmente.

Al comprender profundamente a los usuarios de Crashlytics, sus puntos débiles y sus problemas, estaba mucho mejor equipado para rediseñar el producto. Y al llevar a otros a lo largo de ese proceso, todo el equipo pudo comprender mejor a nuestros usuarios y satisfacer sus necesidades. Después de meses de arduo trabajo y hablar con los usuarios, lanzamos con éxito un rediseño de Crashlytics en Firebase a principios de este año, con una jerarquía de información mejorada y una actualización visual, ¡además de algunas características nuevas!

Para concluir, aquí está mi parte favorita del rediseño de Crashlytics:

¡Una animación de celebración cuando un usuario corrige un error con éxito!