Wyceń usługę

10 barier w rozmowie o badaniach użyteczności

Wróć do wpisów
Kategoria: Analityka
Czerwiec 03, 2019

Badania użyteczności mogą budzić obawy. Wymagają dodatkowego budżetu, czasu i zaangażowania. W rozmowach o badaniach możemy spotkać wiele obiekcji dotyczącej tej formy zdobywania danych. Poniżej najpopularniejsze z nich oraz jak na nie odpowiedzieć.

1. Dlaczego nie użyjecie swojej wiedzy eksperckiej? Macie doświadczenie, powinniście wiedzieć jak zbudować serwis.

Położenie nacisku na poznanie użytkowników jest właśnie najważniejszym elementem naszej wiedzy eksperckiej. Używanie jedynie własnych opinii, nawet popartych dużym doświadczeniem, które posiadamy, nie przynosi takich efektów jak praca z docelowym użytkownikiem serwisu. Opieramy swoje decyzje na danych i faktach, nie intuicji.

2. Badania potrwają długo, a my chcemy działać od razu.

To prawda, badania będą wymagały dodatkowego czasu i dodatkowego budżetu. Jednak jeszcze droższe będzie poprawianie nieprzetestowanego wcześniej serwisu. Utracony zysk na skutek źle dopasowanej do odbiorców strony internetowej nawet trudno oszacować. Badania można prowadzić równolegle z innymi pracami i nie muszą być to wielomiesięczne działania. Oszczędzanie na badaniach to zazwyczaj duże koszty w przyszłości, a także praktyczny brak możliwości uzyskania optymalnych efektów.

3. Znamy doskonale naszych użytkowników, swój biznes. Nasze wskazówki będą wystarczające.

Nie będą. Na pewno w znacznym stopniu znacie swoich użytkowników, ale zazwyczaj tylko tych, którzy są już klientami. Nie wiemy praktycznie nic o tych, którzy nie skonwertowali i porzucili serwis. W interakcji z obecnymi klientami rzadko też poruszamy kwestię samego serwisu. Skupiamy się na biznesie.

Ponadto, znamy również doskonale swoją ofertę i sam serwis. Nie zauważamy trudności w korzystaniu z niego, gdyż wiemy o nim wszystko. Wiemy też gdzie i co zostało umieszczone. Jest to wiedza, której nie posiada użytkownik.

Zazwyczaj wystarczy jeden film z interakcji z użytkownikiem, by szybko zweryfikować, jak bardzo nasze wyobrażenia o interakcji użytkownika rozmijają się z rzeczywistością.

4. Każdy ma własne opinie i gust. Nie możemy opierać działań na jednostkowych opiniach.

Oczywiście, każdy ma swoje przyzwyczajenia i opinie. Celem badań z użytkownikami nie jest zmiana całego serwisu według wskazań niewielkiej grupy respondentów. Celem jest wyciągnięcie takich wniosków, które można przełożyć na większość użytkowników serwisu. Ponadto zebrane od użytkowników dane zestawiamy z danymi ilościowymi (zebranych m.in. na podstawie Google Analitycs), tak by zweryfikować ich zasadność.

Skupiamy się na problemach i barierach w interakcji, a nie na jednostkowych opiniach. Zwracamy więc na przykład uwagę na brak odpowiednich notyfikacji z systemu, a nie np. na sugestie odnośnie używania kolorów, które lubi pojedynczy użytkownik.

5. Korzystamy już z metod ilościowych. Mamy Google Analytics, HotJara. Po co nam więcej?

Badania ilościowe są istotne, prawidłowo skonfigurowany Google Analytics to fundament, który należy mieć dobrze przygotowany. Jednak posługiwanie się tylko danymi z tego źródła daje ograniczony pogląd na rzeczywistość. Owszem, dowiemy się, że coś się dzieje (np. dana podstrona jest popularna lub użytkownicy w danym miejscu opuszczają serwis), ale nie dowiemy się dlaczego. Nasze wnioskowanie będzie więc obarczone dużym błędem.

Tylko połączenie badań ilościowych i jakościowych daje kompletny, rzetelny obraz interakcji użytkownika z serwisem i pozwala dokonać realnej zmiany.

6. Badania jakościowe nie są reprezentatywne. Nie jesteśmy w stanie przebadać odpowiedniej ilości użytkowników.

Badania jakościowe nie muszą być realizowane na dużej grupie. Już 5 użytkowników w danej turze pozwala wychwycić większość kluczowych błędów interfejsu. Stwierdził to już lider badań użyteczności, Jakob Nielsen w 1993 roku. Na opublikowanym wykresie widać, że, wydawałoby się, niewielka grupa respondentów daje nam większość kluczowych danych.

Źródło: https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

Istotą badań jest więc ich iteracyjność, a nie liczba respondentów. To właśnie tryb pracy “badanie – zmiana – badanie” jest kluczowe.

7. Badania można ustawić pod swoje wnioski.

Można, ale dlaczego ktokolwiek miałby to robić? Ideą badań jest oderwanie się od swojej wiedzy eksperckiej i patrzenie na interakcje oczami użytkownika. Wszelkie prace realizowane są dla użytkowników, nie dla klienta czy ekspertów.

8. Badania nie oddają prawdziwych zachowań. Ludzie inaczej zachowują się podczas badań.

To prawda, użytkownicy podczas badań zazwyczaj starają się… bardziej. Gdy w normalnej sytuacji porzuciliby interakcję, podczas badań kontynuują działania. Dzieje się tak z wielu powodów. Nikt nie chce “zawieść” moderatora. Poza tym każdy badany chce wykonać zadanie, najlepiej jak potrafi, skoro otrzymuje wynagrodzenie, to niezręcznie byłoby porzucić interakcję. Jeśli więc na badaniach użytkownicy porzucają działania, to w rzeczywistości jest tylko gorzej.

9. Ludzie nie znają się na budowie serwisów, ich opinie się nie przydadzą.

To prawda. Użytkownicy nie znają się na budowaniu serwisów. I nie muszą się znać! Mają czerpać satysfakcję z interakcji. Serwis powinien być zbudowany tak, by maksymalnie służyć użytkownikom i być tak użyteczny, jak dalece to możliwe. Nikt nie powinien posiadać żadnej szczególnej wiedzy, by móc z niego korzystać.

10. Zamiast przeprowadzać kosztowne badania, można inspirować się działającymi serwisami na rynku.

Inspirowanie się konkurencją wydaje się ciekawą strategią, jednak też bardzo ryzykowną. Nigdy nie masz pewności, czy rozwiązania konkurencji naprawdę działają. To, że duży podmiot realizuje coś w określony sposób, nie oznacza, że jest to słuszne. Pozycji rynkowej nie gwarantuje jedynie użyteczność serwisu. Często zdarza się tak, że użytkownicy są skłonni zacisnąć zęby i przebrnąć przez nieintuicyjny serwis, tylko dlatego, że chcą produktów lub usług znanej marki.

Nie wiesz też nic o planowanych pracach, modernizacjach serwisu konkurencji itd.

Wojciech Popiela
Wojciech Popiela
Project Manager i developer z ośmioletnim stażem. Doświadczenie zdobywał przy realizacji dużych projektów aplikacji internetowych. W TenseApp! czuwa nad jakością wdrożeń i rozwojem usługi jako członek zarządu.
Komentarze