Pilnīgas produktu pārveidošanas atbalstīšana

Pārliecināt manu komandu pārveidot Fabric Crashlytics Firebase

Crashlytics audumā (pa kreisi), pārveidots Crashlytics in Firebase (labajā pusē)

Man nesen bija iespēja pārveidot Crashlytics - avāriju ziņošanas rīku, kas palīdz mobilo lietotņu izstrādātājiem saprast, kāpēc viņu lietotnes notiek avārijās. (Vai jums kādreiz ir notikusi lietotnes avārija? Crashlytics palīdz izstrādātājiem to novērst.)

Mana komanda pievienojās Firebase uzņēmumā Google 2017. gada janvārī kā daļu no auduma iegādes. Viens no iegādes mērķiem bija nogādāt Crashlytics Firebase. Tas nozīmēja mūsu produkta pārveidi un pārbūvi Firebase, kurā tiek izmantots Material Design un kurai ir ļoti atšķirīga vizuālā dizaina sistēma.

Tā kā mums bija jāveic Crashlytics vizuālā dizaina atjaunināšana, es nolēmu, ka tā ir lieliska iespēja pārdomāt visu lietotāja pieredzi, nevis tikai pārvietoties pa funkcijām, kā tas ir. Crashlytics ir ļoti iecienīts produkts, taču kopš tā izveidošanas 2011. gadā bija uzkrājies daudz dizaina parādu. No daudziem lietotājiem mēs dzirdējām, ka viņiem ir grūti izmantot funkcijas vai viņi nevarēja atrast funkciju, kas mums jau bija. Arī mūsu komandai bija grūti uzzināt, kur likt jaunas funkcijas, jo izstrādājumam nebija skaidras informācijas hierarhijas - gan mums pašiem, gan lietotājiem. Bija laiks pārveidot.

Bet vispirms man vajadzēja izveidot savu lietu.

Nevajag vienkārši sākt pārveidot produktu. Nepieciešams laiks, lai saprastu lietotājus, kā viņi izmanto jūsu produktu, un viņu problēmas. Pirms uzsākt pārveidošanu, ir svarīgi iegūt visas šīs atziņas, lai pārliecinātos, ka komanda risina pareizās problēmas un pieskaņojas projekta mērķiem.

1. darbība. Izprotiet savus lietotājus

Es sāku ar informācijas vākšanu. Es runāju ar Crashlytics komandas biedriem, kuri daudzus gadus strādāja pie produkta, ar mūsu izstrādātāju attiecību komandu, lietotāju pētniekiem un, protams, ar mūsu lietotājiem. Man vajadzēja saprast, kāpēc un kā cilvēki izmanto Crashlytics, pirms es varēju izdomāt, kā uzlabot viņu lietotāja pieredzi.

Par laimi Jason St. Pierre, mans produktu menedžeris, bija strādājis Crashlytics vairāk nekā 5 gadus un bieži runāja ar lietotājiem, tāpēc viņam bija dziļa izpratne par to, kā Crashlytics izmanto daudzi cilvēki. Viņš identificēja četrus kritiskos Crashlytics lietotāju braucienus:

  1. Nesen izlaistas lietotnes versijas stabilitātes uzraudzība
  2. Lietotnes stabilitātes pārbaude
  3. Prioritātes noteikšana, kuras avārijas jālabo
  4. Klienta problēmas atkļūdošana
Kritiskākais lietotāja ceļojums vietnē Crashlytics: nesen izlaistas lietotnes versijas stabilitātes uzraudzība

Katru no šiem lietotāju braucieniem es sastādīju plūsmās, izmantojot personas, kas atklāja konsekventu mikrotransportu starp visiem 4 braucieniem: “izpētīt un labot” plūsmu. Es dalījos šajos braucienos ar komandu un pēc vajadzības pārskatīju plūsmas. Šīs plūsmas pieskaņoja Crashlytics komandu kopējai, pamatotai izpratnei par to, kā lietotāji izmanto mūsu produktu.

Plūsma “Izmeklēt un labot” ir atkārtots darbību kopums, kuru lietotājs iziet visos 4 mūsu lietotāja braucienos

2. solis: izprotiet viņu sāpju punktus

Kad vienojāmies par to, kā cilvēki izmanto mūsu produktu, mums bija jāsaprot viņu sāpju punkti ar esošo UX. Crashlytics komanda sadarbojas ļoti intensīvi, un mēs visi esam ieguldīti lielas pieredzes veidošanā mūsu lietotājiem. Es gribēju veidu, kā iesaistīt viņus pārveidošanas procesā, kas bija vairāk sadarbojies, nekā es dalījos ar koncepcijām un ieguvu viņu atsauksmes. Komandai bija arī daudz vērtīga konteksta attiecībā uz produktu, ko būtu noderīgi izmantot, lai pārveidotu dizainu, jo daudzi no viņiem gadiem ilgi strādā pie šī produkta.

Daudzi cilvēki no Crashlytics komandas pieminēja dažādus paneļa aspektus, kuriem nepieciešami uzlabojumi. Lai izmantotu viņu zināšanas, es nolēmu veikt virkni iekšējo lietotāju pētījumu. Mans mērķis bija saprast, kādi ir lielākie sāpju punkti lietotāju pieredzē, balstoties uz to, ko gadu gaitā esam dzirdējuši no klientiem.

