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.

Zanim napiszesz choć jedno słowo

Poznaj cel serwisu

Serwisy internetowe mogą realizować wiele różnych celów, najczęściej w projektach biznesowych jest to różnie pojęty zysk. Liczony w twardej walucie, np. „serwis sprzedający e-booki musi tyle i tyle zarobić w danym czasie”, albo „serwis hostujący pliki musi zarobić określoną ilość pieniędzy z pozyskanych abonamentów ludzi wykupujących dostęp”. Serwis może też mieć inne cele nie przekładające się bezpośrednio na twardy zysk, np. serwis ma informować pacjentów o ofercie nowych leków, skierowany jest do ludzi starszych. Celem serwisu jest wówczas zbudowanie świadomości dotyczącej stosowania leku w tej grupie wiekowej.

W Internecie nazywamy to konwersją (wskaźnik konwersji), czyli stosunkiem liczby osób, które wykonały jakieś zadanie (np. wykupiły abonament, zalogowały się na stronie) do liczby osób które np. odwiedziły serwis. Użyteczność ma wspierać główny cel serwisu i mniejsze cele, ale zawsze ma służyć konwersji przez na przykład dobrze zaprojektowany proces zakupowy lub ogólny wygląd i dopracowanie szczegółów formularza kontaktowego. Jeśli znasz cel to poznaj też użytkowników serwisu. Zanim zagłębisz się w statystyki, porozmawiaj ze swoim klientem, zapytaj dla kogo jest serwis, kogo chcą przyciągnąć, co się udaje a co nie, jaką rolę odgrywają działania offline. Im więcej wiesz, tym bardziej precyzyjnie będziesz myślał.

Kim są użytkownicy

Zdarza się, że właściciel serwisu myśli, że jego klientami są mężczyźni po 40 roku życia, a okazuje się, że ta grupa nie stanowi większości klientów. Skonfrontuj to co mówi tobie klient na temat użytkowników z rzeczywistymi statystykami serwisu. Gdy usłyszysz, że serwis jest stworzony dla wszystkich, zapytaj dla kogo szczególnie i czy ci „wszyscy” mają takie same cele w serwisie.

Rzuć okiem na statystyki serwisu

Numer dwa po rozmowach z klientem to dostęp do statystyk serwisu, najlepiej Google Analytics. Nie musisz ich studiować z zapałem, ale ważne, żebyś miał ogólny ogląd na temat ilości użytkowników, dynamiki wzrostu, źródeł odwiedzin, wskaźnika odrzuceń w poszczególnych segmentach użytkowników oraz tego kiedy użytkownicy rezygnują z surfowania po serwisie. Takie podstawowe dane pozwolą Ci przejść do punktu trzeciego, czyli….

Poznaj ścieżkę konwersji użytkownika

Jest to punkt bezpośrednio związany z punktem drugim, ale warto o nim szczególnie pamiętać. Każdy serwis powinien mieć zdefiniowane ścieżki konwersji. Idąc do np. do supermarketu podążasz precyzyjnie zaprojektowaną ścieżką – ktoś postawił regał z pieczywem daleko od wejścia, żebyś musiał przemierzyć cały sklep by dotrzeć do bułek, umieścić batony i kondomy przy kasach, żebyś mógł dokonać zakupów w ostatniej chwili. Ktoś też rozpylił zapach lawendy i wymyślił to co ma mówić do ciebie sprzedawca. W Internecie podejmowane są podobne działania, masz zobaczyć produkt, sprawdzić jego opis, i kupić Nic prostszego, nie możesz tylko po drodze zgubić się w gąszczu podobnie wyglądających przycisków, które wykonują różne funkcje, być zmuszonym do podawania imienia swojego barta ciotecznego i numeru NIP przy zakupie, czy też nie mieć możliwości powiększenia zdjęcia produktu. Kiedy już zidentyfikujesz ścieżki konwersji, (czasem będziesz musiał budować je od podstaw), łatwiej Ci będzie znaleźć wąskie gardła serwisu, czyli miejsca gdzie odpada większość użytkowników. Pytanie do Ciebie: dlaczego użytkownicy rezygnują z zakupu? Może proces zakupowy ma 16 korków i zajmuje 30 minut, a może cena przesyłki przewyższa cenę produktu…a może właściciel serwisu ma zupełnie inne cele…

Wejrzyj w bebechy

Potrzebne są Ci tylko podstawowe informacje dotyczące technologii budowy serwisu/aplikacji, będzie to ważne później kiedy będziesz formułował wskazówki dla developerów. Ważne żebyś miał jakieś oględne pojęcie o technologii.

A teraz do dzieła, weź pióro i zacznij badanie

Eksperckie badanie = min. dwóch ekspertów

