Cenne spostrzeżenia we właściwym czasie: określenie idealnego poziomu wierności projektu do testowania użytkowników

W Intercom jedną z naszych zasad rozwoju produktów jest myślenie na wielką skalę, zaczynanie od małych rzeczy, szybkie uczenie się.

Jednym ze sposobów, w jaki szybko się uczymy, jest przeprowadzanie badań ewaluacyjnych w celu budowania zaufania do kierunku projektowania produktów, w którym podążamy. Często naszym celem jest przedstawienie użytkownikom koncepcji produktu na bardzo wczesnym etapie procesu rozwoju produktu, na długo przed napisaniem kodu.

Takie podejście do testowania użytkowników stawia ważne i ciągłe pytanie – jaki poziom wierności projektu należy przedstawić uczestnikom badań? Jak blisko ostatecznego projektu muszą być te koncepcje, aby uzyskać dokładne spostrzeżenia od tych, którzy je testują? Jak znaleźć właściwą równowagę między „surowym, ale wczesnym” z jednej strony a „dopracowanym, ale późno” z drugiej? Jaki poziom abstrakcji projektowej jest najlepszy?

„Odkryliśmy, że warto unikać używania terminu „ projektowanie” podczas wewnętrznej rozmowy o tym, co pokazać uczestnikom – wolimy używać „ stymulacji badawczej””

Słowa mają znaczenie

Po pierwsze, chociaż mówimy o wierności projektu, stwierdziliśmy, że pomocne jest unikanie używania terminu „projekt” podczas wewnętrznego mówienia o tym, co pokazać uczestnikom podczas testów z użytkownikami – wolimy używać „bodźca badawczego”. Terminy takie jak „bodziec badawczy” lub „artefakt prowokacyjny”, choć brzmią nieco dziwnie, pomagają zakomunikować, że to, co zamierzasz pokazać uczestnikowi, jest narzędziem do wydobycia wglądu w ogólną koncepcję, a nie konkretne cechy projektu.

Rozpoznać problem

Korzystanie z najnowszych, najbardziej dopracowanych plików projektowych dostępnych podczas tworzenia bodźca badawczego może być kuszące, ale wiąże się to z pewnymi kosztami, które należy wziąć pod uwagę. Uczestnicy zwrócą uwagę na najwyższy poziom wierności, jaki zapewniasz – jeśli interesuje Cię, czy koncepcja ma wartość, wysłuchanie komentarzy uczestników na temat mikrokopii w CTA prawdopodobnie zakłóci informacje zwrotne, których szukasz.

Zamiast tego uznaliśmy, że warto zacząć od problemu – tego, o czym próbujemy się dowiedzieć – i dopasować to do wierności tego, co pokazujemy uczestnikom badań podczas testów użytkowników.

Aby więc określić poprawną wierność projektu, musisz określić, który z następujących problemów próbujesz rozwiązać:

• Testowanie koncepcji: czy ten pomysł ma wartość?
• Testowanie projektu systemu: Czy użytkownicy mogą wyrobić sobie „wystarczająco dobre” zrozumienie tego systemu?
• Testowanie użyteczności: czy ludzie mogą używać tego produktu?

Po ustaleniu problemu, który próbujesz rozwiązać, pomoże to określić, jaki poziom wierności projektu jest wymagany od bodźca badawczego.

Wyjaśnienie problemu z góry pomaga również nawiązać współpracę z partnerami międzyfunkcyjnymi w zakresie projektowania, produktu i inżynierii – jest to tym ważniejsze, że tworzenie bodźca badawczego jest wysiłkiem opartym na współpracy i takim, w którym własność może być niejasna.

„Na wczesnych etapach nie interesuje cię, jak będą z nim współdziałać. Interesuje Cię, czy będzie to dla nich wartościowe”

Testowanie koncepcji: czy ten pomysł ma wartość?

Na tym etapie Twoim problemem jest ustalenie „Czy ten pomysł ma wartość?” W szczególności, czy klienci uważają, że ten pomysł pomoże im rozwiązać problemy, z którymi się borykają? Na wczesnych etapach nie interesuje Cię, jak będą z nim współdziałać. Interesuje Cię, czy będzie to dla nich wartościowe.

Podczas samego testu będziesz chciał potwierdzić, że uczestnik rzeczywiście doświadcza problemu, który próbujesz rozwiązać, pokazać mu koncepcję i ocenić, czy oczekuje, że rozwiąże on jego problem w wartościowy sposób.

