Case Studies

Jak przeprowadzić testy użyteczności?

Dla klienta tworzącego aplikację sprzedawaną w modelu SaaS przeprowadziliśmy moderowane testy użyteczności. Chcieliśmy sprawdzić, w jaki sposób użytkownicy poruszają się po narzędziu. Wszystko po to, by usprawnić działanie produktu, zwiększyć liczbę powracających do niego użytkowników i poprawić jakość ich doświadczenia, a tym samym podnieść sprzedaż.

Z tego case study dowiesz się:

  • z czego powinien składać się plan badawczy?
  • jak przygotować się do moderowanych zadaniowych testów użyteczności?
  • na jakie pułapki zwracać uwagę?
Klient:
startup tworzący produkt SaaS
Cel:
znalezienie i usprawnienie słabych punktów w ścieżce użytkownika w narzędziu
Okres współpracy
2021
Liczba sprintów
3
Liczba osób w projekcie
3

Tło projektu


Czym są testy użyteczności?

Nim opowiemy o tym, jak podeszliśmy do tego procesu, z jakich narzędzi korzystaliśmy oraz na jakie wyzwania trafiliśmy, warto napisać co nieco o tym, czym właściwie są badania użyteczności

Testy użyteczności są metodą badań User Experience, dzięki której możemy ocenić produkt, testując go z obecnymi lub przyszłymi użytkownikami. Dzięki temu zdobywamy informacje o tym, jak użytkownicy korzystają z narzędzia, co jest dla nich intuicyjne, co nie, jakie mają przyzwyczajenia itd.

Nie tylko znajdujemy błędy w interfejsie czy flow działania naszego produktu, ale też dowiadujemy się, w jaki sposób możemy usprawnić narzędzie. Testy użyteczności mogą dotyczyć różnego rodzaju produktów i są do nich indywidualnie dopasowywane. Możemy testować zarówno aplikacje mobilne, jak i przedmioty fizyczne lub konkretne usługi niemające odzwierciedlenia w jednej aplikacji.

O różnych rodzajach testów użyteczności, dobrych praktykach i pułapkach, na które warto uważać, badając produkty, opowiadała również Agnieszka Zygmunt, UX Researcherka w Project: People. Zajrzyj do jej prezentacji:

Testy użyteczności były kolejnym z etapów beta testów, które przeprowadzaliśmy dla tego klienta. Po tym, jak zderzyliśmy produkt z grupą wczesnych użytkowników w pierwszych działaniach beta testów, gdzie zebraliśmy informacje o ich wrażeniach, okazało się, że jest kilka ważnych pytań, na które nie znamy odpowiedzi. Były to:

  • Dlaczego (i gdzie dokładnie) użytkownicy gubią się w narzędziu?
  • Dlaczego użytkownicy są zainteresowani unikalną propozycją wartości produktu, ale nie widzą jej w jego obecnym kształcie? Co musiałoby się stać, by ich zdaniem produkt przystawał do propozycji wartości już teraz?
  • Dlaczego użytkownicy chętnie korzystają z aplikacji po raz pierwszy, ale potem już do niej nie wracają?

Chcieliśmy zdobyć tę wiedzę, a także pogłębić ją o dodatkowe informacje na temat przyzwyczajeń użytkowników. Dlatego zdecydowaliśmy się na dodatkowe badania. Były nimi właśnie testy użyteczności.

 

Czym są testy użyteczności?

Nim opowiemy o tym, jak podeszliśmy do tego procesu, z jakich narzędzi korzystaliśmy oraz na jakie wyzwania trafiliśmy, warto napisać co nieco o tym, czym właściwie są badania użyteczności

Testy użyteczności są metodą badań User Experience, dzięki której możemy ocenić produkt, testując go z obecnymi lub przyszłymi użytkownikami. Dzięki temu zdobywamy informacje o tym, jak użytkownicy korzystają z narzędzia, co jest dla nich intuicyjne, co nie, jakie mają przyzwyczajenia itd.

Nie tylko znajdujemy błędy w interfejsie czy flow działania naszego produktu, ale też dowiadujemy się, w jaki sposób możemy usprawnić narzędzie. Testy użyteczności mogą dotyczyć różnego rodzaju produktów i są do nich indywidualnie dopasowywane. Możemy testować zarówno aplikacje mobilne, jak i przedmioty fizyczne lub konkretne usługi niemające odzwierciedlenia w jednej aplikacji.

