1. Zbierz i uporządkuj informacje dotyczące celów serwisu i planowanych funkcjonalności. Prototypowanie nie polega na rysowaniu “co nam w duszy gra”. Chodzi o to, aby forma wyrażała treść stojącą za serwisem. Wiele razy okazuje się po rozpoczęciu prac nad interaktywną makietą, że np. zapomnieliśmy o funkcjach z Facebooka albo przestrzeni reklamowej. Potraktuj pracę nad prototypem jako graficzne podsumowanie ustaleń zespołu projektowego.
2. Zaplanuj architekturę informacji. Idealny model projektowania w duchu UCD nie zawsze jest możliwy do zrealizowania. Zaoszczędzisz sobie jednak sporo pracy, jeśli starannie opracujesz architekturę serwisu. Wprowadzanie zmian na późniejszym etapie jest niezwykle uciążliwe i czasochłonne. Przekonałem się o tym, gdy po badaniach z użytkownikami okazało się, że warto rozdzielić pewne treści, co wymusiło dodanie kolejnej podstrony. Modyfikacja nawigacji głównej i linków kosztowała naprawdę sporo czasu.
3. Nie bój się prototypów papierowych. Prace nad projektem często przynoszą nieoczekiwane zmiany. Często również sam projektant zmieni koncepcję np. wyników wyszukiwania. Prototypowanie metodą papier i ołówek umożliwia niskim nakładem dokonać selekcji pomysłów na układ strony. Zaawansowane makiety elektroniczne warto zostawić na sam koniec. Jeśli potrzebny jest bardziej zaawansowany układ np. na potrzeby badań z użytkownikami, wykonaj tylko niezbędne elementy w formie klikalnej makiety. Może się okazać, że wyniki badań spowodują rewolucję w pomyśle na serwis.

Warto prototypować. Trzeba to jednak robić tak, aby czas poświęcić na myślenie, a nie techniczne poprawki. Jakie są Wasze strategie prototypowania?

Burza mózgów

Efekt ten został zauważony już w latach 80. i nazwany został jako efekt próżnictwa społecznego.   Jak to można wyjaśnić to, że liczne badania psychologów społecznych przeczą skuteczności burzy mózgów?

Im więcej osób w grupie tym mniejsze poczucie własnej odpowiedzialności, a w konsekwencji niższe zaangażowanie. Kolejną przeszkodą jest tzw. efekt następnego w kolejce – zastanawianie się nad własnym pomysłem blokuje uwagę na słuchanie pomysłów innych osób.

Skąd zatem taka popularność i poczucie skuteczności tej metody? Przede wszystkim dla większości ludzi doświadczenia grupowe mają subiektywnie wyższą wartość niż doświadczenia indywidualne. Działając w pojedynkę nie mamy porównania ile pomysłów może ostatecznie być, a w grupie widzimy jak pomysłów przybywa.

Jednak Więcej można przeczytać w dostępnej elektronicznie książce “Człowiek wśród ludzi”.

Remedium na to jest zwiększenie poczucia odpowiedzialności członków grupy. Faza generowania pomysłów może być przeprowadzona indywidualnie tzn. każdy z członków zespołu sam spisuje wszystkie możliwe pomysły jakie przychodzą mu do głowy. Wspólnie zaś omawia się zebrane sugestie i dokonuje selekcji najlepszych i najtrafniejszych rozwiązań.

naturalne środowisko użytkownika

Najnowsze nurty w badaniach kognitywistycznych świadczą o tym,  że percepcja nie służy temu, by wiedzieć, ale temu by sprawnie działać. Stąd tak duży nacisk, by projektowane serwisy i aplikacji przede wszystkim jasno komunikowały  co można za ich pomocą zrobić. Dla właściciela witryny jest to korzystne, a dla użytkownika naturalne, by coś kliknąć, włączyć, wpisać itp.

