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).

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.

Ś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.

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 :).

Webusability: Rozwój osobisty

Oceń tę pracę

Bywa, że jestem pytany o to, na co zwrócić uwagę w kształceniu kadry związanej z problematyką UCD (zarówno projektowaniem, jak i analizami z zakresu usability).

Gdy jeszcze pół roku temu prowadziłem dział User Experience w MRM Worldwide, zastanawiałem się dość często w jaki sposób stymulować moich pracowników i na co zwracać uwagę, przy rozwoju ich kompetencji. Najczęściej rzecz jasna do każdej z osób należy podejść indywidualnie tak, by wyciągnąć to, co ma najlepsze i popracować bardziej w tym obszarze, z którym ewidentnie pracownik sobie nie radzi.

Nie istnieje chyba nic takiego jak przepis na kształcenie zdolności projektowych; chociaż jest to wypadkowa wiedzy, doświadczenia i naturalnych skłonności (dla przykładu spotkałem się z osobami, które miały wybitnie rozwinięte myślenie analityczne, jednakże przeszkadzało im to wyraźnie w spostrzeganiu projektu jako całości).

Nie zamierzam się tutaj wymądrzać nt. tego, co w procesie edukacji (samoedukacji?!) jest ważne, a co nie – sam codziennie uczę się czegoś nowego – ale chciałbym zaspokoić potrzebę udzielenia odpowiedzi. Do tego zadania poprosiłem także moich kolegów po fachu – osoby, które cieszą się świetną (i zasłużoną) opinią (w kolejności alfabetycznej): Roberta Drózda, Tomka Karwatkę oraz Eryka Orłowskiego, by bazując na swoich doświadczeniach zechciały podzielić się obserwacjami. (Generalnie, jeśli idea się przyjmie, to będę chciał wprowadzić element wielogłosu na blogu, częściej prosząc innych specjalistów o podzielenie się wiedzą).

Ja pozwolę sobie na krótkie podsumowanie na końcu (poza porządkiem alfabetycznym :).

Robert Drózd (Webaudit)

Jak zostać dobrym fachowcem od usability?

Musisz umieć dwie rzeczy. Po pierwsze, spojrzeć na stronę czy aplikację oczami użytkownika. Po drugie, spojrzeć na użytkownika oczami systemu, którego częścią jest ta strona.

Wcielenie się w rolę użytkownika jest najtrudniejszym – psychologicznie – elementem całej pracy. Bo ta perspektywa wcale nie jest oczywista i co chwilę będziemy od niej odciągani – czy to przez innych ludzi, czy przez nasze przyzwyczajenia. Przy systemie jako całości oraz każdym najmniejszym elemencie, trzeba zawsze odwoływać się do doświadczeń pojedynczej osoby, która na ten element trafi w interakcji.

Spojrzenie „oczami systemu” wymaga z kolei znajomości tego systemu – czyli najczęściej po prostu biznesu, który prowadzą nasi klienci. Nie zapłacą nam za akademickie dywagacje. To co przygotujemy ma działać w ich otoczeniu, dla ich klientów, budżetu czy innych zasobów.

Od czego zacząć?

  1. Naucz się najważniejszych zasad, jakie rządzą interakcją człowieka z komputerem. Znajdziesz je w najpopularniejszych książkach na ten temat (Krug, Nielsen itd.). Nigdy nie traktuj ich jak dogmatów, ale za każdym razem próbuj zrozumieć dlaczego są takie, a nie inne.
  2. Pamiętaj o „trzech filarach użyteczności”: marketingu, psychologii oraz informatyce. Pisałem o nich rok temu na swoim blogu. Użyteczność jest właściwie nauką interdyscyplinarną. Jeśli kuleje jeden z tych obszarów, możesz na przykład proponować świetne rozwiązania, które nie będą nadawały się do wdrożenia.
  3. Naucz się metod oceny i projektowania, ale zawsze pamiętaj, że sama metoda nie da nam gotowych wniosków. Wnioski zawsze zależą od nas.
  4. Miej jak najwięcej styczności z użytkownikami. Rozmawiaj, obserwuj, testuj, pytaj. Nigdy nie zakładaj, że nauczyłeś się już wszystkiego.

