Zapytaj "Co zrobiłby użytkownik?" (Nie jesteś użytkownikiem)
Oryginalny tytuł: Ask, "What Would the User Do?" (You Are Not the User)
Autor: Giles Colborne
Wszyscy mamy skłonność do zakładania, że inni ludzie myślą tak jak my. Ale tak nie jest. Psycholodzy określają to mianem błędu fałszywego konsensusu. Kiedy ludzie myślą bądź postępują inaczej niż my, jesteśmy skłonni do (podświadomego) szufladkowania ich jako upośledzonych w pewien sposób.
Ten błąd wyjaśnia, dlaczego tak trudno jest programistom postawić się na miejscu użytkowników. Użytkownicy nie myślą jak programiści. Począwszy od tego, że spędzają o wiele mniej czasu przy komputerze. Nie wiedzą i nie obchodzi ich to, jak działa komputer. Oznacza to, iż nie potrafią oni wykorzystać technik rozwiązywania problemów, które są dobrze znane programistom. Nie rozpoznają oni wzorców ani wskazówek, których programiści używają, aby pracować z interfejsami.
Najlepszym sposobem na dowiedzenie się, w jaki sposób myśli użytkownik, jest obserwacja. Poproś użytkownika o wykonanie zadania za pomocą oprogramowania podobnego do tego, które rozwijasz. Upewnij się, że zadanie jest rzeczywiste: "Zsumuj kolumnę liczb" jest OK; "Oblicz swoje wydatki za ostatni miesiąc" jest lepsze. Unikaj zadań, które są zbyt specyficzne, jak na przykład "Czy mógłbyś zaznaczyć te komórki arkusza, a następnie wprowadzić formułę SUM poniżej?" - w tym pytaniu znajduje się duża podpowiedź. Zmuś użytkownika, aby mówił w miarę postępu zadania. Nie przerywaj. Nie staraj się pomóc. Zadawaj sobie pytanie, "Dlaczego on tak robi?" bądź "Dlaczego ona tak robi?"
Pierwszą rzeczą, jaką zauważysz jest to, że podstawowe rzeczy użytkownicy wykonują podobnie. Starają się wykonać zadania w tej samej kolejności - i popełniają te same błędy w tych samych miejscach. Powinieneś projektować w oparciu o te podstawowe zachowania. Różni się to od spotkań projektowych, gdzie wysłuchuje się kogoś mówiącego, "A co jeśli użytkownik zechce...?" To prowadzi do skomplikowanych funkcjonalności i zamieszania co do tego, czego chce użytkownik. Obserwacja użytkowników eliminuje te pomyłki.
Będziesz obserwował, jak użytkownicy napotykają na trudności. Kiedy Ty napotykasz na trudność, rozglądasz się. Kiedy użytkownicy napotykają na trudność, zawężają swoje pole poszukiwań. Trudniej jest im zaobserwować rozwiązanie zamieszczone gdzie indziej na ekranie. To powód, dla którego pomoc tekstowa jest kiepskim rozwiązaniem dla kiepskiego projektu interfejsu użytkownika. Jeśli już musisz mieć instrukcje bądź pomoc tekstową, upewnij się, że będą umieszczone zaraz obok problematycznych miejsc. Zawężenie pola poszukiwań użytkowników jest powodem tego, że podpowiedzi w dymkach są bardziej użyteczne niż menu z pomocą.
Użytkownicy jakoś sobie radzą. Znajdują sposób, który działa i trzymają się go niezależnie od stopnia zagmatwania. Lepiej jest dostarczyć jeden naprawdę oczywisty sposób zrobienia czegoś niż dwa bądź trzy skróty.
Zauważysz również, że istnieje przepaść między tym, czego użytkownicy chcą, a tym co w rzeczywistości robią. To niepokojące jako, iż normalnym sposobem zbierania wymagań użytkownika jest wypytywanie. Dlatego właśnie najlepszą metodą wyłapania wymagań jest przyglądanie się użytkownikom. Spędzenie godziny na obserwowaniu użytkowników jest o wiele bardziej pouczające, niż spędzenie dnia na zgadywaniu tego, czego mogliby chcieć.
Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
