Czy wiesz kim jest i czego potrzebuje użytkownik Twojego produktu? Stworzenie strony, czy aplikacji odpowiadającej na potrzeby użytkowników to nie lada wyzwanie. Problemem okazuje się już samo zidentyfikowanie potrzeb i zbudowanie na ich podstawie listy funkcjonalności niezbędnych do wdrożenia. Czym zatem są potrzeby? Jak je rozpoznawać?

3 rodzaje potrzeb użytkowników

Zacznijmy od tego, że z reguły ludzie są przekonani, że znają swoje potrzeby. Są dorośli, świadomi, wiedzą, czego chcą. Na Twoje pytanie o potrzeby są w stanie odpowiedzieć bez zastanowienia.  A Ty możesz wziąć tę listę wymagań za pewnik i zmienić cały swój produkt, albo… na chwilę się zatrzymać i zastanowić. “Czy ludzie naprawdę wiedzą, czego potrzebują?”. Mam dla Ciebie złą wiadomość… nie wiedzą.

To, co użytkownicy mówią, że potrzebują

Potrzeby możemy podzielić na trzy grupy. Pierwsza z nich jest oczywista- to wszystko to, co użytkownicy mówią, że potrzebują. Integracja z innymi systemami, możliwość nakładania filtrów na zdjęcia w aplikacji, albo szybkiego zakupu produktów, więcej kolorów, żeby było ładniej. To przecież oczywiste! Każdy wie, czego potrzebuje.

Musisz jednak pamiętać, że na potrzeby te wpływają takie czynniki, jak emocje, zdrowie i otoczenie, a wszystko to jest tymczasowe, co oznacza, że trudno przewidzieć  na tej podstawie przyszłe wymagania. To, że w aplikacji do planowania zadań ktoś  właśnie potrzebuje możliwości wygenerowania raportu z wykresami kołowymi nie oznacza, że powinieneś siadać do biurka, by pracować nad nową funkcjonalnością. To potrzeba, która zrodziła się, gdy zaistniały określone okoliczności w życiu użytkownika. Już za kwadrans wszystko może ulec zmianie.

To, czego użytkownicy naprawdę potrzebują

Druga grupa potrzeb to już nie chwilowe zachcianki, a potrzeby rozwiązania problemów. Gdy użytkownicy natrafiają na problem, bardzo łatwo jest im wyobrazić sobie jego rozwiązanie- funkcjonalność, narzędzie, czy sposób, który uwolni ich od zmartwienia. Niezależnie od formy, wyobrażone rozwiązanie staje się potrzebą. Tak docieramy do drugiej grupy, do tego, czego użytkownicy naprawdę potrzebują- rozwiązania problemu.

I tutaj jednak podążanie za wskazaniami użytkowników może być błędne. Bardzo często wybrane rozwiązanie jest tylko odpowiedzią na objaw problemu, nie jego źródło. To, czego użytkownik potrzebuje staje się więc jedynie środkiem przeciwbólowym, nie lekiem. W takim przypadku Twoja praca nad produktem, w odpowiedzi na tak zakomunikowane potrzeby, także nie osiągnie pozytywnego rezultatu.

To, czego użytkownicy nie wiedzą, że potrzebują

I tak trafiamy do ostatniej grupy potrzeb- do oczekiwanego rezultatu, znacznie ważniejszego niż wybrane narzędzie. Ostatni poziom potrzeb to rodzaj przeczucia, pożądania, oczekiwania, na które brakuje konkretnej odpowiedzi. Oczywiście, gdy spytasz użytkowników o szczegóły będą w stanie je określić, nie będą to jednak odpowiedzi, z Twojego punku widzenia, wartościowe. Znakomicie ujął to Henry Ford mówiąc „gdybym na początku swojej kariery jako przedsiębiorca zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem.”[1] Nie chodzi jednak o to, by lekceważyć użytkowników i tworzyć produkty w odosobnieniu, ale o to, by zadawać właściwe pytania.

Użytkownicy B2B a B2C