O różnych rodzajach testów użyteczności, dobrych praktykach i pułapkach, na które warto uważać, badając produkty, opowiadała również Agnieszka Zygmunt, UX Researcherka w Project: People. Zajrzyj do jej prezentacji:

2-badania-uzytecznosci-aga

Sprint 1: Scenariusz i przygotowanie do badań, rekrutacja

Najbardziej wymagającym krokiem tego projektu był dla nas etap konceptualizacji badań. Jest takie powiedzenie odnoszące się do badań: „garbage in, garbage out”. Odnosi się ono do tego, że jeśli wprowadzimy do badania niewłaściwe osoby, dane, będziemy mieli również niewłaściwe, „śmieciowe” wnioski. Dlatego gruntowne przemyślenie celów badań, pytań, na które chcemy znaleźć odpowiedzi, przygotowanie planu badawczego i scenariusza jest tak ważne.


Konceptualizacja badań, prace nad planem badawczym

Zaczęliśmy od ustalenia celów badań użyteczności. Były to:

  • zdefiniowanie czynników, które wpływają na chęć lub brak chęci korzystania z narzędzia albo polecania go dalej,
  • pogłębienie feedbacku uzyskanego w toku wcześniejszych działań z zakresu beta testów,
  • zlokalizowanie punktów we flow użytkownika, które wymagają usprawnienia.

Pytania i hipotezy badawcze wyprowadzaliśmy na podstawie uzyskanego do tej pory w beta testach feedbacku. 

Było ich naprawdę sporo, dlatego potrzebowaliśmy narzędzia, które pomoże nam wyznaczyć priorytety – w końcu na badania mieliśmy tylko 3 tygodnie. Sięgnęliśmy po Experiment Sprint Canvas, a zwłaszcza po będącą jego częścią matrycę priorytetyzacji hipotez ważne – nieważne / wiem – nie wiem.

 

 

Umieściliśmy na niej nasze hipotezy, a podstawą do badań stały się te, które znalazły się najbliżej ćwiartki nie wiem – ważne (czyli takie, które najbardziej odpowiadają celom naszego badania).

 

Matryca hipotez i pytań

Mapując hipotezy do zbadania, uwzględniliśmy również perspektywę klienta. Podczas wspólnych i zdalnych warsztatów na Miro przeszliśmy przez obszary, które chciałby zbadać, a następnie zamieściliśmy je na matrycy hipotez. Ostatecznie nie byliśmy w stanie zwalidować wszystkich, jednak bardzo ważne jest, że omówiliśmy ich wpływ na projekt oraz uargumentowaliśmy, dlaczego nie są najważniejszymi obszarami do sprawdzenia.

Kolejnym krokiem było dopasowanie metod badawczych do pytań. Chcieliśmy ustalić, co w jaki sposób możemy zbadać. Ostatecznie zdecydowaliśmy się na moderowane zadaniowe testy użyteczności z elementami wywiadu pogłębionego.

Dlaczego? Pytania, na które chcieliśmy znaleźć odpowiedź, wymagały podejrzenia tego, jak użytkownicy zachowują się w narzędziu. Ze względów na wymagania polityki prywatności klienta nie było możliwe skorzystanie z narzędzi śledzących i rejestrujących nagrania sesji jak Hotjar czy cux.io. Dodatkowo same nagrania sesji nie pozwoliłyby nam na uzyskanie tego, na czym nam zależało – pogłębionej odpowiedzi na pytanie, dlaczego użytkownicy wykonują konkretne kroki, czego nie rozumieją i tak dalej. A ponieważ mieliśmy łatwy dostęp do przedstawicieli grupy docelowej, zadaniowe testy użyteczności były dobrym rozwiązaniem.

 

Matryca, na której podzieliliśmy pytania i hipotezy na rodzaje badań

Pytania na matrycy hipotez odnoszące się do podobnych obszarów układaliśmy obok siebie, tak by móc zagospodarować je tą są grupą zadań lub pytań. Ostatecznie przygotowaliśmy 5 zadań. Każde miało określony cel, odnosiło się do konkretnego pytania badawczego, niektóre zadania miały dodatkowo warianty A i B. Było ich dość dużo, jak na 45-minutowe spotkanie, które planowaliśmy. O tym, jak to rozwiązaliśmy, piszemy dalej.

