Product discovery w małej firmie: 5 kroków do lepszego UX produktu

Product discovery to rozpoznawanie potrzeb użytkowników i sprawdzanie pomysłów przed rozpoczęciem pełnego developmentu. Discovery odpowiada na pytania: jaki problem rozwiązujemy, dla kogo i po czym poznamy, że rozwiązanie pomaga. Delivery oznacza zaprojektowanie, zbudowanie i wdrożenie wybranego rozwiązania. Discovery nie zastępuje projektu ani programowania, lecz zmniejsza ryzyko rozpoczęcia prac nad funkcją opartą wyłącznie na założeniu.

Rozpocznij discovery, gdy klienci zgłaszają ten sam kłopot różnymi kanałami, dane pokazują odpływ na konkretnym etapie albo zespół nie potrafi uzgodnić, którą zmianę wdrożyć. Proces przydaje się także przed przebudową sklepu, jeśli firma nie wie, czy problem dotyczy nawigacji, informacji, cen czy ograniczeń technicznych. Nie trzeba prowadzić osobnego projektu badawczego dla każdej drobnej poprawki, której przyczynę da się już potwierdzić.

Zespoły e-commerce mogą połączyć discovery z analizą zachowania w lejku. Diagnoza porzuconego koszyka WooCommerce pokazuje, jak rozpoznawać bariery w ścieżce zakupowej. Jeśli rozpoznany problem wymaga nowego lub przebudowanego sklepu, projekt sklepu internetowego na WooCommerce może być kolejnym etapem po ustaleniu potrzeb. Proste wyjaśnienie pojęć znajdziesz w materiale co oznacza UX.

Wybierz problem, który pojawia się w więcej niż jednym źródle i ma znaczenie dla użytkownika lub wyniku firmy. Zbierz sygnały z obsługi klienta, analityki, sprzedaży i zwrotów, ale zachowaj kontekst: skarga, kliknięcie i zwrócony produkt nie mówią same z siebie, dlaczego użytkownik postąpił w określony sposób. Połącz sygnały w konkretne pytanie badawcze, na przykład: "Co utrudnia klientom znalezienie właściwego rozmiaru?".

Tabela odpowiada na pytanie, jakie źródła sygnałów połączyć i jak przełożyć je na pytanie do badania.

Wybieraj sygnały, które wskazują problem z zachowaniem lub zadaniem, a nie tylko ogólną potrzebę zmiany.

Zapisz każdy sygnał w tym samym formacie: źródło, data, kontekst, obserwacja i możliwy wpływ. Obserwacja brzmi: "trzy zgłoszenia dotyczyły wyboru rozmiaru". Interpretacja brzmi: "tabela rozmiarów jest nieczytelna". Dopiero rozmowa lub test może potwierdzić interpretację. Jeśli sygnały dotyczą kilku problemów, badaj je osobno albo wybierz ten, który ma najwięcej dowodów i da się sprawdzić przed kosztowną zmianą.

Hipoteza badawcza powinna wskazywać użytkownika, problem i obserwowalny skutek, który może ją potwierdzić lub podważyć. Użyj szablonu: "Użytkownicy [grupa] mają trudność z [zadanie], ponieważ [podejrzewana przyczyna]; sprawdzimy to przez [metoda]". Przykład: "Klienci wybierający rozmiar mają trudność z oceną dopasowania, ponieważ tabela nie pokazuje sposobu pomiaru; sprawdzimy to w rozmowach i teście prototypu".

Pytania badawcze powinny dotyczyć zachowania i doświadczeń, a nie oczekiwanej funkcji. Pytaj: "Jak ostatnio wybierałeś rozmiar?", "Co zrobiłeś, gdy nie byłeś pewien?" albo "Jak rozumiesz tę informację?". Unikaj pytań sugerujących odpowiedź, na przykład: "Czy przydałaby się tabela z większą liczbą rozmiarów?". Przed badaniem zapisz, jaki wynik zmieni decyzję, na przykład problem powtarzający się podczas samodzielnego zadania.

