Kształtowanie doświadczenia użytkownika w Zivame: studium przypadku zarządzania produktem

To jest blog gościnny autorstwa Udita Khandelwala.

„Strona jest niesamowita, a sesja była niesamowita! Chciałbym wrócić na kolejną rundę!” – zawołał Deepika wychodząc do domu po przejściu sesji testowania użyteczności w Zivame. Od tego momentu Zivame zawsze miał być pierwszym wyborem dla Deepiki – dumnej gospodyni domowej i przedsiębiorcy.

Co zrobiliśmy, aby wywołać takie surrealistyczne emocje u ludzi, którzy robią u nas zakupy?

Cóż, angażowaliśmy użytkowników na każdym etapie projektowania produktu. W moim artykule Jak zmieniłam sposób, w jaki kobiety kupują biustonosze online, opisałem, w jaki sposób wykorzystaliśmy badania użytkowników, aby odkryć nowy sposób kupowania biustonoszy. Tutaj idę http://notuser.com/how-i-changed-the-way-women-buy-bras-online, aby przeprowadzić Cię przez podróż, w której udało nam się przetestować projekt z prawdziwymi użytkownikami, uzyskaliśmy prawdziwy wgląd i wdrożona korekta kursu.

Plan gry

Wyzwanie
Zasoby były ograniczone, zakres był ogromny i musieliśmy ciągle tworzyć coraz ulepszone projekty.

Dążyć

Cały serwis miał być zaprojektowany i wykonany od podstaw w ciągu 5 miesięcy. Ostatni miesiąc był już zarezerwowany na wszystkie działania związane z testowaniem, wdrażaniem i stabilnością. Nie mieliśmy więc więcej niż 120 dni na zaprojektowanie i opracowanie nowego doświadczenia Zivame. Słyszałem gdzieś to powiedzenie:

Dzisiaj nie ma dróg na skróty; Spieszę się – szwajcarskie powiedzenie

… i pomyślałem, że to właściwy czas, aby to zrobić. Potrzebowaliśmy planu gry, który nie zakładałby skrótów, ponieważ nie mogliśmy sobie pozwolić na zjechanie na złą linię. Dlatego po zakończeniu naszych wczesnych badań postanowiliśmy wykonać następujące czynności:

• Prototypy Lo-Fi: Dopracuj szkice, dopóki nie zakończymy odkrywania luk i nie naprawimy wszystkich uszkodzonych przepływów.
• Testy kształtujące: używaj papierowych prototypów do testowania z kimkolwiek możesz, kiedy tylko możesz, nawet jeśli było to na stole w porze lunchu.
• Prototypy Hi-Fi: Opracuj interaktywny prototyp o wysokiej wierności, możliwie najbardziej zbliżony do produktu końcowego.
• Testy podsumowujące: Przetestuj go z prawdziwymi użytkownikami i uzyskaj prawdziwy wgląd.
• Testy beta: Ostatnia runda testów na samym produkcie, zanim przekazaliśmy go światu.
• Iteracje: Każdy test dostarczał dobrych i złych wiadomości (co było dobrą wiadomością). Musieliśmy traktować priorytetowo naprawianie błędów i wprowadzanie ulepszeń w każdej iteracji.

Lekcja

Testowanie użyteczności to ciągłe działanie, które wymaga odpowiedniego planowania, czasu i zasobów.

Testy kształtujące

Wyzwanie
Początkowy projekt był całkowicie nieprzetestowany i czekały na nas zespoły programistów. Musieliśmy dać im coś solidnego, naprawdę szybko.

Dążyć

Prototypy o niskiej wierności działają pięknie, gdy chcesz szybciej zawieść. Pomagają odkryć wady w projektowaniu na wczesnym etapie, a sami projektanci są bardzo otwarci na wprowadzanie zmian w surowym projekcie. To samo zrobiliśmy w Zivame. Gdy skończyliśmy z białą tablicą, szybko przeszliśmy do naszych narzędzi do tworzenia różnych ekranów na komputerze i wykonaliśmy wydruki, aby utworzyć przepływy ekranów.

A potem po prostu poprosiliśmy kilka osób z biura (którzy ściśle pasowali do naszej docelowej osoby Mahi Agarwal), aby wykonali określone scenariusze. Ilekroć utknęli chociaż na chwilę, wiedzieliśmy, że jest problem. Częściej dawali nam nawet sugestie, na co zwracaliśmy uwagę. Potem wracaliśmy i dyskutowaliśmy, dlaczego użytkownicy sugerowali, kim są, przechodziliśmy do głównej przyczyny problemu i wymyślaliśmy własne rozwiązanie.

