Toote täieliku ümberkujundamise propageerimine

Minu meeskonna veenmine Firebase Fabric Crashlytics ümber kujundama

Crashlytics kangas (vasakul), ümber kujundatud Crashlytics in Firebase (paremal)

Hiljuti oli mul võimalus ümber kujundada Crashlytics - krahhide teatamise tööriist, mis aitab mobiilirakenduste arendajatel mõista, miks nende rakendused jooksevad. (Kas teil on kunagi olnud rakenduste krahhi? Crashlytics aitab arendajatel seda parandada.)

Minu meeskond liitus Firebase'iga Google'is 2017. aasta jaanuaris Fabrici omandamise käigus. Üks omandamise eesmärke oli viia Crashlytics Firebase'i. See tähendas meie toote ümberkujundamist ja ümberehitamist Firebase'iks, mis kasutab Material Design ja millel on väga erinev visuaalse kujunduse süsteem.

Kuna meil oli vaja teha Crashlytics visuaalse kujunduse värskendus, otsustasin, et see on suurepärane võimalus kogu kasutajakogemuse ümber mõtestada, mitte ainult funktsioonide üle portatiivseks muuta. Crashlytics on hästi armastatud toode, kuid alates selle loomisest 2011. aastal oli sellele kogunenud palju disainivõlgu. Paljudelt kasutajatelt kuulsime, et neil oli funktsioonide kasutamisel raskusi või nad ei suutnud juba leitud funktsiooni leida. Ka meie meeskonnal oli keeruline teada, kuhu uusi funktsioone panna, kuna tootel polnud nii enda kui ka kasutajate jaoks selget teabehierarhiat. Oli aeg ümber kujundada.

Kuid kõigepealt oli mul vaja oma juhtum üles ehitada.

Üks ei hakka lihtsalt toote ümber kujundamist. Kasutajate, teie toote kasutamise ja nende probleemide mõistmine võtab aega. Enne ümberkujunduse alustamist on kriitiline saada kõik need teadmised, et meeskond lahendaks õigeid probleeme ja vastaks projekti eesmärkidele.

1. samm: mõistke oma kasutajaid

Alustasin teabe kogumisega. Rääkisin Crashlyticsi meeskonnakaaslastega, kes olid toote kallal palju aastaid töötanud, meie arendajasuhete meeskonna, kasutajauurijatega ja muidugi ka meie kasutajatega. Enne kui sain aru, kuidas oma kasutajakogemust parandada, pidin aru saama, miks ja kuidas inimesed Crashlyticsit kasutavad.

Õnneks oli minu tootejuht Jason St. Pierre Crashlyticsis töötanud üle 5 aasta ja vestles sageli kasutajatega, nii et tal oli sügav arusaam sellest, kuidas paljud inimesed kasutavad Crashlyticsit. Ta tegi kindlaks 4 kõige kriitilisemat Crashlytics'i kasutajate teekonda:

  1. Äsja välja antud rakenduse versiooni stabiilsuse jälgimine
  2. Rakenduse stabiilsuse kontrollimine
  3. Prioriteetide seadmine, milliseid jookseb parandada
  4. Kliendiprobleemi silumine
Crashlyticsis kõige kriitilisem kasutajareis: värskelt välja antud rakenduse versiooni stabiilsuse jälgimine

Kaardistasin isiksuse abil kõik need kasutaja teekonnad voogudena, mis näitas kõigi 4 teekonna vahelist järjepidevat mikroteekonda: voolu „uurige ja parandage“. Jagasin need teekonnad meeskonnaga ja korrigeerisin vooge vastavalt vajadusele. Need vood viisid Crashlytics meeskonna ühisele aluspõhja mõistmisele, kuidas kasutajad meie toodet kasutavad.

Voog „Uurige ja parandage” on korduv toimingute komplekt, mille kasutaja läbib kõigil neljal meie kasutajareisil

2. samm: mõistke nende valupunkte

Kui olime joondatud selle kohta, kuidas inimesed meie toodet kasutavad, pidime mõistma nende valupunkte olemasoleva UX-iga. Crashlyticsi meeskond on äärmiselt koostööaldis ja me kõik oleme investeerinud oma kasutajatele suurepärase kogemuse loomisse. Tahtsin viisi, kuidas kaasata nad ümberkujundamisprotsessi, mis oleks rohkem koostööaldis kui mina, jagades kontseptsioone ja saades nende tagasisidet. Meeskonnal oli toote kohta ka palju väärtuslikku konteksti, mida oleks kasulik ümber kujundada, kuna paljud neist on toote kallal aastaid töötanud.

Paljud Crashlyticsi meeskonna liikmed mainisid armatuurlaua erinevaid aspekte, mis vajavad täiustamist. Nende teadmiste kasutamiseks otsustasin läbi viia rea ​​sisemisi kasutajauuringuid. Minu eesmärk oli mõista, millised olid kasutajakogemuse suurimad valupunktid - lähtudes sellest, mida me klientidelt aastate jooksul kuulnud oleme.

