Projektowanie przyszłego serwisu WWW wymaga przede wszystkim zebrania gruntowanych informacji na temat przyszłych użytkowników. Na tym etapie nieodzowne stają się badania fokusowe wśród grupy docelowej. Zakładamy, że klient wie, że na dany produkt w postaci wirtualnej usługi jest odpowiednio chłonny rynek użytkowników. Po przeprowadzeniu badań fokusowych, konsultacjach z klientami, przyjrzeniu się do tej pory stosowanym rozwiązaniom w podobnych projektach, możemy przystąpić do przeprowadzenia firmowej burzy mózgów. Wyposażeni w ogromną tablice i ścieralne mazaki tudzież stosy różnokolorowych samoprzylepnych karteczek wspólnie zastanawiamy się nad tym, co jak i gdzie miałby mieć projektowany serwis.

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

Ten wpis opublikowano w dniu piątek, Październik 16th, 2009 o godzinie 22:36 w kategorii Human Computer Interaction, Projektowanie i prototypowanie. Subskrybuj RSS 2.0 komentarze. Zostaw komentarz, albo trackback ze swojej strony.