Skocz do linków, Skocz do treści

Potęga instrukcji obsługi

9 października 2006 9:57. Autor: Robert Drózd. 5 komentarzy

Pewna rzecz mnie zastanowiła, gdy czytałem komentarze do artykułu o edytorach WYSIWYG.

Czy nie zapominamy czasami o instrukcji do naszego wspaniałego systemu?

Tak, jedno z podstawowych praw użyteczności brzmi: jeśli Twoja strona wymaga instrukcji obsługi, to na pewno jest zbyt trudna w obsłudze.

Np. Jacob Nielsen w artykule o paradoksie aktywnego użytkownika twierdzi:

Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don’t care about the system as such and don’t want to spend time up front on getting established, set up, or going through learning packages.

Od każdego prawa istnieją jednak wyjątki. Gdy tworzymy jakikolwiek serwis wewnętrzny, dla firmy czy instytucji, instrukcja dla użytkownika jest sprawą niezbędną. Tutaj po prostu bliżsi jesteśmy tradycyjnej aplikacji niż stronie WWW.

To nic, że intranet stworzyliśmy mega-intuicyjny, że nasz CMS zrozumie nawet dziecko, że przy każdym formularzu umieściliśmy dodatkowe podpowiedzi.

Specyfiką pracy w dużych firmach i właściwie każdej instytucji państwowej jest ścisłe opieranie się na procedurach i szablonach. Urzędnik czy też pracownik niższego szczebla nie jest zachęcany do wykazywania inicjatywy, ma raczej wykonywać to co do niego należy i nic ponad to.

Co jeśli takiej osobie damy system, w którym nie jest ograniczona przez procedury? Ano może stać się jedna z dwóch rzeczy:

  1. Będzie unikać używania systemu. „Bo jeszcze, broń Boże, coś zepsuję.” Albo: „nie mam głowy na uczenie się tego”. Ostatecznie taka osoba zadzwoni do firmowego informatyka, żeby zrobił to za nią.
  2. Będzie tego systemu nadużywać. Czyli kolorowy tekst, szlaczki, pola wypełnione na opak. Ustne zwrócenie uwagi bardzo rzadko działa, a może i wywołać reakcję obronną. Bo on wie lepiej.

Dlatego potrzebujemy instrukcji, która łopatologicznie, krok po kroku przedstawia wszystko co użytkownik może zrobić w systemie. Tego nie załatwi nawet najlepsze szkolenie, bo informacje ze szkolenia wylatują z głowy, a z systemu trzeba będzie skorzystać np. po pół roku. Poza tym przy pewnej rotacji może się okazać, że po roku w danym dziale nie będzie już ani jednej osoby, która pracowała w momencie szkolenia.

Widziałem czasami instrukcje przygotowane przez samych użytkowników, do systemów, których twórcy o instrukcji zapomnieli. Podstawową zasadą było w nich „minimum myślenia”. Mechanicznie robisz A, potem B, potem C. No i podobnie powinna wyglądać nasza instrukcja.

  1. Ewentualna decyzja (np. co chcę zrobić w systemie) na samym początku. Potem użytkownik ma wejść w ciąg czynności, którego już nie przerywa innymi dylematami. :-)
  2. Nie piszmy czego nie można robić, bo i tak użytkownicy to zrobią. Przykładem może być zakaz używania WIELKICH LITER w tytułach newsów.
  3. Jeśli się da, podawajmy przykłady, z których można bezpośrednio kopiować.
  4. Prawie każdy pracownik biurowy uwielbia ilustracje i wyróżnienia w tekście (nawet nadmiarowe).
  5. Jednak dodając przykłady i ilustracje nie zapominajmy o konieczności utrzymania użytkownika w ciągu!
  6. Dobrym pomysłem jest dodatkowa ściągawka z najważniejszych funkcji: człowiek taką ściągawkę drukuje, łamie stronę na pół i przykleja obok monitora.

Dokument, który przygotowaliśmy musi zatwierdzić oczywiście przedstawiciel klienta. Zwykle przeczyta pobieżnie (kto ma na to czas?) i – albo przyczepi się do jakiegoś drobiazgu, albo stwierdzi, że ogólnie jest OK. Następnie instrukcję otrzymują pracownicy i dla nich jest już pismem uświęconym przez kierownictwo. Można na takie pismo narzekać, ale się go nie kwestionuje.

Tutaj praktyczny wniosek dla projektantów: jeśli wiemy że w systemie jest etap, w którym użytkownik może zepsuć coś co zaprojektowaliśmy, a nie jesteśmy w stanie mu przeszkodzić – wtedy do tego etapu musimy dodać jak najbardziej szczegółową instrukcję. Użytkownik przestanie myśleć, a da się prowadzić, dokładnie tak jak tego chcemy.

Podobne artykuły:

Być może zainteresują Cię następujące artykuły:

