Chciałoby się rzec, że historia pomysłu na personas jest stara jak świat, ale w przypadku IT i tworzenia oprogramowania, wszystkie pomysły są relatywnie świeże. Poznajmy więc persony – kolejne narzędzie z naszego agile’owego toolboxa.
Pomysł na Persony
Zacznijmy od podstaw. Czym jest persona i czym są personas? To nic innego jak opis naszego typowego użytkownika, który będzie korzystał z naszego produktu bądź rozwiązania. Różni się od znacząco od opisu roli systemowej, bo nie mamy tu na myśli „pracownika obsługi klienta” czy „kierownika zespołu sprzedaży”.
W przypadku person skupiamy się na konkretnych cechach, a nie na stanowisku, i tworzymy osobę z krwi i kości. Może to więc być „Andrzej, kierownik zespołu sprzedaży, wiecznie zabiegany, ignorujący e-maile i SMS-y, z wadą wzroku, spędzający więcej czasu na telefonie niż laptopie, często pracujący z domu.” Wraz ze zdjęciem, opisem cech charakteru, motywacją i tym podobnymi szczegółami. Proste?
Personas (czy Persony) sformalizowane zostały na przełomie wieku, a więc mniej więcej w tym samym czasie, co dobrze nam znane User Story. Alan Cooper, pomysłodawca person, pracował na swoim pomysłem od lat osiemdziesiątych. Co wcale nie znaczy, że mamy do czynienia z czymś skomplikowanym. Podobnie jak wiele innych zwinnych pomysłów, wydaje się on być oczywisty, gdy już go poznamy.
Ciekawy jest tutaj rys historyczny, bowiem zanim powstały persony, Alan Cooper najpierw przeprowadzał wywiady z kilkoma typowym użytkownikami i na podstawie tychże tworzył opisy. Dziś, niestety, prawie nikt nie działa w ten sposób i persony powstają głównie w oparciu o nasze przeczucia i założenia. Czyli inaczej mówiąc, „metodą ekspercką”.
Persona, czyli użytkownik
„Make up pretend users and design for them.” – Alan Cooper
Wymyślmy sobie użytkownika, osobę z krwi i kości i projektujmy dla niego. A najlepiej, wymyślmy ich sobie kilku. Przydadzą nam się. Czym to się różni od określenia „grupy docelowej”?
Przede wszystkim, grupa docelowa jest bezosobowa. Trudno nam się wczuć w kogoś bez twarzy, element tłumu. Projektując rozwiązanie dla „grupy docelowej” nie rozpatrujemy szczegółowych, konkretnych przypadków użycia. Jasne, mamy jakieś scenariusze w głowie, ale nasza wyobraźnia nie operuje na ogółach. Im więcej szczegółów tym lepiej. Można całą ideę spłycić i stwierdzić, że persona to jest taka bardzo, bardzo wąska grupa docelowa. Wręcz jednostkowa.
Ktoś może też powiedzieć, że wyobrażając sobie nastolatka dojeżdżającego do szkoły komunikacją miejską możemy trafić na inne potrzeby niż tworząc nasz produkt dla kogoś, kto jeździ rowerem. Dlatego person tworzymy wiele i wybieramy te, które są najbardziej odpowiednie dla danego przypadku. I naprawdę dużo łatwiej będzie nam tworzyć lepiej dopasowane produkty, jeżeli będziemy wiedzieli, do kogo je dopasowujemy.
link-cel zwinnosci, motywacja
Jest wiele rzeczy, które dają nam persony. Dzięki zdjęciom i opisom cech charakteru łatwiej nam sobie wyobrazić i zapamiętać wymagania niefunkcjonalne. To, co jednak naprawdę pomoże nam w zadowoleniu klienta, jest opis jego motywacji. Charakter to jedno, ale jasne opisanie po co nasz użytkownik kilka to, co klika może mieć dla nas naprawdę wielkie znaczenie. Zastanówmy się więc, co nasza persona chce osiągnąć.
Bo na przykład to, czy ktoś kupując 10 biletów kolejowych na fakturę kupuje je dla siebie czy dla innych ma ogromne znaczenie. Pozwoli nam to określić czy wolałby dostać 10 e-maili, każdy z jedną fakturą i jedenastą wiadomość z 10 biletami czy też może odwrotnie – fakturę zbiorczą i bilety w osobnych wiadomościach.
Personas 4 Client
Nikt nie powiedział, że że persony tworzymy tylko i wyłącznie dla użytkowników końcowych. Jak mówiliśmy w naszym filmie o perspektywie User Stories, niektóre wymagania opisujemy z perspektywy zamawiającego bądź interesariusza. Te ostatnie to oczywiście Epiki.
W przypadku dużych pomysłów i funkcjonalności, a także w niektórych metodykach zwinnych operujących wieloma stopniami wymagań, mamy do czynienia z elementami backlogu opisywanymi z różnych punktów widzenia. Generalnie, im dalej jesteśmy od konkretnej, „klikaklnej” funkcjonalności, tym dalej jesteśmy w naszym opisie wymagań od użytkownika końcowego.
I tutaj pojawia się dla nas szansa na opisanie naszych interesariuszy oraz potencjalnych klientów. I znów, nie jako grupę docelową, ale osoby z krwi i kości. Ba, w tym przypadku nawet możemy pokusić się o wskazanie konkretnych osób (dyrektorów, managerów) zlecających nam prace. Tylko czy to będą jeszcze persony?
Może jednak zostańmy przy „wirtualnych” osobach, nawet na poziomie wymagań ogólnych. A gdyby ktoś nie zauważył, to persona idealnie wpisuje nam się w format User Story, lądując na samym początku formułki „Jako <persona> chcę <funkcjonalność, rozwiązanie> aby <osiągnąć korzyść>.”
#białko poleca te kombo.
