O wejściu w UX z programowania i różnicach między tymi dziedzinami. Wywiad z Łukaszem Wakułą na UX Poland.

Konferencja UX Poland odbyła się w październiku i już za tydzień przeczytacie relację z tego wydarzenia. Tymczasem mamy coś specjalnego. Podczas prelekcji poprosiliśmy dwóch prelegentów – Łukasza i Kordiana Klechę o odpowiedzenie na parę pytań odnośnie projektowania, przyszłości i codziennej pracy.

Łukasz jest Senior UX Designerem w Hycom, a na UX Poland razem z Łucyną Dziewą opowiadali na temat tworzenia serwisu do zamawiania produktów marki Śnieżka. Łukasz nie zaczął swojej ścieżki od projektowania – przeszedł z front-endu. Poniżej zobaczycie i przeczytacie audiodeskrypcję wywiadu.

Wywiady z prelegentami przeprowadził Sebastian Jagła z redakcji magazynu.

Audiodeskrypcja

Wasza praca musi być bardzo ciekawa. Od Śnieżki, o której dzisiaj mówiłeś przechodzicie na pracę z wielkimi telecomami. Mógłbyś nam coś o tym opowiedzieć?

Tak, mamy taką przyjemność w Hycomie, że mamy bardzo dużą różnorodność projektów. Zdarzają się projekty malutkie takie jak np. zaprojektowanie interfejsu dla łazika na Marsie, po duże telecomy takie jak Orange czy T-mobile. Jest to dość ciekawe, ponieważ można zahaczyć o wiele różnych obszarów i nauczyć się fajnych rzeczy, ale również mamy w Hycomie bardzo fajną rzecz, która nazywa się Innowacje. To jest takie przedsięwzięcie, gdzie każdy z pracowników może zgłosić swój pomysł czy projekt, który chciałby zrealizować. Zarząd tych Innowacji decyduje, czy ten pomysł jest w porządku czy nie, czy możemy coś z tym zrobić, jakoś go rozwinąć wewnątrz firmy. Zostaje podjęta decyzja, następnie te projekty są wyłaniane i można w przeciągu tygodnia w czasie pracy zebrać zespół i wspólnie pracować tylko i wyłącznie nad tym pomysłem, który się wymyśliło lub też ktoś wymyślił i do niego dołączamy do zespołu. Na końcu jest konkurs, gdzie cała firma może głosować na najlepszy, najciekawszy dla nich projekt i te Innowację można wygrać.

Czyli jest całkiem elastycznie, jeśli chodzi o projekty?

Tak. I różnorodnie.

Ok. A dziś właściwie opowiadaliście o tym, że w Hycom przechodzicie co raz bardziej ze skupiania się na samym UX na skupianie się także na customer experience. Czy to wprowadza duże zmiany w tym jak pracujecie? 

Zdecydowanie tak. Nakład pracy, który też jest wykonywany w obszarze CX-owym jest bardzo duży i zupełnie nie chcemy tego niwelować w żaden sposób. A najbardziej, jako UX-owcy czy nawet część programistów i konsultantów, być już jak najwcześniej zaangażowanym w tym etapie wcześniejszym, żeby mieć wspólnie całą wizję, co chcemy wspólnie dostarczyć my jako Hycome dla naszego klienta, ale też i to, co klient chciałby dostarczać dla swojego końcowego użytkownika.

A powiedz mi, studiowałeś informatykę, później byłeś web developerem i teraz właśnie w Hycom jesteś Senior UXem. Teraz przechodzicie jeszcze na Customer Experience. Czy masz może w głowie pewne różnice pomiędzy tym, na czym skupia się web deweloper a tym, na czym skupia się projektant doświadczeń?

Tak. Myślę, że developerów można czasem podzielić na dwie grupy: takich, który lubią robić to, co robią i robią to bardzo dobrze, bardzo skutecznie i bardzo szybko, ale też na takich, którzy chcą wciąż się rozwijać i uczyć bardzo ciekawych rzeczy, i robić coś, co możliwe, że nawet tego nie potrafią. W zależności na kogo trafisz w zespole, tak też są różne trudności czy łatwości. Natomiast teraz tak jak wiemy UX-owcy chcą rozwiązać problemy, ale często są one spowalniane poprzez technologię i różnica jest też taka, że oni są strażnikami tego, co można rzeczywiście zrobić. My możemy wymyślić coś niesamowitego, coś rewolucyjnego, innowacyjnego, ale technicznie to może nie da się w ogóle tego zrobić. I fajnie jak się trafia na osobę, która chce się trochę bardziej otworzyć, czyli jeśli chodzi o programistę, i spróbować czegoś nowego. Czasem takie osoby się zdarzają. Im częściej tym ciekawiej można wspólnie realizować projekty.

To pewnie będzie ten główny zgrzyt pomiędzy zespołami UXu a web developerami, czy w ogóle developerami, że możliwości a chęci, prawda?

Tak, prawda. Natomiast jeśli dostrzeżemy wartość w developerach, a jest ogromna wartość w developerach, ponieważ oni faktycznie realizują te rzeczy, które my wymyślamy czy projektujemy i zaangażujemy ich jak najwcześniej w tym całym procesie projektowania czy nawet zbierania informacji, to oni też czują się nie jako osoby, które otrzymują coś i „weź no mi coś zakoduj”, tylko jako osoby, które biorą duży udział w tym jak to może naprawdę finalnie wyglądać i oni wtedy też trochę się czują jak projektanci. I to jest fajne, bo mają rzeczywiście wpływ na to jak to będzie wyglądało i oni – developerzy podnoszą swoje kwalifikacje, czy rozumienie tego na czym działa cały UX, jak rozwiązujemy te problemy, ale my jako projektanci dowiadujemy się o wiele więcej: jak technologia działa i czego możemy lub też nie możemy, co tez jest ogromną inwestycją na przyszłość.

