Feng GUI: symulacja eyetrackingu?

Oceń tę pracę

Co pewien czas na rynku pojawia się nowe narzędzie wspomagające prace projektantów i badaczy zarówno z zakresu usability, jak User Centered Design. Praca z jednymi staje się standardem (vide Axure), inne odchodzą do lamusa (tak się trochę stało w przypadku programu IBM do cardsortingu – EZSort, które obecnie zastąpiły dużo sprawniejsze aplikacje).

Wciąż niektóre badania i sprzęt potrafią być bardzo drogie. Jednym z droższych (o ile nie najdroższym) urządzeniem wykorzystywanym w badaniach User Experience jest eyetracker (o samych badaniach ET pisaliśmy m.in. z Olą niedawno).

Niedawno ukazał się serwis online, w który umożliwia symulację procesów uwagi wzrokowej – Feng-GUI. Zasady funkcjonowania algorytmów Feng GUI zostały podane na stronie i przypominają z grubsza zasady pewnego modelu teoretycznego selektywnej uwagi typu bottom-up, autorstwa dwu wybitnych naukowców – Christofa Kocha oraz Shimona Ullmana. Pytanie, jak wiarygodne rezultaty daje program? By odpowiedzieć na to pytanie, w ramach prac działu MRM Experience wraz ze współpracownikami (Olą Słomińską i Anią Boguską-Torbicz), przeprowadziliśmy badanie kontrolne.

Szczegóły badania

W badaniu posłużono się eyetrackerem Tobii model T60 wraz z dedykowanym do niego oprogramowaniem Tobii Studio.

W badaniu uczestniczył operator i cztery osoby w roli respondentów. Wybrano 9 stron internetowych, które prezentowano każdej z osób w czasie 8 sekund dla jednej ekspozycji. Uzyskane wyniki podczas badania z użyciem eyetrackera porównano z wynikami uzyskanymi dla symulacji uwagi percepcyjnej, wg programu Feng GUI. Wyniki zaprezentowano poniżej.

***

Amazon.com

Król światowego e-commerce poszedł na pierwszy ogień. Widać, że w przypadku elementów o dużym kontraście, wyniki symulatora Feng GUI potrafią byś dość zbieżne z tymi, uzyskanymi podczas badania z żywymi użytkownikami – trafienia w produkty w części środkowej (robot Wall-E) oraz zdjęcie mężczyzny. Ale symulator nie pokazał bardzo istotnych elementów, wychwyconych już w badaniu z ludźmi: 1)nagłówke koło książki – produktu dnia – jest żywiej penetrowany faktycznie, niżby to wychodziło z symulacji (zresztą jest najgorętszym punktem); 2) w przypadku zdjęcia z mężczyzną, osoby patrzyły na jego twarz, a nie elementy graniczne zdjęcia, kontrastujące z białym tłem strony; 3) w końcu podczas żywej ekspozycji zarówno menu jak i logo, były penetrowane przez wzrok użytkowników – symulator tego nie pokazał.

CoJestGrane.pl

Serwis eventowy o negatywnym kontraście (ciemne tło, jasna czcionka). Na pierwszy rzut oka zadziwiająca dwa trafienia – pierwsze w lewej części górnego banera, drugie w prawej części strony, gdzie występuje pomarańczowy nagłówek. Trafienia staną się mniej zadziwiające, gdy spojrzeć na stronę – górna lewa część banera no mocno kontrastujący jasnozielony prostokąt, świetnie wyróżniający się zarówno na czarnym tle, jak i na ciemnym granatowym tle banera; żółcienie mają lepszy kontrast na czarnym tle, niż biel, stąd pomarańczowy nagłówek (a więc i większy rozmiar fontu) jest bardziej kontrastowy, niż blok białych napisów z nazwami miast.

Rozkład fiksacji na zdjęcia jest inny w przypadku symulacji oraz faktycznej percepcji strony przez ludzi. Żywe osoby spostrzegają także część identyfikacyjną z adresem strony.

Fotka.pl

Grupa Fotka, to blisko 30% zasięg w Polsce i stałe miejsce w czołówce Megapanelu. Fotki widoczne – ale jakby na obu zrzutach nie te same i nie z tą samą uwagą. I znowu: w przypadku żywych osób penetrowane są regiony menu i identyfikacji strony – logo.

GoldenLine.pl

Jeden z czołowych serwisów społecznościowych w naszym kraju. Żywi użytkownicy dużo większą rolą przykuwali do części wyjaśniającej czym jest GoldenLine i do czego służy, niżby to wynikało z przeprowadzonej symulacji programu Feng GUI. Menu i elementy logowania także są dużo ważniejsze. I percepcja zdjęć potrafi się nie pokrywać.

MRM.pl

Strona agencji, w której przeprowadzono badania. Tu – w przypadku osób uczestniczących w badaniu – istotne stało się menu strony – czego symulacja w ogóle nie pokazała. Porównanie najbardziej gorących miejsc z badania i symulacji, pokazuje spore różnice.

Onet.pl

Trudno w Polsce robić badanie nie odnosząc się do Onetu 🙂 Z powyższych heatmap można wyciągnąć jednoznaczne wnioski – człowiek wie co dobre. Duże zdjęcie z artykułu dnia oraz część z wiadomościami bieżącymi, to czołowe miejsca na stronie wg prawdziwych oglądających stronę użytkowników. W przypadku symulacji, cała niemalże uwaga została przypisana banerowi.

Travian.pl

Chyba najbardziej popularna przeglądarkowa gra w naszym kraju, a wg Megapanelu na pewno najbardziej. Dla osób oglądających stronę z mapą gry, po zalogowaniu, dużo ważniejsze jest centrum mapy, niźli jej obrzeża, na co wskazuje symulacja. Nie wspominając o opcjach menu, które penetrowane przez użytkowników, w ogóle nie znajdują odzwierciedlenia w komputerowej symulacji Feng GUI.

Wyborcza.pl

Niedawny redesign strony i już przeprowadzone badanie… No, no 🙂

Prócz tego, że na obydwu heatmapach stwierdzono zwiększoną uwagę na zdjęciu głównym (chociaż w innych regionach!) oraz banerze reklamowym w prawej części strony, to pozostałe elementy w ogóle się nie zgadzają.

YouTube.com

YouTube wg statystyk ruchu w sieci, to obecnie 80% ruchu w Internecie. Ale mapy uwagi są tak rozbieżne w stosunku do siebie, że nawet nie ma potrzeby komentowania tego – wystarczy rzucić okiem.

Wnioski

Twierdzenie, że aplikacja w serwisie Feng GUI jest symulatorem uwagi percepcji wzrokowej, jest grubym nadużyciem. Wyniki otrzymane podczas badania są tak rozbieżne w stosunku do tych otrzymanych z użycia Feng GUI, że ich interpretacja nie jest w stanie dać projektantom wiedzy na temat faktycznego zachowania żywych użytkowników na stronie WWW. W przypadku prezentowania i badania zdjęć, dane wyszły tak samo rozbieżne.

Choć osobiście mocno wierzę w stochastyczne podłoże naszych procesów percepcyjnych, to zastosowane w symulatorze algorytmy, nie pozwalają uzyskać żadnej miarodajnej wiedzy i pozostawiają program Feng GUI tylko w sferze ciekawostki.

Feng GUI to narzędzie służące do analizy interfejsów użytkownika (UI) w kontekście symulacji procesu śledzenia ruchu oczu, znanego jako eyetracking. Używane głównie w badaniach nad użytecznością i projektowaniu interfejsów, Feng GUI pozwala na ocenę, jak użytkownicy będą postrzegać i wchodzić w interakcję z różnymi elementami interfejsu na ekranie, opierając się na założeniach dotyczących śledzenia wzroku.

Symulacja eyetrackingu w Feng GUI jest procesem modelowania, w jaki sposób użytkownicy będą patrzeć na różne obszary ekranu w zależności od ich układu oraz typowych wzorców ruchu oczu podczas interakcji z aplikacją. Narzędzie wykorzystuje algorytmy do przewidywania, które elementy UI będą najczęściej przyciągały uwagę użytkowników, bazując na rozmieszczeniu elementów, ich rozmiarze, kolorze i innych cechach wizualnych. Dzięki tej funkcji projektanci mogą testować swoje interfejsy bez potrzeby przeprowadzania kosztownych i czasochłonnych badań z wykorzystaniem rzeczywistego sprzętu do eyetrackingu.

Feng GUI oferuje także możliwość generowania map cieplnych (heatmaps), które wizualizują miejsca na ekranie, które najbardziej przyciągają wzrok użytkowników. Takie mapy mogą być wykorzystywane do optymalizacji interfejsów, np. poprzez poprawienie rozmieszczenia przycisków, zwiększenie kontrastu lub dostosowanie elementów do bardziej naturalnych ścieżek patrzenia użytkowników. Dzięki temu projektanci mogą lepiej zrozumieć, które elementy interfejsu są zauważane najpierw, a które mogą zostać przeoczone.

Symulacja eyetrackingu w Feng GUI ma również duże znaczenie w testowaniu efektywności interfejsu w kontekście jego ergonomii i użyteczności. Pozwala to na dostosowanie elementów do rzeczywistych oczekiwań użytkowników, eliminując potencjalne problemy związane z niską intuicyjnością czy układem interfejsu. Narzędzie to, mimo że symuluje proces śledzenia ruchu oczu, nie jest w stanie zastąpić prawdziwego eyetrackingu w przypadku bardziej szczegółowych badań. Jest to jednak wygodna opcja dla projektantów, którzy chcą szybko iterować swoje projekty i uzyskać ogólne wskazówki dotyczące percepcji wizualnej użytkowników.

