Skip to main content
Designers working on UX/UI design for mobile apps, creating user-centric interfaces on a whiteboard.

Persona - przewodnik (po) użytkownika(ch)

Persony są użytecznym narzędziem w procesie projektowania produktów cyfrowych. Mają swój odpowiednik również w marketingu i reklamie. Persona pomaga zrozumieć użytkownika – jego motywacje, cele, przyzwyczajenia, oczekiwania. Jej umiejętne użycie sprawia, że w procesie projektowania i developmentu nie tracimy z oczu tego, po co i dla kogo tworzymy nasz produkt.


  • Barbara Radziszewska

Czym są persony?

Persona – najogólniej mówiąc – jest realistycznym opisem fikcyjnej osoby reprezentującej docelowego użytkownika produktu. Obrazuje konkretnego człowieka, w odróżnieniu od segmentów klien¬tów, które odzwierciedlają w miarę jednorodne grupy wyodrębnione na podstawie czynników demograficznych, behawioralnych czy psychogra¬ficznych. Persona może opisywać osobę, która już korzysta z naszego produktu, lub potencjalnego użytkow¬nika.

Persona może zawierać najróżniejsze informacje, w zależności od tego, co na danym etapie projek-tu i w kontekście naszego produktu uznamy za najważniejsze i najbardziej wartościowe. Należy pamiętać, że ideą stojącą za korzystaniem z per¬son jest stałe odwoływanie się do niej w procesie wytwarzania produktu cyfrowego przez cały ze¬spół. Nie może więc być obszerna i przeładowana treścią.

Na personę najczęściej składają się:

  • sugestywne zdjęcie - Odzwierciedla cechy charakterystyczne, usposo¬bienie lub kontekst pracy danej persony – dzięki wizerunkowi łatwiej jest później zidentyfikować ją w pamięci, przypomnieć sobie o najważniej¬szych jej cechach;
  • imię i nazwisko + metryczka - Częstą praktyką jest wymyślanie nazwiska od-zwierciedlającego jakąś charakterystyczną cechę danej persony, np. Janusz Niezgoda, Magdalena Pracuś itd., choć nie jest to konieczne. Należy jed¬nak pamiętać, że tworząc personę, nie podajemy informacji demograficznych w formie przedzia¬łu wiekowego (np. 25–34) lub wielkości miej¬sca zamieszkania (np. miasto powyżej 500 tys. mieszkańców) – tym m.in. persona różni się od segmentu. Persona jest konkretną osobą, a zatem ma określony wiek (np. 30 lat) i mieszka w kon¬kretnym mieście (np. Warszawa). Przy czym warto skupić się na informacjach ważnych z punktu widzenia projektu. Jeśli nasz produkt tworzymy z myślą o klientach korporacyjnych, w personie nie zawierajmy informacji o miejscu zamieszkania lub posiadanych dzieciach, zwierzętach czy hob¬by, a raczej takie jak np.: jaka jest rola tej osoby w firmie, co to za firma, jaka branża;
  • cytat lub motto życiowe - To kolejny element pozwalający łatwo przywo¬łać personę w pamięci i odzwierciedlający jakieś istotne jej cechy lub przekonania. Jeśli projekt do¬tyczy oszczędzania, możemy się zastanowić, czy bliższe tej osobie byłoby powiedzenie: „Ziarnko do ziarnka i zbierze się miarka”, czy „Pierwszy milion trzeba ukraść”? Dobrą praktyką jest wyko¬rzystanie prawdziwego cytatu lub „sklejenie” go z różnych wypowiedzi użytkowników, z którymi wcześniej przeprowadziliśmy wywiady. Jeśli nie mamy jednak takiego źródła, nic nie stoi na prze¬szkodzie, abyśmy użyli własnej wyobraźni i taki cytat „stworzyli”;
  • kompetencje techniczne - To istotny punkt przy projektowaniu produktów cyfrowych – jak biegły w korzystaniu z interne¬tu, komputera, smartfona czy tabletu jest nasz użytkownik? Z których urządzeń korzysta? Jakie ma doświadczenia? Ten element persony często przedstawiany jest graficznie, a nie tekstowo, np. za pomocą ikon;
  • wiedza lub stopień zaawansowania w obszarze projektowanej usługi - To również może okazać się przydatną informa¬cją – czy ta persona jest laikiem, czy ekspertem w danym temacie? Jest klientem wymagającym, czy raczej polegającym na obsłudze i potrzebują¬cym merytorycznego wsparcia?;
  • potrzeby, przyzwyczajenia, oczekiwania w da¬nym obszarze i względem tworzonego produk-tu lub usługi - Są to kluczowe informacje pomagające skoncen¬trować uwagę na najważniejszych elementach identyfikujących daną personę. Możemy zawrzeć tu kontekst użycia, kryteria wyboru danej usługi lub wysokopoziomowe potrzeby, takie jak „szyb¬kość”, „niezawodność”, „niska cena” – ważne, żeby były to elementy wyróżniające daną personę na tle pozostałych;
  • bolączki i frustracje  - Podobnie jak w poprzednim punkcie skupia¬my się na kontekście danego procesu. Ta część uświadamia nam, jakie problemy użytkownika staramy się rozwiązać, a także na co powinniśmy uważać i jakich błędów unikać.