Ustal także warunek odrzucenia hipotezy. Jeżeli rozmówcy wykonują zadanie bez trudności, a problem pojawia się wyłącznie w zgłoszeniach po zakupie, przyczyna może leżeć gdzie indziej. Jedno badanie jakościowe nie szacuje częstości problemu w całej populacji; służy do odkrywania mechanizmu i kolejnych pytań.

Do jakościowego badania produktu zaproś 5-8 osób, jeśli chcesz rozpoznać wzorce problemów w wąskiej grupie użytkowników, a nie obliczyć ich udział w całym rynku. Dobieraj uczestników do badanego zachowania, na przykład osoby, które niedawno kupowały produkt z danej kategorii albo przerwały proces rejestracji. Osobno uwzględnij nowe osoby i klientów powracających, jeśli ich doświadczenie może się różnić.

Tabela pomaga ustalić, kogo zaprosić do jakościowego badania i dlaczego dane kryterium wpływa na dobór uczestników.

Dobór uczestników do konkretnego zachowania daje zespołowi użyteczniejsze obserwacje niż przypadkowy nabór.

Przygotuj krótkie kryteria rekrutacji: niedawne wykonanie zadania, używane urządzenie, rola w decyzji i brak udziału w projektowaniu badanego rozwiązania. Rekrutuj przez bazę klientów, obsługę, newsletter lub kontakt bezpośredni. Jeśli firma nie ma własnej bazy, poproś o udział osoby z grupy docelowej poza zespołem i nie przedstawiaj ich opinii jako danych od klientów. Nie rekrutuj wyłącznie znajomych pracowników, bo mogą znać firmę i jej założenia.

Nie obiecuj, że kilka rozmów reprezentuje wszystkich klientów. Jeśli celem jest zmierzenie odsetka osób z problemem, potrzebne będzie badanie ilościowe z odpowiednim doborem próby. Discovery może wskazać, co warto później policzyć.

Rozmowę prowadź wokół ostatniego rzeczywistego doświadczenia, a prototyp testuj zadaniem, które uczestnik ma wykonać bez podpowiedzi. Zacznij od wyjaśnienia celu, uzyskania zgody na notatki lub nagranie i zapewnienia, że oceniasz produkt, a nie uczestnika. Następnie poproś o opis ostatniej sytuacji, pokaż zadanie lub prototyp i obserwuj, co osoba robi oraz mówi.

Przykładowe zadanie: "Znajdź produkt, który pasuje do podanego zastosowania, i powiedz, co sprawdziłbyś przed zakupem". Nie mów, gdzie kliknąć, i nie poprawiaj uczestnika od razu. Gdy osoba utknie, poproś: "Co teraz próbujesz zrobić?" albo "Czego się spodziewałeś?". Zapisz punkt zatrzymania, błędną interpretację, oczekiwanie i rezultat zadania.

Unikaj prezentowania gotowego rozwiązania przed poznaniem problemu. Pytanie "Czy podoba ci się nowa funkcja?" sprzyja uprzejmej opinii, ale nie pokazuje, czy funkcja pomaga wykonać zadanie. W teście prototypu uczestnik może mówić o tym, co widzi, jednak deklaracja zamiaru zakupu nie jest dowodem przyszłej sprzedaży.

Perspektywa KC Mobile: w badaniu sklepu zestawiamy wypowiedź klienta z zachowaniem na konkretnej kategorii lub karcie produktu. UX sklepu internetowego i bariery zakupowe pomaga wyznaczyć miejsca, które warto sprawdzić w rozmowie lub prototypie.

Wniosek badawczy powstaje przez oddzielenie tego, co uczestnik zrobił lub powiedział, od interpretacji zespołu. Po każdej sesji zapisz konkretne zachowania, krótkie cytaty z kontekstem, momenty wahania i warunki zadania. Następnie oznacz powtarzające się problemy i sprawdź, czy pochodzą z tego samego mechanizmu, czy tylko przypominają się słowami.

Przykład zapisu: obserwacja - uczestnik otworzył filtr, wybrał rozmiar i wrócił do listy; interpretacja - nie rozpoznał, że filtr się zastosował; hipoteza - stan aktywnego filtra jest słabo widoczny. Nie zamieniaj interpretacji w fakt przez samo powtórzenie jej w raporcie. Wnioski porównaj z analityką i zgłoszeniami: dane ilościowe mogą pokazać, gdzie problem występuje, a rozmowy wyjaśnić, dlaczego.

