Sostenere per una riprogettazione completa del prodotto

Convincere il mio team a ridisegnare Fabric Crashlytics in Firebase

Crashlytics in Fabric (a sinistra), riprogettati Crashlytics in Firebase (a destra)

Di recente ho avuto l'opportunità di riprogettare Crashlytics, uno strumento di segnalazione degli arresti anomali che aiuta gli sviluppatori di app mobili a capire perché le loro app si stanno bloccando. (Hai mai avuto un crash dell'applicazione con te? Crashlytics aiuta gli sviluppatori a risolverlo.)

Il mio team è entrato a far parte di Firebase presso Google a gennaio 2017 come parte dell'acquisizione di Fabric. Uno degli obiettivi dell'acquisizione era portare Crashlytics su Firebase. Ciò significava ridisegnare e ricostruire il nostro prodotto in Firebase, che utilizza Material Design e ha un sistema di visual design molto diverso.

Dato che dovevamo fare un aggiornamento della progettazione visiva di Crashlytics, ho deciso che era una grande opportunità per ripensare l'intera esperienza utente, piuttosto che limitarsi a eseguire il porting delle funzionalità così come sono. Crashlytics è un prodotto molto amato ma ha accumulato molti debiti di progettazione dalla sua creazione nel 2011. Abbiamo sentito da molti utenti che avevano difficoltà a utilizzare le funzionalità o non riuscivano a trovare una funzionalità che già possedevamo. È stato anche difficile per il nostro team sapere dove inserire nuove funzionalità perché il prodotto non aveva una chiara gerarchia di informazioni - per noi stessi e i nostri utenti. Era tempo di riprogettare.

Ma prima dovevo costruire il mio caso.

Non si inizia semplicemente a ridisegnare un prodotto. Ci vuole tempo per capire gli utenti, come usano il prodotto e i problemi che hanno. È fondamentale ottenere tutte queste intuizioni prima di intraprendere la riprogettazione stessa per garantire che il team stia risolvendo i problemi giusti e si allinei agli obiettivi del progetto.

Passaggio 1: comprendere i tuoi utenti

Ho iniziato raccogliendo informazioni. Ho parlato con i compagni di squadra di Crashlytics che hanno lavorato sul prodotto per molti anni, il nostro team di relazioni con gli sviluppatori, i ricercatori degli utenti e, naturalmente, i nostri utenti. Prima di riuscire a capire come migliorare la loro esperienza utente, dovevo capire perché e come le persone usano Crashlytics.

Fortunatamente Jason St. Pierre, il mio product manager, aveva lavorato su Crashlytics per oltre 5 anni e aveva parlato spesso con gli utenti, quindi aveva una profonda comprensione di come una serie di persone usa Crashlytics. Ha identificato i 4 viaggi utente più critici di Crashlytics:

  1. Monitoraggio della stabilità di una versione dell'app appena rilasciata
  2. Verifica della stabilità dell'app
  3. Dare la priorità agli arresti anomali da correggere
  4. Debug di un problema del cliente
Il viaggio utente più critico in Crashlytics: monitoraggio della stabilità di una versione dell'app appena rilasciata

Ho mappato ciascuno di questi viaggi utente nei flussi usando le personas, il che ha rivelato un micro-viaggio coerente tra tutti e 4 i viaggi: il flusso "investigare e correggere". Ho condiviso questi viaggi con il team e ho rivisto i flussi secondo necessità. Questi flussi hanno allineato il team di Crashlytics a una comprensione condivisa e fondamentale su come gli utenti utilizzano il nostro prodotto.

Il flusso di

Passaggio 2: capire i loro punti di dolore

Una volta che eravamo allineati su come le persone usano il nostro prodotto, dovevamo capire i loro punti deboli con la UX esistente. Il team di Crashlytics è estremamente collaborativo e tutti noi siamo investiti nella costruzione di una grande esperienza per i nostri utenti. Volevo un modo per coinvolgerli nel processo di riprogettazione che era più collaborativo di me condividendo concetti e ottenendo il loro feedback. Il team ha anche avuto un sacco di prezioso contesto sul prodotto che sarebbe utile per sfruttare la riprogettazione, poiché molti di loro hanno lavorato sul prodotto per anni.

Molte persone del team di Crashlytics hanno menzionato vari aspetti della dashboard che necessitavano di miglioramenti. Per sfruttare le loro conoscenze, ho deciso di condurre una serie di studi sugli utenti interni. Il mio obiettivo era capire quali fossero i maggiori punti dolenti dell'esperienza dell'utente, in base a ciò che avevamo sentito dai clienti nel corso degli anni.