Trükkisin ja lõikasin välja Crashlytics armatuurlaua ning pidasin meeskonnakaaslastega individuaalsed seansid, kus palusin neil tükid ümber korraldada ja armatuurlaua ümber kujundada, rääkides valjult oma mõtteid selgitada.

Meeskonnakaaslastel on lõbus Crashlytics paberilõikega ümber kujundadaMõned ümberkujundatud armatuurlauad - paar inimest lisasid post-its-iga ka uusi funktsioone

See oli tohutult kasulik. See polnud mitte ainult lõbus (kui sageli saavad digidisainerid tänapäeval päris paberiga mängida?), Vaid sain näha, mida igaüks määratles valupunktidena, ilma et keegi teine ​​seda kallutaks. See hõlbustas mul korduvate teemade tuvastamist. Näiteks keskendus iga inimene filtrite täiustamisele ja teabehierarhia täiustamisele. Samuti õppisin arendajate suhete meeskonnalt, milliseid funktsioone oli keeruline kasutada ja leida.

Jagasin need õppetunnid meeskonnale käimasolevas tekis, kus kataloogiti ümber kujundamise püüdlused. Samuti seadsin meeskonnaga sisse iganädalased disaini registreerimised, et jagada disainiuuendusi ja viia need ümber kujundamise teekonnale.

Slaid ümberehitusprotsessi tekilt, milles tuuakse välja korduvad teemad lehel Crashlytics Ülevaade

3. samm: määratlege kasutaja probleemid

Pärast meie kasutajate eesmärkide ja valupunktide mõistmist said kasutajaprobleemid palju selgemaks. Võtsin kõik õppetükid paberilõikusseanssidest ja vestlustest kasutajate ja meeskonnaga kokku ning tutvustasin seejärel meie peamisi kasutajaprobleeme:

1. probleem: kasutajatel oli keeruline saada teavet, millest nad tegelikult hoolivad

Esimene asi, mida enamik kasutajaid meie armatuurlaual tegi, oli kerimine allapoole. Otsitud teave oli lehel allpool või jõudmiseks oli vaja mitu klõpsu. See maeti vähem oluliste tunnuste taha.

Väljaande üksikasjade leht rakenduses Fabric Crashlytics

2. probleem: kasutajad ei teadnud, et funktsioonid on olemas

Kunagi küsis üks kasutaja minult funktsiooni lisamise kohta, et logida rakenduses juhtunut, mis viis krahhini. See funktsioon oli meie armatuurlaual juba olemas - see maeti lihtsalt kasutajaliidesesse. Meie tugitiim kuulis ka kasutajatelt palju sarnaseid juhtumeid. See probleem peegeldas ka probleemi, millega meie oma meeskond silmitsi seisis: raskusi teadmisega, kuhu funktsioone panna.

Seansi üksikasjade leht Fabric Crashlytics'is

Esilekerkinud teema oli see, et meie toodete teabehierarhia oli ebaselge, mille ma nimetasin sidusrühmadele peamiseks probleemiks, mida peaksime lahendama. Kuna nad olid kogu aja olnud osa projekteerimisprotsessist, oli neid lihtne joondada ja sisseoste teha.

Kuidas see kõik välja töötas

Meeskond ostis ametlikult ümberprojekteerimise vajaduse. Nad mõistsid kasutajate probleeme ja leppisid kokku, milliseid kasutajakogemuse osi on vaja täiustada. Edu! Järgmised sammud olid armatuurlaua tegelik ümberkujundamine, mis juhtus järgmise paari kuu jooksul paljude ajurünnakute, koostöö, registreerimiste ja kasutajatestide abil.

Ümberkujundamise juhtumi loomine hõlmab palju konteksti. Teile kui disainerile võib olla selge, et toode vajab ümberkujundust, kuid üksinda ei jõua kaugele. Toote ümberkujundamine on meeskonna pingutus ja meeskonna jaoks on oluline, et ta mõtleks, miks ümberkujundus on vajalik. Samuti on võimatu midagi ümber kujundada, kui te ei saa aru, kuidas seda praegu kasutatakse.

Crashlytics'i kasutajate, nende valupunktide ja probleemide sügava mõistmise kaudu oli mul toote ümberkujundamine palju parem. Ja tuues teisi selle protsessi kaudu kaasa, sai kogu meeskond meie kasutajaid paremini mõista ja nende vajadusi rahuldada. Pärast kuudepikkust rasket tööd ja kasutajatega rääkimist käivitasime selle aasta alguses Firebase'is Crashlytics ümberkujundamise, mis sisaldab lisaks mõnele uuele funktsioonile täiustatud teabehierarhiat ja visuaalset värskendust!

Kokkuvõtteks võib öelda, et siin on minu lemmik osa Crashlytics'i ümberkujundamisest:

Pidulik animatsioon, kui kasutaja parandab vea edukalt!