Czyli biorąc jeszcze pod uwagę to, co mówiłeś wcześniej o Customer Experience, to tak naprawdę większość zespołu powinna być zaangażowana jak najwcześniej, żeby można było to wszystko wspólnie dopracować?

Tak, prawda. Oczywiście nie zawsze jest to finansowo możliwe, żeby każda osoba z zespołu brała udział, natomiast takie cykliczne spotkania w zespołach mieszanych i informowanie ich co się dzieje, na jakim jesteśmy etapie, jakie mamy informacje, są mega skuteczne. I to, jak wspomniałem, angażowanie osób, które potem realizują za kilka miesięcy, za miesiąc lub za dwa ten projekt, na wczesnym etapie jest mega super, bo on ich angażuje i oni sobie myślą „dobra, już wiem tyle i wiem, dlaczego coś mam dostarczyć w taki sposób a nie inny”.

Czyli to pomoże nie tylko w projektowaniu produktu, ale też w prowadzeniu zespołu?

Dokładnie tak. Wszyscy wtedy wsiadają na jeden pociąg na jednych torach, siedzą i kumają co można zrobić, czego nie można, czemu w ogóle musimy tak pracować czy też nie. Jeden z takich przyjemniejszych sukcesów mieliśmy jak robiliśmy rebranding NewMobile, gdzie wspólnie z developerami i z ekipą z New oraz z naszymi konsultantami tworzyliśmy cały ten produkt.  Wiedzieliśmy co możemy zrobić a co nie, ponieważ mieliśmy osoby od technologii bardzo blisko nas i oni nas albo spowalniali albo nam umożliwiali jakieś rzeczy, więc nie byliśmy wtedy w stanie wystosować jakiś niesamowitych oczekiwań, których koniec końców nie moglibyśmy zrealizować. A w taki sposób, kiedy pracujemy wspólnie, możemy powiedzieć „zrobimy to w taki sposób” i to rzeczywiście tak jak wcześniej wymyśliliśmy, to tak to dostarczyliśmy. Większość osób, która brała udział w tym projekcie u nas wewnętrznie w Hycome i również w New, jak słyszy ten projekt to ma uśmiech na twarzy, ponieważ on naprawdę przyniósł wiele radości, bo mieliśmy ogromną radość wspólnego tworzenia.

A powiedz mi, często słyszy się pytania, czy może stwierdzenia o tym, że projektant doświadczeń powinien lub nie powinien umieć kodować. Czy masz coś do dorzucenia w tym temacie?

Kodowanie nie jest fajne w większości, jest to żmudna praca, siedzenia non stop przy kompie i wpisywanie tego kodu. Ale ja np. nigdy nie lubiłem kodować programów komputerowych, które pisały się w konsolach, w masie linijek kodu, siedziało się tam przez półtorej godziny i na koniec konsola wypluwa Ci 3 albo 4, a Ty piszesz tam te pętle i inne rzeczy. Zawsze lubiłem robić rzeczy wizualne, które od razu było widać. Czy projektanci powinni umieć programować? Nie jest to mus i widzimy to teraz, natomiast jest to ogromna wartość, ponieważ przy projektowaniu musisz myśleć, jak to zostanie zakodowane. Musisz mieć jakiś background, żeby wiedzieć, czy ja mogę to postawić tu czy tam czy tutaj. Same zasady RWD wynikają z technologii i żeby je zgłębić to wychodzi potem na to, że jak sam kodujesz to mega łatwo będzie Ci zrozumieć, czemu tak to musi później wyglądać.

I czujesz, że rzeczywiście Twoje umiejętności w programowaniu teraz dają Ci jakieś zalety w pracy albo po prostu łatwość komunikacji z zespołem?

Zdecydowanie tak i nie chcąc się chwalić, ale jednak ta wiedza przybliża mnie bardziej do developerów, ponieważ znajdujemy wspólny język. Również jest mi łatwo oszacować, co możemy zrealizować w ramach projektu, co możemy zaprojektować albo jak problem rozwiązać, wiedząc na jakiej technologii w ogóle będziemy opierać to rozwiązanie.

A czy miałbyś jakąś poradę dla osoby, która chciałaby dokonać tego skoku z projektowania do programowania czy z programowania do projektowania, tak jak Ty zrobiłeś?

Tak, żeby spróbowali. Jest masa kursów na necie, to naprawdę może nic nie kosztować, a może być ogromną inwestycją na przyszłość i w samego siebie. Może to komuś się mega spodobać. Ja uwielbiam kodować front-endy, naprawdę to lubię, kilka fajnych projektów też udało mi się zrealizować – bardzo ciekawych, nietypowych. Może ktoś odnajdzie po prostu kolejną pasję w swoim życiu i będzie to też w stanie realizować. A jak nie, to chociaż będzie wiedział, jak rozmawiać z programistami – w sensie to nie jest inny język, ale łatwiej jest zrozumieć, czemu on właśnie w taki sposób myśli, bo jak już siedzi się w tym miejscu to już można zrozumieć, czemu on ma takie zrozumienie czy podejście.

Rozumiem. A czy jest może coś, co Ty zrobiłbyś inaczej dokonując swojego skoku?

Nie wiem, chyba nie. Człowiek uczy się przez całe życie i na błędach. Myślę, że  w porządku póki co.

To świetnie. Mam nadzieję, że tak jak z resztą mówiłeś, nigdy nie pożałujesz tego skoku i dziękuję Ci za rozmowę.

Tak. Dzięki również.

