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.

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

  • www.kajzarowie.net

    Witaj!
    Świetny artykuł. Prosty i jasny. Dawane kontroli użytkownikowi rzeczywiście nie jest obecnie popularne, co boleśnie odczuwam, jako użytkownik różnych systemów.
    Myślę, że najtrudniejszą rzeczą jest wyważenie między dawaniem użytkownikowi kontroli a bezpieczeństwem spójności danych oraz właściwą porcją automatyzacji powtarzających się procesów.

    Odpowiedz
  • Łukasz Kuźba

    Łukaszu czekalem na te przyklady. To o czym piszesz to nic innego jak projektowanie skupione na użytkowniku. Patrząc szerzej na temat szeroko rozumianej analizy – żadna nowość.

    Odpowiedz
    • modelowanieiuzytecznosc

      Jest jednak pewna subtelna różnica. Chodzi o projektowanie skupione na
      użyciu, a nie na użytkowniku. Chciałem się odciąć od tego kto konkretnie
      używa oprogramowania i skupić na tym jaką pracę wykonuje.
      Chodzi mi o
      możliwość używania oprogramowania na różne sposoby przez dowolnych
      użytkowników. Nie musimy wiedzieć jacy dokładnie są nasi użytkownicy ani
      jakie mają preferencje. Raczej musimy wiedzieć jakie zadania będą
      realizowane i oddać pełną kontrolę użytkownikom. W praktyce bardzo
      brakuje takiej kontroli.
      Książka Winograda i Floresa jest z 1988r.
      Jednak tradycja, w której my wszyscy żyjemy utrudnia nam zrozumienie
      idei przekazywanych przez ich autorów.
      Zresztą nie twierdzę, że to co
      piszę to nowość. Dla mnie to było odkrycie ostatnich miesięcy i wydaje
      mi się, że to jednak nie jest powszechny sposób myślenia. Uważam wręcz,
      że nikt i nigdzie nie daje pełnej kontroli użytkownikom. Mam nadzieję,
      że jednak się mylę:) Przykładowo nawet teraz nie mogę opublikować tej
      odpowiedzi bez zalogowania się chociaż wolałbym nie musieć tego robić.

      Odpowiedz
      • Łukasz Kuźba

        Czyli uwazasz ze projektowanie skupione na użytkowniku nie jest projektowaniem skupionym rowniez na użyciu? 🙂 Ciekawe. Wyjasnij mi prosze różnice i dlaczego są to dwie różne (?) rzeczy.

        Odpowiedz
        • modelowanieiuzytecznosc

          Usage Centered Design czyli projektowanie skupione na użyciu to konkretna metodologia stworzona przez Larry’ego Constantines. User-centered Design reprezentuje zmianę kierunku myślenia z technologicznego na ludzi, z interfejsów użytkownika na użytkowników. User-centered Design pozwolił na to, że powstają niesłychanie bardziej użyteczne narzędzia. Larry Constantines twierdzi jednak, że to nie użytownicy powinni być zrozumieni ale użycie narzędzi powinno być zrozumiane. Oba rodzaje projektowania pomagają zwiększać użyteczność oprogramowania ale wydaje mi się, że większe możliwości daje Usage Centered Design.
          Zobacz co na ten temat pisze Donald Norman:
          http://www.jnd.org/dn.mss/human-centered_desig.html
          Więcej i bardziej konkretnie możesz znaleźć w ‚Software for use’ Larry’ego Constantines.

          Odpowiedz
          • Łukasz Kuźba

            Super pojecia, tylko co one wnoszą? Spojrz na praktykę. Otrzymasz wielki mix tego wyżej i innych rzeczy.

  • Mateusz Dylong

    Interesujący artykuł, ale nie jestem przekonany, czy oddanie pełnej kontroli nad oprogramowaniem użytkownikowi naprawdę wspomaga jego użyteczność. Użytkownik młotka nie kupuje narzędzia z myślą o jego różnorakich zastosowaniach, ale z myślą o wbijaniu gwoździ. Do tego równie dobrze nadaje się but, jeśli akurat jest pod ręką 🙂
    Jak mówi zasada 80/20, 80% możliwości dostarczanych przez oprogramowanie będzie wykorzystywane jedynie przez 20% użytkowników, więc warto rozważyć, które z parametrów powinny być modyfikowalne przez użytkownika oraz jakie domyślne wartości do parametrów przypisać, aby zadowolić jak największą rzeszę użytkowników.
    A do tego wszystkiego potrzebne są badania z udziałem użytkowników, więc może warto w niektórych projektach część środków przenieść w stronę badań i testów zamiast planować możliwość parametryzacji wszystkiego.
    Polecam „Prostotę i użyteczność” Gilesa Colborne’a. Krótkie i przystępne wprowadzenie do różnych strategii organizacji funkcjonalności aplikacji 🙂

    Odpowiedz
    • modelowanieiuzytecznosc

      Masz rację jeżeli chodzi o ustalanie priorytetów. Nie wiem jednak czy warto się kierować tak ogólną zasadą jak 80/20 do ustalania wymagań. Wydaje mi się, że sama w sobie nic nie mówi. Badania z pewnością dałyby lepsze zrozumienie zadań jakie mają być wykonywane przez użytkowników. Dzięki za polecenie książki. Daj znać jakie jeszcze pozycje warto przeczytać.

      Odpowiedz

Leave a comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *