5 zasad dbania o użyteczność serwisu WWW
Użyteczny serwis WWW
Użyteczny serwis WWW to taki serwis, który jest wygodny w obsłudze, można szybko odnaleźć w nim informacje oraz zrealizować swoje zadania (np. przelew albo zakup w księgarni internetowej). Klienci chętnie wracają do takich serwisów. To, że użyteczność jest wartością, wydaje się oczywiste. Trudniej jednak zapewnić użyteczność w swoim serwisie.
Oto pięć zasad, którymi warto kierować się, gdy chcemy zwiększyć usability swojego serwisu.
Oto pięć zasad, którymi warto kierować się, gdy chcemy zwiększyć usability swojego serwisu.
1. Myśl w kontekście celów
Złośliwi mówią, że gdy prezydent USA chce gdzieś zaprowadzić pokój, to wysyła tam bombowce. Zostawiając na boku dyskusje o polityce, to stwierdzenie dobrze ukazuje różnicę miedzy celem a zadaniem.
Przechodząc na grunt użyteczności: zastanów się, jakie cele mają Twoi użytkownicy. Patrząc na wiele sklepów internetowych można odnieść wrażenie, jakby ich właściciele zakładali, że klienci przychodzą do e-sklepu aby... założyć tam swoje konto. Wnoszę to po tzw. obowiązkowej rejestracji. Zanim taki e-sklep pozwoli nam zostawić u siebie pieniądze, musimy wymyślić hasło, login, przepisać dziwny ciąg znaków (tzw. CAPTCHA), zalogować się do swojej skrzynki mailowej, kliknąć link na aktywacyjny (o ile ten nie wpadł do spamu), itd.
Użytkownicy nie przychodzą do księgarni internetowej zakładać kolejne konto, do którego muszą pamiętać kolejne hasło. Użytkownicy przychodzą do księgarni internetowej, bo chcą kupić książkę. Ze swojego doświadczenia i opisów przypadków znam sytuacje, gdzie obowiązkowa rejestracja w serwisie obniżała o kilkadziesiąt (!) procent liczbę zamówień.
Jeżeli jasno powiemy sobie, co jest celem, łatwiej będzie nam zrozumieć, które zadania – przed jakimi stawiamy naszych użytkowników – okażą się niepotrzebne.
Czasem warto pomyśleć o celach klientów nieco bardziej finezyjnie. Wróćmy do internetowej księgarni. Oczywistym przykładem celu jest „Chcę kupić książkę Mężczyźni, którzy nienawidzą kobiet”. Ale warto się zastanowić, czy część klientów nie będzie swojego celu formułować inaczej: „Chcę kupić ten słynny szwedzki kryminał”. Czy nasza wyszukiwarka obsłuży takie zapytanie? Inni mogą formułować swój cel na jeszcze wyższym poziomie ogólności, np. „Chcę kupić prezent dla swojej dziewczyny”. Czy nawigacja naszego sklepu potrafi odpowiedzieć na taką potrzebę?
Rysunek: O ile Merlinowi w zakresie użyteczności można wiele zarzucić, o tyle pomysł na alternatywną, opartą na specyficznych celach, nawigację „Prezenty” wydaje się być trafiony.
2. Myśl jak użytkownik
Oczywiście najważniejsze to zrozumieć, jaki cel stawia sobie użytkownik. Ale poza celem warto zastanowić się..., a najlepiej zbadać jego sposób myślenia. Na ten sposób może się składać m.in. stosowany język i chęć poczucia kontroli.
Język i nazewnictwo
Kiedyś w jednym banku musiałem długo tłumaczyć, że nazwa „wtórnik” będzie niezrozumiała dla wielu użytkowników – bardziej oczywistym sformułowaniem jest po prostu „potwierdzenie przelewu”. W innym banku, nazwijmy go XYZ, sekcja dla klientów indywidualnych nosiła nazwę... XYZ (czyli tak samo, jak nazwa banku). Wielu użytkowników poszukujących oferty dla siebie, widząc na głównej stronie etykietę z nazwą banku omijała ją. Zakładali, że kliknięcie w nią nie przyniesie im niczego nowego – i trudno im się dziwić. W tym banku przyjęło się określać grupę klientów indywidualnych mianem „Segment XYZ”, ale klienci wcale nie musieli tego wiedzieć.
Oba przykłady to klasyczne przypadki tworzenia się wewnętrznego „slangu” wewnątrz organizacji. To typowe zjawisko, niemniej warto pamiętać, że klienci bardzo często mówią i myślą innym językiem, niż pracownicy firmy będącej właścicielem serwisu internetowego.
Częstym błędem jest też nadużywanie języka technicznego. Który komunikat będzie lepiej zrozumiany przez użytkownika: „Error#456 Session Expired” czy „Automatyczne wylogowanie. Ze względów bezpieczeństwa po trzech minutach braku aktywności użytkownika zostaje on automatycznie wylogowany, aby nikt inny nie miał dostępu do konta”.
Poczucie kontroli
Człowiek lubi wiedzieć, gdzie się znajduje i jak może znaleźć drogę wyjścia. Dzięki temu czuje się bezpieczniej i chętniej eksploruje dany serwis. Dlatego warto pokazywać użytkownikowi, gdzie obecnie się znajduje (zarówno jeśli jest to hierarchiczny serwis treściowy, jak i kilkuetapowy formularz). W przypadku serwisów transakcyjnych warto zadbać o możliwość cofnięcia akcji, np. po usunięciu produktu z koszyka powinna istnieć możliwość anulowania tej decyzji.
Przykład na temat stosowanego języka (z komunikatami) także obrazuje ten problem. W przypadku niezrozumiałego komunikatu część użytkowników zakłada, że być może to oni coś zepsuli i wolą nie wracać do takiego serwisu.
3. Rób testy
Nawet jeśli przeczytałeś sto mądrych książek i artykułów, i przeszedłeś dziesięć szkoleń o użyteczności – Twoi użytkownicy zawsze Cię zaskoczą. Prawdopodobnie nie czytałeś tylu książek i nie brałeś udziału w tylu szkoleniach. I nic w tym dziwnego – nie każdy ma czas i chęci zostać ekspertem w dziedzinie usability. Dlatego robienie badań z użytkownikami jest tak ważne.
Czy wiesz, że wielu użytkowników w Polsce nie rozumie słowa „newsletter”? Ja też nie wiedziałem. Wyszło to dopiero na badaniach użyteczności. Twoja grupa docelowa to w dużej części ludność wiejska? Sprawdź, czy w swoim formularzu wymagasz wpisania „ulicy”. Ten drugi przykład pokazuje, jak bardzo użyteczność jest zależna od kontekstu i właśnie dlatego książkowa wiedza nie zawsze wystarcza.
4. Podejmuj decyzje na podstawie danych
Pod koniec dnia liczy się głównie to, ile pieniędzy zostało w kasie. Wprowadzenie zmiany zawsze kosztuje, a konsekwencje błędnych zmian kosztują jeszcze więcej. Gdy chcesz wprowadzić jakąś zmianę, zawsze sobie zadaj pytanie „Dlaczego?”.
Pojawia się pomysł: „Zmieńmy kolor przycisku >zaakceptuj koszyk< na zielony”. Zwłaszcza, jeśli to na razie tylko Twoja intuicja lub podpatrzyłeś takie rozwiązanie u konkurencji – staraj się być racjonalny. Spójrz na statystyki – czy w procesie zakupu nagle odpada sporo ludzi? To jest przesłanka do zmiany. Ale czy na pewno chodzi o przycisk „zaakceptuj koszyk”? Zrób mini badanie użyteczności i/lub poproś o opinię eksperta.
Czy nowy pomysł się sprawdza? Czy badani potrafią w nowej wersji sprawnie wykonać swoje zadania? Załóżmy, że tak się dzieje. Ale nie rób od razu rewolucji. Przygotuj alternatywną wersję fragmentu serwisu (np. tylko dla jednej grupy produktów) i pokazuj przez dwa tygodnie jednym użytkownikom nową, a innym starą wersję (losowo). Takie porównanie nazywamy Testami A/B. Jeżeli nowa wersja rzeczywiście jest skuteczniejsza, wówczas dokonaj zmiany w całym serwisie.
Ten proces jest ciągły. Kombinuj, obserwuj konkurencję, czytaj o trendach, analizuj własne statystyki – kto nie poprawia swojego serwisu, ten zostaje w tyle.
Ale zmiany wprowadzaj stopniowo i testuj ich skuteczność. Nieważne, jak genialny był Twój pomysł. Koniec końców to Twoi klienci będą go weryfikować.
Rysunek 1. Poprawianie użyteczności serwisu to ciągły proces
Projektuj z głową – User-Centered Design
Proces projektowania serwisu często polega na napisaniu maila do firmy programistycznej czy agencji interaktywnej „potrzebuję nowego sklepu/systemu zarządzania firmą/produktu”. Programista zadzwoni do znajomego grafika, który przygotuje kolorową wizualizację strony głównej. Gdy klient ją zatwierdzi, programiści zabierają się do pracy, programując wedle własnego rozeznania i gustu, starając się uwzględnić przynajmniej część Twoich uwag.
Problem w tym, że rozeznanie i gust programistów, grafika czy Twój nie zawsze muszą być (i często nie są) rozeznaniem i gustem Twojego klienta.
Dowiedz się, czy agencja potrafi stworzyć tzw. projekt interakcji – określić na podstawie badań główne typy użytkowników (tzw. persony), określić ich cele i napisać krótkie scenariusze opisujące interakcje person z projektowanym produktem. Czy dopiero potem zaczyna rysować makiety serwisu (i czy w ogóle ktoś tam wpadł na taki pomysł, aby zaczynać projekt wizualny od makiet)? Czy w procesie tworzenia interface'u jest miejsce na tworzenie prototypów, które można poddać testom, zanim do roboty wezmą się programiści i czy zajmują się tym ludzie o odpowiednich kompetencjach (grafik może być taką osobą, ale nie zawsze tak jest)? Czy kolejne wersje tworzonego serwisu będą testowane nie tylko pod kątem działa/nie działa, ale też pod kątem użyteczności? Czy jest miejsce i czas (i budżet – to zależy oczywiście od Ciebie) na takie testy, ale też na poprawki wynikające z tych testów?
To zajmuje sporo czasu i sporo kosztuje? Oczywiście. Zastanów się tylko, czy więcej nie będzie kosztować robienie zmian na gotowym produkcie, gdy np. okaże się, że tylko ¼ użytkowników Twojego serwisu umie dokończyć proces zakupu. Do rachunku dolicz straty wywołane tym, że 3/4 Twoich potencjalnych klientów nie zostawiło u Ciebie pieniędzy.
Czasem jestem wzywany w momencie, gdy graficy i programiści już wykonali swoją robotę, a ja mam „zająć się tą całą użytecznością”. Taką sytuację nazywam „malowaniem trupa”. Mogę wskazać liczne problemy użyteczności, ale tak naprawdę uda się tylko nieco przypudrować wygląd serwisu. Pod koniec wdrożenia nikt nie chce słyszeć (ani nikogo nie stać na zmiany w logice wyszukiwarki) drzewie kategorii czy w layoucie strony. O użyteczności trzeba myśleć od początku projektu.
Jeżeli masz pewność, że po prostu zakładasz kolejny sklep w branży, możesz się wesprzeć analizą konkurencji i wiedzą ekspercką – być może korzystanie z całego opisanego wyżej procesu User-Centered Design nie będzie w 100 proc. opłacalne. To tylko model, a rzeczywistość odbiega od modeli. Ale im bardziej odchodzisz od tego modelu, tym bardziej narażasz się na ryzyko porażki.
Rysunek: Proces User-Centered Design
Autor: trener z firmy CTS
CTS jest autoryzowanym ośrodkiem szkoleniowym Microsoft, McAfee, CompTIA, Novell Linux SUSE. Ponadto posiadamy certyfikację centrum egzaminacyjnego Pearson VUE, Prometric, Certiport (Microsoft Office Specialist).
Szkolimy, doradzamy, wdrażamy.
CTS - Centrum Technik Sieciowych
cts@cts.com.pl
www.cts.com.pl
tel. 22 838-19-08
22 838-52-70
Złośliwi mówią, że gdy prezydent USA chce gdzieś zaprowadzić pokój, to wysyła tam bombowce. Zostawiając na boku dyskusje o polityce, to stwierdzenie dobrze ukazuje różnicę miedzy celem a zadaniem.
Przechodząc na grunt użyteczności: zastanów się, jakie cele mają Twoi użytkownicy. Patrząc na wiele sklepów internetowych można odnieść wrażenie, jakby ich właściciele zakładali, że klienci przychodzą do e-sklepu aby... założyć tam swoje konto. Wnoszę to po tzw. obowiązkowej rejestracji. Zanim taki e-sklep pozwoli nam zostawić u siebie pieniądze, musimy wymyślić hasło, login, przepisać dziwny ciąg znaków (tzw. CAPTCHA), zalogować się do swojej skrzynki mailowej, kliknąć link na aktywacyjny (o ile ten nie wpadł do spamu), itd.
Użytkownicy nie przychodzą do księgarni internetowej zakładać kolejne konto, do którego muszą pamiętać kolejne hasło. Użytkownicy przychodzą do księgarni internetowej, bo chcą kupić książkę. Ze swojego doświadczenia i opisów przypadków znam sytuacje, gdzie obowiązkowa rejestracja w serwisie obniżała o kilkadziesiąt (!) procent liczbę zamówień.
Jeżeli jasno powiemy sobie, co jest celem, łatwiej będzie nam zrozumieć, które zadania – przed jakimi stawiamy naszych użytkowników – okażą się niepotrzebne.
Czasem warto pomyśleć o celach klientów nieco bardziej finezyjnie. Wróćmy do internetowej księgarni. Oczywistym przykładem celu jest „Chcę kupić książkę Mężczyźni, którzy nienawidzą kobiet”. Ale warto się zastanowić, czy część klientów nie będzie swojego celu formułować inaczej: „Chcę kupić ten słynny szwedzki kryminał”. Czy nasza wyszukiwarka obsłuży takie zapytanie? Inni mogą formułować swój cel na jeszcze wyższym poziomie ogólności, np. „Chcę kupić prezent dla swojej dziewczyny”. Czy nawigacja naszego sklepu potrafi odpowiedzieć na taką potrzebę?
Rysunek: O ile Merlinowi w zakresie użyteczności można wiele zarzucić, o tyle pomysł na alternatywną, opartą na specyficznych celach, nawigację „Prezenty” wydaje się być trafiony.
2. Myśl jak użytkownik
Oczywiście najważniejsze to zrozumieć, jaki cel stawia sobie użytkownik. Ale poza celem warto zastanowić się..., a najlepiej zbadać jego sposób myślenia. Na ten sposób może się składać m.in. stosowany język i chęć poczucia kontroli.
Język i nazewnictwo
Kiedyś w jednym banku musiałem długo tłumaczyć, że nazwa „wtórnik” będzie niezrozumiała dla wielu użytkowników – bardziej oczywistym sformułowaniem jest po prostu „potwierdzenie przelewu”. W innym banku, nazwijmy go XYZ, sekcja dla klientów indywidualnych nosiła nazwę... XYZ (czyli tak samo, jak nazwa banku). Wielu użytkowników poszukujących oferty dla siebie, widząc na głównej stronie etykietę z nazwą banku omijała ją. Zakładali, że kliknięcie w nią nie przyniesie im niczego nowego – i trudno im się dziwić. W tym banku przyjęło się określać grupę klientów indywidualnych mianem „Segment XYZ”, ale klienci wcale nie musieli tego wiedzieć.
Oba przykłady to klasyczne przypadki tworzenia się wewnętrznego „slangu” wewnątrz organizacji. To typowe zjawisko, niemniej warto pamiętać, że klienci bardzo często mówią i myślą innym językiem, niż pracownicy firmy będącej właścicielem serwisu internetowego.
Częstym błędem jest też nadużywanie języka technicznego. Który komunikat będzie lepiej zrozumiany przez użytkownika: „Error#456 Session Expired” czy „Automatyczne wylogowanie. Ze względów bezpieczeństwa po trzech minutach braku aktywności użytkownika zostaje on automatycznie wylogowany, aby nikt inny nie miał dostępu do konta”.
Poczucie kontroli
Człowiek lubi wiedzieć, gdzie się znajduje i jak może znaleźć drogę wyjścia. Dzięki temu czuje się bezpieczniej i chętniej eksploruje dany serwis. Dlatego warto pokazywać użytkownikowi, gdzie obecnie się znajduje (zarówno jeśli jest to hierarchiczny serwis treściowy, jak i kilkuetapowy formularz). W przypadku serwisów transakcyjnych warto zadbać o możliwość cofnięcia akcji, np. po usunięciu produktu z koszyka powinna istnieć możliwość anulowania tej decyzji.
Przykład na temat stosowanego języka (z komunikatami) także obrazuje ten problem. W przypadku niezrozumiałego komunikatu część użytkowników zakłada, że być może to oni coś zepsuli i wolą nie wracać do takiego serwisu.
3. Rób testy
Nawet jeśli przeczytałeś sto mądrych książek i artykułów, i przeszedłeś dziesięć szkoleń o użyteczności – Twoi użytkownicy zawsze Cię zaskoczą. Prawdopodobnie nie czytałeś tylu książek i nie brałeś udziału w tylu szkoleniach. I nic w tym dziwnego – nie każdy ma czas i chęci zostać ekspertem w dziedzinie usability. Dlatego robienie badań z użytkownikami jest tak ważne.
Czy wiesz, że wielu użytkowników w Polsce nie rozumie słowa „newsletter”? Ja też nie wiedziałem. Wyszło to dopiero na badaniach użyteczności. Twoja grupa docelowa to w dużej części ludność wiejska? Sprawdź, czy w swoim formularzu wymagasz wpisania „ulicy”. Ten drugi przykład pokazuje, jak bardzo użyteczność jest zależna od kontekstu i właśnie dlatego książkowa wiedza nie zawsze wystarcza.
4. Podejmuj decyzje na podstawie danych
Pod koniec dnia liczy się głównie to, ile pieniędzy zostało w kasie. Wprowadzenie zmiany zawsze kosztuje, a konsekwencje błędnych zmian kosztują jeszcze więcej. Gdy chcesz wprowadzić jakąś zmianę, zawsze sobie zadaj pytanie „Dlaczego?”.
Pojawia się pomysł: „Zmieńmy kolor przycisku >zaakceptuj koszyk< na zielony”. Zwłaszcza, jeśli to na razie tylko Twoja intuicja lub podpatrzyłeś takie rozwiązanie u konkurencji – staraj się być racjonalny. Spójrz na statystyki – czy w procesie zakupu nagle odpada sporo ludzi? To jest przesłanka do zmiany. Ale czy na pewno chodzi o przycisk „zaakceptuj koszyk”? Zrób mini badanie użyteczności i/lub poproś o opinię eksperta.
Czy nowy pomysł się sprawdza? Czy badani potrafią w nowej wersji sprawnie wykonać swoje zadania? Załóżmy, że tak się dzieje. Ale nie rób od razu rewolucji. Przygotuj alternatywną wersję fragmentu serwisu (np. tylko dla jednej grupy produktów) i pokazuj przez dwa tygodnie jednym użytkownikom nową, a innym starą wersję (losowo). Takie porównanie nazywamy Testami A/B. Jeżeli nowa wersja rzeczywiście jest skuteczniejsza, wówczas dokonaj zmiany w całym serwisie.
Ten proces jest ciągły. Kombinuj, obserwuj konkurencję, czytaj o trendach, analizuj własne statystyki – kto nie poprawia swojego serwisu, ten zostaje w tyle.
Ale zmiany wprowadzaj stopniowo i testuj ich skuteczność. Nieważne, jak genialny był Twój pomysł. Koniec końców to Twoi klienci będą go weryfikować.
Rysunek 1. Poprawianie użyteczności serwisu to ciągły proces
Projektuj z głową – User-Centered Design
Proces projektowania serwisu często polega na napisaniu maila do firmy programistycznej czy agencji interaktywnej „potrzebuję nowego sklepu/systemu zarządzania firmą/produktu”. Programista zadzwoni do znajomego grafika, który przygotuje kolorową wizualizację strony głównej. Gdy klient ją zatwierdzi, programiści zabierają się do pracy, programując wedle własnego rozeznania i gustu, starając się uwzględnić przynajmniej część Twoich uwag.
Problem w tym, że rozeznanie i gust programistów, grafika czy Twój nie zawsze muszą być (i często nie są) rozeznaniem i gustem Twojego klienta.
Dowiedz się, czy agencja potrafi stworzyć tzw. projekt interakcji – określić na podstawie badań główne typy użytkowników (tzw. persony), określić ich cele i napisać krótkie scenariusze opisujące interakcje person z projektowanym produktem. Czy dopiero potem zaczyna rysować makiety serwisu (i czy w ogóle ktoś tam wpadł na taki pomysł, aby zaczynać projekt wizualny od makiet)? Czy w procesie tworzenia interface'u jest miejsce na tworzenie prototypów, które można poddać testom, zanim do roboty wezmą się programiści i czy zajmują się tym ludzie o odpowiednich kompetencjach (grafik może być taką osobą, ale nie zawsze tak jest)? Czy kolejne wersje tworzonego serwisu będą testowane nie tylko pod kątem działa/nie działa, ale też pod kątem użyteczności? Czy jest miejsce i czas (i budżet – to zależy oczywiście od Ciebie) na takie testy, ale też na poprawki wynikające z tych testów?
To zajmuje sporo czasu i sporo kosztuje? Oczywiście. Zastanów się tylko, czy więcej nie będzie kosztować robienie zmian na gotowym produkcie, gdy np. okaże się, że tylko ¼ użytkowników Twojego serwisu umie dokończyć proces zakupu. Do rachunku dolicz straty wywołane tym, że 3/4 Twoich potencjalnych klientów nie zostawiło u Ciebie pieniędzy.
Czasem jestem wzywany w momencie, gdy graficy i programiści już wykonali swoją robotę, a ja mam „zająć się tą całą użytecznością”. Taką sytuację nazywam „malowaniem trupa”. Mogę wskazać liczne problemy użyteczności, ale tak naprawdę uda się tylko nieco przypudrować wygląd serwisu. Pod koniec wdrożenia nikt nie chce słyszeć (ani nikogo nie stać na zmiany w logice wyszukiwarki) drzewie kategorii czy w layoucie strony. O użyteczności trzeba myśleć od początku projektu.
Jeżeli masz pewność, że po prostu zakładasz kolejny sklep w branży, możesz się wesprzeć analizą konkurencji i wiedzą ekspercką – być może korzystanie z całego opisanego wyżej procesu User-Centered Design nie będzie w 100 proc. opłacalne. To tylko model, a rzeczywistość odbiega od modeli. Ale im bardziej odchodzisz od tego modelu, tym bardziej narażasz się na ryzyko porażki.
Rysunek: Proces User-Centered Design
Autor: trener z firmy CTS
CTS jest autoryzowanym ośrodkiem szkoleniowym Microsoft, McAfee, CompTIA, Novell Linux SUSE. Ponadto posiadamy certyfikację centrum egzaminacyjnego Pearson VUE, Prometric, Certiport (Microsoft Office Specialist).
Szkolimy, doradzamy, wdrażamy.
CTS - Centrum Technik Sieciowych
cts@cts.com.pl
www.cts.com.pl
tel. 22 838-19-08
22 838-52-70
|
nr 3(107)2011  Zobacz więcej na temat: kuśmierek szkolenia | proces user-centered design | sampling | użyteczność serwisu |
|