Na plan badawczy, którzy przedstawiliśmy klientowi, poza celami badań, pytaniami badawczymi i hipotezami, składały się m.in.:

  • opis metody badawczej wraz z uzasadnieniem wyboru,
  • szczegółowe informacje oraz materiały dotyczące grupy docelowej,
  • informacje o tym, w jakiej formie zostaną przedstawione wyniki;
  • inne niezbędne informacje prawne.

Załącznikami do planu badawczego były uprzednio zaakceptowana przez klienta matryca hipotez i scenariusz badań. W tym ostatnim opisaliśmy dokładnie planowane spotkanie z uczestnikami badania. Zawarliśmy w planie:

informacje o formalnościach takich jak nagrywanie, protokół głośnego myślenia (prosimy uczestników, by głośno mówili o wszystkim, co ich zastanawia, by pamiętali, że nie ma ani dobrych, ani złych odpowiedzi, że testujemy narzędzie, nie ich wiedzę), 

rozgrzewkę – pytania wstępne, dzięki którym z jednej strony pomagamy uczestnikowi się rozluźnić, a z drugiej skupić na spotkaniu; dodatkowo już na tym etapie pozyskujemy nierzadko ważne informacje na jego temat,

  • dwa zestawy zadań wraz z wariantami i dodatkowymi pytaniami – co ważne, wyróżniliśmy dwie grupy badanych – tych, którzy z narzędzia korzystali po raz pierwszy, oraz tych, którzy już je znali; grupy te były dla siebie nawzajem grupami kontrolnymi i dzięki nim mogliśmy m.in. ocenić, czy spostrzeżenia, które pojawiają się u nowych użytkowników, zmieniają się wraz z lepszym poznaniem narzędzia,
  • pytania zamykające – dzięki którym możemy rozładować ewentualne emocje, wątpliwości powstałe u badanego w czasie spotkania, a także zdobyć kolejne informacje na temat jego przyzwyczajeń, preferencji.

Dlaczego przygotowaliśmy tak szczegółowe dokumenty? Przede wszystkim dzięki nim jasno określamy wszystkie cele badań oraz ich formę. Takie jasne opisanie procesu jest z jednej strony podstawą działań badaczy, którzy w razie wątpliwości mogą np. sprawdzić, czy dodatkowe działanie, które chcą podjąć, pomaga osiągnąć cel badań. Dzięki temu nie poświęcamy czasu na działania, które nie przybliżają nas do celu. Z drugiej strony taka dokumentacja pomaga klientowi zrozumieć, jak będą przebiegały badania, oraz co będzie ich wynikiem, a co nie.


Przygotowanie narzędzi

Kolejnym etapem przygotowania do testów użyteczności było opracowanie arkusza odpowiedzi w narzędziach Google. W trakcie spotkań z badanymi i po nich notowaliśmy w tym arkuszu spostrzeżenia po spotkaniach. Zawczasu uporządkowana struktura arkusza miała przyspieszyć późniejszą analizę materiałów z badań.

 

Arkusz odpowiedzi

Przygotowaliśmy też na Miro matrycę wniosków, którą potem wykorzystaliśmy do dyskusji i zderzenia spostrzeżeń między badaczami.

Matryca wniosków na Miro


Rekrutacja

Następnym krokiem była rekrutacja uczestników badań. To zazwyczaj najbardziej czasochłonny etap przygotowania do badań. Potrzebowaliśmy 16 osób – 8, które jeszcze nie korzystały z narzędzia i pasują do grupy docelowej, i 8, które narzędzie znają. Rekrutację do badań użyteczności zaczęliśmy od kontaktu z dotychczasowymi użytkownikami narzędzia. Wykorzystaliśmy też tematyczne grupy na Facebooku, gdzie znajdowaliśmy nowych użytkowników pasujących do profilu badanego. Wykorzystaliśmy również metodę kuli śniegowej, czyli pytaliśmy zrekrutowane osoby, czy znają kogoś, kto pasuje do profilu badanego.

Ostatecznie celowo umówiliśmy się z większą liczbą osób niż 16 – zakładaliśmy, że część może odwołać spotkania, i tak się rzeczywiście stało. My na szczęście byliśmy zabezpieczeni.

Planując spotkania, staraliśmy się nie umawiać więcej niż 3-4 spotkania dziennie (każde po około 45-60 minut) i zachowywać między nimi przerwy na spisywanie notatek.

Dopinaliśmy też niezbędne formalności: wysyłaliśmy do badanych maile z zaproszeniem i linkami do spotkania, informacje o nagrywaniu i prośbę o zgodę. Aby umówione osoby na pewno pojawiły się na spotkaniu, wysyłaliśmy im wiadomości przypominające – dzień przed spotkaniem i w jego dniu.


Testy nagrywania i dry testy

Czy po tych krokach mogliśmy już zacząć nasze testy? Jeszcze nie 🙂 Zanim przystąpimy do badań, musimy… zbadać same narzędzia badawcze, tak by upewnić się, że wszystko działa i jest zrozumiałe dla użytkowników.

Zaczęliśmy od testów nagrywania. Ponieważ badania odbywały się zdalnie, zachowanie użytkowników w aplikacji mieliśmy śledzić dzięki temu, że udostępnią nam ekran. Taki ekran musieliśmy nagrywać po to, by później móc wrócić do materiału i analizować akcje użytkowników. Potrzebowaliśmy więc narzędzia do wideokonferencji, które pozwoli na łatwe udostępnianie ekranu, nagrywanie obrazu oraz dźwięku. Wybraliśmy Zoom. Nim umówiliśmy się z użytkownikami na dry testy, w gronie badaczy przeprowadziliśmy testy połączenia i nagrywania. Chcieliśmy się upewnić. że zestaw narzędzi, który wybraliśmy, pomoże nam w przygotowaniu dobrej dokumentacji badań.

A czym są wspomniane dry testy? To próba generalna samego badania, nazywana również testami pilotażowymi. Nie służy jednak zebraniu wniosków na temat testowanego produktu. Chodzi tutaj o sprawdzenie z użytkownikami z grupy docelowej, czy zaprojektowane badanie i przygotowane zadania są dla nich wykonalne w zaplanowanym czasie, czy polecenia zostały zrozumiale sformułowane. Przeprowadziliśmy 2 takie testy – jeden z osobą, która nie znała narzędzia, a drugi z osobą z grupy kontrolnej.

Okazało się, że zaplanowaliśmy za dużo zadań jak na 45-60-minutowe spotkanie. Dlatego podjęliśmy decyzję o przeredagowaniu scenariusza i zastanowiliśmy się, z których zadań możemy zrezygnować bez szkody dla celu badania.

Po ponownym zatwierdzeniu scenariusza z klientem mogliśmy przejść do właściwych testów użyteczności.

Sprint 2: Moderowane zadaniowe testy użyteczności


Podział pracy między badaczami

W ciągu jednego tygodnia przeprowadziliśmy 16 testów, gdzie każdy trwał około godziny. Zespół składał się z 2 badaczy, spotkania prowadziliśmy indywidualnie, bez udziału obserwatorów. Podzieliliśmy się następująco: jedna osoba zajęła się spotkaniami z użytkownikami, którzy do tej pory nie znali narzędzia, a druga – tymi, którzy produkt już znali. Dzięki temu mogliśmy zderzać ze sobą cząstkowe spostrzeżenia i wspólnie wyciągać wnioski, by potem konstruować odpowiedzi na pytania postawione w planie badawczym.


Notatki

Sporządzaliśmy je zarówno w trakcie badania, jak i bezpośrednio po nim oraz na koniec każdej z serii badań danego dnia. Dzięki temu mieliśmy pewność, że zebraliśmy jak najwięcej świeżych wrażeń.

Co ciekawe, jedno z badaczy wolało notatki na papierze, przenoszone następnie na arkusz odpowiedzi, drugie – cyfrowe, od razu wprowadzane w arkuszu. Ostateczne ważne jest, by wybrać taki sposób notowania, jaki z jednej strony pozwala badaczowi na jak najdokładniejsze zebranie materiału, a z drugiej jest dla niego wygodny.


Wyzwania i dobre praktyki