Feng GUI stanowi skuteczne narzędzie do wstępnej analizy efektywności interfejsu użytkownika w kontekście śledzenia ruchu oczu. Dzięki temu projektanci mogą optymalizować rozmieszczenie elementów, testować różne warianty układów i szybciej poprawiać design, zanim przejdą do bardziej zaawansowanych, kosztownych testów z wykorzystaniem prawdziwego sprzętu do eyetrackingu.

image_pdf

Search: elementy wyszukiwarki

5/5 - (1 vote)

Do tego wpisu skłoniło mnie kilka wydarzeń:

  • Jak wiadomo, jednym z podstawowych scenariuszy w ramach eksploracji Internetu są wyszukiwarki. Są tak ważne, że obecnie wymieniane są zaraz przy poczcie e-mail, jeśli chodzi o użycie podstawowych narzędzi internetowych przez osoby korzystające z sieci.
  • O wyszukiwarkach w ostatnim czasie było głośno z jednej strony z powodu kupna przez Microsoft Powerset, a to ze względu na fakt nagłośnienia, że twórcy Cuil, to tak naprawdę byli pracownicy Google, którzy teraz będą chcieli zdetronizować swojego byłego pracodawcę.
  • Od m-ca jednym z casów, nad którymi pracuję, jest wyszukiwarka. I to wyszukiwarka nie byle jaka, bo znajdująca się w pierwszej 10-tce 20-tce w Megapanelu.
  • No i w końcu projekt wyszukiwarki muzyki… Ale o tym innym razem.

***

Wyszukiwarka, w wersji podstawowej, składa się przeważnie z dwu pól: pola wpisu (text field) oraz przycisku (button) z odpowiednim napisem (szukaj, search, go!, find) bądź ikonką lupy. Reszta to tak naprawdę wariacje na ten temat, z dodatkowymi elementami – drugim przyciskiem (jak w google), elementami wyboru (radiobutton), pole wyboru (dropdown), itd. Coraz częściej jednak projektanci w nowych projektach starają się jeszcze uprościć wyszukiwarkę tak, by sprowadzić dwa elementy do jednego – pola wyszukiwania, z obsługą akcji przez odwołanie do przycisku Enter na klawiaturze, a nie osobnego klikalnego przycisku. Jest to widoczne chociażby na nowej odsłonie Last.fm. Pytanie, czy jest to zabieg uzasadniony? Tym bardziej, gdy weźmie się pod uwagę przegląd form wyszukiwania z Funkcjonalność stron WWW. 50 witryn bez sekretów, Jakoba Nielsena i Marie Tahir (oryginał z 2002) oraz wytyczne raportu E-commerce User Experience: Design Guidelines for Search (też sprzed kilku lat), gdzie wszystkie (!) formy wyszukiwarki użyte na analizowanych stronach WWW posiadają przycisk zatwierdzania.

Dane, które przeanalizowałem w ramach badań z użyciem systemu do clicktrackingu (razem kilkaset tysięcy kliknięć!) pokazują, że coraz częściej stosowanym schematem użycia wyszukiwarek jest właśnie zachowanie użytkowników odwołujące się do potwierdzenia wyszukiwania przez akceptację przyciskem „Enter” z klawiatury; rzadziej przez kliknięcie przycisku „Szukaj”.

Analiza danych z kilkudziesięciu serwisów pokazuje, że odsetek odwołań do przycisku, w ramach wyszukiwania, wynosi ok. 9% wszystkich oddanych zapytań.

Analiza jakościowa wyszukiwarek pokazuje, że częściej użytkownicy odwołują się do przycisku wtedy, gdy jest on mocno wyeksponowany, bądź wyszukiwarka składa się z wielu pól. Proste wyszukiwarki dużo rzadziej obsługiwane są przyciskiem. W związku z tym, sam proces użycia wyszukiwarki związany jest z formą jej prezentacji oraz tego, na ile jest złożona.

A poniżej interesujące wyniki, które przesłał mi znajomy, z badania wyszukiwarki Google (Słowenia).

image_pdf

Pattern recognition: wzorce WWW

Oceń tę pracę

Architektura informacji jest wtedy czytelna, kiedy posiada duży stopień swojskości odczuwany przez użytkownika, tj. użytkownik nie ma problemu z jej czytelnością i przez to eksploracją; rozmieszczenie najważniejszych opcji funkcjonalnych tam, gdzie spodziewają się je zastać użytkownicy, znacznie przyczynia się do ich używalności. Dlatego tak istotne jest poznanie bagażu doświadczenia użytkowników z grupy docelowej, dla których projektujemy aplikację bądź usługę, czy stronę WWW.