Zapisz się na kanał RSS bloga i dołącz do ponad 1500 czytelników RSS.

Zostań fanem WebAudit na Facebooku.

Komentarze czytelników

Śledź komentarze do tego artykułu: format RSS
  1. krst.

    Hmm, uwaga słuszna oczywiście, ale jak zwykle – łatwiej powiedzieć niż zrobić. Z mojego doświadczenia wynika, że instrukcja dla bardziej złożonych systemów, szczególnie takich które będą używane z wymogu a nie z chęci, jest elementem krytycznym. I jednocześnie jest jednym z trudniejszych i tym samym droższych do wyprodukowania. Kiepska instrukcja może wyrządzić więcej złego niż dobrego (jeśli tego nie ma w instrukcji, tzn że nie da się tego zrobić),a dobrą jest wbrew pozorom ciężko zrobić. Z drugiej strony gdy trzeba ciąć budżet lub deadline’y, pomoc wylatuje jako pierwsza. Wg. mnie dobrym pomysłem jest poprowadzenie użytkownika za rękę przez pierwsze kilka kroków tak, żeby wiedział jak zacząć (chociażby w formie krótkiego filmiku pokazującego co klikać) i nie zagłębianie się w szczegóły, tak żeby nikt nie miał wątpliwości że to tylko takie pierwsze 3 kroki, a nie kompletna instrukcja. Zrobienie czegoś takiego nie jest specjalnie cięzkie/drogie, pokazuje jak zacząć i nie sprawia wrażenia kompletnej instrukcji, dzięki czemu użytkownik wie że jak czegoś tu nie znalazł to powinien sam poszukać albo zapytać.

  2. Michał Stempień

    No proszę, a właśnie przedwczoraj mieliśmy w firmie dyskusję na ten temat. Tworzysz klientowi CMSa, dajesz WYSIWYGa, a on potem, albo psuje stronę, albo pisze, żeby zrobić to za niego, bo sobie nie radzi.

    Zamiast instrukcji proponuje zrobić screencasta, jest łatwiejszy do przełknięcia, szybszy do zrobienia niż pisanie instrukcji, a i może spowoduje, że klient nie będzie eksperymentował z czymś czego nie pokażemy dokładnie w filmiku.

  3. Mikołaj

    Zapomnieliście o jednym — w wielu przypadkach warto wprowadzić standardowe dokumenty firmowe, sformatowane do potrzeb WWW i CMS-a. Jeśli w systemie jest opcja „kopiuj”, to wystarczy zatytułować dokumenty odpowiednio [„WZÓR okólnika o płacach” czy „WZÓR zarządzenia o wolnej sobocie”] i gotowe.
    Niech użytkownik to kopiuje, a po skopiowaniu podstawi odpowiednie daty, nazwiska etc., dokładnie tak jak w większości instytucji produkuje się kolejne dokumenty w Wordzie. Tłumaczenie ograniczone do minimum, możliwość pomyłek także niewielka, a zawsze kolejne wzory można dodać.

  4. alw

    Moim zdaniem i Robert ma rację, z instrukcjami, i Mikołaj z szablonami, Gorzej po części z propozycją Michała gdyż o ile instrukcja i szablon są proste i łatwe do opanowania, o tyle z filmikami instruktażowymi bywa różnie z racji selektywnego zapamietywania a i utrudnienia w powrocie do odpowiedniego fragmenciku. Czytany tekst zapamietujemy dużo lepiej i sprawniej.

  5. Robert Drózd

    Nigdy nie miałem do czynienia ze screencastami, wydają się świetnym pomysłem, szczególnie gdy operacje w systemie mają być bardziej skomplikowane niż wypełnienie formularza.

    Natomiast raczej nie zastępowałbym filmikiem drukowanej instrukcji. Już lepiej, gdy czas nagli, wydrukować 2 kartki z pierwszymi krokami (jak sugeruje krst), niż nie przygotować nic.

    Sam film sprawy nie rozwiązuje, bo dla wielu użytkowników (cały czas mówimy o pracownikach biur i urzędów) już sam ekran komputera to bariera „innego świata”, pomoc, która w tym innym świecie się znajduje, nie pomaga.

    Może nie do końca miarodajny (ale dla mnie tak) był test, jaki przeprowadziliśmy z kolegami parę lat temu. Był sobie intranet, który dzielił się na niezależne moduły. Każdy moduł miał instrukcję w PDF do pobrania i wydrukowania. Poza jednym – dla którego zrobiliśmy po prostu pomoc w postaci instrukcji do przeglądania online. Efekt był nieprzypadkowy: najwięcej problemów i uwag ze strony userów mieliśmy właśnie tam, gdzie nie było instrukcji drukowanej.

Zostaw komentarz

W komentarzu można (choć nie trzeba) używać podstawowych znaczników XHTML. Komentarze zawierające w podpisie słowa kluczowe mogą zostać potraktowane jako spam i usunięte.