Dlaczego akurat dwóch – dlatego, że to lepsze wyjście, niż jeden ekspert. Zawsze możesz coś pominąć, nie wychwycisz 100% błędów, potrzebujesz drugiej osoby, która w tym samym czasie również będzie badała serwis. Pewnie pod koniec samego badania okaże się, że macie wspólnych 90% błędów, ale to 10% stanowi właśnie wartość dodaną.

Wciel się w użytkownika

Kluczowa część każdego badania użyteczności. Jesteś użytkownikiem, który korzysta z różnych funkcjonalności badanego serwisu. Weźmy pierwszy z brzegu przykład, czyli typowy sklep internetowy, jako wcielający się w rolę badanego spróbuj zamówić coś z tego sklepu, dowiedzieć się czegoś o danym produkcie, przejść przez proces zakupowy, etc. Jesteś użytkownikiem i śledzisz napotkane przez siebie przeszkody w toku realizacji poszczególnych zadań w serwisie. Wiesz jacy użytkownicy korzystają z serwisu, jakie są jego cele, na czym szczególnie zależy zleceniodawcy. Może np. kluczową rolę z pkt widzenia konwersji odgrywa dział „odzież damska” bo to najczęściej kupują klienci i na tym właściciel sklepu ma najwyższą marżę. Zastanów się jak możesz pomóc właścicielowi w konwersji ruchu napływającego do działu z odzieżą damską, może większość kupujących to mężczyźni, którzy potrzebują profesjonalnej pomocy w postaci video tutoriali wyjaśniających czym jest rozmiar stanika?

Określ kategorię błędu

Każdy błąd użyteczności w serwisie może być problematyczny dla użytkownika, ale tylko te które uniemożliwiają mu, albo drastycznie zmniejszają prawdopodobieństwo wykonania zadania powinny być traktowane jako błędy kluczowe, które należy poprawić w pierwszej kolejności. Do takich błędów możemy np. zaliczyć: puste linki, nieklikalne buttony, nie działające formularze, brak podstawowych informacji o firmie/produkcie/ofercie, brak optymalizacji serwisu sprawiający, że nawet przy dużej przepustowości łącza serwis bardzo długo się ładuje, brak optymalizacji pod najważniejsze przeglądarki. Jaki błąd będzie przez nas traktowany jako krytyczny zależy od specyfiki serwisu – na pewno do krytycznych zaliczany będzie każdy błąd, który sprawia, że użytkownik nie może, albo ma bardzo ograniczone możliwości przejścia przez najważniejsze ścieżki konwersji w serwisie.

Do lżejszych błędów na pewno możemy zaliczyć te, które w umiarkowany sposób przeszkadzają użytkownikowi w ukończeniu zadania. Do takich błędów możemy zaliczyć np. brak spójnych oznaczeń linków w serwisie, trudność rozpoznania, który element jest linkiem, skomplikowaną i nie logiczną nawigację w serwisie (błędy projektowe nawigacji, umieszczanie wielu poziomów zagłębień w serwisie), brak prawidłowej walidacji pól formularzy, brak przyjaznych URL, brak atrybutów alt przy obrazkach,

Do trzeciej kategorii możemy zaliczyć wszelkie pozostałe problemy, typu: brak podlinkowania logo do strony głównej, brak możliwości dokonania zakupu w sklepie internetowym jeśli nie założy się w nim konta, używanie technicznego języka dla nietechnicznych użytkowników.

Rzecz jasna przykłady, które podałem nie zawsze muszą znajdować się akurat w tej grupie w której wskazałem. Wszystko zależy od serwisu i jego celów.

Rekomenduj pozytywne rozwiązania

Nie możesz przygnieść klienta negatywnymi opiniami o jego serwisie, wskaż co najmniej kilka rozwiązań pozytywnych. To taki psychologiczny zabieg – nikt nie lubi być ciągle krytykowany.

Opisz koszty implementacji zmiany

Trudna sprawa, ale zawsze można określić problem z implementacją: trudne w implementacji, wymaga zmian takich i takich w kodzie, zaangażowania developerów, zmian innego rodzaju, umiarkowanie trudne, łatwe – zmiany w CSS, elementy front endu. Jeśli nie masz wiedzy technicznej poproś znajomego developera o pomoc w oszacowaniu czasu pracy nad implementacją proponowanych przez ciebie zmian. Pierwszeństwo mają krytyczne problemy w serwisie, ale często jeden problem wpływa na drugi, jeden generuje drugi i rozwiązanie tego pierwszego sprawi, że drugi również się rozwiąże, albo nie będzie taki uciążliwy. Poprawki należy zacząć od tego typu błędów krytycznych w serwisie, czyli nie poprawiamy jak leci, ale poprawiamy tak, by eliminacja jednego błędu, automatycznie wyeliminowała inny błąd użyteczności.