Coś, co w psychologii określane jest jako tzw. background knowledge, kształtuje w dużym stopniu nasze zachowanie. Funkcjonując na co dzień, bazujemy na automatyzmach poznawczych, ukształtowanych z jednej strony przez bagaż ewolucyjnego przystosowania, z drugiej strony – przez środowisko. Dlatego w ramach projektowania stron WWW ważne jest poznanie środowiska naturalnego dla użytkowników, a w nim zidentyfikowanie elementów kluczowych – wzorców – które wykształtowały takie, a nie inne typy zachowania.

Prosty przykład: spora część użytkowników polskich stron internetowych, chcąc zalogować się do swojego konta, bądź utworzyć nowe konto w serwisie, w ramach automatyzmu podąża wzrokiem (a często i – mimowolnie – kursorem myszy) w prawy górny róg strony WWW. Umiejscowienie opcji logowania i rejestracji konta w innych miejscach, niż prawy górny róg, jest średnim pomysłem i wpływa na obniżenie stopnia dopasowania strony do modelu mentalnego użytkownika, który został wdrożony w ramach interakcji z innymi stronami WWW (ze środowiskiem). Podobnie możemy mówić o wzorcowej przestrzeni na logo, wyszukiwarkę, system wyszukiwania i rezerwacji wycieczek na stronach e-travel (jak na projektowanej przeze mnie BliżejSłońca.pl), etc.

Bardziej ogólne wzorce można wychwycić poddając analizie strony z danego sektora, np. e-commerce (Michael L. Bernard, Criteria for optimal web design).

W przypadku pracy projektanta, trzeba także uważać z generalizowaniem wniosków powstałych w wyniku badania naturalnego środowiska i zważać na regionalne wpływy. Do klasycznych regionalizmów należą chociażby – w przypadku Internetu – rozmieszczenie na anglojęzycznych stronach bankowych logowania do systemu w lewej kolumnie (a nie w prawej); w przypadku desktopu – rozmieszczenie opcji zamykania okienek w systemie Mac OS, w lewej górnej części, a nie prawej, jak to ma miejsce w innych systemach (ten regionalizm to tak na prawdę rodzaj atawizmu interfejsowego – pierwsze GUI było obsługiwane częściej z klawiatury, niż myszą, w związku z czym elementy Anuluj i Zatwierdź zostały przypisane odpowiednio klawiszom Esc i Enter; szkoda, że już rodzime strony przeznaczone dla użytkowników jabłuszek nie grzeszą konsekwencją – zarówno formularze na Macplug, jak i opcje dostosowania boksów na stronie głównej MyApple, to przykłady typowo windowsowego podejścia).

Rzadko kiedy zdarza się diametralnie przełamanie panujących wzorców, ale jednak czasem się zdarza, a skutki tego mogą być różne.

Niedawno, wertując The Art & Science of Web Design Jeffreya Veena, natrafiłem na schemat wzorca klasycznej strony WWW (rysunek 1). Książka wydana w 2001 roku miała istotny wpływ na innych projektantów, a rysunek ten doczekał się wielu omówień i przedruków (w tym w wydanej u nas: June Cohen, Serwisy WWW. Projektowanie, tworzenie i zarządzanie).

Falę dyskusji wywołałem w swoim czasie wpisem nt. prawostronnego menu i jego ewentualnych zalet. Koncepcję swoją – pokrótce – miałem także stosowność omówić na zeszłorocznym World Usability Day (nawet powstał komiks nawiązujący do tego wydarzenia). Tymczasem, przyglądając się stronom z nurtu Web 2.0 – blogom, które zastąpiły web-jedno-zerowe home-page – czy też serwisom twitteropodobnym, trudno oprzeć się wrażeniu, iż nurt ten w dużym stopniu propaguje model odwrotny do klasycznego (rysunek 2).