Nie zawsze Twój zespół będzie dysponował wykwalifikowanym zespołem badaczy. Tak naprawdę nie zawsze będzie mógł pozwolić sobie na jakiekolwiek sformalizowane badania użytkowników. Między innymi z tego powodu warto, abyś jako jeden z członków zespołu, potrafił zidentyfikować potrzeby użytkowników produktu, nad którym pracujesz. Dzięki temu nie tylko stworzysz produkt dający prawdziwą wartość, ale też zaoszczędzisz mnóstwo czasu, który mógłbyś zmarnować na wdrażanie i usuwanie niepotrzebnych funkcjonalności.

Proces zdobywania informacji będzie przebiegał w nieco inny sposób, w zależności od rodzaju użytkowników, dla których powstaje Twój produkt- czy będą to użytkownicy biznesowi, czy indywidualni klienci. Jak identyfikować potrzeby obu tych grup?

Identyfikacja potrzeb użytkowników B2B

Zacznijmy od klientów biznesowych. To, że tworzysz produkt na potrzeby firmy nie oznacza, że nie musisz zwracać uwagi na ludzkie potrzeby, wręcz przeciwnie- rozwiązujesz realne problemy pracowników, to oni są najważniejsi. Na Twoją korzyść będzie zwykle przemawiał budżet projektu, który pozwoli Ci na więcej, nie możesz  jednak z tego powodu zmieniać założeń produktu w nieskończoność. Po prostu się przygotuj.

Pytania, które warto zadać podczas zdobywania wymagań powinny być otwarte i nie mogą naprowadzać użytkowników na odpowiedzi. Najważniejsze jest jednak to, aby nie dotyczyły one konkretnych rozwiązań, z których korzystają użytkownicy, a procesu, jaki przechodzą, by osiągnąć cel powiązany z Twoim produktem. Pamiętasz? Użytkownicy nie wiedzą, czego tak naprawdę potrzebują, Twoim zadaniem jest rozwiązać ich problem, nie spełniać zachcianki.

Załóżmy, że pracujesz właśnie nad aplikacją do planowania codziennych zadań, zgodną z metodyką Kanban. O co powinieneś spytać? Zamiast pytać użytkowników, z której aplikacji do planowania korzystają teraz, powinieneś skupić się na samym procesie planowania zadań.

Spytaj o sposób w jaki użytkownicy planują zadania. Kiedy to robią? Jakie dodatkowe narzędzia wykorzystują (może tablicę, na której przyklejają post-ity)? Z jakimi problemami się borykają? Które elementy procesu są dla nich proste? Co jest niezrozumiałe? Możesz też spytać o inne aplikacje, strony, czy systemy, z których użytkownicy korzystają w ciągu dnia. Być może warto, by były one zintegrowane z Twoim nowym produktem. Dowiedz się wszystkiego o zarządzaniu projektami/produktami w ich firmie, poznaj proces z perspektywy pracowników na różnych szczeblach hierarchii.

Wyniki wywiadów z użytkownikami warto wspierać narzędziami, które pozwalają uporządkować wiedzę i określić wymagania produktu, takich jak np. mapowanie. Twórz diagramy, mapy doświadczeń, mapy procesu, analizuj je z użytkownikami. Twoja praca może nie tylko zweryfikować poprawność założeń dotyczących produktu, ale także procesów klienta, a dzięki temu np. wyeliminować czasochłonną, choć niepotrzebną funkcjonalność Twojego produktu. Przykład? Bardzo często wśród wymogów firmy znajdują się raporty, czy dokumentacja, której generowanie jest niezwykle uciążliwe. W trakcie mapowania okazuje się jednak, że są to dokumenty zbędne lub dublowane, można je więc usunąć.

Identyfikacja potrzeb użytkowników B2C

Praca nad produktem dla użytkowników indywidualnych wiąże się z dużo większą niepewnością, co wynika z różnorodności ludzi, do których on trafia. Jak zebrać wymagania? Tu także zadawane pytania powinny być otwarte i nie mogą naprowadzać użytkowników na odpowiedzi. Przydatne może się okazać też pamiętanie o trzech zasadach ułatwiających przeprowadzenie rozmowy:

