Moje prototypy pozbawione były również tekstów, nie licząc nazw zakładek w każdym menu. Zamiast tekstów umieszczałem „lorem ipsum”, co również miało służyć nie rozpraszaniu uwagi klienta.

Pozostawiałem też dużo miejsca na inwencję twórczą grafika, zatem wszelkie elementy typu ikony, wykończenie graficzne elementów, czy wstawienie odpowiednich zdjęć pozostawiałem grafikowi. Podsumowując prototyp był:

• wykonany z odcieniach szarości
• pozbawionych tekstów nie licząc nazw zakładek
• pozbawiony zdjęć (placeholdery zamiast zdjęć) oraz ikon (przynajmniej braku spójnego zestawu ikon)

Ilustracja projektu strony głównej serwisu Sabre: źródło: http://www.stephenthomas.com/about/stn.php

Wprowadzamy kolory, wyrzucamy „lorem ipsum”

Prezentując tego typu prototypy klientowi zauważyłem jednak, że moja konkurencja wygrywa ze mną prezentując bardzo podobne projekty, ale w większym stopniu wykończone graficznie i tekstowo. Teraz mogą się podnieść głosy, że nie potrafiłem przekonać klienta do idei prototypu, być może, ale prawda jest taka, że czarno – biały prototyp nie był tak atrakcyjny sprzedażowo jak jago konkurent lepiej wykończony graficznie. Nie mówię tutaj o całkowitym wykończeniu graficznym, ale raczej mam na myśli wprowadzenie kilku elementów graficznych, które lepiej oddają charakter prototypu:

• ogólne utrzymanie stylistyki kolorystycznej w odcieniach szarości
• wprowadzenie wyblakłych kolorów w miejscach serwisu wskazujących na elementy aktywne np. 20% koloru jako tła aktywnej zakładki w menu, czy przycisku „call to action”, wyróżnienie kolorem aktywnego kroku w procesie zakupowym, wprowadzenie kolorów w elementach które mają zwracać uwagę użytkownika np. dodatkowy link informujący o promocji,
• użyte wyblakłe kolory powinny być zbliżone do kolorystyki CI serwisu, używamy oryginalnego logotypu,
• nie stosujemy tekstów „lorem ipusm” jeśli to możliwe, „lorem ipusm” może negatywnie wpływać na wygląd serwisu w fazie wdrożeniowej, może się okazać, że dodawane teksty są długie i powodują po prostu rozbicie layoutu graficznego, konieczność przenoszenia tekstów do drugiej linii, poszerzania szerokości strony, zmniejszenia szerokości sidebarów, etc.
• wprowadzanie do prototypu tekstów merytorycznych przesłanych przez klienta
  stworzenie tekstów perswazyjnych, warto podjąć się pracy copywritera (lub współpracy z copywriterem) i przynajmniej w najważniejszych częściach serwisów zaproponować jakieś teksty perswazyjne, zamiast „lorem ipsum”

Nie poruszam tutaj spraw, które są dla mnie jasne, ale często pomijane w pracy nad projektem. Jeśli pracujemy nad poważnym projektem, gdzie prototyp ma być podstawą prac dla grafika i dewelopera, to musi on być w jak największym stopniu zbliżony do wersji ostatecznej. Dlatego też jestem zwolennikiem tworzenia prototypów „high fidelity”, „pixel precise”. Takie projekty mogą powstawać tylko dzięki stałemu kontaktowi z klientem i akceptowaniem przez niego kolejnych faz pracy projektanta.

O czym powinien pamiętać projektant?

Projektant powinien pamiętać nie tylko o wymaganiach funkcjonalnych i niefunkcjonalnych dotyczących projektu ale również brać pod uwagę inne czynniki w fazie przedprojektowej i w fazie tworzenia prototypu.

Przed przystąpieniem do projektu należy pamiętać o:

Nie ma projektu w którym nie pojawiłyby się jakieś dodatkowe pytania do klienta, zawsze warto pytać o precyzować, to nie truizm ponieważ projektantowi może się wydawać, że rozumie w 100% założenia klienta, a później się okazuje, że klient i projektant rozumieli coś zupełnie innego pod tym tymi samymi pojęciami. Warto uściślić, czym jest strona unikalna w projekcie, co to dokładnie znaczy że prototyp będzie interaktywny, jaki będzie zakres zmian które chciały wprowadzić klient po przesłaniu wersji ostatecznej,

Jeśli pracujemy nad przeprojektowaniem serwisu już istniejącego to należy koniecznie zapoznać się ze statystykami serwisu, kluczowe jest skonfrontowanie tego co mówi klient o celach serwisu z tym co zostało skonfigurowane w celach w Google Analytics. Należy zidentyfikować istniejące wąskie gardła i przejrzeć źródła odwiedzin (to rzecz jasna skrótowy opis).