Co z tego wynika dla projektowania?

  1. Badaj zachowanie użytkowników, by zidentyfikować wzorce ich zachowań.
  2. Analizuj statystyki, zwłaszcza pod kątem tego, w jakich innych niż Twój serwisach internetowych przebywają osoby z grupy docelowej. Gdy wyodrębnisz odpowiednią grupę stron WWW, poddaj analizie ich układ tak, by móc określić wzorce, które sprzyjają takiemu, a nie innemu zachowaniu użytkowników.
  3. Strona, którą projektujesz, zyska na czytelności, gdy będzie zbliżona w ramach układu do stron, które już znają Twoi użytkownicy. Jeśli tak dużą osiągasz wartość, to nie bój się kopiowania – uskuteczniają to zarówno mniejsi gracze (GL vs Oferia), jak Ci więksi (poprzednia wersja Polska Times vs aktualna Wyborcza), czy w swoim czasie Yahoo! vs WP.
  4. Pójście pod prąd, wywołuje przeważnie natychmiastową reakcję. Mogą to być odczucia użytkowników związane z doznaniem nowości (viva Web 2.0), jak i rozdrażnienia („do cholery, gdzie to logowanie?”).
  5. Siła wzorców zauważalna jest zwłaszcza w obliczu prac natury redesignu (odczuwam to teraz, gdy siedzę nad redesignem serwisu z kilkumilionową oglądalnością [która przekłada się na używalność] na m-c). Użytkownicy na pewno się przyzwyczaili do takiego, a nie innego układu treści i jeśli zabierzesz im stały i znany im element, z pewnością wzbudzi to niepokój (jak wtedy, gdy pracując dla GoldenLine udało mi się namówić Mariusza do likwidacji zakładki Fora, dublującą w tamtym czasie w dużej mierze funkcjonalność Grup, a dzięki czemu zrobiło się miejsce na Spotkania). Najlepiej wtedy 1) zlokalizować elementy istotne dla użytkowników, przyczyniające się do wytworzenia w nich takiego, a nie innego modelu mentalnego strony (np. w ramach clicktrackingu, o którym mówiłem ostatnio to tu, to ówdzie), 2) rozważyć ZA i PRZECIW decyzjom natury strategicznej – mimo wszystko czasem trzeba coś usunąć i basta!
  6. Wzorce, przez to, że pozwalają zautomatyzować w sporej mierze prace użytkowników, są również bardzo silną podstawą dla systemu oceny produktu. Gdy coś projektujesz i adaptujesz wzorce, nie mów co to ma być, tylko raczej skup się na tym, co przypomina to użytkownikom. Przykład: jeden z serwisów, które aktualnie mam na tapecie, w ramach podstawowego układu oparty jest o główną architekturę Twittera – ale nie służy do tego, co Twitter. Odczucia i system oceny, który wyzwala u testowanych użytkowników, jest zbieżny z generalną strategią serwisu, która ma wiele wspólnego z systemami do mikroblogingu. Dzięki temu, podczas użytkowania systemu, odpowiednio szybko u użytkowników powinny pojawić się odczucie znajomości systemu i przez to braku skomplikowania. Dodatkowo, naturalnym jest, że pewne odczucia towarzyszące w ramach użytkowania systemów do mikroblogingu, powinny zostać przeniesione na nowy serwis.
image_pdf

Śniadanie usability: Kreoaula

5/5 - (1 vote)

Wbrew tytułowi to dwa różne spotkania, ale mające tę wspólną cechę, że bedę miał okazję opowiedzieć na nich co nieco o tym, co robimy w MRM Experience + jak to robimy.

1. Na Śniadaniu będę miał krótką prezentację pod roboczym tytułem: „Kryminalni: tropem użyteczności„, w ramach której, prócz wprowadzenia w wątek kryminalny, będę chciał się skupić na procesie zbierania śladów z miejsca zdarzenia. 🙂

2. A Kreoaula będzie wyglądała anstępująco (z notki organizatorów):

KreoAula – czyli jak zrobić internaucie dobrze?

2 czerwca o godzinie 17.25 w Budynku Agory, przy ulicy Czerskiej 8/10 w Warszawie, rozpocznie się KreoAula. Jest to pilotażowe spotkanie cyklu wydarzeń skierowanego do osób odpowiedzialnych za wygodę i zadowolenie użytkowników internetu oraz technologii mobilnych.

Nazwa KreoAula nawiązuje do kreatywności – narzędzia, dzięki któremu dyrektorzy artystyczni, projektanci stron www, designerzy, projektanci interakcji, flash-developerzy itp. starają się poprawić zaangażowanie użytkowników w dany produkt lub usługę. Człon Aula pochodzi od nazwy nadrzędnego projektu – AulaPolska (www.aulapolska.pl) łączącego inicjatywy wspierające przedsiębiorczość technologiczną.

Gdzie: Budynek Agory, ul. Czerska 8/10

Kiedy: 12 czerwca, godz. 17.25

Temat: Użyteczność w internecie, projektowanie aplikacji, Flex/AIR, user experience

Informacje: aulapolska.pl

Wstęp: za darmo (konieczne zapisy)

Program aktualnej edycji:

  • Marek Kasperski (MRM Worldwide): Badania usability – co, czym i jak badać? Co mi to da i czy badania są drogie? Metodologie badań, narzędzia i wyciąganie wniosków.
  • Dariusz Zieliński (Aula Team): Skinowanie interfejsów aplikacji webowych, desktopowych i mobilnych od strony funkcjonalnej i technologicznej (SVG, Flex/AIR/Flash Lite) – case studies i trochę teorii.
  • Jarek Szczepański (Peer2Peer Systems): Enhancing user experience w webie i na desktopie z Flexem i AIR – o prostocie budowania efektownych interfejsów, łamaniu paradygmatu prostokątnego okna z X-em, integracji z rozwiazaniami webowymi i przewadze front-endu stworzonego we Flex/AIR nad Javą.
  • Panel dyskusyjny: Usability / User Experience w Polsce i na świecie – jak nasze uselaby wypadają na tle zachodnich firm i „jak to się robi za granicą”.

Moderator: Dariusz Zieliński (Aula Team)

