Przewodnik produktowy
Onboarding: pomóż użytkownikowi ruszyć dalej
Piotr, założyciel Voicedot
Na tej stronie
Daj właściwej osobie jedno zadanie. Poproś o wyjaśnienie tam, gdzie nie wie, co dalej. Oddziel jej obserwację od własnego pomysłu na przyczynę.
Najpierw zadanie. Potem opinia.
„Wypróbuj onboarding” to wiele możliwości. „Utwórz projekt i zaproś osobę z zespołu” to konkretne zadanie.
Wskaż konfigurację do testu i chroń dane produkcyjne. Nie objaśniaj wcześniej każdego elementu. Sprawdzasz, co interfejs mówi sam.
Zapytaj w chwili niepewności
Powiąż pytania z zadaniem:
- Co chcesz zrobić w tym miejscu?
- Jakiego efektu oczekujesz po tym działaniu?
- Co stało się zamiast tego lub czego nie dało się ustalić?
- Jaka informacja pomogłaby zdecydować, co zrobić dalej?
Użytkownik nie musi znać technicznej przyczyny. Wystarczy wyjaśnienie, z którym zespół znajdzie i omówi problem.
Oddziel obserwację od interpretacji
Wysłanie zaproszenia do zespołu.
Oddziel obserwację od interpretacji
Obserwacja użytkownika
- Przykład
- „Po wybraniu Wyślij zaproszenie ekran pozostał bez zmian. Nie wiem, czy cokolwiek zostało wysłane”.
Co warto zachować
- Przykład
- Ekran zaproszeń, wybrany element sterujący i widoczny stan po działaniu.
Możliwa interpretacja
- Przykład
- Może brakować potwierdzenia lub trudno je zauważyć.
Co nadal trzeba sprawdzić
- Przykład
- Czy zaproszenie wysłano? Co widział użytkownik? Jakie potwierdzenie powinien dostać?
Decyzja po sprawdzeniu
- Przykład
- Popraw działanie, potwierdzenie lub opis na podstawie sprawdzenia, nie pierwszego przypuszczenia.
| Warstwa | Przykład |
|---|---|
| Obserwacja użytkownika | „Po wybraniu Wyślij zaproszenie ekran pozostał bez zmian. Nie wiem, czy cokolwiek zostało wysłane”. |
| Co warto zachować | Ekran zaproszeń, wybrany element sterujący i widoczny stan po działaniu. |
| Możliwa interpretacja | Może brakować potwierdzenia lub trudno je zauważyć. |
| Co nadal trzeba sprawdzić | Czy zaproszenie wysłano? Co widział użytkownik? Jakie potwierdzenie powinien dostać? |
| Decyzja po sprawdzeniu | Popraw działanie, potwierdzenie lub opis na podstawie sprawdzenia, nie pierwszego przypuszczenia. |
Zapisany widok pomaga zobaczyć stan strony. Nie jest nagraniem całej sesji ani diagnozą backendu.
Dopytaj bez podsuwania rozwiązania
„Po czym poznasz, że wysłano zaproszenie?” pozwala poznać oczekiwania. „Czy komunikat rozwiąże problem?” podsuwa odpowiedź. Wybierz pierwsze.
Za ogólnie? Wróć do miejsca i działania. Użyj przykładów uwag jako pomocy w doprecyzowaniu uwagi.
Przygotuj zmianę do wykonania
PRZEGLĄD ZADANIA
Zadanie użytkownika:
Strona i istotny stan:
Oryginalny komentarz:
Późniejsze doprecyzowanie:
Co jest potwierdzone:
Co wymaga dalszego sprawdzenia:
Uzgodniona zmiana:
Jak ją sprawdzimy:Przeczytaj uwagę przy stronie i omów ją z zespołem. Dalej skorzystaj z Markdown lub agenta. W podsumowaniu zachowaj odwołanie do oryginału.
Sprawdź kolejną wersję
Poproś o ponowne wykonanie zadania. Sprawdź, czy zmiana wyjaśniła wątpliwość i nie stworzyła nowej.
Jedna osoba może wskazać ważny problem. Nie mówi to, jak często występuje ani czy tłumaczy każde porzucenie procesu.
Częste pytania
Czy Voicedot znajduje dla mnie testerów?
Nie. Zapraszasz wybrane osoby lub zbierasz uwagi obecnych użytkowników. Produkt obsługuje uwagi, ale nie rekrutuje panelu.
Czy potrzebujemy rozmowy na żywo?
Nie zawsze. Przy konkretnej sprawie może wystarczyć komentarz. Rozmowa na żywo pomoże, gdy trzeba lepiej zrozumieć zadanie lub różnicę zdań.
Czy powinniśmy poprawić wszystko, co zostanie wspomniane?
Nie. Zrozum problem, sprawdź oczekiwane zachowanie i wybierz priorytet. Nowa funkcja i niejasna instrukcja wymagają różnych decyzji.