25. Za co zapłaci Twój klient? Jak to sprawdzić?

Rozmowy możesz też posłuchać na Youtube:

„Mamy duży worek funkcjonalności, które chcemy testować z użytkownikiem, ale tak naprawdę nie wiadomo, od których zacząć. Co wtedy?”

Transkrypcja

Radek: Dzień dobry. To już kolejny odcinek podcastu Design i biznes. Podcastu, w którym staramy się pokazać wartość płynącą z szeroko pojętego projektowania user experience, czyli tak zwanego UX-a. 

My jesteśmy projektantami. Prowadzimy swoją agencję i dzielimy się z wami naszym doświadczeniem i praktyczną wiedzą, która pochodzi z projektów, które realizujemy.

Za dużo pomysłów naraz 

Ilona: I na tapet bierzemy kolejny problem, z którym na co dzień spotykamy się w naszych projektach i z którym przychodzą nasi klienci. 

Mianowicie mają bardzo dużo pomysłów na funkcjonalności, które mają być w produkcie. I nie do końca wiedzą, które z nich realnie przynoszą wartość i za które klienci będą chcieli zapłacić.

Radek: Tak i ta niepewność bierze się stąd, że w zespole mamy różne osoby, które troszeczkę inaczej mogą patrzeć na nasz produkt i na jego rozwój. 

Inaczej będzie myśleć o tym osoba, która jest product ownerem. Inaczej będzie myśleć o funkcjonalnościach projektant / projektantka. A jeszcze inaczej osoba, która jest pomysłodawcą całego przedsięwzięcia. 

Jak się zbierze te wszystkie pomysły do jednego worka, okazuje się, że to jest naprawdę bardzo duży zbiór. I bardzo trudno wybrać te kluczowe funkcjonalności, za które… jak wcześniej powiedziała Ilona… za które klient zapłaci.

Za co zapłaci klient?

Ilona: I taka sytuacja będzie występowała zarówno dla produktów, które dopiero zaczynają (czyli których nie ma jeszcze na rynku i są w tym momencie tworzone), jak i tych, które już są na rynku i chcą się rozwijać. 

Problem pozostaje ten sam — co wziąć na road mapę? Co wziąć do planu jako następną funkcjonalność, żeby ten produkt przynosił większą wartość użytkownikom?

Radek: I są takie dwa poziomy zagnieżdżenia się tego problemu. 

Pierwszy poziom jest taki, kiedy wewnętrznie w zespole musimy zrobić shortlistę funkcjonalności, która wciąż jest jakąś hipotezą, ale już jakąś konkretną. 

Kolejny poziom dotyczy użytkownika. Jest to lista funkcjonalności, które wskaże użytkownik jako te, które są interesujące dla niego i potencjalnie za nie zapłaci.

Ilona: I w tym momencie przychodzimy my — projektanci user experience.

Radek: My sami nie przyjdziemy, wy musicie do nas przyjść…

Ćwiczenie buy a feature

Ilona: OK… więc kiedy przyjdziecie do nas i poprosicie nas o pomoc, to my z naszego worka z naszymi narzędziami wyciągniemy ćwiczenie, które nazywa się buy a feature, czyli w wolnym tłumaczeniu „kup sobie funkcjonalność”.

Radek: Przede wszystkim jest to ćwiczenie, które świetnie sprawdzi się w tych dwóch kejsach przy priorytetyzowaniu tej długiej listy funkcjonalności, którą udało nam się stworzyć zespołem.

Przyda nam się również w rozmowie z użytkownikiem, żeby tę listę już ostatecznie skrócić do tego finalnego kształtu. 

Ale jak wygląda mechanika takiego badania?

Zanim opowiemy, jak wygląda podstawowa forma tego badania, należy wspomnieć, że to badanie jest bardzo plastyczne. Można je wykonywać indywidualnie z jedną osobą, ale można też przeprowadzić taką sesję grupową.

W takim corze buy a feature jest przede wszystkim symulacja procesu podejmowania decyzji zakupowej, czy to w grupie, czy też indywidualnej.

I  teraz wyobraźmy sobie, że mamy listę np. 30. funkcjonalności. Każda z tych funkcjonalności ma swoją cenę…

Ilona: I ta cena jest różna. Jedna funkcja kosztuje 1 zł, inna 10 zł, a inna 15 zł.

Radek: Tak, ale gdybyśmy zsumowali te kwoty, to wyszłoby nam na przykład 100 zł. I osoba, która bierze udział w badaniu ma w portfelu 60 zł.