Rekomenduj zmiany

Twoje rekomendacja powinna być jasna i zrozumiała w ciągu kilku sekund Pokazuj zdjęcia dobrych rozwiązań, sam zaprojektuj kilka ekranów, pokażesz klientowi, że nie tylko umiesz identyfikować błędy, ale i projektować.

Opisuj błędy w sposób zrozumiały

Co to znaczy? Czy to oznacza, że musisz stworzyć kilka kategorii, np. nawigacja gdzie wrzucasz wszystkie problemy związane z nawigacją w serwisie? Możesz tak zrobić, ale czy taki podział będzie optymalny z punktu widzenia developerów wprowadzających zmiany na podstawie Twojego dokumentu? Moim zdaniem nie, raport powinien być podzielony według kryterium ważności błędów. Innymi słowy na samym początku przedstawiasz błędy krytyczne z punktu widzenia najważniejszych ścieżek konwersji w serwisie. Poprawki mają tak szybko jak to tylko możliwe wpłynąć na wzrost zysku serwisu. Jako najważniejsze z najważniejszych umieszczasz te problemy kluczowe, które generują inne problemy kluczowe, będziesz mógł je zidentyfikować dzięki pomocy developera.

Stwórz podsumowanie dla zarządu

Zarząd lubi krótkie i zrozumiałe fragmenty. Twojego raportu nie będzie czytał nikt z zarządu, a tylko odpowiedzialni za projekt project managerowie oraz wprowadzający zmiany web developerzy. Jeśli jakimś cudem wpadnie on w ręce kogoś z zarządu, to ta osoba musi w ciągu 60 sek, czytania tego raportu przekonać się, że pieniądze firmy zostały dobrze wydane. Wszelkie wykresy typu ROI, zyski, itp mile widziane, nawet jeśli dotyczą one innych projektów, co rzecz jasna należy wskazać.

Testuj!

Ten punkt może być naprawdę obszerny, ale z podstawowych zadań jakie powinieneś wykonać to:

• sprawdź jak serwis wyświetla się na urządzeniach przenośnych, przede wszystkim telefonach komórkowych, serwis nie musi być specjalnie projektowany pod urządzenia mobilne, choć byłoby to najlepsze rozwiązanie, jednak dobrze zoptymalizowany serwis powinien bez problemu być dostępny przynajmniej w jakimś procencie przez telefon komórkowy
• sprawdź jak szybko serwis się ładuje: http://tools.pingdom.com
• sprawdź meta tagi
• używaj web developer add on, dodatku do firefoxa, za pomocą którego szybko przetestujesz wszystkie elementy serwisu
• sprawdź czy serwis dobrze wyświetla się na różnych przeglądarkach i jeśli to konieczne również na różnych systemach operacyjnych
• waliduj, za pomocą checkerów w3c, ale bądź ostrożny, strona Google też nie przechodzi testów walidacji
• sprawdź czy serwis nie ma linków prowadzących donikąd

Nie zapominaj o dostępności

Temat często traktowany po macoszemu jako niewielki dodatek do raportu dotyczącego użyteczności, jest tak naprawdę bardzo ważnym elementem. Nie będę się tutaj rozwodził na temat zasad jakie spełniać ma serwis, oprócz tylko jednej – zapewnij użytkownikowi alternatywny dostęp do treści i funkcji serwisie. To jest najważniejsza zasada – serwis powinien być tak samo dostępny, czytelny i w dużym stopniu możliwy do używania, bez obrazków, arkuszy stylów, javascriptu, elementów flash. Temat dostępności będzie rozwijany w następnych postach.

Wyjdź do ludzi

Testujesz serwis sklepu internetowego, zadzwoń do konsultanta i zapytaj go o pomoc, zamów produkt ze sklepu, wypytuj o szczegóły, staraj się go zdenerwować. Jeśli masz możliwość idź do sklepu w realu, bądź namolnym klientem, sprawdź jak reaguje obsługa. Użyteczność serwisu to tylko etap, dalej mamy kontakt z klientem, wysyłkę, obsługę po sprzedażową, to tak buduje się zaufanie i zyskuje lojalnych klientów na lata.

Wyślij

Bądź dostępny

Twój raport powinien być dostępny zarówno w wersji elektronicznej jak i papierowej. Przekazując go klientowi umieść kopię na FTP, napisz o tym w samym raporcie, do wersji papierowej dodaj raport nagrany na płycie DVD, najlepiej z oznaczeniem twojej firmy lub nazwisk i telefonu na samym nośniku (lightscribe nie markerem po płycie!).