Paneliści: Tomek Karwatka (Divante.pl), Zbyszek Braniecki (Mozilla), Maciek Lipiec (Komitywa.com)

  • Bitwa Ilustratorów: Graficy realizują zadany temat – rozstrzyga publiczność.

Zakończenie KreoAuli: godz. 20.00 żeby każdy zdążył na mecz Polska-Austria!

Partnerami KreoAuli są: Adobe, Peer2Peer Systems, Wacom, Gazeta.pl, Mediarun, max3d.pl oraz blog.mediafun.pl.

image_pdf

User-Centered Design: Wielogłos

Oceń tę pracę

To drugi wpis z serii Wielogłos (poprzedni dotyczył ścieżki rozwoju osobistego w działce Usability). Tym razem tematem przewodnim jest Projektowanie Zorientowane na Użytkownika.

Zagadnienie ogólne, co – jak mam nadzieję – pozwala na spojrzenie wielowymiarowe do zagadnienia i odkrywa indywidualny sposób podejścia Autorów.

Wśród zaproszonych znaleźli się: Robert Drózd (WebAudit), Joanna Kotala (Ideacto), Krzysztof Piwowar (ADV, blog Usability On Air) i na końcu moja wypowiedź – a ja nazywam się Marek Kasperski 🙂 (ThinkLab).

Robert Drózd (Webaudit)

Projektować będziemy tak czy inaczej. Jak zorientować to projektowanie na użytkownika? Użytkownik musi być na początku, w środku i na końcu tego projektowania. Tylko wtedy mamy pewność, że projekt nie wymknie się nam spod kontroli.

Na początku – na użytkownika musimy przemapować wszystkie cele, jakie stawiane są przed projektowanym produktem. Z różnych technik, które pozwalają nam dowiedzieć się czegoś o naszych użytkownikach (i znaleźć ich cele) najbardziej lubię jakościowe: indywidualne wywiady bezpośrednie i obserwacje. Typowe techniki badań marketingowych, jak fokusy, ankiety, CATI będą już mniej przydatne, bo po prostu możemy nie trafić z pytaniami – i dowiemy się zupełnych banałów. Następnie wyniki musimy sobie przerobić na narzędzia z których da się skorzystać – przede wszystkim profile użytkowników i przypadki użycia. Jedna rzecz, o której nie wolno zapomnieć – to są narzędzia dla nas, a nie dla klienta czy programistów. Jeśli nie potrafimy z nich skorzystać podczas projektowania, straciliśmy czas.

W środku procesu projektowania musimy wciąż czuć oddech użytkownika na plecach. Niedosłownie – przez ciągłe odwoływanie się do przygotowanych wcześniej person i scenariuszy. I dosłownie, przez konfrontowanie z użytkownikami kolejnych iteracji projektu, na przykład makiet i prototypów.

Pamiętać trzeba jednak o tym, że wiedza o użytkownikach ma nam pomagać, ale nie może determinować naszych decyzji. W wielu przypadkach nie jesteśmy w stanie przewidzieć, czy użytkownik na pewno nie zachowa się tak jak zapowiadał, czy jak to wynikało z poprzednich badań. Czasami innowacyjność wymaga pewnego zignorowania przyzwyczajeń użytkownika, a nowy produkt na początku wywoła szok i zagubienie. Byleby tylko na początku! Tylu ludzi narzekało na wstążki w Office 2007 i nie umiało wykonać w nowym Wordzie podstawowych operacji. Przyzwyczaili się i polubili wstążkę, a jej metaforę przejęły po Microsofcie inne firmy.

Na końcu projektowania są testy użyteczności. I jeśli ich nie udało się przeprowadzić w czasie trwania projektu, teraz są już niezbędne. Jeśli bieżącego projektu już nie zdążymy poprawić, to będziemy mieli podstawy do jego następnej wersji. Jeśli nie przypomnieliśmy sobie o użyteczności dopiero teraz, nie będzie raczej wielkich problemów. W innym przypadku nową wersję będziemy czasami musieli wykonać bardzo szybko. Tak stało się w przypadku systemu blogowego WordPress, gdzie nieudana wersja 2.5 została zastąpiona wersją 2.7 w ciągu pół roku.

Testy to jednak nie wszystko – powinniśmy określić metryki, które – w oparciu o zachowanie czy satysfakcję użytkownika – pozwolą nam ocenić skuteczność naszego projektu i wprowadzanych w nim zmian. Na przykład dla serwisów internetowych podstawą jest wykonywanie pożądanych akcji, lojalność i częstość odwiedzin dla osób powracających. Statystyki w serwisie zorientowanym na użytkownika mówią bardzo wiele o jego „pulsie” i pomagają wychwycić problemy, zanim jeszcze doniosą nam o nim sami użytkownicy, lub dowiemy się w teście.

Joanna Kotala (Ideacto)