Ilona: Co oznacza, że ma ograniczony budżet. 

Radek: Tak, czyli nie kupi wszystkich funkcjonalności. Musi sama zdecydować, którą z tych funkcjonalności kupić.

Wiedza ilościowa i jakościowa

Ilona: Z jednej strony ograniczamy budżet i w ramach tego ograniczonego budżetu nasz respondent wybiera to, co jest najważniejsze.

My jako moderatorzy takiego ćwiczenia siedzimy obok naszego respondenta, widzimy, co wybiera i mamy szansę dopytać go o powody. Możemy go dopytać dlaczego. To daje nam fajną kombinację wiedzy ilościowej z jakościową. 

Radek: Tak i przy takim badaniu z użytkownikami, na przykład w sesji 1:1… Powiedzmy, że odbyliśmy 6 rozmów z takim badaniem buy a feature… Wtedy możemy sobie ilościowo policzyć, ile zostało wydane na daną funkcjonalność w tej grupie. 

Jakościowo możemy też zebrać feedback od klientów, dlaczego podjęli taką, a nie inną decyzję. Dlaczego wydali swoje pieniądze na te funkcjonalności, a nie na inne? Które były dla nich trudnym wyborem? Gdzie się wahali?

To jest bardzo ważna, wiedza jakościowa, która jest po tym wykorzystywana, jako na przykład argument sprzedażowy.

Tutaj dotykamy takiej fajnej relacji projektowania, które przynosi jakiś insight, oraz marketingu i sprzedaży, które mogą wykorzystać w komunikacji te argumenty, żeby sprzedać dany produkt. 

To jest absolutnie ważna rzecz.

Natomiast jeśli chodzi o takie ćwiczenie w fazie, gdy jesteśmy wewnątrz zespołu i rozmawiamy o funkcjonalnościach, których każdy z nas przynosi do stołu, to jest to świetna okazja, żeby podyskutować o każdej nich. 

Jest to okazja, żeby tak naprawdę wspólnie zastanowić się nad różnymi aspektami, które wiążą się z wprowadzeniem danej funkcjonalności. 

Bo nie tylko jest to część naszej strategii, ale też np. naszego budżetu, który może pochłonąć technologia wydewelopowania czegoś. 

I oczywiście sama kwestia użytkownika. W jakim stopniu nam się wydaje, że realnie przeniesie to wartość naszemu klientowi.

Więc to jest też ten moment, gdzie my jako zespół możemy sobie wspólnie trochę o tym podyskutować i pomyśleć. Gdzie zazwyczaj nie mamy w codziennej pracy czasu wziąć tego na warsztat i rzeczywiście przerobić ten temat krok po kroku.

Gdy nie wiemy, co testować

Ilona: Radek, przychodzę do ciebie z sytuacją. Powiedzmy, że reprezentuję produkt, który jest już jakiś czas na rynku, jakieś dwa, trzy, cztery lata. Mamy bardzo duży worek z funkcjonalnościami i chcemy testować pewne funkcje z użytkownikiem, ale tak właściwie nie wiemy które. Co w takiej sytuacji?

Radek: Rozumiem, że jesteś klientem, który wszedł na naszą stronę www.designzima.com i skontaktował się z nami przez nasz formularz. 

Na pewno chciałbym na początku zebrać od was listę funkcjonalności wszystkich pomysłów, które macie. I zbadałbym, na jakiej podstawie ona powstała, bo nie chciałbym, żebyśmy pracowali na rzeczach, które znalazły się tam z kosmosu. 

Chciałbym, żeby były to rzeczy, które biorą pod uwagę funkcjonalności sugerowane przez użytkowników. Jeśli takich mamy, albo wiemy to z jakiegoś researchu, który zrobiliśmy.

I chciałbym, żeby to były pomysły, które odbite są od konkurencji. Widzimy, że konkurencja coś wprowadziła i mamy podejrzenie, że w naszym produkcie może się to świetnie sprawdzić. Albo mamy na przykład jakieś usprawnienia na bazie tego, co już widzieliśmy u konkurencji.

I takie funkcjonalności, które zostały wymyślone na podstawie naszej strategii, którą chcemy dążyć. To jest też super ważne. Jako firma mamy jakieś ambicje, aspiracje, chcemy gdzieś być. I te funkcjonalności również muszą być spójne z tym kierunkiem. 

Must have, should have & nice to have

