To drugi wpis z serii Wielogłos (poprzedni dotyczył ścieżki rozwoju osobistego w działce Usability). Tym razem tematem przewodnim jest Projektowanie Zorientowane na Użytkownika.
Zagadnienie ogólne, co – jak mam nadzieję – pozwala na spojrzenie wielowymiarowe do zagadnienia i odkrywa indywidualny sposób podejścia Autorów.
Wśród zaproszonych znaleźli się: Robert Drózd (WebAudit), Joanna Kotala (Ideacto), Krzysztof Piwowar (ADV, blog Usability On Air) i na końcu moja wypowiedź – a ja nazywam się Marek Kasperski 🙂 (ThinkLab).
Robert Drózd (Webaudit)
Projektować będziemy tak czy inaczej. Jak zorientować to projektowanie na użytkownika? Użytkownik musi być na początku, w środku i na końcu tego projektowania. Tylko wtedy mamy pewność, że projekt nie wymknie się nam spod kontroli.
Na początku – na użytkownika musimy przemapować wszystkie cele, jakie stawiane są przed projektowanym produktem. Z różnych technik, które pozwalają nam dowiedzieć się czegoś o naszych użytkownikach (i znaleźć ich cele) najbardziej lubię jakościowe: indywidualne wywiady bezpośrednie i obserwacje. Typowe techniki badań marketingowych, jak fokusy, ankiety, CATI będą już mniej przydatne, bo po prostu możemy nie trafić z pytaniami – i dowiemy się zupełnych banałów. Następnie wyniki musimy sobie przerobić na narzędzia z których da się skorzystać – przede wszystkim profile użytkowników i przypadki użycia. Jedna rzecz, o której nie wolno zapomnieć – to są narzędzia dla nas, a nie dla klienta czy programistów. Jeśli nie potrafimy z nich skorzystać podczas projektowania, straciliśmy czas.
W środku procesu projektowania musimy wciąż czuć oddech użytkownika na plecach. Niedosłownie – przez ciągłe odwoływanie się do przygotowanych wcześniej person i scenariuszy. I dosłownie, przez konfrontowanie z użytkownikami kolejnych iteracji projektu, na przykład makiet i prototypów.
Pamiętać trzeba jednak o tym, że wiedza o użytkownikach ma nam pomagać, ale nie może determinować naszych decyzji. W wielu przypadkach nie jesteśmy w stanie przewidzieć, czy użytkownik na pewno nie zachowa się tak jak zapowiadał, czy jak to wynikało z poprzednich badań. Czasami innowacyjność wymaga pewnego zignorowania przyzwyczajeń użytkownika, a nowy produkt na początku wywoła szok i zagubienie. Byleby tylko na początku! Tylu ludzi narzekało na wstążki w Office 2007 i nie umiało wykonać w nowym Wordzie podstawowych operacji. Przyzwyczaili się i polubili wstążkę, a jej metaforę przejęły po Microsofcie inne firmy.
Na końcu projektowania są testy użyteczności. I jeśli ich nie udało się przeprowadzić w czasie trwania projektu, teraz są już niezbędne. Jeśli bieżącego projektu już nie zdążymy poprawić, to będziemy mieli podstawy do jego następnej wersji. Jeśli nie przypomnieliśmy sobie o użyteczności dopiero teraz, nie będzie raczej wielkich problemów. W innym przypadku nową wersję będziemy czasami musieli wykonać bardzo szybko. Tak stało się w przypadku systemu blogowego WordPress, gdzie nieudana wersja 2.5 została zastąpiona wersją 2.7 w ciągu pół roku.
Testy to jednak nie wszystko – powinniśmy określić metryki, które – w oparciu o zachowanie czy satysfakcję użytkownika – pozwolą nam ocenić skuteczność naszego projektu i wprowadzanych w nim zmian. Na przykład dla serwisów internetowych podstawą jest wykonywanie pożądanych akcji, lojalność i częstość odwiedzin dla osób powracających. Statystyki w serwisie zorientowanym na użytkownika mówią bardzo wiele o jego „pulsie” i pomagają wychwycić problemy, zanim jeszcze doniosą nam o nim sami użytkownicy, lub dowiemy się w teście.
Joanna Kotala (Ideacto)
Na projektowanie produktu patrzę zawsze z perspektywy wszystkich ludzi zaangażowanych w jego tworzenie – od sponsorów, analityków, projektantów, grafików, programistów aż do testerów. Produkt końcowy, z którego korzystają użytkownicy, jest rezultatem pracy całej grupy, a nie jedynie twórcy interfejsów, zwolennika Projektowania Zorientowanego na Użytkownika. Nawet przy starannie przygotowanym projekcie wpada on w ręce ludzi często mniej entuzjastycznie podchodzących do zagadnień użyteczności. Jak sobie z tym poradzić? Dobrą radą na początek jest staranne zaplanowanie zadań związanych ze zdobywaniem i analizą wiedzy o użytkownikach, projektowaniem, prototypowaniem itp. od strony zarządzania całym projektem. Inną zasadą, zaczerpniętą z Projektowania Kontekstowego – dla mnie jest to właśnie UCD w praktyce – jest angażowanie pozostałych członków zespołu w proces projektowania. W ten sposób pokazujemy im, że produkt będą używali konkretni ludzie, którzy mogą mieć zupełnie inne potrzeby niż my sami. Co więcej obecność dodatkowej osoby w procesie projektowania interfejsu daje nam nowe spojrzenie na to co robimy.
Pamiętam jak pierwszy raz w Ideacto zrobiliśmy wspólną sesję interpretacyjną danych o użytkownikach. Początek był trudny, ale rezultaty inspirujące. Nagle ci, którzy tylko słyszeli o UCD, zaczęli patrzeć na cały projekt przez pryzmat porozkładanych na stole karteczek z notatkami o użytkownikach. Co więcej, zaczęli kreować pomysły na rozwiązania interfejsowe, które jak się później okazało, odpowiadały potrzebom użytkowników. A przecież o to właśnie chodzi…
Krzysztof Piwowar (ADV, Usability On Air)
Pełen teoretyczny model UCD w praktycznym zastosowaniu występuje równie rzadko, jak Yeti. Bardzo wielu o nim słyszało, kilku miało szczęście widzieć go na własne oczy, pojedynczym udało się zrobić zdjęcie. I to nie dlatego, że model UCD to wymysł teoretyków. Po prostu jego realizacja wymaga bardzo specyficznych warunków, które niestety przyrodzie nie występują zbyt często. Oczywiście, wcale nie oznacza to, że należy się zrażać na starcie i prawdą jest, że należy walczyć o każdy jeden klocek z modelu – jeśli jego wykorzystanie ma służyć dołożeniu kolejnego właściwego puzzla do układanki projektowej.
Dzięki metodologii UCD w rękach zespołu projektowego mamy do wykorzystania m.in. takie narzędzia jak: grupy fokusowe, wywiady, ankiety, sortowanie kart i testy z użytkownikami, ale o tym czytelnicy tego bloga zapewne bardzo dobrze już wiedzą (jeśli nie, warto przywołać pamiętny plakat autorstwa Tomka Karwatki). Istotne w tych narzędziach jest to, że każde angażuje użytkownika końcowego i to dzięki niemu zespół uzyskuje dane do podejmowania decyzji – a im więcej jakościowej wiedzy, tym lepsze rozwiązania można zaproponować.
W praktyce jednak każdemu zespołowi przychodzi skonfrontować świadomość i potrzebę wykorzystania tychże narzędzi z rzeczywistością, gdzie dochodzą do głosu takie obszary jak: rentowność i budżet projektu, cele biznesowe klienta oraz deadline. To głównie one okrajają teoretyczny UCD, jaki znamy. I to właśnie z ich powodu można w takiej sytuacji poczuć się odrobinę schizofrenicznie.
Ale i na to jest sposób – praktyczny oczywiście :). Model teoretyczny UCD nie mówi nic o celowości wykorzystania wyżej wymienionych narzędzi. Mówiąc prostym językiem – praktyce nie wszystko zawsze musimy stosować. Model praktyczny (życiowy) dopuszcza ustalenie wartości narzędzi i umożliwia wybór tych, z których uzyskamy najbardziej wartościowy feedback oraz wiedzę – z punktu widzenia projektu i jego realiów. Po drugie – praktyczne podejście wymaga popatrzenia na projekt nie tylko z punktu widzenia użytkownika (user-centered) ale i z poziomu biznesowego klienta. I to właśnie w tym tkwi magia praktycznego wykorzystania projektowania zorientowanego na użytkownika. Aby uzyskać konsensus pomiędzy celami i potrzebami użytkowników a celami i potrzebami biznesowymi klienta. W inną stronę się nie da.
UCD w praktyce z mojego punktu widzenia to właśnie szukanie i znajdowanie takiego złotego środka. Jest on ciężki do osiągnięcia, ale gdy się go raz skosztuje, chce się go znowu spróbować – nie teoretycznie, ale właśnie praktycznie. Dlatego też pozwolę sobie na następujące stwierdzenie: UCD praktyczne jest jak uzależnienie – z tą różnicą, że wychodzi na dobre i więcej niż jednej osobie.
Marek Kasperski (ThinkLab.pl)
W jednej z książek, które miałem okazję czytać – bodajże w „Projektowanie nawigacji strony WWW” Kolbacha – autor definiuje pojęcie Projektowania Zorientowanego na Projektanta (PZnP). To po Projektowaniu Zorientowanym na Klienta (PZnK, osoby z działu marketingu, sprzedaży, prezesa, …) bodajże najbardziej rozpowszechniona metoda pracy projektowo-badawczej w interesującym nas obszarze.
Na początku książki „Projektowanie stron WWW. Użyteczność w praktyce” opisuję elementy związane z projektowaniem w metodyce UCD (s. 12-16) – zarówno w ramach budowania interdyscyplinarnego zespołu projektowego, jak i elementów szerszego procesu jakim de facto jest Projektowanie Zorientowane na Użytkownika (PZnU). Nie będę chciał się tutaj specjalnie powtarzać, ale zwrócę uwagę na kilka istotnych z mojego punktu widzenia elementów.
1. PZnU nie stoi w żaden sposób w sprzeczności z interesami PZnK. Jeśli w wyniku analizy danych zebranych w ramach statystyk, wywiadów z użytkownikami, clicktrackingu, tak by wynikało, to mamy poważny problem. Tak jak nie należy ignorować głosu użytkowników, tak interes klienta powinien być dla Ciebie równie istotny. Staraj się nie dopuszczać do sytuacji, w której stajesz się advocatus diaboli użytkowników i zwracasz się przeciwko interesom klienta. Co będą warci użytkownicy, gdy biznes klienta będzie zagrożony?
2. Zbieraj dane od użytkowników. Ile się da. Wykonaj, jeśli możesz:
- Badania satysfakcji klientów z aktualnie istniejących rozwiązań (bądź w ramach strony WWW klienta jeśli to redesign, bądź w ramach analizy konkurencji). Możesz to zrobić online na przykład w formie ankiet (w książce też pisałem o badaniu ankietowym, które przeprowadziłem w swoim czasie na GoldenLine), albo w ramach grup fokusowych.
- Badania potrzeb grupy docelowej. Może się okazać, że aktualna strona WWW nie spełnia wszystkich potrzeb użytkowników; zresztą podobnie jak strony konkurencji (ostatnio często powtarzam, że rozwiązania webowe są daleko w tyle za tymi, który zostały wykształcone w świecie rzeczywistym i jeśli chcesz sprzedawać elementy wyposażenia łazienek, to wcale nie oznacza, że powinieneś użyć do tego klasycznego sklepu internetowego).
- Badania zachowań użytkowników na stronie WWW. Niestety, jest to możliwe tylko w przypadku, gdy pracujesz nad rozbudową bądź modyfikacją istniejącego już serwisu. Ale przeglądnij dane ze statystyk (skonfrontuj je ze stroną, by zobaczyć na ile wiarygodne są te dane – zob. jeden z przypadków, które opisuję na blogu Ideas2Action), mapy cieplne z clicktrackingu (coraz powszechniej wykorzystywane i słusznie), testy z użytkownikami, z użyciem scenariuszy użycia plus – jeśli możesz – z eyetrackerem (teraz miałem taki przypadek, gdzie dane z eyetrackingu stanowiły świetne uzupełnienie danych z clicktrackingu, dzięki czemu uniknęliśmy z klientem pójścia na łatwiznę przy interpretacji danych).
- Zbierz i zanalizuj dane krytyczne. Określenie ‘dane krytyczne’ ukułem na potrzeby rozmów z klientami. Są to elementy z obszarów Pomocy, FAQ, pytania zadawane w ramach korespondencji, kliknięcia w części Mapa serwisu czy logi zapytań do wyszukiwarki. To ważne, a pomijane bardzo często, tropy, które pokazują z czym użytkownicy mają kłopoty.
3. Zbieraj dane od klienta. To się rozumie samo przez się. Ważne, że nie wszystkie Twoje pomysły i pomysły użytkowników będą stały w zgodzie z interesami klienta. Nie warto tym sobie zaprzątać głowy – zawsze będzie mógł je wykorzystać w ramach kolejnych prac z innym klientem.
4. Myśl… krytycznie. No właśnie. Doświadczenie uczy, że prawda leży gdzieś po środku, a w ramach UCD niejednokrotnie jeszcze zostanie zmodyfikowana :). Na końcu jesteś Ty, jako projektant, bądź Twój zespól. Musicie podjąć decyzję co jest ważne, a co nie – zarówno dla klienta, jak i dla użytkowników. W ten sposób powracamy do PZnP – Projektowania Zorientowanego na Projektanta… chociaż już z inną specyfiką danych wejściowych :).