W czasie badań nie obyło się bez wyzwań. Były nimi m.in. problemy techniczne – np. zerwane łącze internetowe. Zorientowaliśmy się także, że u niektórych użytkowników elementy interfejsu narzędzia wykorzystywanego do wideorozmowy zasłaniają elementy interfejsu narzędzia – musieliśmy na gorąco zmodyfikować część zadania, a następnie w czasie analizy materiałów brać tę sytuację pod uwagę.

Musieliśmy też być bardzo uważni, jeśli chodzi o rozmowy z użytkownikami – pozwalać na ciszę po zadaniu pytania i dłuższe zastanowienie. Często bywa to trudne, bo w codziennych rozmowach mamy tendencje do przeformułowywania pytań, dopowiadania, jeśli słyszymy po nich ciszę. Tymczasem w testach takie powtarzanie pytania może wybić z rytmu badanego. Ważna była również uważność na błędy poznawcze, takie jak np. podświadome nadawanie większej wartości słowom badanego, który jest w jakiś sposób do nas podobny.

Aby uniknąć podbramkowych sytuacji, po każdym spotkaniu sprawdzaliśmy, czy nagranie dźwięku i obrazu się powiodło. Gdyby tak się nie stało, jedynym rozwiązaniem byłoby dla nas szybkie zapisanie tylu obserwacji z badania, ile udało się zapamiętać.

Dodatkowo modyfikowaliśmy leanowo scenariusz rozmowy wstępnej i domykającej, jeśli zauważaliśmy, że warto jeszcze o coś dopytać.


Co moglibyśmy zrobić lepiej następnym razem?

Tym razem nie korzystaliśmy z Calendly, by umawiać spotkania, co sprawiło, że zarządzanie nimi zajmowało nam nieco więcej czasu. W efekcie mieliśmy też bardzo duże przerwy między spotkaniami, spora część z nich odbywała się w późnych godzinach wieczornych (dostosowaliśmy się do dyspozycyjności badanych). Ten projekt nauczył nas, że warto automatyzować taki proces jak umawianie spotkań, a także przedstawić rekrutowanym zakres dostępnych terminów dopasowany do nas, badaczy.

Sprint 3: Analiza i synteza wyników


Indywidualna analiza

Zaczęliśmy od indywidualnej analizy po stronie każdego z badaczy. Każde z nas miało notatki sporządzone w trakcie badań, podsumowania po seriach spotkań. Uzupełniliśmy je o wnioski z ponownego obejrzenia nagrań. Co bardzo ważne, nie przygotowywaliśmy w tym procesie badawczym pełnej transkrypcji spotkań – ze względu na ograniczony czas. 


Warsztaty i priorytetyzacja wniosków

Kolejnym krokiem było zderzenie i omówienie wyników między badaczami w czasie warsztatu, który tradycyjnie przeprowadziliśmy na Miro. Zaprezentowaliśmy sobie wzajemnie zebrane spostrzeżenia, cytaty od użytkowników itd. Wzajemna walidacja pomogła nam uniknąć błędów poznawczych.

Taki warsztat przeprowadziliśmy dwukrotnie. Kiedy zamknęliśmy listę wniosków, priorytetyzowaliśmy je, zadając sobie pytanie, w jakim stopniu dana obserwacja może przybliżyć zespół produktowy klienta do poprawy doświadczenia użytkownika. Podzieliliśmy wnioski na 3 poziomy:

  1. czerwony – wysoki priorytet,
  2. żółty – średni priorytet,
  3. zielony – niski priorytet.

Tego kodu kolorystycznego trzymaliśmy się w późniejszej prezentacji dla klienta.


Prezentacja dla klienta

Ponieważ badania były wykonywane w przyspieszonym trybie, nie podsumowywaliśmy ich pełnym raportem, a spotkaniem z klientem i prezentacją. Przedstawiliśmy wnioski wysokopoziomowe dotyczące odbioru narzędzia wśród żytkowników, a także niskopoziomowe dotyczące interakcji z poszczególnymi funkcjami produktu. W prezentacji zawarliśmy zanonimizowane cytaty uczestników badań oraz screeny (również zanonimizowane) z nagrań sesji. 

Wnioski i dalsze kroki po testach użyteczności


