Kontrola czy swoboda użytkownika, czyli filozofia projektowania systemów, cz.2 – przykłady

Użytkownik powinien mieć pełną kontrolę nad oprogramowaniem

W poprzednim artykule opisywałem sposób myślenia polegający na uznaniu wyższości użytkownika nad oprogramowaniem. Wracamy tu do myśli, że żywy organizm jest lepiej przystosowany do radzenia sobie w świecie niż komputer [1]. W pracy wykonywanej przez użytkowników zawsze będą pojawiać się sytuacje, których nie przewidzieli twórcy. Aby sprostać takim sytuacjom, oprogramowanie powinno współdziałać z użytkownikiem, tworząc środowisko, gdzie można wykorzystać możliwości ludzkiej inteligencji.

Praktyczne wnioski dla analityka biznesowego

Jakie w praktyce wypływają z tego wnioski? Otóż kontrola użytkownika nad systemem powinna być jak największa. Dotyczy to sposobu prezentowania informacji przez daną aplikację oraz możliwych do wykonania akcji. Nie oznacza to jednak, że użytkownik ma wyręczać oprogramowanie czy też jego twórców w wykonywaniu pracy. Chodzi raczej o zakres możliwości jakie powinno ono dawać.
Warto pomyśleć o oprogramowaniu jak o narzędziu w rękach użytkownika. Oprogramowanie teoretycznie daje nieograniczone możliwości. Gdybyśmy mieli podobne opcje w rzeczywistym świecie, moglibyśmy stworzyć idealne narzędzia, przykładowo idealny młotek. Ile waży idealny młotek? Tyle, ile w danej chwili chce jego właściciel. Z jakiego jest materiału? Z takiego jakiego potrzebuje jego właściciel np. raz metal, raz drewno, a raz guma. Jakie są jego wymiary? Dokładnie takie, jak potrzebne do danej pracy, czyli raz długi do burzenia muru, a raz krótki do wbijania gwoździ w trudno dostępnych miejscach. Na co pozwala idealny młotek? Na każde zadanie jakie chce wykonać jego właściciel. Nawet na skuteczne rozbicie szyby w swoim samochodzie, kiedy zatrzasnął tam kluczyki będąc na parkingu na jakimś odludziu. Dodatkowo idealny młotek pozwala na wycofanie wykonanych akcji np. wyjęcie wbitego gwoździa.
Weźmy teraz analityka biznesowego, który pisze wymagania do konkretnego projektu, powiedzmy do listy przedmiotów na portalu aukcyjnym. Trzeba napisać konkretne wymagania do tej listy.

• Co ma być pokazywane? To czego chce użytkownik. Raz lista przedmiotów, raz statystyka liczby przedmiotów wg konkretnych atrybutów.
• Jaka ma być kolejność pokazywanych przedmiotów? Taka, jakiej chce dany użytkownik w danym momencie np. rosnąco, malejąco, wg konkretnego atrybutu.
• Jakie przedmioty mają być pokazane? Takie, których szuka użytkownik. Interesują go przedmioty o konkretnych atrybutach lub kombinacji atrybutów.
• Jakie szczegóły mają być wyświetlane dla każdego przedmiotu? Takie, jakie są potrzebne użytkownikowi do dokonania wyboru i porównania.
• Dla których przedmiotów pokazać wszystkie szczegóły? Dla wybranych przez użytkownika.
•  …

To wszystko, i jeszcze więcej, powinien móc kontrolować użytkownik po to, by lepiej radzić sobie z różnymi trudnymi wyborami. Im większa kontrola użytkownika, tym większa jest użyteczność portalu i większe prawdopodobieństwo znalezienia tego, co trzeba. Mam nadzieję, że tą drogą w przyszłości będą podążać portale aukcyjne i nie tylko. To wszystko przecież da się osiągnąć w tworzonych przez nas systemach.
Analizując potrzeby naszych użytkowników powinniśmy zawsze dążyć do tworzenia rozwiązań, które w pełni wspierają ich pracę. Oprogramowanie nie powinno zabraniać użytkownikowi wykonywania, tego co on uznał za stosowne. Można to osiągnąć jedynie poprzez oddanie kontroli nad zachowaniem oprogramowania w ręce użytkownika. Może wydawać się to bardzo trudne i pracochłonne dla twórców oprogramowania. No cóż, wygląda na to, że nie musimy się martwić o brak pracy w przyszłości:)
Nie zawsze też zwiększanie elastyczności zwiększa koszty dla twórców oprogramowania. Czasem wydłuża nieznacznie albo wcale, zmniejszając za to koszt jego utrzymania i wsparcia dla użytkowników. Poza tym, projektując nowe rzeczy nie wiemy, ile pracy jest do wykonania aż do momentu kiedy specyfikacja wymagań jest gotowa. Ze specyfikacji można usunąć mechanizmy chroniące użytkownika przed nim samym, zastępując je mechanizmami wycofywania wykonanych akcji.