Co jeszcze? Ani projektowanie, ani ocenianie użyteczności nie dadzą się zamienić na suche procedury. To co na pierwszy rzut oka wygląda banalnie, w rzeczywistości jest i sztuką i nauką. Trzeba poszukiwać w sobie pasji, która będzie potrafiła połączyć wiedzę oraz intuicję.

Tomek Karwatka (Divante)

Pracowałem z wieloma ludźmi od usability i generalnie dzielę ich na dwa typy osobowości / umiejętności.

Analitycy – osoby specjalizujące się w rozbijaniu rzeczy na atomy i znajdowaniu niuansów, osoby te potrafią najbardziej przerażający projekt rozłożyć na atomy z pomocą łyżeczki i kilku miesięcy. Projektanci – z trochę wizjonerskim podejściem i parciem na kreatywne wymyślanie nowego, niekiedy mają problemy z zamykaniem spraw. Sam należę chyba do tej drugiej grupy. Nie sprawia mi przyjemności zagłębianie się w detale i zawsze jest w moim zespole ktoś kto jest w tym dużo lepszy ode mnie. Obecnie w zasadzie w moim zespole jest ktoś lepszy ode mnie w każdej dziedzinie na jakiej się znam – polecam, to doskonałe uczucie pracować z ludźmi, od których możesz się tyle nauczyć!

Wracając do usability – wydaje mi się, że w pierwszej fali zainteresowania tematem (powiedzmy w okolicach 2004) osób z duszą audytora było zdecydowanie więcej i większa część rynku właśnie tak pojmowała usability. Sami robiliśmy wtedy dużo audytów – miały swoją wartość, ale z perspektywy czasu widzę, że mogliśmy pracować efektywniej. Wszyscy się uczyli tematu.

Dziś coraz częściej mówi się o projektantach interakcji i podkreśla się połączenie tej dziedziny z marketingiem, tworzeniem produktu jako takiego. To dobrze, bo dobry zespół musi mieć szerokie kompetencje, a weryfikacja jego pracy dokonuje się na rynku, a nie w laboratorium.

Co bym poradził osobom, które chcą wejść do branży? Zacząć coś robić. I mam tutaj na myśli nie tyle czytanie książek i blogów, co po prostu projektowanie produktów. Zamiast wytykać błędy Merlinowi czy Allegro, lepiej zaprojektować coś samemu i zrozumieć, jak radzić sobie w świecie pełnym ograniczeń (jak poprawić usability darmowego OS Commerce, jak dogadać się z grafikiem, co zrobić aby odwiedzający serwis wrzucili coś do koszyka).

Ja zaczynałem po prostu od robienia serwisów – zacząłem na poważnie w 1999. Robiliśmy między innymi niekomercyjny magazyn internetowy, który nazywał się NoName. Wszyscy dużo się uczyliśmy i nikt nie myślał wtedy o „monetyzacji ruchu”. Później zacząłem pracę w firmie informatycznej, potem w agencji reklamowej (projektowałem między innymi stoiska targowe i nawet wygrywaliśmy konkursy :)). Zajmowałem się też tworzeniem programów edukacyjnych i gier. Później przyszedł czas na agencję interaktywną. W międzyczasie zostałem współudziałowcem sklepu internetowego. Dziś pracuję w Ideacto jako konsultant pomagający firmom budować biznes w Sieci oraz prowadzę własną firmę IT. Angażuję się też w projekt Biznes20.pl, który ma służyć wymianie wiedzy (już niedługo także pomiędzy branżami). Jak widzisz, przede wszystkim staram się zbierać doświadczenia, bo to jest szalenie pomocne w pracy projektanta.