Czasami testy nie tylko pokazują, co jest nie tak z projektowaniem, ale także ujawniają nowe możliwości. Na przykład podczas testów formatywnych odkryliśmy, że użytkownicy byli w stanie zrozumieć powiadomienia i wchodzić z nimi w interakcję. Przyjęliśmy to jako zielony sygnał i projekt dla silniejszej, głębszej integracji powiadomień.

Lekcja

Do testów nie czekaj na produkt końcowy; idź naprzód z dowolnym prototypem, na jaki cię stać, i testuj z kimkolwiek, kogo znajdziesz. Porażka szybciej.

Prototypy o wysokiej wierności

Wyzwanie
Witryna miała ponad 300 unikalnych ekranów i stanów ekranów. Stworzenie kliku było gigantycznym zadaniem.

Dążyć

Najpierw ustalamy nasze cele i nie-cele przed zbudowaniem prototypu. Pomogło nam to zredukować zakres prototypowania. np. Chcieliśmy przetestować nową funkcję zakupów według doświadczenia, ale byliśmy prawie pewni, że zastosowaliśmy się do najlepszych praktyk przy kasie, więc postanowiliśmy nie skupiać się na tym przepływie.

Następnie oceniliśmy 3 opcje budowy prototypu:

1. Flash – mój osobisty faworyt, wiem, że brzmię staroświecko!
2. Marvel App – bo wszyscy idą w tę stronę.
3. Invision App – konkurent Marvela.

Teraz Flash został szybko wykluczony z powodu związanych z tym kosztów ogólnych. Marvel trochę zadziałał, ale miał ograniczone wsparcie dla nakładek, a cały mój projekt opierał się na powierzchniach i nakładkach. Invision oferował mi większą elastyczność, więc zdecydowałem się na Invision.

Lekcja

Ustalanie zakresu ma kluczowe znaczenie; nawet na prototyp.

Testy podsumowujące

Wyzwanie
Test musiał zostać zoptymalizowany, aby projekt zakończył się niepowodzeniem.

Dążyć

Postanowiliśmy napisać skrypt, którego będziemy używać podczas sesji testowania użyteczności. Najważniejszym elementem było ustalenie, co dokładnie przetestować i jak. Wypisałem więc swoje cele i nie-cele, na podstawie których ogólnie ustaliłem, co zamierzam przetestować.

1. Wstępny Model Mentalny – Test Oczekiwania
2. Rzeczywiste wykorzystanie — bezpłatny test eksploracyjny
3. Nawigacja – Test wydajności
4. Afordancja – test afordancji wzrokowej
5. Przepływ zadań – test wydajności
6. Sentyment – ​​proces różnicowania semantycznego

Gdy to zrobiłem, szybko przypisałem technikę do każdego elementu zamówienia, a następnie przeszedłem do modułów, na których chciałem się skoncentrować. Następnie przeszedłem do definiowania przepływu zadań poszczególnych scenariuszy. Nie zapisałem języka scenariuszy, ponieważ nie chciałem brzmieć sztywno. Skrypt udostępniłem poniżej na Slideshare.

Lekcja

Użyj młotka do gwoździ, ale śrubokrętu do śrub.

Rekrutacja

Wyzwanie
Znalezienie kobiet (w Indiach), które zgodziłyby się wziąć udział w testowaniu witryny z bielizną.

Dążyć

Chcieliśmy kobiet, które bardzo przypominałyby docelową osobowość Zivame, Mahi Agarwal. Zabraliśmy się do mediów społecznościowych i ogłosiliśmy. Poprosiliśmy kobiety, aby pomogły Zivame w budowaniu wspaniałych zakupów dla kobiet! Zgłosiło się wiele kobiet i otrzymaliśmy wiele odpowiedzi. Nie tylko to, do udziału zaprosili także swoich znajomych. I wyrazy uznania dla myślących przyszłościowo kobiet, takich jak Deepika, Subha i Aastha, które poszły o krok dalej i zgodziły się nadać twarz naszym uczestnikom.

Byliśmy w dobrej sytuacji, by prześwietlać i rekrutować naszych uczestników. Kobiety, które wyraziły zainteresowanie, musiały wypełnić formularz rekrutacyjny uczestników. Po krótkim przeglądzie wybraliśmy uczestników i zadzwoniliśmy do nich, aby umówić się z nimi na sesję.

Lekcja

Znalezienie prawdziwych użytkowników nie jest takie trudne. Po prostu musisz to zrobić we właściwy sposób!

Sugerowane czytanie

Efekt ważki, Jennifer Aaker i Andy Smith

Sesje testów użyteczności

Wyzwanie
Rozmowa z kobietami o stronie internetowej sprzedającej biustonosze.

Dążyć