Współczesne pytania o to jak poznajemy i skutecznie działamy, przynoszą odpowiedź, że nasze poznanie jest ucieleśnione (embodied cognition) i zanurzone w świecie. Nasze myślenie nie jest funkcją samego mózgu, ale charakter nadaje mu to jak się poruszamy i działamy. Najlepszym tego dowodem są metafory w naszym języku np. dotyczące Internetu – poruszamy się po nim, szukamy w nim, surfujemy, odwiedzamy, nawigujemy. Aby zatem w pełni zrozumieć jak użytkownicy podejmują decyzje potrzebujemy szerokiego spojrzenia na kontekst ich działania.

Na pewno znane jest Tobie pojęcie analizy zadań (task analysis), czyli obserwacja jak ludzie wykonują zadania – ile wykonali i w jakim stopniu.  Jej ciekawe rozszerzenie proponuje Frank Spiller, specjalista ds. użyteczności, kognitywista, autor idei Cognitive archeology, której głównym założeniem jest badanie aktywności użytkowników w ich naturalnym środowisku korzystania z Sieci.

Jakie są główne techniki tej metody?

• wywiady kontekstowe – to nie osoby przychodzą na badanie, ale badanie prowadzone jest tam, gdzie użytkownicy pracują i korzystają z Internetu – w miejscu pracy, na uczelni, w kawiarni z WiFi. Dzięki temu procesy kognitywne użytkownika są pod normalnym wpływem poznawczych artefaktów czyli np. żółtych karteczek przyklejonych do monitora.
• analiza zadania – obserwacja użytkownika i identyfikacja kontekstu użycia – czy stosowane są  skróty klawiszowych, praca na zakładkach, jakiego rodzaju aplikacje dodatkowo są uruchomione oraz ilości błędów,  szybkości i kompletności wykonania.
• diary studies -  nie wszystkie istotne spostrzeżenia użytkownika
  

  diary studies

  mogą być zarejestrowane przez badacza. Dlatego warto dać osobie badanej kartki papieru na których będzie mogła zapisać swoje obserwacje, wrażenia czy uwagi.
  

Metody analizy danych

• affinity diagrams – metoda wizualizacji pozwalającą określać za pomocą małych kartek relacje i zgrupowania np. pomysłów powstałych podczas burzy mózgów czy spostrzeżeń z notatek użytkownika
• task flow - obrazowanie akcji użytkownika, akcji systemu i ich wzajemnej interakcji za pomocą ustandaryzowanych schematów np. za pomocą UML.

• scenariusze – synteza obserwacji użytkownika, która pozwala wyjaśniać przebieg wykonania zadania i wyciągać wnioski dotyczące możliwych usprawnień czynności użytkownika ze strony projektowanego interfejsu

Więcej o badaniu kontekstu możesz przeczytać w artykule Task Analysis through Cognitive Archeology (PDF), który ukazał się jako rozdział książki The Handbook of Task Analysis for HCI.

Dobry interfejs to dobre narzędzie dla użytkownika.  Taki narzędzie powinno wspierać i rozszerzać możliwości poznawcze użytkownika tak jak młotek jest artefaktem wydłużającym możliwości dłoni, a okulary możliwości oka.  Zauważ, że jest w tym miejsce dla realizacji celów biznesowych Twojego projektu. Jeśli poznasz kontekst działania twojego użytkownika, zrozumiesz jak podejmuje decyzje. Z naukowych teorii czasami coś ciekawego wynika, czyż nie?

Dlaczego warto zająć się użytecznością komercyjnej strony? Ponieważ oprócz wzrostu liczby konwersji (użytkownicy stają się klientami) i zyskania lojalnego grona klientów, tworzenie i badanie prototypów pozwoli oszczędzić środki wydawane na techniczne poprawki.
Strona, która jest przyjazna użytkownikom to doskonały sposób na zbudowanie przyjaznego wizerunku firmy.

Czy warto inwestować w badanie użyteczności wewnętrznych serwisów – systemów ERP, intranetu itp? Tak, ponieważ projektowaniu zorientowanemu na użytkownika firma zapewnia sobie większą produktywność pracowników, korzystających z systemu. Dzięki określeniu schematów interakcji i architektury informacji użytkownicy popełniają coraz mniej błędów w obsłudze. Ze zwiększeniem produktywności idzie również oszczędność tych środków, które firma przeznaczyłaby na wsparcie techniczne pracowników i ich szkolenie.

