Prosta krzywa uczenia się

Ucz się ucz…

Pod­czas pro­jek­towa­nia sys­temów i aplikacji należy pamię­tać o czyn­nikach, które wpły­wa­ją na pro­ces ich nau­ki – szy­bkość i efek­ty­wność nau­ki sys­te­mu przez użytkown­ików koń­cowych jest kluc­zowa z punk­tu widzenia biz­ne­sowego. Celem jest przyspiesze­nie tego pro­ce­su i dojś­cie do eta­pu, w którym sys­tem lub aplikac­ja są obsługi­wane niemal automaty­cznie. Taka automatyza­c­ja w kon­tekś­cie pro­cesów myślowych oznacza między inny­mi zmin­i­mal­i­zowanie iloś­ci pamię­ci krótkotr­wałej wyko­rzysty­wanej pod­czas korzys­ta­nia z sys­te­mu oraz umożli­wie­nie tzw.  mul­ti­task­ingu (oznacza­jącego, że równole­gle do obsłu­gi sys­te­mu mogą być wykony­wane przez użytkown­i­ka inne czyn­noś­ci). Wielozadan­iowość jest szczegól­nie istot­na właśnie w aplikac­jach biz­ne­sowych, gdzie użytkown­i­cy muszą wykony­wać w tym samym cza­sie szereg nieza­leżnych zadań np. pra­cown­i­cy call cen­ter poszuku­ją infor­ma­cji w swoim sys­temie jed­nocześnie roz­maw­ia­jąc z klien­tem przez tele­fon. Zadaniem pro­jek­tan­ta jest stworze­nie takiego sys­te­mu, którego nau­ka obsłu­gi została­by skró­cona do niezbęd­nego min­i­mum, co przekła­da się wymiernie na kosz­ty (pomył­ki, czas treningu, itp.).

Jakie zatem czyn­ni­ki przyspiesza­ją naukę? Jeff John­son w swo­jej książce Design­ing with the mind in mind wskazu­je na trzy ważne ele­men­ty:

  • Oper­ac­je — zori­en­towane na konkretne zada­nia, proste i spójne;
  • Słown­ict­wo — zori­en­towane na konkretne zada­nia, proste i spójne;
  • Niskie ryzyko.

 

Oper­ac­je

Pro­jek­tant powinien zlik­wid­ować coś, co Don­ald Nor­man nazwał gulf of exe­cu­tion tj. różnicę między tym co użytkown­ik chce zro­bić a tym co ofer­u­je mu dane narzędzie. Niezbędne do tego sta­je się więc zrozu­mie­nie celów użytkown­i­ka oraz typowych zadań, które będzie wykony­wał użytkown­ik. Aby spre­cy­zować te wyma­gania warto zacząć od  anal­izy zadań, na jej pod­staw­ie zbu­dować kon­cep­tu­al­ny mod­el aplikacji a następ­nie zapro­jek­tować na tej pod­staw­ie inter­fe­js.

Anal­iza zadań ma na celu znalezie­nie odpowiedzi na następu­jące pyta­nia:  które zada­nia wykony­wane są częs­to a które rzad­ko, jakie są kole­jne kro­ki poszczegól­nego zada­nia, jaki jest wynik każdego zada­nia itp.

Kiedy zna­jdziemy już odpowiedzi na te i podob­ne pyta­nia, moż­na będzie przy­go­tować mod­el kon­cep­tu­al­ny aplikacji, który określa funkc­je aplikacji i który powinien uwzględ­ni­ać zada­nia wykony­wane przez użytkown­i­ka.

Pod­czas tworzenia mod­elu kon­cep­tu­al­nego warto przeprowadz­ić anal­izę obiek­tów i dzi­ałań – określa ona, jakie ele­men­ty będą widoczne w sys­temie dla użytkown­i­ka oraz jakie dzi­ała­nia będzie mógł on na nich wykony­wać. W przy­pad­ku sys­te­mu bankowoś­ci elek­tron­icznej pod­sta­wowy­mi ele­men­ta­mi – obiek­ta­mi będą np. kon­to, rachunek czy transakc­ja a możli­wy­mi dzi­ała­ni­a­mi np. sprawdze­nie stanu kon­ta lub przelew na rachunek. Obiek­ty i dzi­ała­nia widoczne dla użytkown­i­ka nie mogą być prostym odw­zorowaniem obiek­tów i dzi­ałań widocznych na poziomie imple­men­tacji – użytkown­i­ka nie intere­su­ją takie obiek­ty jak bufor, tabela i „string” lub oper­ac­je takie jak zacią­ganie danych  bazy czy opróż­ni­an­ie bufo­ra.

