Tukee täydellisen tuotteen uudelleensuunnittelua

Suostuttelin ryhmääni suunnittelemaan Fabric Crashlytics Firebasessa uudelleen

Kankaan Crashlytics (vasen), uudelleensuunniteltu Crashlytics in Firebase (oikea)

Minulla oli äskettäin tilaisuus suunnitella uudelleen Crashlytics, onnettomuusraportointityökalu, joka auttaa mobiilisovellusten kehittäjiä ymmärtämään miksi heidän sovelluksensa kaatuu. (Onko sinulla koskaan tapahtunut sovelluksen kaatuminen? Crashlytics auttaa kehittäjiä korjaamaan sen.)

Tiimini liittyi Firebaseen Googlessa tammikuussa 2017 osana Fabric-yrityskauppaa. Yksi yrityskaupan tavoitteista oli tuoda Crashlytics Firebaseen. Tämä tarkoitti tuotteemme uudelleensuunnittelua ja uudelleenrakentamista Firebaseksi, joka käyttää materiaalisuunnittelua ja jolla on hyvin erilainen visuaalinen suunnittelujärjestelmä.

Koska jouduimme tekemään Crashlyticsin visuaalisen suunnittelun päivitys, päätin, että se oli loistava tilaisuus harkita koko käyttökokemusta sen sijaan, että vain siirrettäisiin ominaisuuksia sellaisena kuin se on. Crashlytics on rakastettu tuote, mutta sillä oli kertynyt paljon suunnitteluvelkaa sen perustamisesta lähtien vuonna 2011. Kuulimme monilta käyttäjiltä, ​​että heillä oli vaikeuksia ominaisuuksien käyttämisessä tai he eivät löytäneet jo olemassa olevaa ominaisuutta. Tiimillämme oli myös vaikea tietää, mihin uusia ominaisuuksia voi laittaa, koska tuotteella ei ollut selkeää tietohierarkiaa - itsellemme ja käyttäjillemme. Oli aika suunnitella uudelleen.

Mutta ensin minun piti rakentaa tapaukseni.

Tuotteen suunnittelua ei tarvitse vain aloittaa. Kestää aikaa ymmärtää käyttäjiä, kuinka he käyttävät tuotteitasi ja heidän ongelmiaan. On ensiarvoisen tärkeää saada kaikki nämä käsitykset ennen uuden suunnittelun aloittamista, jotta voidaan varmistaa, että tiimi ratkaisee oikeat ongelmat ja on linjassa projektin tavoitteiden kanssa.

Vaihe 1: Ymmärrä käyttäjät

Aloitin keräämällä tietoja. Puhuin Crashlytics-joukkuetovereiden kanssa, jotka olivat työskennelleet tuotteen parissa vuosien ajan, kehittäjäsuhdetiimimme, käyttäjien tutkijoiden ja tietysti käyttäjien kanssa. Minun piti ymmärtää miksi ja miten ihmiset käyttävät Crashlytics-sovellusta, ennen kuin pystyin selvittämään, kuinka parantaa heidän käyttökokemustaan.

Onneksi tuotepäällikköni Jason St. Pierre oli työskennellyt Crashlyticsissä yli 5 vuotta ja keskustellut usein käyttäjien kanssa, joten hänellä oli syvä käsitys siitä, kuinka monet ihmiset käyttävät Crashlyticsiä. Hän yksilöi 4 kriittistä Crashlytics-käyttäjän matkaa:

  1. Äskettäin julkaistun sovellusversion vakauden seuranta
  2. Sovelluksen vakauden tarkistaminen
  3. Priorisoimalla mikä kaatuminen korjataan
  4. Asiakkaan ongelman vianmääritys
Kriittisin käyttäjän matka Crashlyticsissä: äskettäin julkaistun sovellusversion vakauden seuranta

Kartoitin kaikki nämä käyttäjän matkat virtauksiksi henkilöiden avulla, mikä paljasti yhdenmukaisen mikromatkan kaikkien 4 matkan välillä: tutkia ja korjata -virta. Jaoin nämä matkat ryhmän kanssa ja tarkistin virtauksia tarpeen mukaan. Nämä virrat linjasivat Crashlytics-tiimin jaetun, perustavanlaatuisen käsityksen siitä, kuinka käyttäjät käyttävät tuotteitamme.

Vaihe 2: Ymmärrä heidän kipupisteensä

Kun olimme linjassa sen suhteen, miten ihmiset käyttävät tuotteitamme, meidän piti ymmärtää heidän kipupisteensä olemassa olevan UX: n kanssa. Crashlytics-tiimi on erittäin yhteistyöhaluinen ja me kaikki olemme panostaneet loistavan kokemuksen luomiseen käyttäjillemme. Halusin tapa saada heidät mukaan uudelleensuunnitteluprosessiin, joka oli enemmän yhteistyötä tekevää kuin minä jakoin konsepteja ja saisin heidän palautetta. Tiimillä oli myös paljon arvokasta ympäristöä tuotteesta, josta olisi hyötyä hyötyä uudelleensuunnittelussa, koska monet heistä ovat työskennelleet tuotteen parissa vuosien ajan.

Monet Crashlytics-tiimin ihmiset mainitsivat kojelaudan erilaisia ​​näkökohtia tarvitsevan parannuksia. Hyödyntääkseen heidän tietonsa päätin suorittaa sarjan sisäisiä käyttäjien tutkimuksia. Tavoitteenani oli ymmärtää, mitkä käyttökokemuksen suurimmat kipupisteet olivat - perustuen siihen, mitä olemme kuulleet asiakkailta vuosien varrella.