Przedłożyłbym doświadczenie i zaangażowanie nad każde formalne wykształcenie. Sam pracuję z bardzo wszechstronnymi ludźmi o bogatych doświadczeniach i widzę jak wielki potencjał to wytwarza.

Jeśli chcesz zostać projektantem interakcji – znajdź swój zespół i zacznijcie coś robić, najlepiej coś co sprawi wam dużo frajdy.Wwszystko inne przyjdzie samo – szybciej niż myślisz.

Eryk Orłowski (Komitywa)

Nie chciałbym odnosić się do siebie, jako wzorca – tego nawet moje ego nie zniesie 😉 Wolę dwa słowa o tym, co zrobiłbym sam, gdybym zaczynał od zera.

Zacznijmy od edukacji. Dziś na rynku mamy już kilka uczelni i kierunków, które pomogą adeptom projektowania dla użytkownika – SPiK w Szkole Wyższej Psychologii Społecznej, kognitywistykę na UAM. Osobiście zacząłbym od kierunku, który pozwala zarówno zrozumieć użytkownika na poziomie procesów poznawczych, jak również wprowadza studentów w świat dostępny dotąd wyłącznie dla informatyków – mowa o kognitywistyce.

Poza wiedzą na poziomie akademickim, bardzo ważne jest nabyte możliwie najprędzej praktyczne doświadczenie. Nadal mamy na rynku zbyt duży rozziew pomiędzy codzienną pracą w organizacjach komercyjnych, a podejściem wyniesionym z uczelni. Na szczęście, to się powoli zmienia, choć mam wrażenie, że głównie za sprawą tych zainteresowanych, którzy nie czekają do dyplomu z podjęciem pracy bądź praktyk.

To wszystko to podstawy. A dobrym fachowcem zostaje się poprzez krytyczne podejście do powszechnie wyznawanych pseudozasad i wykorzystanie posiadanej, bądź nabytej, skłonności do myślenia „out of the box”. Na początek przyda się wiedza wyniesiona ze szkoły plus szczypta zdrowego sceptycyzmu. W sumie – jak w każdej chyba branży.

Autora Podsumowanie 🙂

Dla mnie cały czas nie tracą na ważności 10 przykazań projektowych, które w swoim czasie udało mi się spisać.

Generalną zasadą jest znalezienie źródła nieustających stymulacji – jeśli nie dostarczają Ci ich w Twojej firmie, sam sobie je organizuj i PATRZ (z otwartością poznawczą). Staraj się oglądać kilka-, kilkadziesiąt serwisów dziennie – nie pod kątem ich zawartości merytorycznej, ale zasad na jakich działają, zarówno na poziomie ogólnym (strategii) jak i w detalach (rozwiązań interfejsowych).

Zgadzam się z moimi przedmówcami co do istotności wiedzy. Zdobywa się ją zasadniczo na dwa sposoby: projektując na co dzień, bądź czytając / podglądając jak projektują inni. Wątek związany z podglądactwem jest dość istotny, gdyż uczysz się jak rozwiązywać problemy (czasem też jak ich nie rozwiązywać, co też jest nie do przecenienia) plus zdobywasz informacje, którymi możesz się posłużyć przy kolejnych projektach.

I najważniejsze – nie śpiesz się! Nie myśl o szybkich awansach (to zmora), bo niczego się nie nauczysz; a jak się nauczysz, to awanse przyjdą same 🙂 Powoli, ale konsekwentnie. Opanuj terminologię; wytyczne z guidebooków popularnych systemów operacyjnych; nie zamykaj się na nowości; staraj się myśleć poprzez analogię a zobaczysz, że na pewnych poziomach nawet innowacyjne rozwiązania, czy wydawałoby się zupełnie nowe problemy, można uchwycić w ramach klasycznych rozwiązań.

A ostatecznie: projektując nie myśl o interfejsach – myśl o ludziach i ich potrzebach, to dla nich w końcu projektujesz.