Pomoc kontekstowa w aplikacji
Załóżmy, że jesteśmy citizen developerami i właśnie zbudowaliśmy na platformie no-codowej aplikację dla naszej firmy. Pokazaliśmy ją prezesowi, głównemu interesariuszowi, księgowej – wszystkim aplikacja się bardzo podobała. Nasze wyjaśnienie jak jej używać zostały przyjęte ze zrozumieniem. Pełni optymizmu chcemy od nowego tygodnia uruchamiać naszą aplikację produkcyjnie, ale nagle odzywa się jeden z pracowników działu, który ma używać aplikacji z pytaniem: „A co z pomocą dla użytkownika?”
Po co stosować pomoc kontekstową?
Pytanie z wymyślonej scenki otwierającej ten artykuł jest bardzo istotne. Skąd użytkownik ma wiedzieć, jak należy używać naszej aplikacji? Oczywiście możemy powiedzieć, że zrobimy szkolenia, napiszemy podręcznik użytkownika, uruchomimy helpdesk. Tyle, że to zajmuje czas oraz generuje koszty. Zamiast zatrudniać pracownika helpdesku, który 10 razy dziennie będzie odpowiadał na to samo pytanie, lepiej tak skonstruować nasz system, by użytkownik znalazł odpowiedź sam. Zacząć należy od prawidłowego skonstruowania systemu, zgodnie z wytycznymi User Experience, jednak to często nie wystarcza. Trzeba również dodać do systemu pomoc kontekstową w miejscach, w których przewidujemy potencjalne trudności.
Jaka może być pomoc kontekstowa?
Jeżeli przemyśleliśmy całą koncepcję aplikacji jeszcze raz i doszliśmy do wniosku, że należy dodać pomoc kontekstową, nawet już wytypowaliśmy na nią miejsca, to ostatnim krokiem jest wymyślenie, jak taka pomoc powinna wyglądać. Różne systemy pozwalają na użycie różnych mechanizmów udostępniania pomocy kontekstowej. Nie będziemy się zajmowali metodami, w których po wybraniu opcji z menu następuje przekierowanie do dokumentacji ogólnej. Takie rozwiązania, popularne w poprzednich generacjach aplikacji, nie powinny być dziś stosowane.
Do najpopularniejszych metod pokazywania pomocy należą:
- Podpowiedź w „chmurce”, która pokazuje się po najechaniu kursorem myszy na element.
- Podpowiedź pod ikonką. Przy etykiecie pola wyświetlona jest ikonka, najczęściej z literą „i”, która pokazuje, że system ma dla nas jakieś dodatkowe informacje. Po kliknięciu na ikonę pojawia się okno z tekstem podpowiedzi.
- Podpowiedź pod etykietą. Tekst, z reguły pisany mniejszymi literami i wyróżniony graficznie, jest cały czas widoczny na ekranie.
- Podpowiedź w polu. Tego typu podpowiedź stosuje się z reguły do pól w których wprowadzamy tekst. Podpowiedź znika, gdy zaczynamy wprowadzać wartość do pola.
Którą wersję podpowiedzi powinniśmy użyć, oczywiście zakładając, że nasz system posiada je wszystkie? To zależy. Inaczej będziemy chcieli pokazać krótką podpowiedź typu „Wprowadź wartość zgodnie z instrukcją kancelaryjną”, a inaczej dłuższy fragment, np. cytat ze wspomnianej instrukcji. Zaletą podpowiedzi pod etykietą czy w polu jest to, że jest zawsze widoczna (przynajmniej do czasu aż nie uzupełnimy pola), zaletą wyskakujących okienek jest z reguły więcej miejsca, co pozwala na umieszczenie dłuższego tekstu.
Dla kogo jest pomoc kontekstowa?
Zanim zaczniemy pisać naszą pomoc poświęćmy jeszcze chwilę na zastanowienie się – kto będzie korzystał z naszego systemu. „Ale po co, czy to ma jakieś znacznie?” możecie zapytać. Oczywiście, że ma. Popatrzmy na dwa skrajne przypadki:
- System wewnętrzny, do codziennej pracy działu HR czy księgowości. Po tygodniu pracy użytkownicy biegle się po nim poruszają, a po miesiącu znają go na pamięć. Pomoc potrzebna jest głównie dla nowych pracowników oraz w miejscach rzadziej używanych lub sprawiających więcej trudności.
- System zewnętrzny służący, np. do rekrutacji. Tu każdy użytkownik jest nowy i raczej nie używa systemu wielokrotnie. W takim przypadku potrzebna pomoc powinna być znacznie bardziej rozbudowana i zawierać elementy, które nam mogą się wydawać oczywiste, ale niekoniecznie takie są dla osoby z zewnątrz. Należy również pamiętać, że systemy wystawione dla użytkowników zewnętrznych są wizytówką naszej firmy, jeżeli poprzez brak pomocy i niezrozumienie aplikacji użytkownik zrezygnuje, nasza firma może stracić potencjalnego klienta lub dobrego pracownika.
Projektując system pomocy, należy uwzględnić grupę docelową. Nie zawsze będą to tak skrajne grupy jak w przykładach powyżej, ale nawet wśród pracowników będą osoby o różnym zakresie kompetencji. Weźmy popularny system do obiegu faktur czy innych dokumentów zakupowych. Jedną z grup użytkowników będą pracownicy księgowości, drugą – pracownicy działów merytorycznych (zakupy, produkcja). Należy tak przygotować system pomocy, by wszystkie grupy zrozumiały, jak używać systemu. Nawet jeżeli coś jest oczywiste dla księgowości, może nie być oczywiste dla produkcji.
Co powinna zawierać pomoc?
Pzejdźmy do konkretów. Co powinna zawierać wzorcowa podpowiedź? Odpowiedź wydaje się oczywista – kompleksowe omówienie tematu. Ale jak to zrobić, gdy mamy do dyspozycji dwie linijki tekstu? Pogrupujmy dobre rady:
- Popatrzmy, ile mamy informacji do przekazania i dostosujmy formę prezentacji do ilości informacji. Dla małych podpowiedzi dodajmy je pod etykietą, dla większych używajmy dymków lub wyskakujących okienek.
- Stopniujmy informację. W podpowiedzi nie musi być przepisana cała instrukcja użytkownika. Zgodnie z zasadą Pareto, 80% użytkowników wystarczy 20% instrukcji, by prawidłowo używać systemu. Nie przeciążajmy ich nadmiarem informacji. Zamiast tego warto dodać odwołanie do obszerniejszej dokumentacji poprzez link osadzony w podpowiedzi.
- Nie zapominajmy o prostych podpowiedziach typu „Data powrotu musi być większa od daty wyjazdu”. Unikniemy dzięki temu pytań w stylu „Dlaczego system pokazuje błąd/nie pozwala zapisać dokumentu”?
- Pamiętajmy o przykładach. Jeden przykład użycia opcji jest więcej wart niż 10 stron tekstu.
- Multimedia. Ktoś kiedyś powiedział, że jeden obraz wart jest tysiąca słów. Jeżeli Wasz system pozwala na dołączanie grafiki do podpowiedzi – używajcie tej opcji.
- Filmy. Zobaczenie czegoś na przykładzie nagranym na filmie z pewnością pozwoli na lepsze zrozumienie działania systemu.
Czego unikać przy tworzeniu pomocy kontekstowej?
Mamy zatem cały projekt pomocy, przygotowaliśmy podpowiedzi do każdego pola na formularzu… I nagle zaczynamy się zastanawiać, czy nie przesadziliśmy? Mamy kilkadziesiąt podpowiedzi które wyskakują użytkownikowi z różnych miejsc, do jednego pola mamy po kilka podpowiedzi (małą pod etykietą, większą pod ikoną). Spójrzmy krytycznym okiem na to, co przygotowaliśmy i zastanówmy się czego nie robić w systemie podpowiedzi. Najlepiej unikać następujących elementów:
- Nie dodawajmy trywialnych podpowiedzi. Jeżeli mamy pole „Data zdarzenia” to podpowiedź „Podaj datę zdarzenia” nic nie wnosi.
- Z drugiej strony, nie dodawajmy podpowiedzi zbyt obszernych. Jeżeli mamy wyskakujące okno, a w nim trzy strony tekstu, to mogę się założyć, że nikt tego tekstu nie przeczyta. Skracajmy teksty do najważniejszych informacji i dawajmy linki do pełnej dokumentacji.
- Unikajmy zbyt wielu podpowiedzi. Czy naprawdę potrzebujemy podpowiedzi do wszystkich pól? Może wystarczy podpowiedź przy etykiecie grupy?
- Pamiętajmy o formatowaniu podpowiedzi. Jeżeli system umożliwia użycie np. HTML-a do pogrubiania czy wypunktowania elementów – używajmy ich.
Komputer to nie wszystko
Na koniec warto zwrócić uwagę na fakt, że współczesne systemy informatyczne to nie tylko aplikacje na komputer. Używamy ich na tabletach, telefonach, generalnie na urządzeniach z mniejszym ekranem. Projektując system podpowiedzi należy uwzględnić ten fakt. Oczywiście należy przygotować kompromis między jakością podpowiedzi, a prezentacją na urządzeniach mobilny. Przed udostępnieniem aplikacji użytkownikowi sprawdźmy, jak nasza aplikacja zachowa się na tego typu urządzeniach.
Podsumowanie
Jak widzimy, system podpowiedzi kontekstowej jest niezwykle istotnym, choć często pomijanym, aspektem przygotowania aplikacji dla użytkownika. Bywa niestety tak, że zostawia się go na ostatnią chwilę i dorabia na samym końcu procesu tworzenia aplikacji.
Poprawne przygotowanie aplikacji dla użytkownika powinno zawierać przygotowanie pomocy kontekstowej projektowanej od samego początku, równolegle z tworzeniem samej aplikacji. Dobrze przygotowany system pomocy pozwoli w przyszłości usprawnić proces wdrażania i uruchamiania systemu, obniży koszty utrzymania systemu poprzez mniejszą liczbę zgłoszeń czy pytań od użytkowników.
Absolwent Uniwersytetu Jagiellońskiego na kierunku Informatyka, Wydział Matematyki i Fizyki. W firmie pełni rolę analityka i specjalisty ds. kontroli jakości. Specjalizuje się w modelowaniu procesów biznesowych, projektowaniu systemów informatycznych czy opisie wymagań biznesowych. Posiada prawie 20 letnie doświadczenie jako projektant systemów informatycznych i analityk systemowy, prowadził także duże projekty budowy i wdrożeń systemów informatycznych w obszarze finansowo – księgowym. Jest wykładowcą Wyższej Szkoły Ekonomii i Informatyki w Krakowie, dzieląc się ze studentami wiedzą z obsługi systemów obiegu dokumentów na przykładzie NAVIGATORA.