Radek: Mając na uwadze to, że naszym celem jest doprowadzenie do takiej shortlisty, którą będziemy mogli dalej testować z użytkownikiem, najpierw musimy sobie przeprowadzić wewnętrzne buy a feature. 

Żeby to zrobić, musimy nadać każdej z tych funkcjonalności jakąś wartość. A tę wartość nadajemy poprzez takie ćwiczenie, które się nazywa must have, should have i nice to have.

Chodzi o to, żeby pogrupować nasze funkcjonalności pod względem np. kosztów, trudności albo tego, jak nam się wydaje, że coś jest potrzebne użytkownikowi czy nie.

I tak na przykład must have to funkcjonalności, które są tanie, które są według nas corem danego produktu albo danej części produktu. I tu jesteśmy prawie pewni, że to powinno wejść. 

Should have to takie funkcjonalności, których nie jesteśmy pewni. Nie do końca czujemy… Wydaje nam się, że to powinno wejść, ale nie jesteśmy tak bardzo przekonani w przypadku must have.

Nice to have to totalne wodotryski. To są zazwyczaj rzeczy drogie, które nie budują podstawowej wartości.

Kiedy mamy już wszystkie funkcjonalności, które sobie wcześniej rozpisaliśmy na tych trzech obszarach, to możemy uznać, że wszystkie funkcjonalności, które są pod must have, mają wartość jednego punktu. 

Should have będą miały dwa, a nice to have trzy. 

Znaczy to tyle, że podczas badania jako użytkownik, gdy będę chciał kupić jakąś funkcjonalność, która określona została jako must have, będę musiał wydać 1 punkt. Żeby kupić coś z nive to have, będę musiał wydać 3 punkty, czyli więcej. 

To jest bardzo dobre, bo do samego ćwiczenia możemy ustalić konkretne kwoty. I tak np. funkcjonalność z must have kosztuje 10 zł, funkcjonalność should have 60 zł, a budżet użytkownika to 120 zł. 

Ale przyszłaś do mnie Ilona jako klientka. Więc tutaj bym chyba zaproponował po tej priorytetyzacji takie ćwiczenie z całym waszym zespołem.

Wziąłbym 4-5 osoby, które są głównie odpowiedzialne za powstawanie tego produktu, czy też jego rozwój i przeprowadziłbym z nimi taką sesję grupową.

Chciałbym, żebyście wspólnie podjęli decyzję, jak będzie wyglądała wasza krótka lista funkcjonalności.

To jest świetna okazja do tego, żebyście mieli żywą, odpowiedzialną, moderowaną dyskusję na temat tego, co do tej shortlisty wejdzie.

Podliczanie punktów

Ilona: No dobra. Przeprowadziliśmy tę dyskusję, ale wciąż pozostaje pytanie, co testować?

Radek: My przygotowujemy podsumowanie tego badania. Z jednej strony zliczamy to, co zostało wskazane, co zostało kupione. Z drugiej strony rozpisujemy te wszystkie wasze argumenty.

W zależności od tego, jaka ta lista nam wyszła… bo może być tak, że będzie tych funkcjonalności dużo za dużo, żeby podejść do użytkownika i przeprowadzić z nim podobne ćwiczenie… wtedy jeszcze robimy jakiś wspólny cut, który jest naszą rekomendacją, opierającą się na tym, co usłyszeliśmy w badaniu z wami.

Jak długo trzeba czekać na efekty?

Ilona: Ile taki proces może zająć czasu?

Radek: Jeśli mówimy o takim wewnętrznym buy a feature, to dwa tygodnie. Jeśli włączymy w to jeszcze proces rozmowy i badań z użytkownikiem, to cały proces zajmie cztery tygodnie. 

Ilona: Czyli możemy powiedzieć, że możemy zacząć od posiadania bardzo dużej chmury funkcjonalności, a po czterech tygodniach, możemy skończyć z listą, która jest przetestowana. Mamy poukładane priorytety, co powinniśmy wziąć jako kolejną funkcję na naszej road mapie produktowej.

Radek: Dokładnie. Ale pamiętajmy, że buy a feature nie powie w 100%, za co zapłaci Twój użytkownik. On podpowie ci, za co może zapłacić twój użytkownik. A to już jest bardzo wartościowe. 

Dzięki buy a feature możemy ograniczyć ryzyko, które może nastąpić, jeśli popełnimy błąd, jeśli wrzucimy coś, co nam się wydaje.