W tym momencie bodziec testowy nie musi wyglądać jak interfejs. W rzeczywistości prawdopodobnie lepiej, jeśli tak nie jest – jeśli zdecydujesz się przedstawiać koncepcje jako interfejs, pamiętaj, że Twoi uczestnicy mogą przeskoczyć do myślenia o tym, w jaki sposób będą z nim współpracować, jak to miałoby związek z resztą Twój produkt i co myślą o projekcie wizualnym. Ten rodzaj informacji zwrotnej jest łatwiejszy do przekazania, więc uczestnicy w naturalny sposób będą skłaniać się ku niej, zamiast głęboko zastanawiać się nad samą koncepcją i tym, jak może rozwiązać problem, którego doświadczają. Twój bodziec badawczy musi tylko przekazać pomysł, który testujesz, i niewiele więcej.

Szybkie opisy tekstowe, scenorysy, makiety stron docelowych, diagramy w Prezentacjach Google lub gryzmoły w stylu tablicy to uzasadnione opcje. Zachowaj prostotę i koncentrację, rozmazując niepotrzebną kopię i używając oczywistej grafiki zastępczej.

Testowanie projektu systemu: Czy użytkownicy mogą wyrobić sobie „wystarczająco dobre” zrozumienie tego systemu?

Czasami zespół produktowy może pracować nad stworzeniem całego systemu , a nie interfejsów lub przepływów. Kiedy przeprowadzasz badania na tym etapie, prawdopodobnie Twoim pytaniem jest, czy w oparciu o dotychczasowe wyobrażenia zespołu Twoi użytkownicy mogą tworzyć funkcjonalne modele umysłowe, które umożliwią im korzystanie z produktu bez blokowania się i dezorientacji. Najlepszym na to dowodem jest to, czy użytkownicy mogą dokładnie przewidywać, jak będą wykonywać reprezentatywne zadania w systemie.

Chociaż można po prostu pokazać abstrakcyjne diagramy systemu i zapytać użytkowników, jak spodziewaliby się z nim wchodzić w interakcję, nie ma to dużej ekologicznej wartości; pokazywanie bodźców, które bardziej przypominają interfejs użytkownika, sprawia, że ​​badania są bardziej realistyczne. Ponownie jednak stwierdziliśmy, że poproszenie uczestnika o faktyczne użycie prototypu sprawia, że ​​prawie niemożliwe jest, aby jego uwaga nie została skierowana na projektowanie interakcji, a prawdopodobnie nadal tego nie rozwiązujesz.

Zastanów się nad przedstawieniem im realistycznych problemów i poproszeniem ich, aby omówili, w jaki sposób mogliby sobie z nimi poradzić za pomocą wymyślonych interfejsów, podczas gdy udostępniasz ekran i dbasz o konkretne interakcje, które przenoszą ich przez produkt. Dzięki temu nie będziesz musiał budować w pełni interaktywnych prototypów, zanim będziesz mieć pewność co do kierunku projektowania, albo narazisz się na frustrowanie uczestników z interakcjami, o których wiesz, że wciąż są niepewne.

Testowanie użyteczności: czy ludzie mogą używać tego produktu?

Na tym etapie będziesz chciał wiedzieć, czy użytkownik może wchodzić w interakcję z Twoim produktem z realistycznym poziomem wsparcia (np. nie więcej onboardingu, niż prawdopodobnie zapewnisz w produkcie końcowym) i wykonać zadania, które reprezentują Twój problem rozwiązujemy.

Istnieje wiele rodzajów testów użyteczności, a we wszystkich z nich ważniejsze staje się projektowanie interakcji. Możesz testować użyteczność za pomocą prototypów o różnych poziomach wierności, gdy jasno i szczegółowo określisz zadania, które mają wykonać i przetestować uczestnicy, a interakcje, które są potrzebne do ich umożliwienia, są obsługiwane w prototypie.

W podsumowaniu

Linie między tymi fazami są rozmyte i znalezienie odpowiedniego protokołu dla danej sytuacji może być trudne. Przygotuj się do dostosowania zarówno bodźca badawczego, jak i pytań, które zadajesz z sesji na sesję.

Wreszcie, nie ma nic złego w pytaniu uczestników, jak odnaleźli samą sesję badawczą, a nie bodźce badawcze. Zamieszanie lub frustracja są oznaką, że masz jeszcze trochę pracy. A jeśli utkniesz, pamiętaj, aby zacząć od problemu: co dokładnie chcesz uzyskać z sesji testowania użytkowników?

Chcesz dowiedzieć się więcej o pracy z naszym zespołem? Przeczytaj o naszych wartościach, sposobie pracy i naszych otwartych rolach tutaj.