Ułatw życie użytkownikowi, pomóż mu w wyborze

Ostatnio, korzystając z bankomatu Millennium, przez przypadek wybrałem anglojęzyczną wersję interfejsu. Nic strasznego się nie stało (osoby nieznające angielskiego mogą mieć inne zdanie), błąd wyniknął głównie z mojej nieuwagi, ale można go było uniknąć lepiej projektując system.

Nie znam dokładnych statystyk banku, ale z pewnością znaczna większość użytkowników w naszym kraju korzysta interfejsu polskiego. Mimo to, system w żaden sposób nie sugeruje, że jest to wybór domyślny. A dlaczego nie pomijać w ogóle tego kroku, automatycznie wybierać polską wersję, a w głównym MENU dodać wybór języka angielskiego?

Dzięki temu, nie tylko zminimalizujemy ryzyko błędu, ale też znaczna większość użytkowników zaoszczędzi czas pomijając krok wyboru języka.

Ale co z anglojęzycznymi klientami? — nasuwa się pytanie. Wbrew pozorom, nie będzie to dla nich negatywna zmiana. Jak w poprzedniej wersji, muszą wcisnąć przycisk ze swoim językiem. Jedynym utrudnieniem może być liczba alternatyw do wyboru — w poprzedniej wersji jedna, w nowej pewnie ok. 5,6. Jeśli jednak weźmiemy pod uwagę różnicę języka, to szybkie odrzucenie komunikatów po polsku nie powinno stanowić problemu.

Kolorowy przycisk może załatwić sprawę

Przewidywanie kolejnej akcji użytkownika i jej ułatwianie np. użyciem odpowiedniego koloru, to jedna z prostszych „sztuczek” projektantów interfejsów. Tym bardziej dziwi, że często się o niej zapomina. I to w sytuacjach, gdy ewentualny błąd będzie bardziej szkodliwy, niż w przypadku z bankomatem.

Przykład z Windows 7. Zmieniamy rozdzielczość ekranu, klikamy „Zastosuj”, potwierdzamy, że zmiany są w porządku. Kolejnym naturalnym krokiem, jest kliknięcie „Ok” i wyjście. Ale nie dla Microsoftu, który za równorzędną opcję uważa „anuluj”. Nawet, jeśli w przypadku wybrania np. błędnej rozdzielczości system od razu proponuje mi anulowanie zmian.

Postawienie „Ok” i „anuluj” jako równorzędnych akcji może zwiększyć możliwość błędu (nawet typowo mechanicznego, bo przyciski są blisko siebie i daleko od ustawień panelu — nie trudno sobie wyobrazić, że szybki ruch myszki może zakończyć się kliknięciem w nieodpowiedni przycisk), ale przede wszystkim wydłuża decyzję. Musimy przeanalizować dwie równorzędne opcje i wybrać odpowiednią.

Jeśli natomiast wyróżnimy pierwszorzędną akcję (najczęściej będzie to „Zatwierdź”, „Ok”, „Zgadzam się” itp.) graficznie, użytkownik będzie mógł dokonać wyboru nawet nie czytając etykiet przycisków.

Jeszcze gorzej, gdy przypadkowe kliknięcie zniweczy trud długo wpisywanych danych. Sytuacje, w której na końcu formularza umieszcza się równorzędnie przyciski “Wyślij” i “Wyczyść” ciężko nazwać nawet błędem. Wygląda to wręcz na celową próbę sabotażu działań użytkownika.

Nie tylko przyciski

Zaznaczanie akcji domyślnej to nie tylko przyciski typu „OK”/”anuluj”. Domyślny wybór można podpowiadać też np. w formularzach. Dobrym przykładem jest rejestracja Gmail. System rozpoznaje, w jakim kraju zakładane jest konto i domyślnie podpowiada lokalizację. Dzięki temu nie musimy szukać Polski wśród około 200 innych pozycji.

Podobnego rozwiązania możemy użyć, gdy wiemy, że jedna z opcji formularza jest popularniejsza od pozostałych (ewentualnie, gdy chcemy, aby była popularniejsza).