Czy naprawdę ich potrzebujemy?

Persony działają, ponieważ na wielu z nas, włą¬czając w to programistów, projektantów, interesariuszy, lepiej działają konkretne przykłady niż abstrakcja i uogólnienia. Dzięki personom wszyscy członkowie zespołu mogą „wejść w buty” użytkownika, zrozumieć, dlaczego robimy to, co robimy, i mogą podejmować decyzje ukierunko¬wane na potrzeby rzeczywistych użytkowników. Jeśli opisujemy ich jedynie ogólnikami, w kate¬goriach statystycznych, jako wysokopoziomowe, szerokie profile, informacje te nie zapadną tak dobrze w pamięć członków zespołu, jak reprezen¬tacja konkretnej (choć fikcyjnej) osoby.

Kolejną zaletą korzystania z person jest to, że tworzą wspólne i bardziej precyzyjne rozumienie użytkownika, a także uwspólniają słownictwo używane w zespole w kontekście grupy docelowej. Chociażby podczas spotkań sama nazwa persony określa już cały zestaw potrzeb, cech i zachowań, które należy wziąć pod uwagę przy podejmowaniu decyzji projektowych. Jeśli zamiast tego pytamy, czego chcieliby „użytkow¬nicy”, każda osoba na spotkaniu może zinter¬pretować inaczej, kim są ci użytkownicy i jakie mają potrzeby. Co więcej, definicja „użytkowni¬ka” mogłaby być różna w zależności od modelu mentalnego każdego uczestnika spotkania. Dzięki ujęciu konkretnej persony usuwamy z dyskusji ryzyko i pokusę opierania się na naszych osobi¬stych osądach. Gdy zespół z łatwością obrazuje tę samą grupę użytkowników, może tworzyć lepsze projekty, jednocześnie przy mniejszym wysiłku i wyeliminowaniu niepotrzebnych dyskusji.

Persony są bardzo przydatne na etapie podejmo¬wania strategicznych decyzji. Dzięki odniesieniu do potrzeb i bolączek naszych wiodących person wiemy, które funkcje powinniśmy wdrożyć i po-traktować priorytetowo, a jednocześnie unika¬my marnowania czasu na budowanie zbędnych funkcjonalności.

Ponadto persony stanowią doskonały punkt wyj¬ścia do wielu innych narzędzi modelowania i ma-powania, np. map empatii, scenariuszy użycia, Customer Journey, Value Proposition itd.

Na co uważać?

Najlepiej tworzyć persony na jak najwcze¬śniejszym etapie projektu, jednak nie powinny powstawać tylko na podstawie naszych przeczuć i wyobrażeń. Persony, aby były trafne i dokładne, muszą być zakorzenione w danych z badań użyt¬kowników. Choć persony to wymyślone postacie, powinny być wykreowane na podstawie infor¬macji o prawdziwych osobach. Persony dobrze jest tworzyć kolektywnie, jako zespół. Wówczas mamy większą szansę, że cały zespół będzie chętniej z nich korzystał i do nich wracał. Jest to również proces, który integruje zespół i podnosi jego kulturę pracy. Jeśli chcemy, aby zarówno zespół, jak i stakeholderzy projektu korzystali z person i „uwierzyli” w nie, musimy zadbać, by mieli swój wkład w ich powstanie lub przynaj¬mniej aby transparentnie komunikować im proces i wysiłki włożone w budowanie person, a także (co jest zasadniczo celem niniejszego artykułu) edukować na temat znaczenia i korzyści płyną¬cych z wykorzystania person. 

Błędem, którego powinniśmy się wystrzegać, jest tworzenie person „do szuflady” – niekomuniko-wanie ich w zespole i wśród stakeholderów projektu,  traktowanie jako gotowego artefaktu, który nie podlega dyskusji ani dalszym zmianom, lub wręcz myślenie o personach jako o celu samym w sobie. Persony powinny być żywym materiałem. Możemy odnosić się do nich podczas spotkań, planowania, burzy mózgów, warsztatów, a raz na jakiś czas (szczególnie po przeprowadzeniu badań czy testów z użytkownikami) warto je zrewidować i upewnić się, że są aktualne i odzwierciedlają stan naszej wiedzy o użytkownikach.