The Aesthetic-Usability Effect – o tym, czy da się pogodzić piękno i użyteczność ~ Anna Ostrowska

Zwycięski artykuł z konkursu zorganizowanego we wrześniu na fanpage’u „UX magazynu”. Jego autorka, Anna Ostrowska, wygrała od nas bilet na „UX Poland”. Gratulacje!

Z usług którego fryzjera chętniej skorzystasz? U dobrze wyglądającego, zadbanego, w pięknym, lśniącym salonie, czy u takiego, który sprawia wrażenie, że nie mył swoich włosów od tygodni i porusza się w salonie pomiędzy resztkami włosów swoich klientów? Czy wrócisz z radością do sklepu spożywczego, w którym zaschnięta plama z rozlanego soku wita cię przy wejściu od kilku wizyt?

W swoim życiu często podejmujemy decyzje wskutek szybkiej oceny sytuacji, w której się znajdujemy. Podobne zjawisko ma miejsce, kiedy spotykamy ludzi fizycznie atrakcyjnych. Nasz umysł podpowiada nam, że prawdopodobnie są również godni zaufania. Pojęcie greckiej kalokagatii, łączenia dobra z pięknem, jest wciąż aktualne. Zapewne wielu z was zorientowało się, że z większą przyjemnością sięga po produkty z ładniejszą etykietą czy ciekawszym projektem butelki. Lubimy rzeczy ładne, piękne, estetyczne. Ale czy stawianie walorów estetycznych na pierwszym miejscu w momencie podejmowania decyzji jest najbardziej rozsądnym działaniem?

Występowanie zjawiska, z którym mamy do czynienia, zaobserwowano już w kilku eksperymentach. W 1995 roku dwaj naukowcy z Design Center Hitachi, Masaaki Kurosu i Kaori Kashimura, testowali 26 odmian interfejsów bankomatów. Badani (a było ich 252) mieli ocenić każdy interfejs pod względem zarówno użyteczności, jak i wyglądu. Wyniki badań wykazały silną współzależność estetycznego wyglądu z użytecznością. Uznano wówczas, że wyglądający estetycznie interfejs może sugerować, że jest on również funkcjonalny i dobrze działa.

Aesthetic-Usability Effect to paradoks, w którym użytkownicy często postrzegają produkt o estetycznym designie jako bardziej użyteczny.

Historia pamięta mało praktyczne przedmioty, które zdobywały serca ich nabywców wyłącznie dzięki ich pięknu. Nie sposób nie wspomnieć w tym miejscu chociażby o francuskich perukach. W rozumieniu Władysława Tatarkiewicza, filozofa i estetyka, z estetyką mamy do czynienia w wymiarze nie tylko wypowiadanych przez filozofów twierdzeń, ale również w duchu danej epoki. Dzieła sztuki i gusta w danym miejscu i czasie wpływają na pojmowanie szeroko rozumianej estetyki. Każdy projektant musi pamiętać, że preferencje estetyczne w różnych miejscach na świecie nie są jednakowe. A co więcej, często poczucie estetyczne wiąże się ściśle z emocjami.

Zastanowienie się nad konsekwencjami Aesthetic-Usability Effect może doprowadzić nas do wielu ciekawych wniosków. Na przykład podczas projektowania sklepów e-commerce ten paradoks może oznaczać, że więcej osób chętniej skorzysta z bardziej estetycznej witryny, pomijając te mniej atrakcyjne. Nagromadzenie dużej ilości informacji, chaotyczny układ, nieadekwatny dobór zdjęć istotnie może wpłynąć na konwersję. W większości przypadków nowoczesna czcionka, atrakcyjne, profesjonalnie wykonane zdjęcia, przemyślany i spójny UI mogą przyciągnąć uwagę użytkowników. Estetyka może nawet przyćmić ich problemy podczas korzystania z danego produktu. Pozytywna reakcja na jego wygląd uruchamia uczucia przywiązania, zrozumienia i cierpliwości. Możemy dojść do wniosku, że użytkownicy chętniej używają produktu, który został ładnie zaprojektowany, bez względu na to, czy rzeczywiście jest łatwiejszy w obsłudze.

Prawdą jest, że estetyczne interfejsy są zawsze warte inwestycji. Konkurencja na rynku jest ogromna. Skorzystanie z Aesthetic-Usability Effect może zapewnić naszemu projektowi sukces. Należy jednak pamiętać o ograniczeniach omawianego zjawiska. Rzeczywiście estetyka strony może sprawić, że nasi użytkownicy będą dla naszych produktów bardziej wyrozumiali. Ale jeśli klient nie będzie potrafił znaleźć tego, czego potrzebuje, porzuci stronę pomimo jej pięknego wyglądu szybciej niż nam się wydaje. Trzeba uzmysłowić wszystkim członkom zespołu projektowego, że nawet świetny UI nie będzie odpowiednim ratunkiem dla słabej użyteczności.  

Zjawisko to może stać się również problemem podczas badań z użytkownikami. Badani pod wpływem danego zjawiska mogą pominąć ważne problemy z punktu widzenia użyteczności, które później w kolejnych fazach projektu mogą się ujawnić. Istotne podczas badań jakościowych jest wsłuchanie się w słowa użytkowników, które należy prawidłowo zinterpretować. Jedno z niebezpieczeństw, które może się pojawić, dotyczy sytuacji, w której użytkownicy czują konieczność skomentowania produktu i powiedzenia czegoś miłego jego twórcom. Mimo, że przechodzą trudności w wykonaniu zadań, komplementują wygląd produktu, ponieważ najłatwiej jest im się do tego odnieść. Ogromną rolę odgrywa wtedy zachowanie moderatora badania. To on może uświadomić uczestnika, że negatywne komentarze nikogo nie urażą i będą stanowić ważne wskazówki dla rozwoju produktu.