Przykłady

Przyjrzyjmy się przykładowi transakcji zakupu przedmiotu w sklepie internetowym. Co robić, kiedy brakuje jakichś danych lub mają one niewłaściwy format? Co powinno się wówczas dziać? Tradycyjnie, najprościej jest nie pozwalać na wykonanie transakcji. Uznając jednak wyższość człowieka nad maszyną moglibyśmy wykonać transakcję, dając jednocześnie możliwość uzupełnienia brakujących danych w późniejszym terminie.
Kiedy nie było jeszcze komputerów, rzesze urzędników pracowały z użyciem papieru. Mogło się zdarzyć, że ważny klient potrzebował pilnie zrealizować jakąś transakcję, ale urzędnik nie miał wszystkich potrzebnych informacji czy dokumentów. Wówczas, wbrew wszelkim oficjalnym zasadom i procedurom, urzędnik akceptował transakcję pomimo braków. Dopisywał adnotację we właściwym miejscu i robił notatkę o konieczności uzupełniania informacji. Później, kiedy już transakcja były zakończona, urzędnik otrzymywał potrzebne dokumenty czy informacje i umieszczał je tam, gdzie ich brakowało [2]. Wdzięczny klient coraz chętniej korzystał z usług organizacji tego zaradnego urzędnika. Niestety z nastaniem informatyzacji, początkowo takie sytuacje nie mogły znaleźć rozwiązania, co niewątpliwie rodziło frustrację klientów i urzędników. Logika komputerów działała sprawnie tylko dzięki ściśle pilnowanej poprawności danych.
A taka, na przykład, aplikacja do analizowania kursów walut czy też akcji… Jak powinna działać? Tak, jak tego potrzebuje użytkownik w danym momencie. Powinien mieć on kontrolę nad formatem danych np. raz tabelka, a raz wykres. Powinien móc ustalać okres, za który wyświetlane są dane, typ kursu dla waluty jaka go interesuje, wybierać próbkowanie wykresu (miesięcznie, tygodniowo, dziennie), ale także wskazywać listę konkretnych dat. Powinien móc ustalać, ile miejsca zajmuje jego wykres czy tabelka na ekranie i wybierać zakres dla skali x i y. Powinien móc wybrać liczbę miejsc po przecinku i stosowany przelicznik (kurs za 1 jednostkę czy za 100 jednostek). Oprócz kursu wymiany użytkownik powinien móc zobaczyć w tym samym miejscu inne powiązane informacje, jak np. wartości wybranej stopy procentowej, dane finansowe konkretnej spółki czy też inne wskaźniki finansowe. Użytkownik powinien móc kontrolować wyświetlania danych na jednym lub kilku wykresach. Posiadając taką kontrolę użytkownik chętnie i często będzie wracał do narzędzia, które tak bardzo ułatwia mu pracę.

Co dalej?

Zachęcam Was do zagłębienia się w pracę Terry’ego Winograda i Fernando Floresa. Ich książka [1] może być dla Was drogowskazem utwierdzającym w niepopularnych decyzjach. W kolejnym artykule postaram się opisać metodę zbierania wymagań od klientów i użytkowników opartą na tej książce.
Źródła:

1. Winograd, Terry i Flores, Fernando. 1987. Understanding computers and cognition. A New Foundation for Design. Addison-Wesley.
2. Zuboff, Shoshana. 1988. In the age of the smart machine. The future of work and power. BasicBooks.