Efektywność UI

Saturday, February 27th, 2010 | Author: Aga

Zainspirowana jednym z wykładów na uczelni,  zaczęłam się ostatnio zastanawiać, co tak naprawdę znaczy słowo: efektywność w kontekście badań użyteczności. Typowa odpowiedź to:   czas potrzebny do wykonania danego zadania przy użyciu danego narzędzia. Prawda to, choć niecała.  Bo rodzaje efektywności są tak naprawdę dwa:

  • efektywność pragmatyczna (czyli optymalizacja wykonania danego zadania) i
  • efektywność poznawcza (czyli optymalizacja wysiłku poznawczego potrzebnego dodanego zadania)

Czyli tak naprawdę pytanie o efektywny design to nie pytanie o to jak najszybciej wykonać dane zadanie a raczej, jaka jest najwłaściwsza droga do poradzenia sobie z danym problemem. Ale co to znaczy? Według mnie, żeby ocenić efektywność danego systemu trzeba ocenić trzy rzeczy:

  • prostotę znaczeniową, która dla mnie oznacza, że użytkownik dostaje właściwe rozwiązanie we właściwej postaci
  • umiejscowienie, czyli to, że użytkownik natyka się na kolejne elementy informacyjne i interakcyjne we właściwym miejscu i o właściwym czasie
  • tempo, czyli to, że wszystko to odbywa się w odpowiednim tempie i przez odpowiednią ilość czasu.

No dobrze, ale jak to osiągnąć?  Jest na to kilka podstawowych zasad:

  • przede wszystkim trzeba pokazać użytkownikowi właściwy kawałek informacji i instrukcji w momencie, kiedy może jej potrzebować. Najlepszym tego przykładem, na jaki natknęłam się ostatnio są strony portalu radiownet, gdzie prowadzimy z Łukaszem podcast o innowacji  (www.radiownet.pl/radio-novum). Ktoś wyszedł z założenia, że zakładanie radia to proces krokowy, więc i instrukcje można podzielić na odpowiednio małe kawałki i właściwy kawałek umieścić  na ekranie we właściwym momencie.

  • Należy też zapewnić użytkownikowi wygodny sposób wykonania zadania, czyli zapewnić elementy interakcyjne pozwalające na kolejne kroki. Jest to pewnie łatwiejsze do wyobrażenia w kontekście projektowania przedmiotów użytkowych, jak np. czajnik, którego rączka nie powinna się nagrzewać w czasie gotowania wody (co wydarza się w przypadku naszego). Ale odnosi się to też do sfery cyfrowej, gdzie użytkownik powinien bezproblemowo znaleźć potrzebną mu funkcjonalność. Dla mnie przekłada się to bezpośrednio na prostotę interfejsu, ale także na redundancję, czyli na zapewnianie użytkownikowi więcej niż jednej opcji pozwalającej na zrobienie kolejnych kroków zadaniowych. Takim typowym przykładem może być umieszczanie kilku opcji to zalogowania się do sklepów internetowych lub więcej niż tylko jedna możliwość dostępu do listy oferowanych przez nie kategorii produktów.

  • W każdym przypadku użytkownik powinien być prowadzony “za rękę” przez system. To oznacza, że sposób użycie kolorów, elementów interakcyjnych czy multimodalnych rozwiązań nie powinno być jedynie elementem dekoracyjnym, ale też podpowiedzią dla użytkownika pozwalającą mu na zorientowanie się gdzie jest, co ma do dyspozycji i co dalej może lub powinien zrobić. Dlatego tak istotnym jest konsekwentne umieszczanie powtarzających się elementów w tych samych miejscach.  Takim sztandarowym przykładem jest prezentacja fontów w edytorach tekstów. Samo napisanie nazwy czcionki  nie ułatwia wyboru użytkownika. Natomiast napisanie nazwy czcionki przy pomocy tej właśnie czcionki daje użytkownikowi potrzebna do dokonania takiego właśnie wyboru wskazówkę.
  • Wreszcie istotnym jest zapewnienie użytkownikowi właściwych narzędzi potrzebnych do wykonania danego zadania. Tu chyba najlepszym przykładem IKEA, która nie tylko sprzedaje meble, ale też dostarcza użytkownikowi narzędzi pozwalających na ich zamontowanie.  W kontekście cyfrowym takim odpowiednikiem jest automatyczne wypełnienie za użytkownika danych osobowych, które znajdują się już w systemie, czy też dostarczenie mu bezpośredniej pomocy, kiedy poszukuje potrzebnej informacji. Może nie jest to typowy przykład, ale ja sama najczęściej zauważam taką potrzebę, kiedy zgłaszam artykuły naukowe do publikacji i potrzebuję stworzyć listę słów-kluczy. W niektórych serwisach naukowych taka lista jest osadzona obok pola wymagającego tej informacji, w innych jest podpięty link do odpowiedniej taksonomii, a w niektórych nie ma nic i samemu trzeba szukać i kombinować, jakie dokładnie są wymagania związane z tagowaniem artykułu.

  • Na końcu jeszcze ważne jest to, żeby wprowadzać ograniczenia interakcyjne. Ograniczenia obniżają poziom niepewności użytkownika związany z tym, co robić w danym momencie i przyspieszają jego decyzje interakcyjne. Ale ograniczenia nie powinny być wprowadzane bez poinformowania użytkownika, kiedy będzie mógł daną czynność wykonać. Takim typowym przykładem ograniczeń jest  niewysłanie wiadomości mailowej bez wpisania jej treści.

Bo z tworzeniem systemów dla użytkowników jest jak z pisanie przepisu na sernik. Kucharz potrzebuje nie tyko właściwej informacji we właściwym momencie, ale też holistycznej wiedzy o tym co trzeba zrobić dalej, jakie narzędzia są to tego potrzebne i czego absolutnie nie można zrobić. Każda interakcja ma swój naturalny proces, swój naturalny rytm i strukturę. Dlatego, żeby wspomagać taki proces należy:

  • umieszczać opcje tam gdzie naprawdę przynależą
  • redukować złożoność opisową i wizualną
  • dobrze zrozumieć proces  i wspomagać właściwe kroki i decyzje (również w sposób niebezpośredni)
  • nie pokazywać użytkownikowi całości informacji, ale też zagwarantować, że ma całościowy obraz danego procesu
  • zaproponować właściwą sekwencję kroków, czyli zasugerować, że wysłanie pustego maila nie jest może tym, co użytkownik chciał
  • i wreszcie pytać o odpowiednią informację we właściwym momencie

I co dla mnie jest chyba zawsze myślą przewodnią to to, że większość projektantów tworzy dobre ale skomplikowane rozwiązania. Naprawdę dobrego projektanta poznaje się po tym, że jego rozwiązanie jest nie tylko dobre ale też proste.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Secured for spam by MLW and Associates, LLP's Super CAPTCHASecured by Super-CAPTCHA © 2009-2010 MLW & Associates, LLP. All rights reserved.