Prosta krzywa uczenia się

Ucz się ucz…

Podczas projektowania systemów i aplikacji należy pamiętać o czynnikach, które wpływają na proces ich nauki – szybkość i efektywność nauki systemu przez użytkowników końcowych jest kluczowa z punktu widzenia biznesowego. Celem jest przyspieszenie tego procesu i dojście do etapu, w którym system lub aplikacja są obsługiwane niemal automatycznie. Taka automatyzacja w kontekście procesów myślowych oznacza między innymi zminimalizowanie ilości pamięci krótkotrwałej wykorzystywanej podczas korzystania z systemu oraz umożliwienie tzw.  multitaskingu (oznaczającego, że równolegle do obsługi systemu mogą być wykonywane przez użytkownika inne czynności). Wielozadaniowość jest szczególnie istotna właśnie w aplikacjach biznesowych, gdzie użytkownicy muszą wykonywać w tym samym czasie szereg niezależnych zadań np. pracownicy call center poszukują informacji w swoim systemie jednocześnie rozmawiając z klientem przez telefon. Zadaniem projektanta jest stworzenie takiego systemu, którego nauka obsługi zostałaby skrócona do niezbędnego minimum, co przekłada się wymiernie na koszty (pomyłki, czas treningu, itp.).

Jakie zatem czynniki przyspieszają naukę? Jeff Johnson w swojej książce Designing with the mind in mind wskazuje na trzy ważne elementy:

  • Operacje – zorientowane na konkretne zadania, proste i spójne;
  • Słownictwo – zorientowane na konkretne zadania, proste i spójne;
  • Niskie ryzyko.

 

Operacje

Projektant powinien zlikwidować coś, co Donald Norman nazwał gulf of execution tj. różnicę między tym co użytkownik chce zrobić a tym co oferuje mu dane narzędzie. Niezbędne do tego staje się więc zrozumienie celów użytkownika oraz typowych zadań, które będzie wykonywał użytkownik. Aby sprecyzować te wymagania warto zacząć od  analizy zadań, na jej podstawie zbudować konceptualny model aplikacji a następnie zaprojektować na tej podstawie interfejs.

Analiza zadań ma na celu znalezienie odpowiedzi na następujące pytania:  które zadania wykonywane są często a które rzadko, jakie są kolejne kroki poszczególnego zadania, jaki jest wynik każdego zadania itp.

Kiedy znajdziemy już odpowiedzi na te i podobne pytania, można będzie przygotować model konceptualny aplikacji, który określa funkcje aplikacji i który powinien uwzględniać zadania wykonywane przez użytkownika.

Podczas tworzenia modelu konceptualnego warto przeprowadzić analizę obiektów i działań – określa ona, jakie elementy będą widoczne w systemie dla użytkownika oraz jakie działania będzie mógł on na nich wykonywać. W przypadku systemu bankowości elektronicznej podstawowymi elementami – obiektami będą np. konto, rachunek czy transakcja a możliwymi działaniami np. sprawdzenie stanu konta lub przelew na rachunek. Obiekty i działania widoczne dla użytkownika nie mogą być prostym odwzorowaniem obiektów i działań widocznych na poziomie implementacji – użytkownika nie interesują takie obiekty jak bufor, tabela i „string” lub operacje takie jak zaciąganie danych  bazy czy opróżnianie bufora.

Przy tworzeniu modelu konceptualnego warto zadbać aby był tak prosty, jak to możliwe – zbyt rozbudowany model, posiadający wiele obiektów i możliwych  operacji powoduje, że system jest bardziej skomplikowany a co za tym idzie – trudniejszy w nauce.

Inną kluczową kwestią jest zachowanie spójności zarówno na poziomie modelu konceptualnego – aby na podobnych obiektach możliwe były do wykonania takie same operacje. Ważna jest również spójność na poziomie „fizycznego” interfejsu – co oznacza, że te same akcje są wywoływane i kontrolowane w ten sam sposób (chodzi o ustandaryzowanie sposobu wykonywania czynności tego samego typu na poziomie interfejsu – np. jeżeli w aplikacji desktopowej po kliknięciu prawy przycisk myszy na jednym pliku otwiera się menu, a na innym już nie – można mówić o braku spójności na tym poziomie).

 

Słownictwo

Drugim czynnikiem wpływającym na czas potrzebny do nauki systemu jest użyte słownictwo – tutaj również warto pamiętać o tym aby terminologia była zorientowana na zadania, znana użytkownikom oraz spójna.

Pojęcia używane w systemie powinny być informatywne i zorientowane na zadania – tzn.  nieść za sobą zrozumiałą dla użytkownika treść związaną z zadaniem które chce wykonać. Zakres używanego słownictwa można ustalić za pomocą np. wywiadów z użytkownikami. Poza tym ważne jest stosowanie słownictwa, które jest znane dla użytkowników końcowych – nie zmuszajmy ich do nauki  nowych, skomplikowanych, technicznych pojęć. Ich znajomość nie powinna być konieczna do wykonania zadania (o ile oczywiście nie projektujemy np. interfejsu systemu do zarządzania bazami danych).

Słownictwo używane w systemie powinno być spójne –  te same elementy powinny być tak samo nazwane oraz tak samo nazwane elementy powinny oznaczać te same rzeczy. Jeżeli wprowadzimy do systemu różne nazwy dla oznaczenia tych samych elementów lub jeśli jedno pojęcie będzie stosowane do oznaczenia różnych rzeczy to  wpłynie to negatywnie na proces nauki oraz możliwe pomyłki.

 

Ryzyko

Kolejną kwestią ułatwiającą naukę jest zaprojektowanie systemu, który zapobiega błędom, wybacza błędy już popełnione oraz daje możliwość wycofania się z pomyłki. Taki system redukuje stres i zachęca do jego eksploracji – poznawania nowych funkcji i tym samym bardziej efektywnego korzystania z systemu. I odwrotnie –  użytkownicy nie będą chcieli uczyć się systemu ze świadomością, że jeżeli popełnią pomyłkę to może ona być trudna do skorygowania.

Wymienione przez Johnsona czynniki nie wyczerpują oczywiście listy – oprócz nich istnieje szereg innych elementów (często zewnętrznych i niezależnych od projektanta) które wpływają na to jak szybko użytkownicy uczą się obsługi systemu czy aplikacji. Niemniej te wyżej wymienione pozostają w zasięgu wpływu projektanta i tylko od niego zależy czy za ich pomocą uprościmy czy utrudnimy naukę systemu.

 

0 odpowiedzi

Odpowiedz

Want to join the discussion?
Feel free to contribute!

Dodaj komentarz

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