O ile intuicja bardzo często nas nie zawodzi i jest świetnym narzędziem, którego należy słuchać, bo jest wypracowana przez nasze doświadczenia i to nie jest nic z kosmosu, tylko to jest praca naszego mózgu… ale jednak warto spytać się użytkownika, warto przegadać, zanim coś wprowadzimy, zanim wydamy na coś pieniądze.

Ilona: I jeszcze kolejny problem, który adresuje to ćwiczenie, to pewnego rodzaju impas. Gdy wewnętrznie dyskutujemy długimi tygodniami, nie dochodząc nawet do tej listy kluczowych funkcjonalności. 

Z jednej strony możemy przez miesiąc wszyscy w zespole dyskutować i nie dojść do niczego, albo możemy mieć po takich czterech tygodniach odpowiedź od użytkowników.

Rodzaje buy a feature

Radek: Tak jak już wcześniej wspomniałem, mechanika buy a feature jest bardzo uniwersalna. Można tworzyć różne scenariusze badawcze na podstawie tej mechaniki, a sama forma tego ćwiczenia też może przybierać różne postacie. 

Można robić to online, na przykład używając tablic na Miro, wykorzystując krótkie opisy, fotografie, ikonografie. Można też przygotować narzędzia i spotkać się z zespołem albo z użytkownikiem offline. 

Świetnym narzędziem jest Monopoly money, które można wziąć do ręki, przetestować i podzielić na kupki. Można wykorzystać drukowane karty, które będą miały fotografie obrazujące czym mniej więcej, jest dana funkcjonalność. To tylko kwestia już dobrania do danego wyzwania i celu badania. 

Natomiast tak jak też krótko wspomniałem, możemy to badanie przeprowadzić zarówno indywidualnie, jak i grupowo. I to już też zależy od danego produktu, bo niekiedy w decyzję zakupową uwikłana jest więcej niż jedna osoba…

Mieliśmy taką sytuację, w której badaliśmy sylwetkę konsumenta, którym był licealista, a dokładnie pierwszoklasista. I te osoby, jeśli podejmują decyzję zakupową, to podejmują ją wspólnie z rodzicami.

I tutaj musieliśmy zrobić na przykład badanie w diadach, żeby sprawdzić, jaka jest dynamika w podejmowaniu decyzji. Bo z jednej strony dziecko ma potrzebę, chce kupić, a rodzic jest sponsorem realizacji tej potrzeby.

Więc obserwacja energii, jaka zachodzi między rodzicem a dzieckiem w tym wypadku, jest bardzo ważna. Przypomnę, że pojawia się potem ten wątek marketingowo-sprzedażowy. I potem tymi argumentami, którymi dziecko przekonuje swojego rodzica do zakupu, będziemy przekonywać do zakupu naszego klienta w komunikatach marketingowych.

Więc to są naprawdę bardzo cenne rzeczy jakościowe, które można wyciągnąć i bardzo polecamy to ćwiczenie na wielu płaszczyznach.

Podsumowanie

Ilona: Reasumując, to, o czym dzisiaj powiedzieliśmy… 

Często klienci przychodzą do nas z problemem bardzo wielu funkcjonalności, gdzie nie wiedzą, które powinny być kolejne przy wdrożeniu. 

My, projektanci UX, jesteśmy w stanie pomóc im poprzez metodę buy a feature, którą dzisiaj omówiliśmy w tym odcinku. Ta metoda może pomóc w określeniu priorytetów na road mapie. Może też pomóc dostarczyć nam informacji o naszym użytkowniku i na przykład o personie UX. Może pomóc nam w momencie, kiedy nie mamy jeszcze produktu na rynku, żeby go dookreślić, żeby nadać mu jakiś ramy.

Radek: Jeśli chcecie się zgłosić do nas po to, żebyśmy przeprowadzili u was w firmie albo z waszymi użytkownikami takie ćwiczenie, zapraszamy do kontaktu poprzez naszą stronę www.designzima.com.

Możemy porozmawiać o waszym wyzwaniu. O tym, czy tego potrzebujecie w ogóle. Jaką formę by miało to przyjąć. I umówimy się na przykład na jakąś sesję. 

Także zapraszamy was do kontaktu!

Dziękuję wam bardzo za wysłuchanie tego odcinka i mam nadzieję, że niedługo widzimy się ponownie… słyszymy się w zasadzie… chociaż z niektórymi może się zobaczymy.

Ilona: Dziękujemy, że wysłuchaliście tego odcinka i słyszymy się w kolejnym.

Radek: Do usłyszenia, cześć.

Podobał Ci się ten odcinek?