Propagowanie pełnego przeprojektowania produktu

Przekonanie mojego zespołu do przeprojektowania Fabric Crashlytics w Firebase

Crashlytics in Fabric (po lewej), przeprojektowane Crashlytics in Firebase (po prawej)

Niedawno miałem okazję przeprojektować Crashlytics, narzędzie do zgłaszania awarii, które pomaga twórcom aplikacji mobilnych zrozumieć, dlaczego ich aplikacje ulegają awarii. (Czy miałeś kiedyś awarię aplikacji? Crashlytics pomaga programistom to naprawić).

Mój zespół dołączył do Firebase w Google w styczniu 2017 r. W ramach przejęcia Fabric. Jednym z celów przejęcia było doprowadzenie Crashlytics do Firebase. Oznaczało to przeprojektowanie i przebudowę naszego produktu do Firebase, który wykorzystuje Material Design i ma zupełnie inny system wizualny.

Ponieważ musieliśmy dokonać aktualizacji graficznej Crashlytics, zdecydowałem, że to świetna okazja, aby przemyśleć całą wygodę użytkownika, a nie tylko przesuwać funkcje. Crashlytics to ukochany produkt, ale od czasu jego powstania w 2011 r. Narobił wiele długów projektowych. Wielu użytkowników słyszało, że mieli problemy z używaniem funkcji lub nie mogli znaleźć funkcji, którą już mieliśmy. Nasz zespół miał również trudności z ustaleniem, gdzie umieścić nowe funkcje, ponieważ produkt nie miał jasnej hierarchii informacji - dla nas i naszych użytkowników. Nadszedł czas na przeprojektowanie.

Ale najpierw musiałem zbudować swoją sprawę.

Nie wystarczy po prostu przeprojektować produkt. Zrozumienie użytkowników, sposobu, w jaki korzystają z twojego produktu i problemów, jakie mają, zajmuje trochę czasu. Bardzo ważne jest, aby uzyskać wszystkie te spostrzeżenia przed rozpoczęciem samego przeprojektowywania, aby upewnić się, że zespół rozwiązuje właściwe problemy i dostosowuje się do celów projektu.

Krok 1: Zrozum swoich użytkowników

Zacząłem od zebrania informacji. Rozmawiałem z kolegami z zespołu Crashlytics, którzy pracowali nad produktem przez wiele lat, naszym zespołem ds. Relacji z programistami, badaczami użytkowników i oczywiście naszymi użytkownikami. Musiałem zrozumieć, dlaczego i jak ludzie używają Crashlytics, zanim mogłem dowiedzieć się, jak poprawić ich wrażenia z użytkowania.

Na szczęście Jason St. Pierre, mój menedżer produktu, pracował nad Crashlytics od ponad 5 lat i często rozmawiał z użytkownikami, więc miał głębokie zrozumienie tego, jak wiele osób używa Crashlytics. Zidentyfikował 4 najbardziej krytyczne podróże użytkowników Crashlytics:

  1. Monitorowanie stabilności nowo wydanej wersji aplikacji
  2. Sprawdzanie stabilności aplikacji
  3. Priorytetowanie, które awarie naprawić
  4. Debugowanie problemu klienta
Najważniejsza podróż użytkownika w Crashlytics: monitorowanie stabilności nowo wydanej wersji aplikacji

Każdą z tych podróży użytkownika zamapowałem na przepływy, używając osobowości, co ujawniło spójną mikroprzejazd między wszystkimi 4 podróżami: przepływ „zbadaj i napraw”. Udostępniłem te podróże zespołowi i w razie potrzeby poprawiłem przepływy. Przepływy te doprowadziły zespół Crashlytics do wspólnego, fundamentalnego zrozumienia, w jaki sposób użytkownicy korzystają z naszego produktu.

Przebieg „zbadaj i napraw” to cykliczny zestaw kroków, przez które przechodzi użytkownik we wszystkich 4 naszych podróżach użytkowników

Krok 2: Zrozum ich punkty bólu

Po ustaleniu, w jaki sposób ludzie korzystają z naszego produktu, musieliśmy zrozumieć ich problemy z istniejącym UX. Zespół Crashlytics bardzo współpracuje i wszyscy inwestujemy w budowanie wspaniałych wrażeń dla naszych użytkowników. Chciałem sposobu na zaangażowanie ich w proces przeprojektowywania, który byłby bardziej oparty na współpracy, niż dzielenie się pomysłami i uzyskiwanie ich opinii. Zespół miał również wiele cennych kontekstów dotyczących produktu, które byłyby przydatne w celu przebudowy, ponieważ wielu z nich pracowało nad produktem od lat.

Wiele osób z zespołu Crashlytics wspomniało o różnych aspektach deski rozdzielczej, które wymagają ulepszeń. Aby wykorzystać ich wiedzę, postanowiłem przeprowadzić serię wewnętrznych badań użytkowników. Moim celem było zrozumienie, jakie były największe problemy związane z wrażeniami użytkowników - na podstawie tego, co słyszeliśmy od klientów przez lata.