W D-day byliśmy dobrze przygotowani z ustawionymi systemami, wydrukowanymi kopiami scenariusza, zespół był gotowy do pełnienia swoich ról, a uczestnicy mieli być ciepło przywitani.
Sesje rozpoczęliśmy od sprawienia, by uczestnicy czuli się komfortowo. Zaczęliśmy od kilku pogawędek i krótkiego wprowadzenia. Podkreśliliśmy, jak ważny jest ich wkład i poprosiliśmy, aby nie martwili się o zranienie naszych uczuć i udzielali szczerych informacji zwrotnych. Aby uniknąć udostępniania nam informacji o rozmiarze stanika , powiedzieliśmy im, aby założyli, że mają 34C. Myślę, że spodobał im się ten pomysł. Upewniliśmy się, że uwierzyli:

Nie jesteś testowany, my jesteśmy!
Niezmiennie każdy użytkownik w tym momencie się uśmiechnął, a my wiedzieliśmy, że udało nam się sprawić, by był wygodny. Przez całą sesję upewniliśmy się, że skupiliśmy się na zadaniach (a co za tym idzie na projektowaniu), a nie na produktach. Wtedy zaczęlibyśmy przepływ (jak wspomniano w PPT).

Podczas tych testów odkryliśmy kilka całkiem interesujących rzeczy. Ku naszemu zdziwieniu żaden z użytkowników nie miał problemów ze znalezieniem menu „sklep” , co było dużą zmianą w stosunku do naszego poprzedniego projektu. Jednak użytkownicy byli zdezorientowani, gdy dotarli do podmenu i wiedzieliśmy, że należy je uprościć (co zrobiliśmy później).
Odkryliśmy również podstawowy problem z paskami tytułowymi naszych powierzchni. Użytkownicy mieli trudności z cofaniem się i zamykaniem powierzchni. Ponownie rozwiązaliśmy ten problem w następnej iteracji.

Jedno z kluczowych ustaleń dotyczyło lepkich przycisków na spodzie powierzchni. Zdaliśmy sobie sprawę, że czasami przycisk używany do przerywania przepływu użytkowników, gdy użytkownicy klikali go bez czytania etykiet lub błędnie interpretowali etykiety. Znaleźliśmy alternatywy dla takich sytuacji.
Podsumowując, użytkownicy okazali się bardzo pomocni!

Lekcja

Użytkownicy to ludzie, jeśli dobrze ich potraktujesz, będą bardzo pomocni.

Bash Bash

Wyzwanie
Musieliśmy się upewnić, czy produkt końcowy zachowuje się zgodnie z projektem i przeznaczeniem, a nam się kończyło!

Dążyć

Zawsze istnieje spora różnica między rzeczywistym produktem a wdrożeniem.
Gdy strona internetowa produktu Zivame w wersji beta była gotowa, chcieliśmy się upewnić, że produkt zachowuje się zgodnie z oczekiwaniami. Chcieliśmy sprawdzić, czy użytkownicy czuli się komfortowo wchodząc w interakcję z zaimplementowanymi przez nas kontrolkami interfejsu użytkownika i chcieliśmy, aby działały w prawdziwym świecie.

Otworzyliśmy go więc dla wszystkich pracowników Zivame i przeprowadziliśmy 3-godzinny maraton zgłaszania błędów, który nazwaliśmy Bug Bash. Wydaliśmy kupon, który działał tylko na stronie beta przez 3 godziny, i poprosiliśmy wszystkich pracowników o skorzystanie z kuponu i zapisanie każdego błędu, z którym się spotkali w formularzu Bash Bash.
Podzieliliśmy ich na różne zespoły i ogłosiliśmy nagrody dla 3 najlepszych zespołów. Plan zadziałał i otrzymaliśmy 223 odpowiedzi od różnych zespołów. Przejrzenie całej listy i ustalenie, które z nich są prawdziwe, zajęło nam 2 dni. Większość zgłoszonych błędów to duplikaty lub znane problemy, ale odkryliśmy 12 nowych błędów (z czego 3 dotyczyły interfejsu użytkownika).

Dało nam to dużą pewność, że wydamy wersję beta na zewnątrz!

Lekcja

Testowanie nigdy nie boli i można je przeprowadzić na każdym etapie.
Uznanie dla kobiet, które pomogły nam przez cały czas w budowaniu tak fantastycznych zakupów w Zivame!

Ucz się kursów zarządzania produktami online na najlepszych światowych uniwersytetach. Zdobywaj programy Masters, Executive PGP lub Advanced Certificate Programy, aby przyspieszyć swoją karierę.

Polecany program dla Ciebie: Program certyfikacji Design Thinking od Duke CE