Należy porozmawiać z deweloperami, programiści mogą naszą pracę taktować jako zbędną, ale coraz częściej mam do czynienia z projektami w których zespół programistów tworzy kod na podstawie dostarczanych ekranów poszczególnych stron. Strony tworzone są w oparciu o wcześniej opracowaną architekturę informacji, opisane ścieżki konwersji i dokładną mapę wszystkich podstron w serwisie.

W fazie opracowywania architektury informacji należy pamiętać o:

Samo pojęcie architektury informacji jest bardzo różnie rozumiane. Ja proponuję je zdefiniować jako szkielet przyszłego serwisu, który powinien się składać z:

• hierarchicznej mapy serwisu, składającej się z nazw poszczególnych podstron „slug’ów”: skróconej nazwy oraz jeśli to możliwe ścieżki url np. onet.pl/film/premiery/true_grit,
• systemu nawigacji – z jakich zakładek będzie się składać nawigacja główna, nawigacja drugorzędna, narzędziowa,
• określenie ścieżek konwersji, np. oznaczenie kolorem podstron jakie użytkownik musi przejść by w zrealizować swój cel np. zakup produktu oraz opracowanie diagramu przepływu
• wstępnego zarysu rozkładu elementów w serwisie w postaci placeholderów np. umieszczenie placeholdera w miejscu gdzie będzie menu o zbliżonej do ostatecznego menu szerokości i długości, umieszczenie placeholdera treści, sidebara, stopki, etc.

Wszystkie te elementy powinny zostać przesłane do klienta i przez niego zaakceptowane.

Ilustracja diagramu przepływu składania zamówienia tzw. flow na przykładzie platformy e-commerce Magento: źródło: http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_purchase_checkout_and_order_processing_flow?do=show

W fazie opracowywania prototypu należy pamiętać o:

Projektując należy brać pod uwagę nie tylko cele użytkownika i użyteczność, ale również cele biznesowe serwisu, może np. klientowi zależeć na tym, aby reklam w serwisie było dużo, co naturalnie wpływa negatywnie na użytkownika, zadaniem projektanta jest zatem uwzględnienie w prototypie wymiarów i miejsca emisji reklam. Dalej należy uwzględnić ograniczenia ze strony deweloperskiej, może nasz projekt będzie super innowacyjny, ale okaże się, że programiści nie są w stanie go wdrożyć w przewidzianym czasie, ponieważ – co jest najczęstszym zarzutem – mają już wcześniej przygotowane jakieś rozwiązania i nie chcą programować modułów od podstaw. Wówczas nasze super pomysły zostaną przykrojone do tego co proponują deweloperzy. Projektując miejmy to na uwadze, czy projekt będzie programowany od podstaw, czy może będzie w większym stopniu korzystał z już wcześniej opracowanych modułów dla np. poprzedniego serwisu, które tylko wymagają niewielkiej przebudowy, innej grafiki, zmian przycisków czy umiejscowienia w serwisie.

Dalsze prace powinny przebiegać w stałym kontakcie z klientem. Klient powinien otrzymać kilka działających podstron w pierwszym etapie prac nad prototypem, tak aby projektant mógł na bieżąco korygować projekt o uwagi klienta. Tutaj kryje się jednak pewna pułapka w przypadku dużych projektów dla większych firm, swoje zdanie n.t. prototypu i swoje zmiany zgłasza nie tylko project manager, ale również grafik, inny project manager, szef działu, czasem nawet deweloperzy. Projektant wprowadzając te wszystkie zmiany na bieżąco nie miały czasu na rozwijanie projektu. W przypadku kiedy decydentów jest więcej warto poprosić tylko o akcept całej architektury informacji i przekazać gotowy prototyp już po zakończeniu prac. Wówczas zebrać od klienta listę uwag (pamiętajmy, że wcześniej klient zaakceptował cały szkielet czyli AI serwisu, dlatego też jeśli jego zmiany będą bardzo daleko idące należy je osobno wyceniać).

Po skończeniu prototypu, albo w czasie prac nad nim co zależy do czasu trwania projektu projektant powinien opisać wszystkie akcje użytkownika – albo te najważniejsze -wraz z reakcjami systemu w postaci przypadków użycia. Moim zdaniem to zadanie nie powinno być realizowane przez dewelopera, ponieważ natura prototypu jest taka, że niektórych sposobów działania funkcjonalności czy ograniczeń związanych z brakiem możliwości podłączenie do bazy danych nie da się skutecznie zasymulować. Projektant dobrze zna swoje projekt i szybciej wykona przypadki użycia niż inna osoba, która dopiero musiałby poznać projekt, zapoznać się z prototypem i zadać wiele pytań uszczegóławiających.