Wydrukowałem i wyciąłem pulpit Crashlytics i zorganizowałem indywidualne sesje z kolegami z drużyny, gdzie poprosiłem ich o zmianę kolejności elementów i przeprojektowanie deski rozdzielczej, głośno rozmawiając, aby wyjaśnić ich sposób myślenia.

Koledzy bawią się przeprojektowując Crashlytics z wycięciami z papieruNiektóre z przeprojektowanych pulpitów nawigacyjnych - kilka osób dodało również nowe funkcje z post-it

To było niezwykle przydatne. Nie tylko było fajnie (jak często projektanci cyfrowi bawią się teraz prawdziwym papierem?), Mogłem zobaczyć, co każda osoba określa jako ból, bez uprzedzeń ze strony innych osób. Ułatwiło mi to identyfikację powtarzających się motywów. Na przykład każda pojedyncza osoba koncentrowała się na ulepszaniu filtrów i ulepszaniu hierarchii informacji. Dowiedziałem się także od zespołu ds. Relacji z programistami, które funkcje były trudne w użyciu i znalezieniu.

Dzieliłem się tymi wnioskami z powrotem w zespole w ciągłej talii, która skatalogowała wysiłek przeprojektowania. Z zespołem założyłem również cotygodniowe kontrole projektu, aby dzielić się aktualizacjami projektu i zabierać je na nowo.

Slajd z przeprojektowanego zestawu procesów opisującego powtarzające się tematy na stronie Przegląd Crashlytics

Krok 3: Zdefiniuj problemy użytkownika

Po zrozumieniu celów i problemów naszych użytkowników problemy użytkowników stały się znacznie wyraźniejsze. Zebrałem wszystkie moje wnioski z sesji wycinania papieru i rozmów z użytkownikami i zespołem, a następnie skupiłem się na naszych głównych problemach z użytkownikami:

Problem 1: Użytkownikom trudno było uzyskać informacje, na których im naprawdę zależało

Pierwszą rzeczą, którą większość użytkowników zrobiła na naszym pulpicie nawigacyjnym, było przewinięcie w dół. Informacje, których szukali, znajdowały się na dole strony lub wymagały wielu kliknięć, aby się do nich dostać. Został pochowany za mniej ważnymi cechami.

Strona szczegółów problemu w Fabric Crashlytics

Problem 2: Użytkownicy nie wiedzieli o istnieniu funkcji

Kiedyś użytkownik poprosił mnie o dodanie funkcji rejestrowania zdarzeń w aplikacji, które doprowadziły do ​​awarii. Ta funkcja istniała już na naszym pulpicie nawigacyjnym - została właśnie pochowana w interfejsie użytkownika. Nasz zespół wsparcia słyszał również o wielu podobnych sprawach od użytkowników. Problem ten odzwierciedlał także problem, przed którym stanął nasz zespół: trudność w określeniu, gdzie umieścić funkcje.

Strona szczegółów sesji w Fabric Crashlytics

Nadrzędnym tematem, który się pojawił, było niejasne, że hierarchia informacji o naszym produkcie jest niejasna, co uznałem za główny problem, który powinniśmy rozwiązać. Ponieważ cały czas byli częścią procesu projektowania, łatwo było je wyrównać i uzyskać wpisowe.

Jak to wszystko ułożyło się

Zespół oficjalnie wykupił się na potrzebę przeprojektowania. Zrozumieli problemy użytkowników i uzgodnili, które elementy doświadczenia użytkownika wymagają ulepszeń. Powodzenie! Kolejne kroki polegały na przeprojektowaniu pulpitu nawigacyjnego, co miało miejsce w ciągu najbliższych kilku miesięcy poprzez wiele burz mózgów, współpracę, meldowanie się i testy użytkowników.

Budowanie argumentu za przeprojektowaniem wymaga mnóstwa kontekstu. Jako projektant może być dla ciebie jasne, że produkt wymaga przeprojektowania, ale nie można iść daleko sam. Przeprojektowanie produktu to wysiłek zespołu i ważne jest, aby zespół ustalił, dlaczego przeprojektowanie jest konieczne. Niemożliwe jest również przeprojektowanie czegoś, jeśli nie rozumiesz, jak to jest obecnie używane.

Dzięki dogłębnemu zrozumieniu użytkowników Crashlytics, ich problemów i problemów, byłem znacznie lepiej przygotowany do przeprojektowania produktu. Dzięki zaangażowaniu innych osób w ten proces cały zespół był w stanie lepiej zrozumieć naszych użytkowników i zaspokoić ich potrzeby. Po miesiącach ciężkiej pracy i rozmów z użytkownikami z powodzeniem wprowadziliśmy przeprojektowanie Crashlytics we Firebase na początku tego roku, oferując ulepszoną hierarchię informacji i odświeżenie wizualne, a także kilka nowych funkcji!

Podsumowując, oto moja ulubiona część przeprojektowania Crashlytics:

Uroczysta animacja, gdy użytkownik skutecznie naprawi błąd!