Iga Mościchowska

Badania jako podstawa projektowania user experience


Скачать книгу

które sprawiają, że twórcy kręcą się w kółko. Znacznie trudniej jest dyskutować z wynikami badań („Połowa respondentów nie potrafiła znaleźć produktu przy użyciu wyszukiwarki”) niż opiniami („Moim zdaniem pole wyszukiwarki jest mało widoczne”).

      NAJCZĘSTSZE ARGUMENTY PRZECIWKO BADANIOM I JAK SOBIE Z NIMI RADZIĆ

      Nasi pracownicy znają potrzeby naszych użytkowników.

      Znają też produkt od podszewki, mogą nie dostrzegać problemów, gdyż wszystkie rozwiązania wydają się im już oczywiste. Wpadają w rutynę i nie dostrzegają szans na nowe rozwiązania, nowe podejście czy potrzebne usprawnienia. Prawdopodobnie też ich wiedza o użytkowniku i jego środowisku jest przestarzała lub niekompletna. Kiedy ostatni raz rozmawiali z użytkownikiem? Czy widzieli go kiedykolwiek wykonującego daną czynność? Czy jesteście absolutnie pewni, że macie kompletną wiedzę o Waszych użytkownikach?

      Ludzie nie wiedzą, czego chcą.

      To prawda, dlatego sprawny badacz będzie wnioskował o potrzebach w sposób pośredni, w oparciu o obserwacje czy techniki projekcyjne. Bardziej niż pomysły na rozwiązania będą go też interesować problemy i zwyczaje ludzi. Te będą świetnym źródłem inspiracji dla projektanta, ale to projektant zaprojektuje produkt (bazując na faktach, nie przeczuciach).

      Nie mamy czasu na badania.

      A czy mamy czas na podejmowanie błędnych decyzji? Czy mamy czas na wdrażanie produktu, który nie jest nikomu potrzebny? Czy stać nas na poprawianie produktu już po jego uruchomieniu, kiedy wywoła pierwsze, negatywne wrażenia? Poza tym nie wszystkie badania są czasochłonne. Można dobrać te techniki, które nie będą wpływały zbytnio na harmonogram projektu. Część prac może przebiegać równolegle. Zamiast badań formalnych można spróbować bardziej nieformalnego podejścia, zrezygnować z opasłych raportów i szczegółowej transkrypcji na rzecz większego zaangażowania całego zespołu w badania.

      Po co ci badania, przecież jesteś ekspertem.

      I właśnie dlatego potrzebuję danych, na których mogę oprzeć dobry projekt, realizujący realne potrzeby i pasujący do faktycznego kontekstu użycia. Moja praca polega na połączeniu wymagań różnych środowisk – biznesu, technologii oraz użytkowników – w jednym projekcie. Każdy projekt ma użytkowników o innych charakterystykach i innych celach. Trzeba je poznać, aby im sprostać.

      Poza tym nie jestem nieomylny, zdarza mi się przyjąć błędne założenia. Dzięki testom z użytkownikami jestem w stanie te błędy wychwycić i naprawić. I na tym właśnie polega moja praca jako eksperta.

      Badania tylko ograniczają innowacje.

      Badania służą innowacji, nie są jej ograniczeniem. To projektant projektuje, nie badacz, nie respondent. Badania zaś są dla niego nieocenionym źródłem wiedzy, inspiracji i momentów olśnienia. Pozwalają skupić się kreatywności na tych miejscach, gdzie jest to istotne. Później weryfikują produkt, zmniejszając ryzyko błędnych decyzji projektowych jeszcze przed wypuszczeniem go na rynek.

      Badania jakościowe nie są reprezentatywne, więc nie można im ufać.

      Celem badań nie jest określenie, jakiego procentu społeczeństwa dotyczy dane zjawisko czy problem, ale sama jego identyfikacja i lepsze jego zrozumienie. Zwykle 5 uczestników testów użyteczności wystarcza, żeby odnaleźć 80% problemów. Ale możemy przeprowadzić więcej badań. Zaplanujmy 8 rund testów, w każdej rundzie po 5 osób. Kiedy uznasz, że wiesz już wystarczająco dużo, przerwiemy badania, OK? (Zwykle przy 8.–10. teście problemy powtarzają się tak mocno, że obserwatorzy zaczynają się nudzić na badaniach. Zdarzyło nam się nawet, że klient na 12. teście zasnął!).

      Badania można zmanipulować i ustawić wyniki pod swoje tezy.

      To prawda. Tak jak można być złośliwym i specjalnie źle zaprojektować interfejs. Dlaczego jednak zakładać złą wolę badacza? Celem każdego specjalisty UX jest przede wszystkim dbanie o wysoką jakość projektu i dobro użytkowników. Mamy to zapisane w zawodowym DNA! Dobremu badaczowi nie zależy na udowodnieniu swojej racji, ale na poznaniu prawdy.

      Ludzie kłamią, a sytuacja badań jest sztuczna, więc nie oddaje realnych warunków.

      Ludzie kłamią wtedy, kiedy nie znają odpowiedzi albo się ich wstydzą, co nie ma miejsca wcale tak często. Poza tym większość wnioskowania w badaniach user experience opiera się jednak na obserwacjach, a nie deklaracjach. Są techniki i metody badawcze minimalizujące sztuczność sytuacji badawczej (np. badania etnograficzne i wywiady kontekstowe). Poza tym zawsze lepiej jest mieć jakieś dane niż żadnych, prawda?

      Projekt dopasowany do odbiorców, nie twórców rozwiązania

      Twórcy produktu rzadko są jednocześnie jego odbiorcami: nie mają takich samych doświadczeń, potrzeb, ale i ograniczeń, jak docelowi użytkownicy. Mogą mieć mniejszą wiedzę z danej tematyki (bo nie skończyli studiów pięcioletnich z finansów), nie znać dobrych praktyk branży (bo nie zajmują się rachunkowością osiem godzin dziennie), za to zwykle mają większą świadomość technologiczną (bo z komórką nie rozstają się nawet w czasie wyjścia do toalety). Jednocześnie jako osoby uczestniczące w procesie tworzenia produktu od samego początku (jakieś pół roku temu) wiedzą doskonale, jakie są jego założenia biznesowe, znają mechanikę działania poszczególnych funkcjonalności, przyczyny użycia takich, a nie innych terminów, a także kolejne kroki w procesie. Wiedzą o swojej aplikacji więcej, niż kiedykolwiek będzie wiedział jej przyszły użytkownik. Znajomość założeń projektu skutecznie ogranicza możliwości znalezienia wielu problemów, które wynikają właśnie ze świeżego podejścia użytkowników i z braku doświadczenia. Interakcja takiej osoby z projektem pozwala wyeliminować wiele błędów, z których istnienia twórcy nie zdawaliby sobie sprawy.

      Lepsze zrozumienie potrzeb specyficznej grupy odbiorców

      Badania są szczególnie istotne w wypadku tworzenia rozwiązań dla grupy docelowej o jakiejś specyficznej charakterystyce. O ile postawienie się w roli użytkownika jest stosunkowo łatwe w przypadku produktów masowych, takich jak: wyszukiwarka Google czy system do rezerwacji biletów do kina, o tyle ciężko jest utożsamić się z 8-letnią dziewczynką, maklerem giełdowym z 5-letnim doświadczeniem, osobą niedowidzącą czy lotnikiem symulatora lotu. Wszędzie tam, gdzie użytkownicy produktu mają konkretne ograniczenia (technologiczne, społeczne, kompetencyjne, fizyczne) lub posiadają specyficzne kompetencje i doświadczenie, trudne do nabycia w krótkim czasie, badania z użytkownikami są niezbędne do zebrania potrzeb oraz weryfikacji projektu. Ich pominięcie może zaowocować kompletnym rozminięciem się produktu z realiami odbiorców, a tym samym – odrzuceniem przez nich produktu.

      Rozwijanie i aktualizowanie kompetencji zespołu projektowego

      Źródłem wszelkich zasad projektowych, dobrych praktyk i heurystyk użyteczności są właśnie badania z użytkownikami. Wnioski z różnych badań były poddawane przez badaczy dogłębnej analizie i uogólniane w taki sposób, aby można było się nimi kierować w kolejnych projektach. Biorąc pod uwagę, jak dynamiczny i stale zmieniający się jest świat nowych technologii, aktualizowanie tej wiedzy staje się koniecznością. Zmieniają się narzędzia, technologie, ale też i przyzwyczajenia (kto z nas robił selfie 10 lat temu?). Badania z użytkownikami stają się więc podstawowym źródłem informacji o tym, co działa, co się sprawdza, a co budzi u użytkowników problemy. Jest to też najszybszy sposób nauki dla projektantów. Nic tak nie uczy pokory, jak obserwacja własnego rozwiązania, którego już ósmy użytkownik na testach nie potrafi użyć. Nawet badacze z wieloletnim doświadczeniem są zaskakiwani przez trudności napotykane przez użytkowników na testach użyteczności.