Na projektowanie produktu patrzę zawsze z perspektywy wszystkich ludzi zaangażowanych w jego tworzenie – od sponsorów, analityków, projektantów, grafików, programistów aż do testerów. Produkt końcowy, z którego korzystają użytkownicy, jest rezultatem pracy całej grupy, a nie jedynie twórcy interfejsów, zwolennika Projektowania Zorientowanego na Użytkownika. Nawet przy starannie przygotowanym projekcie wpada on w ręce ludzi często mniej entuzjastycznie podchodzących do zagadnień użyteczności. Jak sobie z tym poradzić? Dobrą radą na początek jest staranne zaplanowanie zadań związanych ze zdobywaniem i analizą wiedzy o użytkownikach, projektowaniem, prototypowaniem itp. od strony zarządzania całym projektem. Inną zasadą, zaczerpniętą z Projektowania Kontekstowego – dla mnie jest to właśnie UCD w praktyce – jest angażowanie pozostałych członków zespołu w proces projektowania. W ten sposób pokazujemy im, że produkt będą używali konkretni ludzie, którzy mogą mieć zupełnie inne potrzeby niż my sami. Co więcej obecność dodatkowej osoby w procesie projektowania interfejsu daje nam nowe spojrzenie na to co robimy.

Pamiętam jak pierwszy raz w Ideacto zrobiliśmy wspólną sesję interpretacyjną danych o użytkownikach. Początek był trudny, ale rezultaty inspirujące. Nagle ci, którzy tylko słyszeli o UCD, zaczęli patrzeć na cały projekt przez pryzmat porozkładanych na stole karteczek z notatkami o użytkownikach. Co więcej, zaczęli kreować pomysły na rozwiązania interfejsowe, które jak się później okazało, odpowiadały potrzebom użytkowników. A przecież o to właśnie chodzi…

Krzysztof Piwowar (ADV, Usability On Air)

Pełen teoretyczny model UCD w praktycznym zastosowaniu występuje równie rzadko, jak Yeti. Bardzo wielu o nim słyszało, kilku miało szczęście widzieć go na własne oczy, pojedynczym udało się zrobić zdjęcie. I to nie dlatego, że model UCD to wymysł teoretyków. Po prostu jego realizacja wymaga bardzo specyficznych warunków, które niestety przyrodzie nie występują zbyt często. Oczywiście, wcale nie oznacza to, że należy się zrażać na starcie i prawdą jest, że należy walczyć o każdy jeden klocek z modelu – jeśli jego wykorzystanie ma służyć dołożeniu kolejnego właściwego puzzla do układanki projektowej.

Dzięki metodologii UCD w rękach zespołu projektowego mamy do wykorzystania m.in. takie narzędzia jak: grupy fokusowe, wywiady, ankiety, sortowanie kart i testy z użytkownikami, ale o tym czytelnicy tego bloga zapewne bardzo dobrze już wiedzą (jeśli nie, warto przywołać pamiętny plakat autorstwa Tomka Karwatki). Istotne w tych narzędziach jest to, że każde angażuje użytkownika końcowego i to dzięki niemu zespół uzyskuje dane do podejmowania decyzji – a im więcej jakościowej wiedzy, tym lepsze rozwiązania można zaproponować.

W praktyce jednak każdemu zespołowi przychodzi skonfrontować świadomość i potrzebę wykorzystania tychże narzędzi z rzeczywistością, gdzie dochodzą do głosu takie obszary jak: rentowność i budżet projektu, cele biznesowe klienta oraz deadline. To głównie one okrajają teoretyczny UCD, jaki znamy. I to właśnie z ich powodu można w takiej sytuacji poczuć się odrobinę schizofrenicznie.

Ale i na to jest sposób – praktyczny oczywiście :). Model teoretyczny UCD nie mówi nic o celowości wykorzystania wyżej wymienionych narzędzi. Mówiąc prostym językiem – praktyce nie wszystko zawsze musimy stosować. Model praktyczny (życiowy) dopuszcza ustalenie wartości narzędzi i umożliwia wybór tych, z których uzyskamy najbardziej wartościowy feedback oraz wiedzę – z punktu widzenia projektu i jego realiów. Po drugie – praktyczne podejście wymaga popatrzenia na projekt nie tylko z punktu widzenia użytkownika (user-centered) ale i z poziomu biznesowego klienta. I to właśnie w tym tkwi magia praktycznego wykorzystania projektowania zorientowanego na użytkownika. Aby uzyskać konsensus pomiędzy celami i potrzebami użytkowników a celami i potrzebami biznesowymi klienta. W inną stronę się nie da.

UCD w praktyce z mojego punktu widzenia to właśnie szukanie i znajdowanie takiego złotego środka. Jest on ciężki do osiągnięcia, ale gdy się go raz skosztuje, chce się go znowu spróbować – nie teoretycznie, ale właśnie praktycznie. Dlatego też pozwolę sobie na następujące stwierdzenie: UCD praktyczne jest jak uzależnienie – z tą różnicą, że wychodzi na dobre i więcej niż jednej osobie.

