Zavzemanje za celovito prenovo izdelkov

Prepričanje moje ekipe, da preoblikuje Fabric Crashlytics v Firebase

Crashlytics v tkanini (levo), preoblikovano Crashlytics v Firebase (desno)

Pred kratkim sem imel priložnost preoblikovati Crashlytics, orodje za poročanje o zrušitvah, ki pomaga razvijalcem mobilnih aplikacij razumeti, zakaj se njihove aplikacije zrušijo. (Ste se že kdaj srečali z aplikacijo? Crashlytics pomaga razvijalcem, da to odpravijo.)

Moja ekipa se je januarja 2017 pridružila Firebase pri Googlu kot del pridobitve Fabric. Eden od ciljev pridobitve je bil pripeljati Crashlytics v Firebase. To je pomenilo preoblikovanje in prenovo našega izdelka v Firebase, ki uporablja Material Design in ima zelo drugačen sistem vizualnega oblikovanja.

Ker smo morali opraviti vizualno posodobitev Crashlytics-a, sem se odločil, da je to odlična priložnost za ponovno premislek o celotni uporabniški izkušnji in ne le za preučevanje funkcij, kakršne so. Crashlytics je zelo priljubljen izdelek, vendar je od nastanka leta 2011 nabiral veliko oblikovnega dolga. Od mnogih uporabnikov smo slišali, da so imeli težave z uporabo funkcij ali niso mogli najti funkcije, ki smo jo že imeli. Tudi za našo ekipo je bilo težko vedeti, kam naj postavi nove funkcije, ker izdelek ni imel jasne hierarhije informacij - za nas in naše uporabnike. Čas je bil za prenovo.

Najprej sem moral zgraditi svoj primer.

Eno ne preprosto začnemo s prenovo izdelka. Potreben je čas, da razumete uporabnike, kako uporabljajo vaš izdelek in težave, ki jih imajo. Ključnega pomena je, da dobite vse te vpoglede, preden se lotite samega prenove in tako zagotovite, da bo ekipa reševala prave težave in se uskladila s cilji projekta.

1. korak: Spoznajte svoje uporabnike

Začel sem z zbiranjem informacij. Pogovarjal sem se s soigralci iz skupine Crashlytics, ki so izdelek delali več let, z našo ekipo za odnose z razvijalci, raziskovalci uporabnikov in seveda z našimi uporabniki. Moral sem razumeti, zakaj in kako ljudje uporabljajo Crashlytics, preden sem lahko ugotovil, kako izboljšati svojo uporabniško izkušnjo.

Na srečo Jason St. Pierre, moj produktni vodja, je delal Crashlytics več kot 5 let in se pogosto pogovarjal z uporabniki, zato je globoko razumel, kako vrsta ljudi uporablja Crashlytics. Identificiral je 4 najbolj kritična potovanja uporabnikov Crashlytics:

  1. Spremljanje stabilnosti na novo izdane različice aplikacije
  2. Preverjanje stabilnosti aplikacije
  3. Prednostno določite, kateri zruši se lahko odpravi
  4. Odpravljanje težav s stranko
Najbolj kritična pot uporabnika v Crashlytics-u: spremljanje stabilnosti na novo izdane različice aplikacije

Vsako uporabniško potovanje sem pretočil v tokove s pomočjo persona, kar je razkrilo konsistentno mikropotovanje med vsemi štirimi vožnjami: preuči in odpravi tok. Ta potovanja sem delil z ekipo in po potrebi popravil pretoke. Ti tokovi so uskladili ekipo Crashlytics na skupnem, temeljnem razumevanju, kako uporabniki uporabljajo naš izdelek.

Tok „raziskava in odprava“ je ponavljajoči se niz korakov, ki jih uporabnik opravi v vseh 4 naših potovanjih

2. korak: Razumejte njihove bolečinske točke

Ko smo se uskladili s tem, kako ljudje uporabljajo naš izdelek, smo morali razumeti njihove bolečinske točke z obstoječim UX. Ekipa Crashlytics je izjemno sodelovalna in vsi smo vloženi v gradnjo odlične izkušnje za naše uporabnike. Želel sem si, da bi jih vključil v postopek prenove, ki je bolj sodeloval od mene, in sicer z deljenjem konceptov in pridobivanjem povratnih informacij. Skupina je imela na izdelku tudi veliko dragocenega konteksta, ki bi ga bilo koristno uporabiti za prenovo, saj so mnogi na izdelku delali že leta.

Mnogi v skupini Crashlytics so omenili različne vidike armaturne plošče, ki jih je bilo treba izboljšati. Da bi izkoristil njihovo znanje, sem se odločil, da bom izvedel vrsto študij internih uporabnikov. Moj cilj je bil razumeti, kaj so največje boleče točke v uporabniški izkušnji - na podlagi tega, kar smo v preteklih letih slišali od strank.