Tulostin ja leikkasin Crashlytics-kojelaudan ja perustin henkilökohtaisia ​​istuntoja joukkuetovereiden kanssa, joissa pyysin heitä järjestämään kappaleet uudelleen ja suunnittelemaan kojetaulun uudelleen puhumalla ääneen selittämään ajatteluaan.

Joukkuetovereilla on hauskaa suunnitella Crashlytics paperinleikkauksellaJotkut uusituista kojetauluista - muutama ihminen lisäsi myös uusia ominaisuuksia jälkikäteen

Tämä oli erittäin hyödyllistä. Sen lisäksi, että se oli hauskaa (kuinka usein digitaaliset suunnittelijat pääsevät leikkimään oikealla paperilla nykyään?), Pystyin näkemään, mitkä kukin ihminen tunnisti kipupisteiksi ilman, että kukaan muu olisi niiden puolueellinen. Tämän ansiosta toistuvien teemojen tunnistaminen oli helpompaa. Esimerkiksi jokainen henkilö keskittyi suodattimien parantamiseen ja tietohierarkian parantamiseen. Olen myös oppinut kehittäjäsuhdetiimiltä, ​​mitä ominaisuuksia oli vaikea käyttää ja löytää.

Jaoin nämä opinnot takaisin joukkueelle meneillään olevalla kannella, joka luetteloi uudelleensuunnittelupyrkimykset. Olen myös perustanut viikoittain suunnittelutarkistukset ryhmän kanssa jakaakseen suunnittelun päivityksiä ja viedä ne uudelleensuunnittelumatkalle.

Dia uudestaan ​​suunnitteluprosessista, jossa hahmotellaan toistuvia teemoja Crashlytics Overview -sivulla

Vaihe 3: Määritä käyttäjän ongelmat

Kun ymmärrimme käyttäjien tavoitteet ja kipupisteet, käyttäjäongelmat tulivat paljon selkeämmiksi. Otin kaikki oppimiseni paperinleikkausistunnoista ja keskusteluista käyttäjien ja tiimin kanssa, ja kavennin sitten ensisijaisia ​​käyttäjäongelmia:

Ongelma 1: Käyttäjien oli vaikea päästä tietoihin, joista he todella välittivät

Ensimmäinen asia, jonka useimmat käyttäjät tekivät kojetaulullamme, oli vierittäminen alas. He etsivät tietoja olivat sivun alapuolella tai tarvitsivat useita napsautuksia päästäkseen. Se haudattiin vähemmän tärkeiden piirteiden taakse.

Fabric Crashlytics -julkaisun yksityiskohdat -sivu

Ongelma 2: Käyttäjät eivät tienneet ominaisuuksien olemassaoloa

Pyysin kerran käyttäjää minulta ominaisuuden lisäämisestä kirjaamaan tapahtumia, jotka johtivat sovellukseen, joka johti kaatumiseen. Tämä ominaisuus oli jo olemassa kojetaulussa - se vain haudattiin käyttöliittymään. Tukitiimimme kuuli monia vastaavia tapauksia myös käyttäjiltä. Tämä ongelma heijasti myös oman ryhmämme ongelmaa: vaikeuksia tietää, mihin ominaisuuksia saattaa.

Istuntojen yksityiskohdat -sivulla Fabric Crashlytics

Esille noussut teema oli, että tuotteidemme tietohierarkia oli epäselvä, minkä osoitin sidosryhmille ensisijaisena ongelmana, jonka meidän pitäisi ratkaista. Koska ne olivat olleet osa suunnitteluprosessia koko ajan, oli helppo kohdistaa ja saada sisäänosto.

Kuinka kaikki meni loppuun

Joukkue osti virallisesti uudelleen suunnittelun tarpeen. He ymmärsivät käyttäjien ongelmat ja sopivat siitä, mitkä käyttökokemuksen osat vaativat parannuksia. Menestys! Seuraavat vaiheet olivat kojelaudan suunnittelu, joka tapahtui seuraavien kuukausien aikana paljon aivoriihiä, yhteistyötä, kirjautumisia ja käyttäjätestejä.

Uudelleensuunnittelun tapauksen luominen vaatii runsaasti kontekstiasetusta. Suunnittelijana voi olla selvää, että tuote tarvitsee uudelleensuunnittelun, mutta yksin ei voi mennä. Tuotteen uudelleensuunnittelu on joukkueen ponnistelua, ja joukkueelle on tärkeää noudattaa sitä, miksi uudelleensuunnittelu on välttämätöntä. Jotakin on mahdollista suunnitella uudelleen, jos et ymmärrä, miten sitä käytetään tällä hetkellä.

Ymmärtämällä syvästi Crashlytics-käyttäjän, heidän kipupisteensä ja ongelmansa, minulla oli paljon paremmat valmiudet suunnitella tuote uudelleen. Ja tuomalla muut prosessin läpi koko tiimi pystyi ymmärtämään paremmin käyttäjiämme ja vastaamaan heidän tarpeitaan. Kuukausien kovan työn ja käyttäjien kanssa puhumisen jälkeen käynnistimme menestyksekkäästi Crashlyticsin Firebase-suunnittelussa aiemmin tänä vuonna, johon sisältyy parannettu tietohierarkia ja visuaalinen päivitys joidenkin uusien ominaisuuksien lisäksi!

Lopuksi totean, että tässä on suosikki osani Crashlyticsin uudelleensuunnittelusta:

Juhlaanimaatio, kun käyttäjä korjaa virheen onnistuneesti!