Ilustracja jednej z podstron prototypu serwisu transakcyjnego Pekao 24 wykonana przez agencję K2: źródło: http://www.slideshare.net/macieklipiec/case-study-pekao24-k2-user-experience-4993614?from=ss_embed

Rola projektanta w całym procesie jest moim zdaniem kluczowa. Projektant przejmuje części obowiązków project managera np. kontaktując się z działem deweloperskim firmy, poniekąd wchodzi w kompetencje grafika oraz copywritera, do tego dostarcza prototyp który jest bardzo wysokiej jakości, wraz z rozpisaniem wszelkich akcji w systemie za pomocą przypadków użycia. Takie projekty rzecz jasna kosztują więcej jeśli chodzi o wynagrodzenie projektanta, ale są o wiele bardziej efektywne i mniej czsasochłonne niż projekty w których projektant jest tylko kolejnym trybikiem w wielkiej maszynie project managera, ponieważ:

• na samym początku prac definiowane są wymagania w sposób bardzo szczegółowy, zarówno funkcjonalne jak i niefunkcjonalne
• projektant ma dostęp do danych statystycznych serwisu oraz do danych związanych ze strategią produktu poznaje zatem ograniczenia biznesowe jak wcześniej wspomniana emisja dużej liczby reklam
• projektant ma bezpośredni kontakt z deweloperami, poznaje wymagania technologiczne, projektując bierze je pod uwagę
• klient akceptuje projekt architektury informacji
• dostarczony prototyp jest projektem „pixel precise” i „high fidelity”- czyli elementy w projekcie są dokładnym odzwierciedlaniem tych które ostatecznie znajd się w wersji zaimplementowanej, np. w zakresie wielkości poszczególnych elementów, dynamiki działania elementów np. symulacja javascript

Długa droga przed projektantem interakcji

Podsumowując te rozważania należy mieć na uwadze to, że polski rynek interaktywny wciąż jest mały i słabo rozwinięty. Czego dowodem jest to, że kwestie związane z użytecznością, czy dobrym funkcjonalnym projektem wciąż nie są ważnymi elementami budowy przewagi konkurencyjnej. Samemu mam często do czynienia z sytuacją w której to grafik wraz z deweloperami pracuje nad projektem, być może są przypadki kiedy taka współpraca owocuje świetnym serwisem, ale ja ich nie znam.

W dużych rozwiniętych projektach najważniejszą rolę odgrywa właśnie projektant interakcji, konsultujący się z grafikami, deweloperami i klientem na każdym etapie prac. To projektant odpowiada za to jak będzie wyglądała ścieżka konwersji w serwisie, w zasadzie spada na niego w dużym stopniu odpowiedzialność za przyszłe zyski serwisu (wiadomo, że są tutaj liczne ograniczenia, typu strategia i reklam, ale zakładam, że te elementy klient dobrze przemyślał).

Żeby nie było za miło mam teraz dużo zarzutów do projektantów, również do siebie – samemu cały czas zgłębiam technologię i zagadnienia graficzne. Wciąż się uczę i nie wierzę, że można być dobrym projektantem nie znając technologii, konkretnie projektant powinien umieć programować przynajmniej w jednym języku (server side) na jakimś podstawowym poziomie. Chodzi o to, żeby się orientował np. co z grubsza jest możliwe w projekcie, a co nie. Rzecz jasna przy dużych i skomplikowanych projektach powinien móc liczyć na pomoc dewelopera. Poza tym projektanci nie zdobędą zaufania programistów jeśli sami nie będą umieć programować. Tak samo przedstawia się sprawa z tworzeniem grafiki – projektant powinien umieć przynajmniej na podstawowym poziomie obsługiwać Photoshopa, znać dobrze HTML’a i CSS’a oraz mieć pojęcie o javascripcie.

Uff nareszcie koniec, jestem ciekaw waszych opinii n.t. roli projektanta i kompetencji jakie powinien posiadać.

Niestety z uwagi na ograniczenia zapisane w umowach nie mogę w tej chwili umieścić zdjęć które ilustrowałby kolejne etapy prac, ale postaram się zdobyć zgody i umieścić ilustracje w najbliższym czasie.

Ilustracje zawarte w tym artykule zostały przeze mnie użyte na zasadzie „prawa cytatu”, podaję linki do materiałów, a same materiały stanowią przykład dobrych praktyk.

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.