Natisnil in izrezal sem nadzorno ploščo Crashlytics in s soigralci namestil posamezne seje, kjer sem jih prosil, naj koščke preuredijo in preoblikujejo, da bi glasno razložili svoje razmišljanje.

Soigralci, ki se zabavajo ob preoblikovanju Crashlytics-a z izrezom iz papirjaNekatere od preoblikovanih nadzornih plošč - nekaj ljudi je dodalo tudi nove funkcije s post-svojim

To je bilo izjemno koristno. Ne samo, da je bilo zabavno (kako pogosto se digitalni oblikovalci danes igrajo s pravim papirjem?), Lahko sem videl, kaj je vsaka oseba opredelila kot bolečinske točke, ne da bi jih kdo drug spremenil. To mi je olajšalo določanje ponavljajočih se tem. Na primer, vsaka oseba se je osredotočila na izboljšanje filtrov in izboljšanje hierarhije informacij. Od ekipe za odnose z razvijalci sem izvedel tudi, katere lastnosti je bilo težko uporabiti in najti.

Te izkušnje sem delil z ekipo na tekočem krogu, ki je katalogiziral prizadevanja za prenovo. Z ekipo sem tudi postavil tedenske prijave na oblikovanje, da bi delil posodobitve oblikovanja in jih pripeljal na poti prenove.

Diapozitiv s krova procesa prenove, v katerem so predstavljene ponavljajoče se teme na strani Crashlytics Overview

3. korak: Določite težave z uporabnikom

Z razumevanjem ciljev in bolečin naših uporabnikov so težave z uporabniki postale veliko bolj jasne. Vzela sem vse svoje nauke iz sej izreza iz papirja in pogovorov z uporabniki in skupino, nato pa se zožila na naše primarne težave z uporabniki:

1. težava: uporabniki so težko prišli do informacij, ki so jih res zanimali

Prvo, kar je večina uporabnikov naredila na naši nadzorni plošči, je bilo pomikanje navzdol. Podatki, ki so jih iskali, so nadaljevali navzdol po strani ali pa je bilo potrebnih več klikov. Pokopan je bil za manj pomembnimi lastnostmi.

Stran s podrobnostmi o težavi v Fabric Crashlytics

2. težava: uporabniki niso vedeli, da obstajajo funkcije

Nekoč me je uporabnik vprašal o dodajanju funkcije, da beležim, kaj se je zgodilo v aplikaciji, kar je povzročilo zrušitev. Ta funkcija je že obstajala na naši nadzorni plošči - pravkar je bila zakopana v uporabniškem vmesniku. Naša skupina za podporo je slišala tudi veliko podobnih primerov od uporabnikov. Ta težava je bila tudi odraz težave, s katero se je soočila naša lastna ekipa: težave pri poznavanju funkcij.

Stran s podrobnostmi o sejah v Fabric Crashlytics

Pojavljala se je glavna tematika, da je hierarhija informacij o našem izdelku nejasna, kar sem postavil zainteresiranim stranem kot primarni problem, ki ga moramo rešiti. Ker so bili ves čas del načrtovanja, je bilo enostavno poravnavo in nakup.

Kako se je vse skupaj izšlo

Ekipa je uradno odkupila potrebo po prenovi. Razumeli so težave, ki so jih imeli uporabniki, in se strinjali, kateri deli uporabniške izkušnje potrebujejo izboljšave. Uspeh! Naslednji koraki so bili dejansko preoblikovanje armaturne plošče, kar se je v naslednjih mesecih zgodilo z množico možganskih napadov, sodelovanjem, prijavami in testiranjem uporabnikov.

Izdelava primera za preoblikovanje vključuje veliko nastavitev konteksta. Kot oblikovalcu vam bo morda jasno, da izdelek potrebuje prenovo, vendar sam ne more iti daleč. Preoblikovanje izdelkov je skupinsko prizadevanje, zato je pomembno, da se tim prilagodi, zakaj je preoblikovanje potrebno. Prav tako je nemogoče nekaj preoblikovati, če ne razumete, kako se trenutno uporablja.

Z globokim razumevanjem uporabnikov Crashlytics, njihovih bolečinskih točk in njihovih težav sem bil veliko bolje opremljen za prenovo izdelka. In s pomočjo tega procesa je celotna ekipa lažje razumela naše uporabnike in zadovoljila njihove potrebe. Po mesecih trdega dela in pogovorov z uporabniki smo v letošnjem letu uspešno začeli s prenovo Crashlytics-a v Firebase-u, ki vsebuje izboljšano hierarhijo informacij in vizualno osvežitev, poleg nekaterih novih funkcij!

Za zaključek je tu moj najljubši del prenove Crashlytics:

Praznovalna animacija, ko uporabnik uspešno odpravi napako!