Zaburzenia odbioru produktu, ze względu na estetykę  mogą też wpłynąć na nasze rozmowy z interesariuszami. Nie bez powodu, wszystkie wstępne wersje tworzy się w odcieniach szarości, bez dodatkowych elementów graficznych. Mogłyby one odwrócić uwagę naszych partnerów od kluczowych zagadnień i kwestii, które są do rozwiązania. We wczesnej fazie prac dyskusje na temat koloru są absolutnie zbędne, jeśli trzeba zadecydować o głównej funkcjonalności produktu. Osobiste preferencje interesariuszy mogą całkowicie zaburzyć w ten sposób proces projektowy.

Najlepsze projekty będą łączyć stronę wizualną z użyteczną. Dla pełnego sukcesu UI (forma) i UX (funkcja) muszą iść w parze. Użytkownicy często oceniają produkty na podstawie pierwszego wrażenia, dlatego estetyka odgrywa niezwykłą rolę. Jednak projektanci muszą pamiętać by nie poświęcać użyteczności dla piękna. Wykorzystanie Aesthetic-Usability Effect będzie najkorzystniejsze, gdy estetyka będzie służyła do wspierania i zwiększania funkcjonalności produktu.

Dla zainteresowanych tematem osób gorąco polecam książkę Dona Normana, “Wzornictwo i emocje”. Autor przedstawia w niej wiele przykładów z codziennego życia, które również odnoszą się do opisanego zjawiska.

Źródła wykorzystane przy pisaniu artykułu:

  • https://www.nngroup.com/articles/aesthetic-usability-effect/
  • https://lawsofux.com/aesthetic-usability-effect
  • W. Tatarkiewicz, Historia estetyki, t. 1, ZNIO, Wrocław – Kraków 1960

Anna Ostrowska – doświadczona w pracy z ludźmi pasjonatka sztuki oraz szeroko pojętego UX. Szczególnym zainteresowaniem darzy zagadnienia związane z UX writingiem oraz badaniami jakościowymi. Od kilku lat współpracuje z samorządową instytucją kultury, gdzie pomaga rozwijać festiwal filmowy dla dzieci i młodzieży.

Anna Ostrowska

Twoim zadaniem jest zmieniać świat – recenzja książki „Mapowanie historyjek użytkownika” ~ Matylda Małecka

Recenzja książki: Jeff Patton, Mapowanie historyjek użytkownika. Przepis na produkt idealny, Gliwice 2019

Na stronie głównej firmy Jeff Patton & Associates widnieje duże hasło “We help product companies improve the way they work.” [Pomagamy firmom produktowym poprawić sposób, w jaki pracują.] To hasło bardzo dobrze ilustruje podejście Jeffa Pattona do usprawnienia procesów w organizacji i zastosowania w tym celu historyjek użytkownika. 

Biogram na okładce Mapowania historyjek użytkownika przedstawia autora przede wszystkim jako specjalistę w zakresie Agile i Scrum, laureata Gordon Pask Award Agile Alliance. W rzeczywistości jest on kimś znacznie więcej. Strona jego firmy prezentuje go w taki sposób: “Jeff Patton is the glue that connects good product management and strategy, lean user experience and agile delivery practices together.”[Jeff Patton jest klejem, łączącym dobre zarządzanie produktem ze strategią oraz lean UX z praktykami zwinnego dostarczania.] Sam siebie określa z dystansem jako “Chief Troublemaker”. 

Książkę rozpoczynają 3 wstępy od branżowych autorytetów: Martina Fowlera (specjalisty od object-oriented analysis and design), Allana Coopera (“ojca” języka Visual Basic i specjalisty od architektury informacji) oraz Marty’ego Cagana (specjalisty od zarządzania produktem). Właściwie to jedyne słowa wstępne, z którymi mamy do czynienia w tej pozycji, bowiem autor odżegnuje się od tej formy. Informuje jedynie, że początkowo książka ta miała mieć postać branżowej broszurki. Wyjaśnia, że ciągłe zmiany dyscyplin, których uczy długo zniechęcały go do napisania tej książki. Chciałby przedstawić historyjki i mapy historyjek jako świetne i przyjemne narzędzie, przy którym ludzie nie będą się męczyć.

Kondensuje też swoje założenia do jednego zdania – esencji całego tekstu: “Dzięki mapowaniu historyjek można skoncentrować się na użytkownikach i ich przeżyciach, co umożliwia prowadzenie lepszych dyskusji, a te z kolei pozwalają na tworzenie lepszych produktów.”. Następnie opisuje sposób tworzenia mapy user stories: zapisujemy wszystkie większe kroki użytkownika na samoprzylepnych karteczkach i przyklejamy do ściany lub flipcharta linearnie od lewej do prawej; później wracamy do początku i rozbijamy każdy z większych kroków na szczegółowe, które umieszczamy pod nimi w pionie. Zaznacza, że podane szczegóły są bardzo użytecznym rejestrem historyjek dla produktów zwinnych. Wskazuje kłopoty, jakie mogą się wyniknąć z błędnego rozumienia koncepcji historyjek, jak np. brak obrazu całości (“frankenprodukt” jako efekt); brak wizji rezultatu (zbytnie skupienie na szczegółach); brak notatek, spowodowany tym, że historyjki opierają się na konwersacji; niedotrzymywanie terminów przez zespoły, wynikające z koncentracji na kryteriach akceptacji historyjek użytkowników; podejście: “Nasz produkt nie ma jeszcze użytkowników, więc nie ma sensu używać user stories”. 