Błędem jest również tworzenie zbyt wielu per¬son. Optymalną liczbą, w zależności od zakresu i stopnia skomplikowania projektu, jest od dwóch do sześciu person, przy czym jeśli robimy ich wię¬cej niż dwie, warto wybrać jedną–dwie główne (wiodące) persony, reprezentujące najbardziej liczne lub dochodowe segmenty klientów. Pozo¬stałe są wówczas personami pobocznymi. Dobrze mieć na uwadze, że im więcej tworzymy person, tym trudniej zapadają one w pamięć i trudniej członkom zespołu kojarzyć ich cechy charaktery¬styczne, co mocno ogranicza korzyści ze stosowa¬nia person. 

Jak zrobiliśmy to w R-Flexie?

Persony dla projektu R-Flex powstały jako owoc współpracy Product Ownerów z zespołem UX oraz stakeholderami w następujący sposób:

  1. Zaczęliśmy od stworzenia szablonu persony w Miro – wylistowaliśmy obszary, które wy-dawały się nam ważne z punktu widzenia projektu i w których chcieliśmy zdobyć wiedzę o użytkownikach. W każdym obszarze wpisali¬śmy pytania pomocnicze. Szablon stworzyliśmy z myślą o wykorzystaniu go podczas warsztatu w Rumunii;
  2. Przeanalizowaliśmy dane z ankiety ilościowej, skupiając się na różnicach pomiędzy segmenta¬mi. Ankieta zawierała m.in. pytania dotyczące zwyczajów i zachowań związanych z wymia¬ną walut, a także metryczkę, a w niej pytania o wiek, branżę, w jakiej działa firma respon¬denta, i jego rolę w firmie. Dane z badania ilo¬ściowego potraktowaliśmy jako pierwszy wkład do person (które chcieliśmy zweryfiko¬wać i omówić podczas warsztatów);
  3. Przeprowadziliśmy warsztat, do którego zapro¬siliśmy dealerów współpracujących na co dzień z klientami i wspólnie staraliśmy się uzupeł¬nić przygotowany szablon. Pojawiło się wiele pobocznych informacji, które dały nam jednak szerszy kontekst funkcjonowania klientów – użytkowników R-Flexa (skupiliśmy się na mikro- i małych przed¬siębiorcach). Spotkanie było nagrywane;
  4. Po warsztacie wróciliśmy raz jeszcze do nagra¬nia i ponownie w składzie PO – UX wybraliśmy najważniejsze informacje, które postanowiliśmy zawrzeć w personach. Przygotowaliśmy treść dwóch person, w których staraliśmy się uchwy¬cić jak najwięcej różnic pomiędzy nimi;
  5. Przeprowadziliśmy analogiczne warsztaty w pozostałych network bankach (Chorwacja i Węgry), na Węgrzech udało nam się również przeprowadzić wywiady pogłębione z klientami.
  6. Przeanalizowaliśmy podobieństwa i różnice pomiędzy krajami, w efekcie stworzyliśmy 2 uniwersalne persony główne. Jednocześnie każdy network bank ma swoje własne persony, które możemy wykorzystywać w sytuacji tworzenia funkcjonalności specyficznych dla danego kraju, mogą być również wykorzystywane przez lokalne zespoły marketingu.
  7. W ostatnim kroku „opakowaliśmy” graficznie zebrany materiał.

Persony okazały się być pomocnym artefaktem podczas mapowania Customer Journey dla procesu zakładania depozytów. Informacje zawarte w personach idealnie uzupełniały wiedzę zdobytą podczas wywiadów z dealerami i pomogły w lepszym zrozumieniu perspektywy klienta, a także opracowaniu pomysłów na usprawnienia w tym procesie, które moglibyśmy wdrożyć na platformie.

R-Flex ma personę, mam i ja!

Podsumowując, persony to jedno z dostęp¬nych narzędzi, które możemy wykorzystać, aby podejmować decyzje bazujące na potrzebach konkretnych ludzi, a nie na potrzebach ogólnego i niezdefiniowanego „użytkownika” lub segmen¬tu. Wspierają zespół we wspólnym rozumieniu potrzeb użytkowników i stanowią zwięzłe, łatwo przyswajalne streszczenie wiedzy, jaką mamy o naszej grupie docelowej.

Gorąco zachęcam Was do korzystania z tego narzę¬dzia w waszych projektach. Dotychczasowe doświadczenie w R-Flexie, pokazało, że tworzenie person jest kreatywnym i integrującym procesem, otwierającym oczy na nowe, nieznane dotąd charakterystyki użytkowników.