Читать книгу Badania jako podstawa projektowania user experience - Iga Mościchowska - Страница 13

Zarówno wśród klientów, jak i twórców oprogramowania odnaleźć można zagorzałych zwolenników badań, jak i ich przeciwników. Dla tych pierwszych konieczność badań w procesie wytwarzania rozwiązań interaktywnych jest oczywista, bo przecież nie można mówić o projektowaniu zorientowanym na użytkownika, jeśli nie ma się z nim kontaktu. Dla tych drugich badania są drogie, zabierają cenny czas, a przede wszystkim są zbędne, bo przecież ludzie i tak nie wiedzą, czego chcą, a do stworzenia dobrego produktu wystarczy dobry projektant. Prawda, jak zwykle, leży pośrodku. Same badania nie są wystarczające do stworzenia świetnego produktu, jest jednak szereg zalet i korzyści, które można dzięki temu uzyskać.

Carol Barnum:

Nikt nie pokaże twojemu klientowi, co działa, a co nie, co się podoba, a co niepokoi, co angażuje lub nudzi użytkownika lepiej niż on sam 21.

Projektowanie oparte na faktach, nie na przeczuciach

Podstawową przesłanką za przeprowadzaniem badań jest dążenie do podejmowania decyzji projektowych na bazie faktów, a nie indywidualnych przekonań projektantów i inżynierów. Intuicja jest ważna, ale bywa zawodna, o czym wie każdy projektant, który kiedykolwiek przetestował swój produkt z użytkownikami. Nagle okazuje się, że ta niezwykle innowacyjna opcja w aplikacji (konkurencja tego nie ma!) nie jest przez nikogo używana (bo po co?), a intuicyjne etykiety nie są wcale takie oczywiste. Nawet najlepszy projektant nie jest nieomylny, czasem się myli, a czasem przyjmuje błędne założenia. Zderzenie intuicji z użytkownikami pozwala zminimalizować ryzyko błędnych decyzji projektowych, co oczywiście może zapobiec katastrofom (takim jak wypuszczanie na rynek aplikacji, której nikt nie potrzebuje lub nikt jej nie rozumie).

Szybsze rozwiązywanie różnic zdań w zespole projektowym

Możliwość odwołania się do wyników badań staje się bardzo przydatna, kiedy w zespole projektowym występują różne, sprzeczne ze sobą poglądy i stanowiska odnośnie do tworzonego produktu. W takim wypadku można albo sięgnąć do istniejących wniosków badawczych, albo przeprowadzić dedykowane badanie w celu jasnej odpowiedzi na pytanie. Zderzenie wątpliwości z realnymi użytkownikami może się okazać nawet szybsze niż ciągłe dysputy wewnątrz zespołu, 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. To jeden z ciekawszych aspektów tej pracy.

Inspirowanie zespołu do tworzenia nowych rozwiązań i ulepszeń

Użytkownicy nie są projektantami, ale to nie znaczy, iż nie są źródłem zaskakujących odkryć i fantastycznych pomysłów. Czasem to będzie mimochodem rzucona uwaga o frustrującym rozwiązaniu konkurencji, a czasem zwrócenie uwagi na wartości, których nikt wcześniej nie traktował jako istotne. Zaproszenie zwykłych ludzi do procesu tworzenia produktu, nie ogranicza, a poszerza horyzonty projektanta, pozwala odkryć zjawiska i problemy, które normalnie mogłyby umknąć jego uwadze. Takie spotkanie bardzo często kończy się chwilą olśnienia, kiedy drobna uwaga staje się inspiracją dla nowego rozwiązania lub zmyślnego usprawnienia.

Budowanie empatii i poczucia zrozumienia wewnątrz zespołu projektowego

Nieco bagatelizowaną korzyścią włączania badań w prace nad rozwojem produktu jest też budowanie empatii jego twórców względem swoich użytkowników. Nagle bezimienny użytkownik staje się osobą z krwi i kości, zyskuje twarz i imię (np. dzięki personom opracowanym na podstawie wywiadów indywidualnych). Jego początkowo dziwne potrzeby i irytujące ograniczenia stają się zrozumiałe w świetle realnego kontekstu użycia i środowiska, które można zobaczyć na badaniach w terenie. Obserwacje zmagań użytkowników z prototypem produktu uzmysławiają inżynierom i projektantom, iż rzeczy oczywiste wcale takimi nie są. Pojawia się lepsze zrozumienie samego użytkownika, ale też poczucie wspólnoty, ponieważ cały zespół lepiej rozumie, jakie problemy rozwiązuje i dla kogo. Taki pozytywny wpływ na kulturę pracy jest szczególnie zauważalny w tych firmach, w których badania są naturalnym elementem pracy i uczestniczy w nich cały zespół, a nie garstka badaczy. Przykładowo, AirBnb opłaca każdemu swojemu nowemu pracownikowi wynajem noclegu za pomocą ich serwisu jeszcze w pierwszym tygodniu pracy, tak aby lepiej poczuli i zrozumieli, czym jest ich produkt. W trakcie takiej wizyty zadaniem pracownika jest szczegółowe udokumentowanie całego doświadczenia i podzielenie się wnioskami z resztą zespołu. Takie zanurzenie w doświadczeniu użytkownika i dosłowne „wejście w jego buty”, zdaniem założycieli startupu, pozwala lepiej zrozumieć kontekst, rodzi empatię i inspiruje do nowych rozwiązań22.