Długo już nie pisałem, ale chciałbym opisać swoje ostatnie doświadczenia w związku z projektowaniem interakcji – projektowaniem architektury informacji, tworzeniem interaktywnych prototypów i przypadków użycia. Wiele moich projektów serwisów w postaci interaktywnych prototypów tworzonych w programie Axure było wykonanych z różnych odcieniach szarości. Nie chciałem aby klient skupiał swoją uwagę na grafice, tylko na architekturze informacji i sposobie działania funkcjonalności.

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.

Tagi: architektura informacji, diagram przepływu, high fidelity, mapa serwisu, projektant, projektowanie interakcji, prototyp serwisu

Ten wpis opublikowano w dniu piątek, Luty 11th, 2011 o godzinie 21:47 w kategorii Projektowanie i prototypowanie, użyteczność WWW. Subskrybuj RSS 2.0 komentarze. Zostaw komentarz, albo trackback ze swojej strony.