Ho stampato e ritagliato il cruscotto di Crashlytics e organizzato sessioni individuali con compagni di squadra in cui ho chiesto loro di riorganizzare i pezzi e ridisegnare il cruscotto, parlando a voce alta per spiegare il loro pensiero.

I compagni di squadra si divertono a ridisegnare Crashlytics con ritagli di cartaAlcune delle dashboard riprogettate - alcune persone hanno anche aggiunto nuove funzionalità con i post-it

Questo è stato tremendamente utile. Non solo è stato divertente (quanto spesso i designer digitali giocano oggi con la carta reale?), Sono stato in grado di vedere ciò che ogni persona identificava come punti dolenti senza essere influenzata da nessun altro. Ciò ha reso più facile per me identificare i temi ricorrenti. Ad esempio, ogni singola persona si è concentrata sul miglioramento dei filtri e sul miglioramento della gerarchia delle informazioni. Ho anche imparato dal team delle relazioni con gli sviluppatori quali funzionalità erano difficili da usare e trovare.

Ho condiviso questi apprendimenti con il team in un mazzo in corso che ha catalogato lo sforzo di riprogettazione. Ho anche organizzato check-in di progettazione settimanali con il team per condividere gli aggiornamenti di progettazione e portarli lungo il viaggio di riprogettazione.

Una diapositiva dal deck del processo di riprogettazione che delinea i temi ricorrenti nella pagina Panoramica di Crashlytics

Passaggio 3: definire i problemi dell'utente

Dopo aver compreso gli obiettivi e i punti deboli dei nostri utenti, i problemi degli utenti sono diventati molto più chiari. Ho preso tutti i miei apprendimenti dalle sessioni di ritaglio cartaceo e dalle conversazioni con gli utenti e il team, quindi ho limitato i nostri problemi con gli utenti principali:

Problema 1: gli utenti hanno trovato difficile ottenere le informazioni a cui tenevano veramente

La prima cosa che la maggior parte degli utenti ha fatto sulla nostra dashboard è stata scorrere verso il basso. Le informazioni che stavano cercando erano più in basso nella pagina o richiedevano più clic per arrivare. È stato sepolto dietro le caratteristiche meno importanti.

La pagina dei dettagli del problema in Fabric Crashlytics

Problema 2: gli utenti non sapevano che esistessero funzionalità

Una volta un utente mi ha chiesto di aggiungere una funzione per registrare ciò che è accaduto nell'app che ha portato a un arresto anomalo. Questa funzione esisteva già nella nostra dashboard: era stata appena sepolta nell'interfaccia utente. Il nostro team di supporto ha ascoltato molti casi simili anche dagli utenti. Questo problema rifletteva anche il problema che il nostro team ha affrontato: difficoltà a sapere dove mettere le caratteristiche.

La pagina dei dettagli delle sessioni in Fabric Crashlytics

Il tema generale emerso era che la gerarchia di informazioni del nostro prodotto non era chiara, che ho definito le parti interessate come il problema principale che dovremmo risolvere. Dato che avevano sempre partecipato al processo di progettazione, è stato facile allinearsi e ottenere il buy-in.

Come è andato tutto bene

Il team ha ufficialmente accettato la necessità di una riprogettazione. Hanno compreso i problemi che gli utenti avevano e concordato su quali parti dell'esperienza dell'utente necessitavano di miglioramenti. Successo! I passi successivi furono in realtà la riprogettazione della dashboard, avvenuta nei mesi successivi attraverso numerosi brainstorming, collaborazioni, check-in e test degli utenti.

La creazione di un caso per una riprogettazione comporta un sacco di impostazione del contesto. Come designer, potrebbe essere chiaro che un prodotto ha bisogno di una riprogettazione, ma non si può andare lontano da soli. Una riprogettazione del prodotto è uno sforzo del team ed è importante che il team si allinei sul motivo per cui è necessaria una riprogettazione. È anche impossibile riprogettare qualcosa se non capisci come viene attualmente utilizzato.

Comprendendo profondamente gli utenti di Crashlytics, i loro punti deboli e i loro problemi, sono stato molto meglio attrezzato per riprogettare il prodotto. E portando gli altri lungo questo processo, l'intero team è stato in grado di comprendere meglio i nostri utenti e soddisfare le loro esigenze. Dopo mesi di duro lavoro e di conversazione con gli utenti, all'inizio di quest'anno abbiamo lanciato con successo una riprogettazione di Crashlytics in Firebase, con una gerarchia delle informazioni migliorata e un aggiornamento visivo, oltre ad alcune nuove funzionalità!

Per concludere, ecco la mia parte preferita della riprogettazione di Crashlytics:

Un'animazione celebrativa quando un utente corregge un bug!