Grupuj problemy według użytkownika, zadania, warunku i możliwego wpływu. Zapisuj przypadki odmienne, bo mogą ujawnić, że trudność występuje tylko na telefonie albo przy określonym typie produktu. Nie licz samych wzmianek jako wskaźnika rynkowego; niewielka próba jakościowa służy rozpoznaniu wzorców, a nie wyliczeniu rozpowszechnienia.

Po syntezie przygotuj krótkie stwierdzenie problemu, dowody za nim, dowody przeciw niemu i nierozstrzygnięte pytania. Zespół może wtedy sprawdzić, czy rozwiązaniem jest zmiana treści, procesu, interfejsu czy funkcji. Jeśli problem jest niejasny, wróć do użytkowników przed planowaniem developmentu.

Priorytetem powinien być problem, który ma mocne dowody, istotny wpływ na użytkownika i możliwy do sprawdzenia przy akceptowalnym koszcie. Oceń wpływ na użytkownika, wartość biznesową, koszt wdrożenia i ryzyko błędnej interpretacji. Kryteria oceniaj jawnie, a nie ukrywaj w jednym wyniku punktowym, który sprawia wrażenie precyzyjnego pomiaru.

Tabela pozwala porównać możliwe działania według wpływu na użytkownika, wartości biznesowej, kosztu i ryzyka.

Porównanie porządkuje rozmowę zespołu, ale nie zastępuje dowodów z badania ani danych o kosztach.

Przed pełnym developmentem przygotuj prototyp o minimalnym zakresie i sprawdź, czy użytkownicy potrafią wykonać zadanie. W sklepie może wystarczyć test zmienionej karty lub procesu na makiecie. Po teście zapisz, co potwierdziło problem, co pozostało niejasne i czy trzeba wrócić do hipotezy.

Jeśli potrzebujesz wykonawcy, tworzenie sklepów internetowych na WooCommerce pozwala przejść od rozpoznanych potrzeb do projektu i wdrożenia. Zakres prac warto poprzedzić diagnozą problemu, aby ustalić, czy potrzebna jest zmiana UX, procesu, integracji czy funkcji.

Efekt discovery mierz tym, czy zespół podjął decyzję opartą na dowodach, a wdrożone rozwiązanie poprawiło wskaźnik powiązany z badanym problemem. Przed zmianą zapisz wartość bazową, okres, segment użytkowników, urządzenie i sposób pomiaru. Po wdrożeniu porównaj te same warunki i sprawdź, czy poprawa nie wynika ze zmiany ruchu, sezonowości albo kampanii.

Tabela łączy rodzaj badanego problemu z miernikiem i warunkiem rzetelnego porównania przed zmianą i po niej.

Dobór wskaźnika do badanego problemu ułatwia odróżnienie poprawy produktu od zmiany warunków ruchu.

W GA4 można użyć eksploracji lejka do oglądania przejść między krokami oraz eksploracji ścieżki do analizy kolejnych działań. Google podaje, że lejek pokazuje liczbę użytkowników odpadających między krokami; poprawne wnioski wymagają prawidłowych zdarzeń i ustalonych warunków lejka. Dla zadania jakościowego dołącz wynik obserwacji, na przykład informację, czy uczestnik ukończył zadanie bez podpowiedzi.

Jeśli zmiana nie poprawia wskaźnika, wróć do hipotezy i sprawdź, czy problem był dobrze zdefiniowany, wdrożenie działało zgodnie z projektem i pomiar obejmuje właściwe zachowanie. Porównanie metod badania UX sklepów ułatwi dopasowanie metody do pytania badawczego. Gdy bariera dotyczy pozyskiwania i konwersji, wybór partnera CRO wymaga oceny procesu pracy i sposobu weryfikacji zmian.

• User experience design: jak przejść od problemu użytkownika do sprawdzonego projektu
• Jak wykorzystać UX i CRO w e-commerce: plan poprawy konwersji
• Jak stworzyć przyjazny klientowi sklep internetowy
• Customer experience: co oznacza i jak poprawić doświadczenie klienta