Sprawdź czy wprowadzono zmiany

Bolączką wielu badaczy jest to, że zmiany są wprowadzane wolno, albo czasem nawet wcale. Ciężko w takiej sytuacji tworzyć case studies i samemu weryfikować swoje własne wskazówki. Bądź cierpliwy i monitoruj proces wdrażania zmian. W końcu sam raport powstaje właśnie w tym celu.

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?

Serwis musi realizować cele jakie zostały przed nim postawione. W przypadku serwisów e-commerce jest to sprzedaż produktów. W przypadków serwisów informacyjnych stopień zainteresowania użytkowników reklamami emitowanymi w serwisie oraz ilością sprzedaży płatnej treści. W przypadków serwisów firmowych celem jest przyciągnięcie efektywnego ruchu, potencjalnie zainteresowanych klientów oraz zachęcenie ich do dokonania zakupu oraz nawiązania kontaktu. Wysoka użyteczność serwisu przekłada się na zwiększenie konwersji w grupie użytkowników które odwiedzają nasz serwis. Wysoka użyteczność to mniej porzuconych koszyków, więcej odwiedzonych podstron, więcej zrealizowanych celów w witrynie. Wysoka użyteczność serwisu to większe pieniądze dla właściciela.

Większe zyski = wysoka użyteczność plus pozyskanie efektywnego ruchu

Ta podstawowa zasada jest powtarzana w każdej książce i w każdym serwisie zajmującym się e-marketingiem, poniższe wyliczenia również nie wyważają żadnych zamkniętych drzwi. W takiej lub innej postaci można je znaleźć np. w serwisach zajmujących się optymalizacją (np. Wider Funnel). Poniższe wyliczenia rzecz jasna są tylko przykładami, pewnym modelem do ilustracji powyższej tezy, że zysk buduje się dzięki kombinacji efektywnego ruchu oraz umiejętności jego zagospodarowania, czyli właśnie wysokiej użyteczności

Wyliczenia opierają się na założeniu, że w serwisie istnieje możliwość zwiększenia współczynników konwersji poprzez poprawę użyteczności, a więc np. zmniejszenie wskaźnika porzuceń koszyka, poprzez optymalizację formularzy oraz na założeniu, że dopływ efektywnego ruchu do serwisu oznaczać będzie proporcjonalny wzrost liczby konwersji.

Poniżej opierając się na fikcyjnych danych zaprezentowano metody realizacji wyższego przychodu ze sprzedaży produktów i/lub usług. Nasz cel główny możemy realizować jednocześnie na dwa sposoby:

• wzrost efektywnego ruchu w serwisie, przy stałym współczynniku konwersji – pozyskujemy ruch
• wzrost współczynnika konwersji przy stałej liczbie efektywnie odwiedzających serwis użytkowników – zagospodarowujemy ruch, przekształcając użytkowników w klientów

Wzrost efektywnego ruchu w serwisie, przy stałym współczynniku konwersji – pozyskujemy ruch

Poniżej określono fikcyjne wskaźniki dla badanego serwisu. W celu osiągnięcia celu jakim jest uzyskanie minimum 200 tys. zł przychodu po okresie 12 miesięcy zwiększamy efektywny ruch (czyli ruch serwisie po odjęciu „bounce rate”) o 2% (0,02) z każdego miesiąca. Zakładamy, że wzrost efektywnego ruchu w serwisie przekłada się płynnie za wzrost sprzedaży. Zatem jeśli:

10000 efektywnie odwiedzających = 200 sprzedanych produktów to
10200 efektywnie odwiedzających = 204 sprzedanych produktów itd…

Współczynnik konwersji nie ulega zmianie i wynosi w ciągu 12 miesięcy 2%.

Wzrost współczynnika konwersji przy stałej liczbie efektywnie odwiedzających serwis użytkowników – zagospodarowujemy ruch, przekształcając użytkowników w klientów

Inną metodą osiągnięcia celu, czyli przychodu min. 200 tys. zł. w okresie 12 miesięcy jest utrzymanie liczby efektywnie odwiedzających serwis na stałym miesięcznym poziomie 10000 tys. osób przy zwiększeniu wskaźnika konwersji do 2,28%. Wszystkie wcześniej podane wskaźniki aktualnej sytuacji serwisu nie ulegają zmianie oprócz wskaźnika konwersji, który wynosi w tym przykładzie 2,28%.

Rzecz jasna w rzeczywistości zarówno liczba efektywnie odwiedzających jak i wskaźnik konwersji zmieniają się w czasie rosnąc i malejąc, jednakże ważny jest wzrostowy trend zarówno w zakresie efektywnego ruchu jak i wskaźnika konwersji.