Oszczędności

Filozofia UCD pozwala zaoszczędzić dzięki zapobieganiu błędom już w fazie projektu.

Zacznijmy od oszczędności. Badania pokazują, że gdy wdrażany system (np. serwis internetowy) jest w fazie rozwoju, wprowadzenie poprawek kosztuje 10 razy więcej w porównaniu z poprawką już na etapie projektowania. Po wprowadzeniu systemu na rynek koszt usunięcia problemów jest 100 razy wyższy niż koszt zmiany na etapie projektu. (za: Gild, 1988). O tym, że o użyteczności produktu warto pomyśleć już na samym początku projektowania przekonuje również Nielesen. Jego badania nad produkcją oprogramowania pokazują, że aż 63% dużych projektów programistycznych przekracza zakładany budżet. Jak pisze Nielsen, menedżerowie projektów podali 24 różne powody wyjścia poza koszty, ale cztery z nich były ściśle związane z użytecznością produktu. Zastosowanie odpowiedniej metodologii na etapie projektu pozwoliłoby uniknąć nieoczekiwanych wydatków (Nielsen, 1993). O jakiej metodologii mowa? Chodzi przede wszystkim o zbadanie potrzeb i doświadczeń końcowych odbiorców produktu oraz określenie celu biznesowego, przygotowanie makiet oraz badania z użytkownikami. Kolejny przykład podają Bias i Mayhew – American Airlines dzięki zaangażowaniu specjalistów od użyteczności w pierwszych fazach projektowania oprogramowania, obniżyli koszty, które przeznaczali wcześniej na poprawki i uzupełniania o 60-90%.

Zyski

Badania z 2000 pokazują, że inwestycja w user experience w sklepach internetowych przynosi wzorst konwersji o 40% i wzrost

Użyteczne projektowanie zapewnia zyski

zamówienień o 10%. (Creative Good, 2000). Znaczący jest również przykład move.com, amerykańskiego serwisu sprzedaży nieruchomości, gdzie zainwestowano w redesign wyszukiwarki na stronie głównej. Wskaźnik znajdowalności na stronie zwiększył się dzięki temu z 62% do 98%.(Vividence,2001) Odnotowano również zwiększenie ruchu na stronie i co za tym idzie znaczący wzrost zainteresowania kupnem reklam na stronie głównej. Efekt zwiększonego ruchu występuje niemal na wszystkich stronach po redesignie, co przynosi właścicielom realne zyski. Dobrym przykładem jest chociażby sklep IBM, gdzie po nowej odsłonie ruch wzrósł o 120%, a sprzedaż aż o 400%! (Battey, 1999). Więcej przykładów można znaleźć na przykład w serwisie Usability First: Usability ROI Case Studies.

Podsumowując – inwestycja w użyteczność oznacza inwestycję we wzrost sprzedaży oraz oszczędności związane z technicznymi poprawkami i pomocą użytkownikom. Oszczędność ta bierze się z tego, że im wcześniej w procesie projektowania określimy funkcjonalności i schematy ich używania, łatwiej będzie uniknąć lub poprawić błędy używając mniejszych środków.  Na prezentowane sukcesy składa się przede wszystkim to, że projektowanie zorientowane na użytkownika skłania do jasnego określenia celów biznesowych i ich ekspozycji oraz zapewnia wzrost satysfakcji potencjalnych użytkowników.

Przykłady użyte w tekście cytuję za: A. Marcus “Return on Investment for Usable User-Interface Design: Examples and Statistics”, 2002.

Jaką potrzebę użytkowników ma zaspokajać serwis/aplikacja