Autor bardzo precyzyjnie zaplanował strukturę książki. Na początku dokonuje wprowadzenia teoretycznego (bez obaw – w bardzo prosty, przyjemny i wręcz felietonowy sposób), następnie przechodzi do rozdziałów bardziej praktycznych, które dają ogólny ogląd mapowania historyjek i pozwalają od razu przejść do ćwiczeń praktycznych. Później autor opowiada szczegółowo o historyjkach, o tym, na czym faktycznie polegają i pokazuje, w jaki sposób należy ich sprawnie używać w ramach projektów agile i lean. W dalszych rozdziałach koncentruje się na cyklu życiowym historyjek i omawia procedury, które ułatwiają korzystanie z historyjek użytkowników i map historyjek. 

Jeff Patton lubi czytelnika zaskakiwać i prowokować. Używa przykładowo tego typu stwierdzeń: “Historyjki nie służą do tworzenia lepszych historyjek” lub “Celem tworzenia produktu nie jest stworzenie produktu”. Chwilę później wyjaśnia i trudno odmówić mu słuszności. 

W historyjkach, tak, jak w dokumentach, które przygotowujemy dla współpracowników nie chodzi w rzeczywistości o perfekcję, ale o uzyskanie wzajemnego zrozumienia, stanowią one narzędzie komunikacji. Patton przekonuje, że dobre dokumenty są jak dobre zdjęcia z wakacji – działają jak wspornik pamięci, ale też wyzwalacz wspomnień o całym kontekście wydarzenia, które prezentują. Hasła i obrazy służą jako pomocnicy wzajemnego zrozumienia pomiędzy interesariuszami, współpracownikami, ludźmi. Wzajemne zrozumienie uzyskuje się wtedy, kiedy obie strony wiedzą, co druga strona sobie wyobraża i dlaczego właśnie tak to wygląda. Przy pomocy dokumentu lub mapy historyjek użytkownika opowiada się historię. Dlatego warto robić zdjęcia, notatki i na wszelkie możliwe sposoby dokumentować proces. 

Stwierdzenie “Celem tworzenia produktu nie jest stworzenie produktu” Patton uzasadnia, używając definicji “udanej historyjki”, która mówi o tym, “kto” coś robi i “dlaczego”, a nie o tym, co jest do zrobienia. Odżegnuje się od “słowa na w” (czyli “wymagań”), przenosząc punkt ciężkości na użytkownika i rozwiązanie jego problemu, np. łatwiejsze osiąganie celów. 

Wprowadza pojęcie “wpływu” (“impact” w oryginale, jak się domyślam), którym określa to wszystko, co na dłuższą metę wynika z dobrego rezultatu i przy okazji wyjaśnia sens projektowania doświadczeń użytkownika. Firma nie dostanie tego, czego chce, jeżeli klienci i użytkownicy nie dostaną tego, czego chcą. Bardzo idealistycznie przekonuje, że “Twoim zadaniem jest zmieniać świat.”. Istotne jest jednak też zadbanie o firmę, bo inaczej nie będziemy mieć zasobów, żeby komuś pomóc.

Historyjki są dyskusjami o tym, jak rozwiązać problemy organizacji, klientów i użytkowników, z których wynikają ustalenia w sprawie tego, co należy opracować. Celem nie jest więc szybsze tworzenie większej ilości oprogramowania, lecz maksymalizowanie efektywności rezultatów i wpływu tego, co tworzysz. 

Podsumowując – będziesz opowiadać historie o użytkownikach i klientach oraz o tym, jak można im pomóc. Jeff Patton niczym coach życia proponuje zastosowania rozwiązania (user story mapping), dzięki któremu w przyjemny sposób będzie można zmieniać świat. Któż by się nie skusił?

Jeff Patton, Mapowanie historyjek użytkownika. Przepis na produkt idealny, Gliwice 2019

Matylda Małecka – copywriterka i redaktorka w zespole „UX Magazynu”. Bada, pisze, projektuje. Była doktorantką antropologii, nadal zafascynowana jest nowym rodzajem doświadczeń, jakie mają ludzie z technologią oraz metodami kokreacji. Człowiek orkiestra – łączy wrażliwość świata kultury z empatią świata projektantów oraz efektywnością branży mediowej.

Matylda Małecka

Subiektywnie o personach – garść inspiracji ~ Anna Wojciechowska

Jakiś czas temu miałam okazję wziąć udział w dwóch warsztatach, w których wykorzystywaliśmy stworzone wcześniej persony. Różniły się od siebie  budową i informacjami, jakie zawierały. Używaliśmy ich w kompletnie różny sposób. Skonfrontowałam to doświadczenie z dotychczasowymi, przemyślałam je i postanowiłam poukładać  tę rozsypankę. Chciałam się z Wami podzielić moim nowo powstałym ładem na półce z personami. Pogrupowałam je, dzieląc na rodzaje pod kątem stopnia szczegółowości oraz tego, kiedy można je wykorzystać i w jakim celu. Nazwy w większości są nadane przeze mnie – tak, jak ja je czuję. Dokonałam również zupełnie subiektywnej analizy. Na samym początku chcę zaznaczyć, że posługuję się tutaj słowem „persona”, mimo że czasem bardziej pasuje „archetyp” lub nawet „stereotyp”. Świadomie stosuję to uproszczenie. Zacznę od przypomnienia protopersony i persony. Jeśli pracowałeś z nimi, przejdź proszę dalej. Jeśli jesteś w tym wszystkim nowy, zachęcam, żebyś dodatkowo zaczerpnął wiedzy ze źródełka wujka G. To zaczynamy :).

Protopersona

Protopersona jest dość często wykorzystywana w początkowych etapach tworzenia produktu. Powstaje też wtedy, gdy nie ma budżetu na badania (zawsze warto dowiedzieć się, dlaczego brakuje środków na research). 