1. nie rozwiązuj problemu,
2. nie sugeruj rozwiązania,
3. nie dawaj rad.

W przypadku klientów B2B najważniejsze jest skupienie na procesie, w którym uczestniczą użytkownicy. Jak jest z klientami B2C?  Z uwagi na charakter użytkowników, zadawanie pytań o sam proces może nie być wystarczające. Użytkownicy B2C mają mniejszą wiedzę o procesie, czy technologii, mogą także mniej świadomie analizować problem, który rozwiązujesz. Tworząc produkt dla szerokiej grupy odbiorców możesz uzyskać nieprecyzyjne, bardzo rozproszone odpowiedzi, które ciężko będzie przełożyć na spójny produkt. Warto nieco złamać zasady współpracy z klientami B2B i nieco więcej uwagi skupić na samym problemie.

Jakie pytania warto zadać?

• Jak często spotykasz się z tym problemem?
• Jak często go rozwiązujesz?
• Jak często przechodzisz przez ten proces?
• Z którego etapu procesu zrezygnowałbyś, gdybyś miał taką możliwość?
• Z jakiej strony lub aplikacji korzystasz, by osiągnąć swój cel?
• W jaki sposób z niej korzystasz? Jak często?
• Co robisz przed, w trakcie i po skorzystaniu z tego rozwiązania?
• Co lubisz w tym rozwiązaniu?
• Co Twoim zdaniem można w nim ulepszyć lub poprawić?

W pracy z klientami B2C jak najszybciej postaraj się stworzyć prototyp produktu. Dzięki temu, że będziesz mógł przedstawić go użytkownikom i przeprowadzić testy (np. testy A/B), zdobędziesz najważniejsze informacje zwrotne. Twoi użytkownicy nie będą musieli wyobrażać sobie produktu, zamiast tego będą mogli wyrazić o nim swoje opinie, wybrać najważniejsze funkcje, przejść pełen proces. Pomóc mogą Ci też inne narzędzia, jak np. Buy a feature game-gra, która pozwala użytkownikom na wybór najważniejszych funkcjonalności zanim jeszcze je wdrożysz. Szukaj, sprawdzaj, testuj, a Twój produkt odpowie na realne potrzeby użytkowników i przyniesie im prawdziwą wartość.

Podsumowanie

Niezależnie od roli jaką spełniasz w zespole, warto, abyś aktywnie uczestniczył w procesie pozyskiwania wymagań, a także z rozsądkiem podchodził do potrzeb, które komunikują użytkownicy. Pamiętaj, że pomiędzy zachciankami, a prawdziwymi potrzebami jest cienka granica, której przekroczenie może kosztować Cię godziny niepotrzebnej pracy. Swoją uwagę skup na procesie lub problemie, który ma rozwiązać Twój produkt. Steve Jobs powiedział kiedyś, że „ludzie zazwyczaj nie wiedzą czego chcą do momentu, kiedy im tego nie pokażesz”[2]. I to jest właśnie Twoim zadaniem, jako twórcy produktu- znalezienie rozwiązań i pokazanie ich światu.

[1] https://pl.wikiquote.org/wiki/Henry_Ford

[2] http://www.edulider.pl/biznes/steve-jobs-najslynniejsze-cytaty

---

Inspiracje

J. Natoli, Think First: My No-Nonsense Approach to Creating Successful Products, Memorable User Experiences + Very Happy Customers, Baltimor 2015.

J. Natoli, UX Strategy Fundamentals, Udemy.

S. Krug, Nie każ mi myśleć! O życiowym podejściu do funkcjonalności stron internetowych. Wydanie III, 2014.

http://www.edulider.pl/biznes/steve-jobs-najslynniejsze-cytaty

---

Paulina Popowicz – absolwentka Zarządzania Projektami na Uniwersytecie Ekonomicznym w Poznaniu, zawodowo związana z marketingiem i brandingiem. Pasjonatka strategicznego UX. UXową wiedzę przemyca do codziennej pracy działu marketingu, w którym odpowiada za markę, a także współtworzenie nowych produktów i usług. W wolnym czasie pisze o tworzeniu produktów i usług na blogu paulapopowicz.pl.