Punktem wyjścia naszych rozważań zawsze musi być jednak konkretna czynność jaką użytkownik będzie realizował w serwisie. Taka czynność jest już zwykle zdefiniowana przez klienta – powiedzmy, że mamy do zaprojektowania serwis, za pomocą, którego użytkownicy będą uploadować swoje zdjęcia. W takim wypadku czynnością, którą użytkownicy będą realizować jest utrzymywanie więzi społecznych.

O metodzie projektowania AOF, pisał Porter w książce omawianej na wrocławskich spotkaniu UX Books. Zatem wychodzimy od czynności – podtrzymywanie więzi społecznych, idziemy do konkretnej akcji jaką użytkownik musi wykonać by realizować ta czynność – upaloadowanie zdjęć, a na samym końcu określamy konkretne parametry akcji (jak będzie w praktyce wyglądać uploadująca funkcjonalność).

Przystępując do projektowania musimy mieć na uwadze zadania jakie użytkownik będzie realizował w serwisie. Tym zadaniom podporządkować cały system. Innymi słowy na samym początku musimy zaprojektować flow – przepływ informacji w systemie. Skupiamy się na akcji uploadowania zdjęć do niej dobudowujemy inne funkcjonalności na zasadzie wspomagającej lub uzupełniającej.

Skupiamy się na tym by zaprojektować jak najlepszą ścieżkę realizacji akcji przez użytkownika. Starajmy się zaprojektować swoisty lejek do którego użytkownika wpada i wykonuje zaplanowane przez nas czynności. Tyle teoria.

Rzecz jasna nie możemy przewidzieć tego w jaki sposób użytkownik będzie korzystał z naszego serwisu. Nie każdy będzie przechodził ścieżką od reklamy po stronę główną i przez kolejne zaplanowane przez nas kroki. Niektórzy użytkownicy będą trafiać w różne części naszego lejka i każdy element musi spełniać swoją rolę – napędzać konwersję. Niezależnie od tego w które miejsce trafi użytkownik, zawsze musi być dla niego jasne w jakim znajduje się serwisie, jaką potrzebę dzięki niemu może zrealizować i jak w najprostszy sposób to zrobić.

Możemy powiedzieć, że każda nasza strona jest stroną typu landing page. Dobry projektant nie tylko zaprojektuje serwis, który jest użyteczny, ale również taki, który spełnia swoje cele biznesowe. To jest probierzem dobrego projektu – zadowolenie użytkownika z powodu otrzymania świetnej aplikacji i zadowolenie klienta w postaci rosnącego konta bankowego na Kajmanach.

Etapy pracy nad projektem

• Konsultacje z klientem
• Poznanianie potrzeb grupy docelowej
• Dogłębne poznanie modelu biznesowego serwisu, oraz planów jego rozwoju, ewentualnie wprowadzenia dodatkowych form zarabiania w serwisie
• Dysponowanie wynikami badań fokusowych
• Przejrzenie aplikacji konkurencyjnych, zastosowanych w nich rozwiązań, historii serwisów konkurencyjnych
• Przeprowadzenie burzy mózgów w firmie
• Przyjęcie określonej metodologii pracy, określamy czynność jaką użytkownik realizuje, określamy wszelkie dostępne możliwości jej realizacji, te z kolei dzielimy na konkretne funkcjonalności
• Przedstawienie diagramu przepływów – pokazanie za pomocą diagramu UML jak będzie przebiegać realizowanie celów w serwisie przez użytkownika
• Wybranie najlepszych funkcjonalności – dysponując wcześniejszymi projektami możemy sobie zaoszczędzić wiele pracy
• Przystąpienie do sporządzenia projektu funkcjonalnego – ja polecam Axure jako najlepsze obecnie narzędzie do prototypowania

Najbardziej istotnym elementem w pierwszej fazie projektowania jest poznanie użytkowników dla których projektujemy system. Możemy tutaj albo konsturować persony, albo poznać bardziej dogłębnie grupę docelową do której kierowana jest aplikacja. Testy fokusowe przyczyniają się do określenia modeli mentalnych przyszłych użytkowników aplikacji. Pod tą dziwnie brzmiącą nazwą kryje się odpowiedź na pytanie jak użytkownicy myślą, w jaki sposób podejmują decyzje, rozwiązujaą problemy w codziennym życiu. System pozwala na prostsze rozwiązywanie określonych problemów jakie pojawiają się w codziennym życiu użytkownika. Projektanci muszą zgłębić dotychczas stosowane przez użytkowników metody ich rozwiązywania i dostosować aplikację do już nabytych doświadczeń użytkowników.