Moderowane zadaniowe testy użyteczności
, które przeprowadziliśmy, pozwoliły nam znaleźć słabe punkty ścieżki użytkownika w narzędziu. Dzięki temu wskazaliśmy zespołowi produktowe mu klienta problemy, które najbardziej wpływają na chęć użytkowników do ponownego skorzystania z narzędzia.

Ponieważ w perspektywie długofalowej zespół Project: People odpowiadał nie tylko za testy użyteczności tego produktu, ale też marketingowe i eksploracyjne wsparcie jego rozwoju, przygotowaliśmy też rekomendacje dotyczące działań, które zespół produktowy klienta mógłby podjąć po tym etapie.

 


Schemat możliwych do podjęcia działań

W trakcie badań ustaliliśmy też, że od momentu zakończenia badań eksploracyjnych do momentu wprowadzenia produktu do fazy testów na rynku pojawiły się rozwiązania konkurencyjne, po które użytkownicy sięgają chętniej. Z tego powodu jedną z naszych rekomendacji był pivot w zakresie grupy docelowej. Ale o tym procesie opowiemy już w innym case study.

Projekt w liczbach

2

badaczy

2

dry testy

16

zadaniowych testów użyteczności

Narzędzia:

  • Zoom
  • Miro
  • Arkusz odpowiedzi
  • Experiment Sprint Canvas
  • Matryca hipotez
  • Matryca wniosków

Case study to za mało?

Chcesz poznać cały proces i dowiedzieć się, jak mógłby wyglądać w Twojej organizacji?

Umów się na bezpłatną konsultację

Zespół projektowy, czyli kto za co odpowiadał

Autor Case Study

Sylwia Paszyna Lean Marketing Consultant & Strategist
Język nie ma przed nią tajemnic. Pracuje z tekstem pod różnymi kątami, zarówno projektując komunikację, jak i redagując i poprawiając treści. Współpracowała m.in. z wydawnictwem Czarnym. Absolwentka edytorstwa na Uniwersytecie Jagiellońskim i UX & Business Design na Wyższej Szkole Europejskiej im. Józefa Tischnera.

Rozwija wiedzę w zakresie badań UX, by u źródła poznawać potrzeby wyrażające się w języku. Projektuje strategie marketingowe, przeprowadza badania i analizy. Wszystkie te doświadczenia wykorzystuje, by tworzyć lepszą komunikację.

Pozostali członkowie zespołu

Kamil Cupial Lean Marketing Consultant & Strategist
Dotychczasowe doświadczenie zbierał w organizacjach NGO, start-upach i agencjach kreatywnych, dzięki czemu z łatwością potrafi zrozumieć wiele - często pozornie sprzecznych - perspektyw. W Project: People pomaga klientom znaleźć swoje miejsce na rynku poprzez kreowanie i wdrażanie strategii marketingowych, biznesowych i produktowych. Uwielbia nieszablonowe rozwiązania, eksperymenty i nieustające testy.

W swoim życiu zawodowym koordynował prace zespołów zarówno kreatywnych, jak i technologicznych. I w tym właśnie dostrzega największą wartość: w holistycznym spojrzeniu na sytuację, na organizację, na człowieka.

Wolne chwile spędza najchętniej na świeżym powietrzu, z książką w jednej ręce i parującą yerba mate w drugiej. Umiarkowany kontestator, dla którego nie istnieje status quo. Wie, że zawsze można zrobić coś inaczej (lepiej?), ucząc się nowego. Wierzy, że świat rzadko jest czarno-biały - Kamil dostrzega w nim na co dzień setki odcieni szarości.
Katarzyna Harmata Lean Marketing Manager & Strategist
Od lat z powodzeniem łączy marketing i biznes. Obecnie specjalizuje się w zarządzaniu projektami i Content Marketingu. W swoim dorobku ma już zarządzanie kilkunastoosobowym zespołem marketingowym, kreowanie cyklu wydarzeń biznesowych, współtworzenie firmy i kierowanie nią.

Pomaga firmom w odnalezieniu własnego „ja” w biznesie i komunikowaniu tego na zewnątrz (strategia marketingowa & personal branding).

Zaangażowana w liczne działania społecznościowe. Jest certyfikowanym Trenerem Biznesu. Prowadzi warsztaty z pogranicza strategii i marketingu. Autorka tekstów dla portali branżowych, m.in. Nowy Marketing, Marketing w Praktyce, E-commerce & Digital Marketing.