Usability is about choosing functionalities

Jakość 02/05/2006 · Link

Przeglądając artykuły na temat analizy wymagań natrafiłem na takie interesujące spostrzeżenie (Why user experience disaster happen at the start of web projects, Sim D'Hertefelt):

"And oh yeah", these prospective clients tell me at the end of their project briefing, "the site has to be sticky and user friendly as well." I have to disappoint them. Usability is not something you add to the design after you're done with the strategic thinking about functionalities. Usability IS about choosing useful functionalities. If a website is not useful, making it easy to use or attractive is not going to make it more usable. Usable means useful AND easy to use AND appreciated by users.

Wybór funkcjonalności oznacza również odrzucenie pewnych z nich. Widzieliście aplikacje webowe opracowane przez 37 signals? Kluczową zaletą tych aplikacji jest prostota użytkowania. Jak ją osiągnięto? Oto fragment z manifestu aplikacji Basecamp:

Basecamp is simple on purpose. We've kept the confusing, complex stuff out. Basecamp doesn't do everything, but what it does it does extremely well. That's focus and that's the baseline principle of our "Less Software" approach. Not more stuff, just the right stuff to help you get your job done.

Pomyślcie o innych produktach, które odniosły masowy sukces. Firefox, Skype, Del.icio.us, Google, Flickr, ... Czym przerosły swoich poprzedników? Czy mają bogatsze od nich funkcjonalności? Według jakich kryterów dokonano ich wyboru?

Zwróćcie przy tym uwagę jeszcze na jeden aspekt: programiści są inni :-). Zwykle mają większą tolerancję na mniej zgrabny UI niż inni ludzie. Dlatego podejmując decyzję o dodaniu lub usunięciu funkcjonalności konieczne jest przyjęcie odpowiedniej poprawki w stosunku do ich opinii.

PS. Osobną kwestią jest przekonanie klienta (lub innego właściciela projektu) do rezygnacji z funkcjonalności. Zwłaszcza, jeżeli projekt jest wykonywany na zamówienie i klient zapłacił za wykonanie w poprzednich wersjach funkcjonalności, które w praktyce nie są używane. Jakąkolwiek przyjąć strategię, kluczowe jest pokazanie kosztu ich pozostawienia: poza oczywistym kosztem utrzymania (np. błędy regresywne, testowanie regresywne, dokumentacja), jest to również najczęściej bardziej skomplikowany interfejs użytkownika a w konsekwencji większa liczba pomyłek użytkowników, mniejsza wydajność, większy koszt szkoleń etc.

---

Zobacz inne wpisy

• Chaos Report dwanaście lat później
• Czy tworzysz fajne rzeczy?
• UI nie jest obszarem inwencji
• Full Life Cycle Object-Oriented Testing
• Dlaczego powstaje kiepskie oprogramowanie?

---