W poradnikach Apple na temat budowy interfesju użytkownika możemy przeczytać: „Użytkownik ma już wypracowany model mentalny opisujący zadania jakie Twoja aplikacja pozwala mu wykonać. Model ten stanowi komponent doświadczeń użytkownika z życia codziennego, doświadczeń z obsługą innego oprogramowania i serwisów WWW i doświadczeń z komputerami w ogóle. Na przykład użytkownicy mają praktyczne doświadczenia z wysyłaniem listów pocztą, aplikacja, która będzie im pomagać utrzymywać kontakt z bliskimi i znajomymi, musi odzwierciedlać oczekiwania uzytkowników co do czynności wysyłania listu – tworzenie nowego listu, precyzowanie odbiorcy, wysyłanie.”

Aplikacja, która idzie pod prąd oczekiwaniom użytkowników, igrnorująca ich modele mentalne skazana jest na porażkę.

Rzecz jasna przedstawiony tutaj schemat czynności projektowych to tylko propozycja, która moim zdaniem dość dobrze się sprawdziła w przypadku realizowanych przeze mnie projektów. Zależnie od projektu i wybranej metodologii pracy, nasz schemat projektowy może być inny. Mogą się w nim pojawić persony, papierowe prototypowanie czy jeszcze inne elemeny.

I na sam koniec – nie zapomnijmy o tym, żeby nasze makiety poddać ocenie użytkowników i wykonać z użytkownikami co najmniej jedną sesję badawczą.

Dlaczego należy prototypować?

Oszczędność czasu, przy dużych projektach stworzenie prototypu przyczyni się do oszczędności czasu – mniej niedomówień i braku zrozumienia na linii projektant – zespół programistów.

Pewność ostatecznych wyników, kiedy programiści wiedzą, co i jak ma działać mają do dyspozycji dynamiczny projekt plus specyfikacje w której opisano to co czego nie dało się zasymulować, to możemy być pewni, że ostatecznie otrzymamy świetnie działający serwis, wykonany zgodnie z naszymi założeniami.

Oszczędność pieniędzy, przy braku prototypu, ilość poprawek wprowadzanych ad hoc przez klienta i ilość poprawek wynikających z powodu braku zrozumienia naszych intencji przez programistów, prowadzi do wydłużenia się realizacji projektu o 1000%. Klient traci pieniądze nie tylko w przeliczeniu na 1 h pracy, traci zyski które mógłby wypracować gdyby aplikacja była gotowa na czas.

Przyjemna praca, projekt funkcjonalny to rezultat wielogodzinnych konsultacji z klientem, który nie zawsze do końca wie co chce zrobić, mając w ręku gotowy prototyp o wiele łatwiej torpedować pomysły klienta idące w kierunku zmian już realizowanej koncepcji, jednym słowem każda ze stron wie na czym stoi.

Klient ma możliwość zobaczenia jak jego serwis będzie nie tylko wyglądał, ale przede wszystkim jak będzie działał. Tutaj możemy natknąć się na rafy niezrozumienia, bo klient nie zawsze rozumie, że prototyp to nie jest działający serwis. Zatem projekty muszą być pozbawione szaty graficzne i skupiać się na mechanizmach działania serwisu, bez niepotrzebnych rozpraszaczy w postaci kolorowych przycisków i obrazków.

W następnym wpisie spróbuję bardziej szczegółowo przyjrzeć się jednemu z narzędzi do tworzenia makiet stron WWW, czyli programowi Axure.

Warto poczytać:

Apple Human Interface Guidelines
Mental Models and Usability
Webaudit, Makiety, prototypy i 6 popularnych błędów