wtorek, 02 03 2010 | Kategoria: Projektowanie
Do podzielenia się przemyśleniami na temat stosowania person w projektowaniu podchodzę od kilku dobrych miesięcy. To powinien być dobry początek pokonywania blogowego marazmu, który się tutaj ostatnio zakradł :-)
Przy okazji: uważni czytelnicy na pewno zauważyli pojawienie się ostatnio pewnego tekstu i jego wyparowanie. Proszę mi wierzyć, że stały za tym ważne przyczyny.
A więc do rzeczy. Mówiąc najkrócej: persona to profil przykładowego użytkownika projektowanego systemu. Jest to przydatne, praktyczne narzędzie wykorzystywane podczas projektowania oraz analizy użyteczności. Niekiedy persony są także nazywane archetypami. Sporo miejsca Alan Cooper poświęca im w książce “Wariaci rządzą domem wariatów”. Cooper był zresztą jednym z prekursorów ich używania przy projektowaniu interakcji jeszcze w latach 80′, a więc przed epoką internetu. Jest to więc narzędzie o dosyć uniwersalnym charakterze.
Oczywiście persony nie są żadnym cudownym remedium na wszystkie problemy projektanta ;-) Zasadność tworzenia person zawsze rozważam z punktu widzenia czasu, którym dysponuję oraz praktyczną przydatnością dla danego projektu.
Punkt pierwszy jest bardzo posty. Pewnie nie utworzę person, jeśli się spieszę, a deadline tuż-tuż. I choć fajnie byłoby zawsze stosować pełną metodykę projektową (mam na myśli popularne standardy UCD), to w praktyce często wychodzi inaczej.
Jeśli chodzi o przydatność, to jestem pewien, że persony nie zawsze są potrzebne. Im mniej innowacyjny, a bardziej standardowy projekt, tym w mojej ocenie mniejsza jest przydatność person. Radzę podejmować racjonalne decyzje i nie korzystać z person, jeśli masz pewność, że nie wniosą one nic do projektu.
Persona nie jest tylko luźnym opisem na który można od czasu do czasu spojrzeć. To dokument, który wszyscy pracujący nad serwisem powinni mieć stale przed oczami. Najlepiej, aby wydrukowaną wersję opracowanych person otrzymały wszystkie osoby pracujące nad projektem. Opis person powinien być częścią dokumentacji projektu.
Przykładowe dane, jakie mogą zawierać persony:
Oczywiście należy przy tym trzymać się grupy docelowej produktu. Liczba tworzonych person zależy od skali i typu projektu. Czasem wystarczy jedna, a innym razem mogą być potrzebne np. trzy. Alan Cooper wśród stworzonych person proponuje określić także persony główne. To te, które są najważniejsze dla projektu, a więc odpowiadają jego kluczowym użytkownikom. Szczególną uwagę polecam zwrócić na cele person – mają związek z tym, jak reprezentowany przez personę użytkownik może korzystać z serwisu, a to jest bardzo ważne.
Inna sprawa, to skąd czerpać dane na temat użytkowników, aby utworzyć persony odpowiadające rzeczywistości. Jednak to już temat na osobny tekst.
Stworzenie person to dopiero początek. Ich praktyczne wykorzystanie to inna para kaloszy i nie zawsze jest to proste. Szczególnie, że z personami w mojej ocenie z personami powinni się także zapoznać inni członkowie zespołu. A to może budzić opór, wszak czasem obawiamy się tego, co dla nas nowe :-)
Po stworzeniu person możesz przestać projektować dla enigmatycznej “grupy docelowej” albo “przeciętnego użytkownika”. Teraz projektując możesz zadawać pytania w rodzaju: “Jak na to zareaguje Jan Kowalski?” A o Janie Kowalskim wiesz już, że jest żonaty, ma dwójkę dzieci, pracuje w dziale marketingu korporacji X, lubi muzykę klasyczną, a z Twojej innowacyjnej aplikacji chce korzystać w celach zawodowych średnio raz dziennie. Masz też jego zdjęcie (znalezione gdzieś w Sieci).
Rozumiesz czego oczekuje Jan Kowalski i projektując kolejne elementy systemu będziesz zwracać uwagę na to, czy są zgodne z jego oczekiwaniami i potrzebami.
Cała persona to dokument, który leży wydrukowany na biurku. I zarówno projektant, grafik, jak i programista myślą o tym, jak spełnić oczekiwania Jana Kowalskiego. W ich głowach on powinien być realną osobą. Inaczej stworzenie person będzie mieć o wiele mniejszy sens.
Z personami wiążą się scenariusze użytkownika. To narzędzie, które pozwala relatywnie szybko sprawdzić, czy użytkownik będzie mógł łatwo zrealizować swoje cele związane z serwisem. Dla każdej persony możesz określić zadania, np.:
W zależnośći od rozmiarów serwisu można mu przypisać od kilku do kilkudziesięciu różnych scenariuszy. Rolą analityka jest prześledzenie, jak te zadania mogą być wykonane w serwisie i odpowiedzenie na pytania:
Wykorzystując scenariusze użytkownika możesz testować tworzone projekty i to nawet na poziomie papierowych szkiców. Jest to też narzędzie przydatne przy analizie użyteczności gotowych serwisów.
Prezentacja Roberta Drózda na temat person:
A tutaj inna ciekawa prezentacja w języku angielskim “Death to personas! Long live personas!”:
Persona to profil użytkownika, który jest pomocny przy projektowaniu i analizach. Powinien być szczegółowy i związany z zadaniami, jakie użytkownicy będą wykonywać w serwisie. Posiadając stworzone persony możemy projektować dla tych person, a nie wirtualnego “przeciętnego użytkownika”.
Komentarze (4)
eryk orłowski, 2 03 2010, 12:10
“Szczególną uwagę polecam zwrócić na cele person – mają związek z tym, jak reprezentowany przez personę użytkownik może korzystać z serwisu, a to jest bardzo ważne.”
- i to jest bodaj najważniejszy przekaz :) Dla realizacji celów modelowych użytkowników projektuje się funkcjonalności aplikacji, które to funkcjonalności umieszcza się także od razu w samych profilach person.
a jako ciekawostka, do pobrania zestaw person utworzonych dla niepełnosprawnych profili użytkowników. Pouczające.
http://www.aegis-project.eu/index.php?option=com_content&view=article&id=63&Itemid=53
Piotr Kręglicki, 2 03 2010, 12:21
Mniej ciekawe może ale mimo wszystko przydatne przykłady “zwykłych” person :)
http://projectuxd.com/?page_id=5
eryk orłowski, 2 03 2010, 12:43
zwykłe czy niezwykłe, Twój przykład pochodzi z całkiem zacnej książki, którą swoją drogą polecam wszystkim, którzy chcą się dogadać z project managerami ;)
Krzysztof Piwowar, 2 03 2010, 15:25
“Inna sprawa, to skąd czerpać dane na temat użytkowników, aby utworzyć persony odpowiadające rzeczywistości. Jednak to już temat na osobny tekst” – to jest kwestia, z którą zmaga się niestety wiele osób (zwłaszcza takich, które nie stać na zakrojone na szeroką skalę badania). Nawet o dziwo jest to problem w projektach o większych budżetach. Są takie półśrodki jak fora, wywiady IDI z targetu (na małą skalę) ale ryzyko popełnienia błędu jest tym większe im bardziej ogólne i mniej rzetelne są zebrane dane. Ktoś znalazł jakieś sprytne remedium na tą bolączkę? :)
Do tematu person dorzuciłbym także link do prezentacji Data Driven Personas (http://www.slideshare.net/toddwarfel/data-driven-personas)
oraz 2 art. które kiedyś sam popełniłem:
Z personą za pan brat –
http://www.usability-onair.com/user-centered-design/z-persona-za-pan-brat/
Persony – jak je nazywać aby było dobrze –
http://www.usability-onair.com/projektowanie-interakcji/persony-jak-je-nazywac-aby-bylo-dobrze/
Dodaj komentarz