Jak rozmawiać z użytkownikami, żeby nie słyszeć tylko „to zależy”
Rozmowy z użytkownikami potrafią być złotem. Ale potrafią też być frustrujące.
Pytasz:
„Czy ta funkcja byłaby dla Ciebie przydatna?”
A użytkownik odpowiada:
„To zależy.”
Pytasz:
„Czy korzystałbyś z takiego rozwiązania?”
A on mówi:
„Możliwe.”
Pytasz:
„Co byś zmienił?”
A słyszysz:
„Ciężko powiedzieć.”
I po 30 minutach rozmowy masz notatki, które brzmią mądrze, ale nie pomagają podjąć decyzji.
Problem zwykle nie jest w użytkowniku. Problem jest w pytaniach. Jeśli pytasz zbyt ogólnie, dostaniesz ogólne odpowiedzi. Jeśli pytasz o przyszłość, dostaniesz przewidywania. Jeśli pytasz o opinie, dostaniesz grzeczne komentarze.
Żeby rozmowy naprawdę pomagały, trzeba sprowadzać je do konkretu: sytuacji, zachowań, decyzji i konsekwencji.
1) Nie pytaj „czy byś używał?” – pytaj „kiedy ostatnio miałeś ten problem?”
Największa pułapka rozmów z użytkownikami to pytania o przyszłość.
„Czy używałbyś tej funkcji?” brzmi naturalnie, ale odpowiedź rzadko coś znaczy. Użytkownik może powiedzieć „tak”, bo:
chce być miły,
pomysł brzmi rozsądnie,
nie musi jeszcze nic robić,
nie zna realnego kosztu używania.
Dużo lepsze pytanie:
„Kiedy ostatnio próbowałeś zrobić X?”
To przenosi rozmowę z teorii do rzeczywistości.
Zamiast:
„Czy przydałby Ci się automatyczny raport?”
Zapytaj:
„Kiedy ostatnio przygotowywałeś raport? Jak to wyglądało krok po kroku?”
I nagle rozmowa robi się konkretna.
2) Pytaj o ostatni przypadek, nie o „zwykle”
Użytkownicy często nie pamiętają dobrze swoich ogólnych zachowań. Gdy pytasz:
„Jak zwykle robisz X?”
Dostaniesz uproszczoną wersję:
„No, normalnie wchodzę, klikam i robię.”
Ale gdy pytasz:
„Opowiedz mi o ostatnim razie, kiedy robiłeś X”
pojawiają się szczegóły:
kto był zaangażowany,
co poszło nie tak,
ile to trwało,
gdzie musiał coś obejść,
co było irytujące.
To właśnie w szczegółach znajdują się insighty.
3) Unikaj pytań z ukrytą sugestią
Czasem sami wkładamy użytkownikowi odpowiedź do ust.
Przykłady:
„Czy ten ekran jest dla Ciebie prosty?”
„Czy ten przycisk powinien być bardziej widoczny?”
„Czy byłoby lepiej, gdybyśmy dodali filtrowanie?”
Takie pytania sugerują, czego oczekujesz.
Lepsze wersje:
„Co myślisz, że możesz zrobić na tym ekranie?”
„Co byś kliknął jako pierwsze?”
„Czego tutaj szukasz?”
„Co jest niejasne?”
Dobre pytanie nie prowadzi użytkownika do odpowiedzi. Dobre pytanie pozwala zobaczyć, jak użytkownik naprawdę myśli.
4) Gdy słyszysz „to zależy”, zapytaj: „od czego?”
„To zależy” nie jest złą odpowiedzią. To jest zaproszenie do doprecyzowania.
Zamiast przechodzić dalej, zatrzymaj się i zapytaj:
„Od czego konkretnie?”
Oto przykład.
Użytkownik:
„To zależy, czy bym tego używał.”
Ty:
„Od czego by to zależało?”
Użytkownik:
„Od tego, czy dałoby się to połączyć z naszym obecnym procesem.”
I nagle masz prawdziwy temat: nie chodzi o samą funkcję, tylko o dopasowanie do workflow.
5) Szukaj zachowań, nie deklaracji
Deklaracja:
„Tak, to brzmi przydatnie.”
Zachowanie:
„W zeszłym tygodniu spędziłem 3 godziny, robiąc to ręcznie.”
Deklaracja:
„Chętnie bym tego używał.”
Zachowanie:
„Dziś płacimy za inne narzędzie, żeby to obejść.”
Deklaracje są miękkie. Zachowania są twarde.
Dlatego warto pytać:
„Co zrobiłeś ostatnio, gdy ten problem się pojawił?”
„Czy próbowałeś to rozwiązać inaczej?”
„Czy płacisz za jakieś obejście?”
„Ile czasu na to tracisz?”
Jeśli użytkownik nie robi dziś nic, żeby rozwiązać problem, to może nie być wystarczająco ważny.
6) Nie zaczynaj od pokazywania rozwiązania
Jeśli od razu pokażesz funkcję, użytkownik zacznie ją oceniać. A Ty możesz przegapić najważniejsze: czy problem w ogóle istnieje.
Lepsza kolejność:
Najpierw zrozum sytuację użytkownika.
Potem sprawdź, jak dziś radzi sobie z problemem.
Dopiero na końcu pokaż pomysł lub prototyp.
Dzięki temu nie pytasz:
„Czy podoba Ci się nasze rozwiązanie?”
Tylko:
„Czy to rozwiązanie pasuje do problemu, który właśnie opisałeś?”
To ogromna różnica.
7) Dopytuj o konsekwencje
Nie każdy problem jest wart rozwiązywania. Czasem coś jest irytujące, ale nie na tyle ważne, żeby użytkownik zmienił zachowanie.
Dlatego pytaj:
„Co się stało, gdy tego nie zrobiłeś?”
„Kogo to dotknęło?”
„Ile czasu straciliście?”
„Czy miało to wpływ na klienta, sprzedaż, decyzję, raport, deadline?”
„Co by się stało, gdyby ten problem pojawił się znowu?”
Konsekwencje pokazują wagę problemu.
Jeśli użytkownik mówi:
„No, trochę mnie to denerwuje”
to co innego niż:
„Przez to nie zdążyliśmy wysłać raportu do zarządu.”
8) Pozwól na ciszę
To brzmi banalnie, ale jest bardzo ważne. Po odpowiedzi użytkownika często od razu wskakujemy z kolejnym pytaniem, żeby rozmowa „płynęła”.
A najlepsze rzeczy często pojawiają się po chwili ciszy.
Użytkownik mówi:
„Nie wiem, chyba było okej.”
Zamiast od razu iść dalej, poczekaj. Albo powiedz:
„Mhm, opowiedz więcej.”
Cisza daje użytkownikowi przestrzeń, żeby pomyśleć. A Tobie pozwala nie ratować rozmowy zbyt szybko.
9) Nie traktuj użytkownika jak projektanta produktu
Użytkownik jest ekspertem od swojego problemu, ale nie musi być ekspertem od rozwiązania.
Gdy mówi:
„Dodajcie przycisk X”
nie zapisuj od razu: „zrobić przycisk X”.
Zapisz:
„Użytkownik próbuje osiągnąć Y, ale dziś blokuje go Z.”
Potem zespół produktowy może znaleźć najlepsze rozwiązanie.
Dobre pytania pomocnicze:
„Co ten przycisk miałby Ci umożliwić?”
„Co by się zmieniło, gdybyś go miał?”
„Jak dziś radzisz sobie bez tego?”
„Dlaczego to jest ważne?”
10) Kończ rozmowę podsumowaniem i sprawdzeniem
Na końcu rozmowy warto powiedzieć:
„Sprawdzę, czy dobrze zrozumiałem…”
I podsumować:
jaki problem usłyszałeś,
kiedy się pojawia,
jak użytkownik radzi sobie dziś,
co jest największą konsekwencją.
Przykład:
„Czyli największy problem nie jest w samym raporcie, tylko w tym, że musisz go ręcznie składać z trzech źródeł i przez to tracisz około 2 godzin tygodniowo. Dobrze rozumiem?”
To daje użytkownikowi szansę poprawić Cię od razu. A Tobie daje dużo lepsze notatki.
Mini-checklista dobrej rozmowy z użytkownikiem
Przed rozmową:
Wiem, czego chcę się dowiedzieć.
Mam 5–7 pytań, ale nie trzymam się ich sztywno.
Nie zaczynam od prezentowania rozwiązania.
W trakcie:
Pytam o ostatnie konkretne sytuacje.
Dopytuję „co zrobiłeś zamiast?”.
Szukam kosztu, konsekwencji i częstotliwości.
Nie sugeruję odpowiedzi.
Gdy słyszę „to zależy”, pytam „od czego?”.
Po rozmowie:
Zapisuję obserwacje, nie tylko cytaty.
Oddzielam problem od propozycji rozwiązania.
Szukam wzorców w kilku rozmowach, nie jednej „mocnej opinii”.
Przykładowy zestaw pytań do skopiowania
„Kiedy ostatnio próbowałeś zrobić [X]?”
„Opowiedz mi krok po kroku, jak to wyglądało.”
„Co było najtrudniejsze albo najbardziej irytujące?”
„Co zrobiłeś, żeby to obejść?”
„Ile czasu / energii / pieniędzy Cię to kosztowało?”
„Co się stało, gdy tego nie udało się zrobić?”
„Kto jeszcze był w to zaangażowany?”
„Od czego zależy, czy to byłoby dla Ciebie ważne?”
„Jak dziś oceniasz ten proces w skali 1–5 i dlaczego?”
„Czy dobrze rozumiem, że największy problem to…?”
Jeśli w rozmowach z użytkownikami słyszysz głównie „to zależy”, „może”, „trudno powiedzieć”, to zwykle znak, że pytania są zbyt ogólne albo zbyt hipotetyczne.
Dobre rozmowy nie polegają na pytaniu użytkownika, co masz zbudować. Polegają na zrozumieniu:
co próbował zrobić,
gdzie utknął,
co zrobił zamiast,
ile go to kosztowało,
czy problem jest wystarczająco ważny, żeby zmienił zachowanie.
Jeśli chcesz zapamiętać jedną zasadę, niech będzie to:
Nie pytaj użytkownika, co by zrobił. Zapytaj, co zrobił ostatnio.
To jedno przesunięcie potrafi zamienić rozmowę pełną opinii w rozmowę pełną konkretów.