Wyobraźmy sobie nową linię opakowań kosmetyków dla osób starszych, które często mają problemy z poruszaniem się czy tzw. małą motoryką. Nasza wiedza o nich jest dość ogólna. Być może mamy taką osobę w naszym otoczeniu i nawet udało nam się z nią porozmawiać. Domyślamy się, że opakowania nie powinny mieć małych zawleczek lub trudnych do odkręcenia wieczek. Może uda nam się znaleźć w sieci jakieś dodatkowe informacje na temat tej grupy osób. Na tej podstawie budujemy naszą protopersonę często kreując  szczegóły z życia lub okoliczności, w jakich może korzystać z naszych usług. 

Kiedy jeszcze jest dobrze stworzyć Protopersonę? Załóżmy, że rozpoczynamy pracę i chcemy zbudować MVP (Minimum Viable Product). Zrobienie protopersony jest dobrym sposobem na potwierdzenie, czy wszystkie strony tak samo postrzegają potencjalną grupę docelową. Oczywiście protoperson może być kilka – główna i poboczne. Pamiętajmy, że trzeba je zweryfikować podczas badań oraz w trakcie zdobywania większej wiedzy o grupie, dla której projektujemy.  Protopersona wyglądem przypomina klasyczną personę, nie powstała jednak w efekcie przeprowadzenia aktualnych badań jakościowych i ilościowych. Jest bardziej przeczuciem, intuicją. Wszystkim tym, co udało nam się zebrać – z zewnętrznych źródeł, własnego przekonania lub odkurzonych starszych badań.

Protopersona w skrócie:

  • stwórz ją z tego, co już masz, użyj wcześniejszych danych i własnej wiedzy;
  • jest przydatna w początkowych fazach projektu;
  • możesz jej użyć, by uspójnić wiedzę w zespole lub z klientem.

Persona Klasyczna

Persona Klasyczna to model idealny persony; to ta, dla której powinno się projektować oraz uszczegóławiać projekt. O niej najczęściej mówią projektanci. Persona powstaje na podstawie badań jakościowych i ilościowych przeprowadzonych już z grupą docelową. Zwracam uwagę na grupę docelową, bo ona może być jeszcze doprecyzowywana w następnych  fazach projektu. Nie zawsze od razu potrafimy ją zidentyfikować. Początkowe badania mogą ją zawęzić lub wyłonić kolejną ważną grupę użytkowników, dla której stworzymy osobną personę.

Wróćmy do przykładu opakowań kosmetyków dla osób starszych. Po badaniach wiemy, co sprawia naszym użytkownikom największe problemy i na co zwracają uwagę podczas kupna produktów. Usłyszeliśmy wiele historii, zweryfikowaliśmy swoje założenia, a przede wszystkim wniknęliśmy bardziej w świat osób starszych. Mogliśmy też odkryć, że opakowania, odpowiednie dla osób starszych  sprawdzą się też w przypadku innych osób z problemami układu ruchu, zwłaszcza małej motoryki. Może więc warto dodać ich jako potencjalnych odbiorców?

Oprócz badań jakościowych dobrze jest zrobić mapę empatii. Dzięki badaniom i ich właściwej analizie jesteśmy w stanie stworzyć personę, która przysłuży się projektowi. Co ważne – powinniśmy do niej regularnie wracać i ją uaktualniać, co najmniej z dwóch powodów. Im dłużej projektujemy, tym lepiej ją rozumiemy, a czasem widzimy zmiany w samej grupie docelowej. Drugi powód stanowią zmiany, zachodzące na rynku lub dotyczące produktu. Monitorując rynek i rozwój naszego produktu, łatwiej wychwycimy moment, w którym należy odświeżyć personę. Persona ma wiele funkcji.  Przypomina dla kogo projektujemy i sprawdza się jako element wprowadzenia nowych projektantów w założenia produktu. Nie bójmy się jej poprawiać, pamiętając wciąż, że to fikcyjna postać, która ma pomagać nam w projektowaniu lepszych i bardziej użytecznych usług.

Persona Klasyczna w  skrócie:

  • stwórz ją na podstawie rzetelnych danych jakościowych i ilościowych;
  • przydaje się  do weryfikacji własnej pracy i kierunku rozwoju produktu;
  • pozwala spojrzeć na projekt z lotu ptaka; 
  • powracaj do niej i uaktualniaj ją – monitoruj rynek i konsumentów.

Persona Inspiracyjna

Personą Inspiracyjną nazwałam personę, z którą miałam do czynienia podczas warsztatów dla moderatorów Design Thinking. Zaznaczę tutaj, że to nie jedyna, jaką stosowaliśmy, te wymienione wyżej również się pojawiły, jednak ta wydała mi się szczególnie charakterystyczna. 

Co ją wyróżnia? Na stworzenie takiej persony nie musimy poświęcać dużo czasu. Tak naprawdę nie musimy wcale jej projektować, bo może opierać się na ogólnych skojarzeniach. Nie chodzi o to, by ją dobrze znać. Chodzi o to, by była  inspiracją.. Zastosować ją możemy na kilku różnych etapach projektu, głównie po to, by spojrzeć z innej strony na dane zagadnienie. Już tłumaczę na przykładzie.