Znów przykład od Google, tym razem w serwisie YouTube. Gdy dodajemy nagranie, serwis domyślnie podpowiada nam ustawienia prywatności (publiczne) i licencję (standardowa YouTube). Dodatkowo rozwiązany zostaje jeszcze jeden problem — duża część użytkowników nie zna się np. na różnicach między licencjami i propozycja ustawień standardowych sugeruje, że będzie to dobry wybór (jeśli oczywiście mają zaufanie do tej witryny).

Wreszcie można iść jeszcze dalej i — podobnie jak w przykładzie z bankomatem — podejmować decyzję za użytkownika.

Takie rozwiązanie przyjęło się choćby w przypadku wyboru języka. Ekrany z listą krajów należą do rzadkości i pojawiają się głównie, gdy zawartość witryny zmienia się z zależności od wybranej opcji lub ekran powitalny jest i tak konieczny np. z powodu weryfikacji wieku. Dużo częściej spotkać się można z wyświetleniem najbardziej popularnej wersji serwisu (ew. dopasowywaniu wersji np. po adresie IP), a zmiana języka możliwa jest najczęściej dzięki niewielkiemu stałemu elementowi.

Decyzję za użytkownika podejmuje też choćby edytor tekstu Word. Po jego otworzeniu, dostajemy od razu przygotowany do pracy nowy dokument. Taka “samowola” pozwala szybciej zacząć pracę nad nowym tekstem, a jednocześnie nie utrudnia życia użytkownikom, którzy zamierzają edytować już istniejący plik.

Akcja domyślna — czy zawsze?

Oczywiście… że nie.

„Ułatwienie” może spowodować skutki odwrotne od zamierzonych. Czasem wskazane jest, aby użytkownik zatrzymał się i przemyślał akcję, a nie działał „na czuja”. Dla zobrazowania, kolejny przykład z Windows 7, tym razem w przypadku, gdy system napotka problem plików o tej samej nazwie.

Duże ilości danych do zanalizowania, brak podpowiedzi dotyczącej poprawnego wyboru. Jednak takie „utrudnienie” nie wzięło się z przypadku. Pochopna decyzja może spowodować, że stracimy ważne dane. A tak, możemy zweryfikować, jakie konsekwencje pociąga za sobą każda z decyzji oraz sprawdzić najważniejsze informacje o obu plikach (np. datę ostatniej edycji). Co ciekawe, tym razem Microsoft opcję „anuluj” słusznie postawił z boku całego wyboru, sugerując zapewne, że jest to głównie swoiste koło ratunkowe dla zdezorientowanych.

Podpowiedź może też rozleniwić użytkownika, który nie będzie chciał zmienić ustawień domyślnych. Jeśli zależy nam np. na poprawności wyboru miejscowości przy zakładaniu konta, lepiej nie sugerować np. odpowiedzi „Warszawa”, nawet jeśli jest to wybór większości użytkowników.

Kiedy pomagać użytkownikowi w wyborze?

Niestety, jak to bywa w świecie projektowania UX — wszystko zależy od sytuacji.

Stosunkowo łatwo jest z przyciskami. O ile nie dotyczą one akcji, która może przynieść nam/użytkownikowi szkodę, warto wyróżniać akcje domyślne lub choćby wizualnie sugerować użytkownikowi różnice w wyborze typu „tak”/”nie”.

Większym wyzwaniem jest przewidzenie odpowiedzi użytkownika i zrobienie kroku za niego. Źle zaprojektowany interfejs może sprawić, że użytkownik preferujący rozwiązanie alternatywne, będzie miał problemy z dotarciem do interesującej go opcji lub nawet ją przeoczy. A ułatwienie obsługi dla części użytkowników nie może powodować, że projekt stanie się mniej użyteczny dla pozostałych.

Warto więc pamiętać, że każdy taki wybór trzeba przemyśleć i co najważniejsze — przetestować. Bez tego, nawet najbardziej błyskotliwy pomysł może przerodzić się w frustrującego potworka.

4.09.2012