Klienci, którzy do nas trafiają, najczęściej oczekują wykonania audytu istniejącego systemu, lub zaprojektowania czegoś od podstaw. To drugie lubimy robić najbardziej, więc proponujemy, aby filarem dalszych działań były badania z użytkownikami. Zdarza nam się jednak zbyt często obserwować z jaką łatwością firmy rezygnują właśnie z badań, uważając je za niepotrzebny element procesu tworzenia produktów cyfrowych. Tworzą rozwiązania przez pryzmat wyobrażeń o grupie docelowej, zamiast poświęcić czas i poznać swoich użytkowników – ich potrzeby, przyzwyczajenia i kontekst użycia produktu.
Może to brak wiary w założenie, że użytkownicy dostarczają ważnych informacji? A może brak wiedzy na temat tego jak badania z użytkownikami mogą wzbogacić projekt?
Na szczęście takie podejście do badań zmienia się wraz z ukończeniem pierwszego procesu badawczego. Wtedy sceptycy i przeciwnicy najczęściej zmieniają się w zagorzałych fanów badań, widząc w nich realną wartość. Coż, jeśli 100% badanych osób mówi, że nie użyje Twojej aplikacji, a Ty dzięki temu nie zaliczysz rynkowej wpadki i masz szansę na drugie podejście, to trudno się dziwić 🙂 (przykład z życia wzięty)
Spieszymy zatem z wyjaśnieniem czym są badania w projektowaniu UX, dlaczego są istotne i co mogą wnieść do projektu.
Nie chcemy tutaj opisywać szczegółowo wszystkich możliwych rodzajów badań, jakie można wykonać projektując produkt cyfrowy.
Nie chcemy też kurczowo trzymać się przyjętych podziałów i zastosowań badań. Z naszej perspektywy nie ma sztywnych granic w wykorzystywaniu opisanych tu metod badawczych. Kierujemy się raczej podejściem “jeśli coś się sprawdza, to czemu tego nie zrobić?” Często w naszej pracy łączymy bowiem testy zadaniowe z wywiadami i ankietami dzięki czemu uzupełniamy naszą wiedzę o użytkowniku i jego wyobrażeniach o produkcie.
“Po co nam badania? Wiemy co myślą nasi użytkownicy, znamy ich potrzeby” – to bardzo częste myślenie i postawa przedstawicieli różnych firm. Jeżeli też reprezentujesz taką podstawę, ten artykuł jest właśnie dla Ciebie!
Zaczniemy od badań potrzeb użytkowników, które zazwyczaj są wykonywane na początku projektu, kiedy mamy tylko (a raczej aż) pomysł na rozwiązanie zauważonego przez nas problemu lub ogólną koncepcję naszego produktu. Badania potrzeb są również przydatne w momencie, kiedy chcemy rozwijać produkt i zastanawiamy się, w którym kierunku należy pójść.
Badania te najczęściej polegają na prowadzeniu tzw. wywiadów pogłębionych IDI (ang.Individual In-depth Interview), czyli rozmowie badacza z użytkownikami, która prowadzona jest na podstawie wcześniej przygotowanego scenariusza. Badacz elastycznie dostosowuje tematy rozmowy, tak by pogłębić wątki, które są interesujące z punktu widzenia projektu.
Dzięki IDI można się dowiedzieć m.in.:
Pytania jakie zadajemy oczywiście dopasowujemy do projektu. Badacz ma jeszcze jedną wielką moc… może pogłębiać i dopytywać rozmówcę o interesujące go odpowiedzi w kontekście projektu. Czyli zamiast domyślania się, co użytkownik miał na myśli, możemy po prostu go o to zapytać.”
Rozmowa z użytkownikiem pozwala testować nasze hipotezy projektowe.
Wywiady mogą obalać założenia, uważane przez nas za oczywiste lub wręcz przeciwnie, potwierdzać ich słuszność. Niezależnie, czy nasze założenia zostaną obalone, czy potwierdzone, dostajemy ogromną dawkę informacji pozwalającą na podjęcie słusznych decyzji projektowych.
“W przypadku potwierdzenia założeń, mamy podstawy do kontynuowania projektu. Z doświadczenia jednak wiemy, że każde badanie wnosi coś nowego do projektu… ciekawe spostrzeżenia, które są warte rozważenia i pochylenia się nad nimi. Dlatego, nawet jeśli nasze hipotezy zostaną potwierdzone, to może się okazać, że dzięki badaniom, mamy szansę zaprojektować jeszcze lepszy, bardziej przemyślany produkt. Produkt, który będzie rozwiązywał realne problemy ujawnione przez użytkowników podczas badań.”
Rozmowa z użytkownikiem pozwala testować nasze hipotezy projektowe. Wywiady mogą obalać założenia, uważane przez nas za oczywiste lub wręcz przeciwnie, potwierdzać ich słuszność. Niezależnie, czy nasze założenia zostaną obalone, czy potwierdzone, dostajemy ogromną dawkę informacji pozwalającą na podjęcie słusznych decyzji projektowych.
Z kolei, w przypadku obalenia naszych założeń, zyskujemy szansę na przemyślenie kierunków projektowych i podjęcia decyzji o wykonaniu zwrotu jeszcze na etapie koncepcji projektu. Co niewątpliwie jest oszczędnością czasu i pieniędzy.
Mówimy tutaj o testach jeszcze na etapie pomysłu, koncepcji. Z kolei, w celu sprawdzenia istniejącego produktu wykorzystać możemy testy użyteczności.
Pytania jakie zadajemy oczywiście dopasowujemy do projektu. Badacz ma jeszcze jedną wielką moc… może pogłębiać i dopytywać rozmówcę o interesujące go odpowiedzi w kontekście projektu. Czyli zamiast domyślania się, co użytkownik miał na myśli, możemy po prostu go o to zapytać.
Część 2 wkrótce na naszym blogu…