Marek Kasperski (ThinkLab.pl)

W jednej z książek, które miałem okazję czytać – bodajże w „Projektowanie nawigacji strony WWW” Kolbacha – autor definiuje pojęcie Projektowania Zorientowanego na Projektanta (PZnP). To po Projektowaniu Zorientowanym na Klienta (PZnK, osoby z działu marketingu, sprzedaży, prezesa, …) bodajże najbardziej rozpowszechniona metoda pracy projektowo-badawczej w interesującym nas obszarze.

Na początku książki „Projektowanie stron WWW. Użyteczność w praktyce” opisuję elementy związane z projektowaniem w metodyce UCD (s. 12-16) – zarówno w ramach budowania interdyscyplinarnego zespołu projektowego, jak i elementów szerszego procesu jakim de facto jest Projektowanie Zorientowane na Użytkownika (PZnU). Nie będę chciał się tutaj specjalnie powtarzać, ale zwrócę uwagę na kilka istotnych z mojego punktu widzenia elementów.

1. PZnU nie stoi w żaden sposób w sprzeczności z interesami PZnK. Jeśli w wyniku analizy danych zebranych w ramach statystyk, wywiadów z użytkownikami, clicktrackingu, tak by wynikało, to mamy poważny problem. Tak jak nie należy ignorować głosu użytkowników, tak interes klienta powinien być dla Ciebie równie istotny. Staraj się nie dopuszczać do sytuacji, w której stajesz się advocatus diaboli użytkowników i zwracasz się przeciwko interesom klienta. Co będą warci użytkownicy, gdy biznes klienta będzie zagrożony?

2. Zbieraj dane od użytkowników. Ile się da. Wykonaj, jeśli możesz:

  • Badania satysfakcji klientów z aktualnie istniejących rozwiązań (bądź w ramach strony WWW klienta jeśli to redesign, bądź w ramach analizy konkurencji). Możesz to zrobić online na przykład w formie ankiet (w książce też pisałem o badaniu ankietowym, które przeprowadziłem w swoim czasie na GoldenLine), albo w ramach grup fokusowych.
  • Badania potrzeb grupy docelowej. Może się okazać, że aktualna strona WWW nie spełnia wszystkich potrzeb użytkowników; zresztą podobnie jak strony konkurencji (ostatnio często powtarzam, że rozwiązania webowe są daleko w tyle za tymi, który zostały wykształcone w świecie rzeczywistym i jeśli chcesz sprzedawać elementy wyposażenia łazienek, to wcale nie oznacza, że powinieneś użyć do tego klasycznego sklepu internetowego).
  • Badania zachowań użytkowników na stronie WWW. Niestety, jest to możliwe tylko w przypadku, gdy pracujesz nad rozbudową bądź modyfikacją istniejącego już serwisu. Ale przeglądnij dane ze statystyk (skonfrontuj je ze stroną, by zobaczyć na ile wiarygodne są te dane – zob. jeden z przypadków, które opisuję na blogu Ideas2Action), mapy cieplne z clicktrackingu (coraz powszechniej wykorzystywane i słusznie), testy z użytkownikami, z użyciem scenariuszy użycia plus – jeśli możesz – z eyetrackerem (teraz miałem taki przypadek, gdzie dane z eyetrackingu stanowiły świetne uzupełnienie danych z clicktrackingu, dzięki czemu uniknęliśmy z klientem pójścia na łatwiznę przy interpretacji danych).
  • Zbierz i zanalizuj dane krytyczne. Określenie ‘dane krytyczne’ ukułem na potrzeby rozmów z klientami. Są to elementy z obszarów Pomocy, FAQ, pytania zadawane w ramach korespondencji, kliknięcia w części Mapa serwisu czy logi zapytań do wyszukiwarki. To ważne, a pomijane bardzo często, tropy, które pokazują z czym użytkownicy mają kłopoty.

3. Zbieraj dane od klienta. To się rozumie samo przez się. Ważne, że nie wszystkie Twoje pomysły i pomysły użytkowników będą stały w zgodzie z interesami klienta. Nie warto tym sobie zaprzątać głowy – zawsze będzie mógł je wykorzystać w ramach kolejnych prac z innym klientem.

4. Myśl… krytycznie. No właśnie. Doświadczenie uczy, że prawda leży gdzieś po środku, a w ramach UCD niejednokrotnie jeszcze zostanie zmodyfikowana :). Na końcu jesteś Ty, jako projektant, bądź Twój zespól. Musicie podjąć decyzję co jest ważne, a co nie – zarówno dla klienta, jak i dla użytkowników. W ten sposób powracamy do PZnP – Projektowania Zorientowanego na Projektanta… chociaż już z inną specyfiką danych wejściowych :).

image_pdf