Załóżmy, że chcemy zrobić brainstorming i wygenerować jak najwięcej pomysłów na nową aranżację jednego z pomieszczeń pubu na krakowskim Kazimierzu. Chcąc mieć więcej nieprzeciętnych pomysłów, zamiast od razu przechodzić do nich, możemy najpierw rozdać kilka Person Inspiracyjnych. Zamiast sztampowych studentów weźmy osobę niewidomą, starszą panią, która podróżuje ze swoimi koleżankami oraz  młodego numizmatyka. Chcemy mieć jak najwięcej pomysłów, więc takie persony nie muszą wiązać się z grupą docelową. Kto wie, może stare monety zapoczątkują nietuzinkowy wystrój pubu? Czujecie, o co chodzi? Nie musimy się skupiać tylko na zaproponowanych przez nas personach, bądźmy otwarci na pomysły uczestników warsztatów. Persony Inspiracyjne mają być jak wrzucenie kamienia do basenu tak, by zrobić wielki plusk, pokazać nową perspektywę  i w efekcie stworzyć coś zupełnie nowego.

Takie ćwiczenia możemy zastosować na wszystkich etapach projektowania, w których potrzebujemy odświeżenia konceptu. Nowa, czasem zwariowana, perspektywa może doprowadzić do całkiem ciekawych i sensownych pomysłów czy rozwiązań. Jeśli więc projektujesz coś od dłuższego czasu, może czas zapytać z czego najbardziej ucieszyłby się Osioł ze Shreka?

Persona Inspiracyjna w skrócie:

  • nie wymaga dużego nakładu czasu i dużej pracy;
  • stwórz ją, korzystając z ogólnej wiedzy i stereotypów;
  • pozwól, by każdy mógł ją interpretować na własny sposób;
  • doskonale sprawdza się podczas warsztatów;
  • użyj jej, gdy potrzebujesz wygenerować dużo pomysłów, spojrzeć inaczej na zagadnienie, pobudzić kreatywność;
  • dobrze się sprawdzi w początkowych fazach kształtowania produktu lub przy zastoju twórczym;
  • zapisz ją na karteczce typu post-it w postaci hasła (bez szczegółów), np. matka niemowlęcia, student matematyki, zakochana para. 

Nie-Antypersona

O Antypersonie zwykle mówi się  w kontekście przypominania użytkownika,  dla którego nie projektujemy. Ja mam inne dla niej zajęcie.  Wróćmy do naszego krakowskiego pubu.

Kto nie może skorzystać z pubu? Nieletni! Okej…, a co by musiało się stać, żeby jednak skorzystał? I tu zaczyna się zabawa. Wysilamy zwoje w mózgu i staramy się odpowiedzieć na pytanie, co by musiało się zadziać, żeby grupa, dla której z pozoru nie  projektujemy, jednak skorzystała z naszych usług. Brzmi jak strata czasu? Pozory! Pomęczmy zatem nieletnich. Co możemy dla nich zrobić? Podstawowym problemem wydaje się być tutaj alkohol. Ale czy ta sala w pubie w ogóle musi mieć w ofercie alkohol? A może zróbmy z niej przestrzeń dla dzieci i nastolatków, może zajęcia manualne w dzień a wieczorem stoliki dla dorosłych? Możemy też przekształcić salę na pracownię i połączyć z pubem, gdzie przy zajęciach manualnych można napić się piwa. Na pewno moglibyśmy stworzyć więcej rozwiązań w oparciu o osoby nieletnie. Te niby od czapy pomysły można znów przekształcić i połączyć z pierwotnymi założeniami.

Taka Nie-Antypersona działa na zasadzie wyzwania. Być może dzięki niej przedefiniujemy nasze założenia i powstanie coś znacznie lepszego niż do tej pory. Podałam przykład z wczesnej fazy projektowania, bo właśnie tu zastosowanie Nie-Antypersony wydaje mi się najbardziej efektywne. Uznaję ją właściwie za podtyp Persony Inspiracyjnej,  bo tak samo pozwala wyzwolić się z dotychczasowego myślenia i poszerzyć perspektywę.

Nie-Antypersona w skrócie:

  • nie wymaga dużego nakładu czasu i pracy;
  • stwórz ją, odpowiadając na pytanie: „Kto na pewno nie skorzysta z naszej usługi?” – to pytanie dobrze sprawdza się na warsztatach;
  • możesz wykorzystać stereotypy lub stworzyć ją razem z uczestnikami warsztatu;
  • wygląda dokładnie tak samo jak Persona Inspiracyjna – hasło na post-icie, np. nieletni.

Persona-Opowieść

Jeśli Persona Klasyczna jest efektem badań, trochę zmienionym dla zachowania spójności, ta jest wynikiem prawdziwego obcowania z człowiekiem. Ta, z którą się spotkałam (znów ukłon dla dziewczyn z DTI), miała kilka stron, bez wizualizacji pokazujących jak bardzo zaznajomiona jest z technologią, bez suwaczków z cechami charakteru. Nie było żadnych uproszczeń wizualnych, tylko sam tekst podzielony na akapity, z nagłówkami czego dotyczą. Tekst stanowił opis życia konkretnej osoby, tego, co robi, co jest dla niej ważne. Forma opowieści pozwala  poczuć większą empatię, bardziej wniknąć w życie persony, jak podczas czytania książki. Persona-Opowieść często jest zapisem realnej rozmowy z kilkoma zmianami personalnymi. Jest bardzo autentyczna, spójna, wysoko empatyczna, ale opiera się na doświadczeniu jednostki. To też oznacza, że nie jest idealną reprezentacją  całej grupy docelowej i nie można jej w taki sposób traktować. Nie bardzo się nada do uszczegóławiania projektu. Za to jest doskonała do empatyzacji i wymyślania rozwiązań. 