Przy tworze­niu mod­elu kon­cep­tu­al­nego warto zad­bać aby był tak prosty, jak to możli­we – zbyt rozbu­dowany mod­el, posi­ada­ją­cy wiele obiek­tów i możli­wych  oper­acji powodu­je, że sys­tem jest bardziej skom­p­likowany a co za tym idzie – trud­niejszy w nauce.

Inną kluc­zową kwest­ią jest zachowanie spójnoś­ci zarówno na poziomie mod­elu kon­cep­tu­al­nego – aby na podob­nych obiek­tach możli­we były do wyko­na­nia takie same oper­ac­je. Waż­na jest również spójność na poziomie „fizy­cznego” inter­fe­j­su – co oznacza, że te same akc­je są wywoły­wane i kon­trolowane w ten sam sposób (chodzi o ustandary­zowanie sposobu wykony­wa­nia czyn­noś­ci tego samego typu na poziomie inter­fe­j­su – np. jeżeli w aplikacji desk­topowej po kliknię­ciu prawy przy­cisk myszy na jed­nym pliku otwiera się menu, a na innym już nie – moż­na mówić o braku spójnoś­ci na tym poziomie).

 

Słown­ict­wo

Drugim czyn­nikiem wpły­wa­ją­cym na czas potrzeb­ny do nau­ki sys­te­mu jest użyte słown­ict­wo – tutaj również warto pamię­tać o tym aby ter­mi­nolo­gia była zori­en­towana na zada­nia, znana użytkown­ikom oraz spój­na.

Poję­cia uży­wane w sys­temie powin­ny być infor­maty­wne i zori­en­towane na zada­nia – tzn.  nieść za sobą zrozu­mi­ałą dla użytkown­i­ka treść związaną z zadaniem które chce wykon­ać. Zakres uży­wanego słown­ict­wa moż­na ustal­ić za pomocą np. wywiadów z użytkown­ika­mi. Poza tym ważne jest stosowanie słown­ict­wa, które jest znane dla użytkown­ików koń­cowych – nie zmusza­jmy ich do nau­ki  nowych, skom­p­likowanych, tech­nicznych pojęć. Ich zna­jo­mość nie powin­na być koniecz­na do wyko­na­nia zada­nia (o ile oczy­wiś­cie nie pro­jek­tu­je­my np. inter­fe­j­su sys­te­mu do zarządza­nia baza­mi danych).

Słown­ict­wo uży­wane w sys­temie powin­no być spójne –  te same ele­men­ty powin­ny być tak samo nazwane oraz tak samo nazwane ele­men­ty powin­ny oznaczać te same rzeczy. Jeżeli wprowadz­imy do sys­te­mu różne nazwy dla oznaczenia tych samych ele­men­tów lub jeśli jed­no poję­cie będzie stosowane do oznaczenia różnych rzeczy to  wpłynie to negaty­wnie na pro­ces nau­ki oraz możli­we pomył­ki.

 

Ryzyko

Kole­jną kwest­ią ułatwia­jącą naukę jest zapro­jek­towanie sys­te­mu, który zapo­b­ie­ga błę­dom, wybacza błędy już popełnione oraz daje możli­wość wyco­fa­nia się z pomył­ki. Taki sys­tem reduku­je stres i zachę­ca do jego eksplo­racji – poz­nawa­nia nowych funkcji i tym samym bardziej efek­ty­wnego korzys­ta­nia z sys­te­mu. I odwrot­nie —  użytkown­i­cy nie będą chcieli uczyć się sys­te­mu ze świado­moś­cią, że jeżeli popełnią pomyłkę to może ona być trud­na do sko­ry­gowa­nia.

Wymienione przez John­sona czyn­ni­ki nie wycz­er­pu­ją oczy­wiś­cie listy – oprócz nich ist­nieje szereg innych ele­men­tów (częs­to zewnętrznych i nieza­leżnych od pro­jek­tan­ta) które wpły­wa­ją na to jak szy­bko użytkown­i­cy uczą się obsłu­gi sys­te­mu czy aplikacji. Niem­niej te wyżej wymienione pozosta­ją w zasięgu wpły­wu pro­jek­tan­ta i tylko od niego zależy czy za ich pomocą uprościmy czy utrud­nimy naukę sys­te­mu.

 

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 *