Es izdrukāju un izgriezu Crashlytics informācijas paneli un izveidoju individuālas sesijas ar komandas biedriem, kur es viņiem palūdzu pārkārtot gabalus un pārveidot informācijas paneli, skaļi runājot, lai izskaidrotu viņu domāšanu.

Komandas biedriem jautri pārveidojot Crashlytics ar papīra izgriezumiemDaži no pārveidotajiem paneļiem - daži cilvēki arī pievienoja jaunas funkcijas ar post-its

Tas bija ārkārtīgi noderīgi. Tas bija ne tikai jautri (cik bieži mūsdienās digitālie dizaineri spēlējas ar īstu papīru?), Bet es varēju redzēt, ko katrs cilvēks identificē kā sāpju punktus, bez neviena cita aizspriedumiem. Tas man ļāva identificēt atkārtotās tēmas. Piemēram, katrs cilvēks koncentrējās uz filtru uzlabošanu un informācijas hierarhijas uzlabošanu. No attīstītāju attiecību komandas es arī uzzināju, kuras funkcijas bija grūti izmantot un atrast.

Es dalījos šajās mācībās ar komandu pastāvīgajā klājā, kas kataloģizēja pārveidošanas centienus. Es arī katru nedēļu izveidoju dizaina reģistrēšanos ar komandu, lai dalītos ar dizaina atjauninājumiem un ņemtu tos līdzi pārveidošanas ceļojumā.

Slaids no pārveidošanas procesa klāja, kurā aprakstītas atkārtotas tēmas lapā Crashlytics Overview

3. solis: definējiet lietotāja problēmas

Pēc mūsu lietotāju mērķu un sāpju punktu izpratnes lietotāju problēmas kļuva daudz skaidrākas. Es izmantoju visas savas zināšanas no papīra izgriešanas sesijām un sarunām ar lietotājiem un komandu, pēc tam pievēršoties mūsu galvenajām lietotāju problēmām:

1. problēma: lietotājiem bija grūti iegūt informāciju, kas viņiem patiešām rūp

Pirmais, ko vairums lietotāju izdarīja mūsu informācijas panelī, bija ritināšana uz leju. Viņu meklētā informācija atradās tālāk lapā vai, lai nokļūtu, vajadzēja vairākus klikšķus. Tas tika apglabāts aiz mazāk svarīgām iezīmēm.

Izdevuma informācijas lapa vietnē Fabric Crashlytics

2. problēma: lietotāji nezināja, ka pastāv funkcijas

Reiz man kāds lietotājs pajautāja par funkcijas pievienošanu, lai reģistrētu lietotnē notikušo, izraisot avāriju. Šī funkcija jau pastāvēja mūsu informācijas panelī - tā vienkārši tika apglabāta lietotāja saskarnē. Mūsu atbalsta komanda dzirdēja daudzus līdzīgus gadījumus arī no lietotājiem. Šī problēma atspoguļoja arī problēmu, ar kuru saskārās mūsu pašu komanda: grūtības zināt, kur ievietot funkcijas.

Fabric Crashlytics sesiju informācijas lapa

Visaptverošā tēma, kas parādījās, bija tāda, ka mūsu produkta informācijas hierarhija nebija skaidra, un es to norādīju ieinteresētajām personām kā galveno problēmu, kas mums būtu jāatrisina. Tā kā viņi visu laiku bija iesaistīti projektēšanas procesā, tos bija viegli izlīdzināt un saņemt pirkumu.

Kā tas viss noritēja

Komanda oficiāli pieteicās, lai būtu nepieciešams pārveidot dizainu. Viņi saprata lietotāju problēmas un vienojās, kurās lietotāju pieredzes daļās nepieciešami uzlabojumi. Panākumi! Nākamās darbības bija faktiski pārveidot informācijas paneli, kas notika dažu nākamo mēnešu laikā, izmantojot daudz ideju, sadarbības, reģistrēšanās un lietotāju pārbaudes.

Plānojot pārprojektēšanu, ir nepieciešams ļoti daudz konteksta iestatījumu. Jums kā dizainerim var būt skaidrs, ka izstrādājums ir jāpārveido, bet viens pats nevar sasniegt tālu. Produkta pārprojektēšana ir komandas centieni, un komandai ir svarīgi pieskaņoties, kāpēc ir nepieciešams pārprojektēšana. Nevar arī kaut ko pārveidot, ja nesaprotat, kā tas pašlaik tiek izmantots.

Dziļi izprotot Crashlytics lietotājus, viņu sāpju punktus un problēmas, es biju daudz labāk sagatavots, lai pārveidotu produktu. Un, iesaistot citus šajā procesā, visa komanda varēja labāk izprast mūsu lietotājus un apmierināt viņu vajadzības. Pēc vairāku mēnešu smaga darba un sarunām ar lietotājiem, šī gada sākumā mēs veiksmīgi uzsācām Crashlytics pārveidi Firebase, piedāvājot uzlabotu informācijas hierarhiju un vizuālu atsvaidzināšanu papildus dažām jaunām funkcijām!

Noslēgumā jāsaka, ka šeit ir mana iecienītākā Crashlytics pārveidošanas daļa:

Svinīga animācija, kad lietotājs veiksmīgi izlabo kļūdu.