Persona-Opowieść w skrócie:

  • stwórz ją na podstawie rozmów z reprezentantami grupy docelowej; najlepiej wybierz jedną osobę, zmieniając kilka szczegółów. Jeśli tworzysz zupełnie fikcyjną postać, to postaraj się o jej autentyczność, korzystaj z tego co usłyszałeś podczas wywiadów. Dołącz jej zdjęcie – wytnij z gazety lub skorzystaj z banku darmowych zdjęć;
  • nie oszczędzaj na tekście, powinno się ją dobrze czytać, może zawierać nawet kilka stron;
  • wykorzystaj ją w fazie empatii, pamiętaj by dać uczestnikom czas na zapoznanie się z nią.

Persony do testów

Tak też można! Nie mam na myśli tutaj testów po wdrożeniu, ale wciąż w trakcie projektowania, zwłaszcza gdy mocno wchodzimy w szczegóły. Rozpisane use case’y możemy urozmaicić postaciami nastawionymi na wykonanie konkretnych zadań w konkretnych warunkach. Może to być pan Mietek, który jest złotą rączką, cały czas pod telefonem i w terenie. A może młoda studentka, która trochę za dużo siedzi na telefonie, używając go podczas spacerów czy nauki do egzaminów? Chodzi o rozszerzenie dotychczasowych założeń użycia produktu. Nie każda postać będzie oczywiście pasować, natomiast ta metoda może nas doprowadzić do nowych pomysłów rozwiązań lub  do przeoczonych scenariuszy użycia (zastanów się wtedy, czy i jak duże zmiany powinny iść za nimi). 

Persony do testów użyteczności w skrócie:

  • stwórz je w obrębie grupy docelowej, ale nadaj im konkretne zadanie w precyzyjnym kontekście, np. młoda matka, która nie spuszczając dziecka z oka, musi zrobić zakupy z dostawą do domu. Zadaj sobie pytania w jaki sposób może się to odbywać, wyobraź sobie jej środowisko (np. może musi co chwila przerywać proces, żeby podejść do dziecka?);
  • jest przydatna, gdy myślisz o szczegółach produktu czy specyfikacji konkretnych elementów (np. czas na odpowiedź użytkownika, autozapis itp).

(Nie)Persona na procentach

Właściwie to nie jest persona, bo nie spełnia podstawowego założenia, w którym zależy nam na personie jakościowej, nie odzwierciedlającej surowych danych. Chciałam o niej  jednak wspomnieć. Dane ilościowe często pomagają uzupełnić grupę docelową i mogą się pojawiać na samej karcie persony. Może to być np. informacja o tym, jak często persona używa smartfona lub naszej aplikacji. Może jest też jakaś konkretna pora używania produktu? Te dane powinny być uzupełnione jakościowo – podamy np. powód i sposób używania produktu. W jednej z firm, w której pracowałam, wisiała ogromna plansza ze statystykami (rozkład wieku, płci, częstotliwości użycia poszczególnych funkcji itd.), na podstawie których zostały nadane nazwy głównym nurtom zachowań użytkowników. Wygląda prawie jak karta persony, prawda? Pamiętajmy, że taka (Nie)Persona nie spełni funkcji tradycyjnej persony, natomiast doskonale się nada jako przypominajka o najważniejszych grupach osób, dla których projektujemy. W tym przypadku również aktualizacja jej jest istotna. 

(Nie)Persona na procentach w skrócie:

  • stwórz ją, zbierając statystyki na temat użytkowników, na ich podstawie podziel użytkowników na grupy,  tworząc taką segmentację, nadaj nazwę każdej z grup i podaj statystyki do każdej z nich, by łatwo można było je ze sobą porównać.

Słowo na zakończenie

Możesz teraz pomyśleć: „Ojej, tworzenie tych wszystkich typów person zajmie mi ogromną ilość czasu!”. Rozumiem. Mam jednak dla Ciebie złotą radę. O ile ostatniej i dwóch pierwszych person nie wyciągniesz z kapelusza, to pozostałe… właściwie tak. Jak widzisz niektóre nie potrzebują specjalnego przygotowania, inne mogą być tylko hasłowo opisane. Najlepiej będzie, jeśli zaczniesz kolekcjonować takie persony i wyciągać je w konkretnych sytuacjach. Z czasem możesz stworzyć sobie całkiem duży kapelusz person. Warto używać różnych rodzajów person, a tych bardziej powierzchownych po to, by pobudzić proces kreatywny w zespole.  

PS. Tak mnie naszło, że troszkę pisze o  personach jak o narzędziach do weryfikacji wszystkiego, co robimy. Uprzejmie donoszę, że persony są wsparciem, a badania i testy weryfikacją. Nie chciałabym bagatelizować roli badań jakościowych i ilościowych, których jestem ogromną zwolenniczką. 

Daj mi znać, jeśli ten artykuł Cię zainteresował lub masz coś do dodania w kwestii person. Może o którejś z person chciałbyś dowiedzieć się więcej? Jestem też ciekawa, w jaki sposób wykorzystujesz persony w swojej pracy. Porozmawiajmy! 


Anna Wojciechowska – stoi na straży potrzeb klienta godząc je z wymogami biznesowymi. Jako UX Designer przez kilka lat była związana z bankowością internetową, obecnie usprawnia produkty w Grupie Pracuj. Certyfikowana moderatorka Design Thinking, współorganizatorka warszawskich spotkań Tipi UX. Uważa, że przez dobry interfejs można zrozumieć skomplikowane produkty, a w swojej pracy najbardziej ceni konfrontację projektów z użytkownikami. Chciałaby, by wszystkie powstające produkty odpowiadały na realne potrzeby, a nie je tworzyły.

Anna Wojciechowska

Potrzeby użytkowników w projektach B2B i B2C – jak je zidentyfikować? ~ Paulina Popowicz

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.

https://www.givegoodux.com

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

https://pl.wikiquote.org/wiki/Henry_Ford


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.