DZIELIMY SIĘ WIEDZĄ
18 października 2021
10 zasad tworzenia aplikacji 'user friendly’ czyli dlaczego standardy budowania obiegów sprawiają, że szkolenie użytkownika nie jest konieczne
Z artykułu dowiesz się, m.in.:
- dlaczego narzucony standard realizacyjny zwiększa efektywność pracowników wykorzystujących systemy workflow,
- o co warto zadbać, by intuicyjność WEBCON BPS była dla użytkowników największą korzyścią,
- do czego prowadzi mieszanie nazewnictwa w konkretnych obiegach.
Jedną z kluczowych cech platformy WEBCON BPS jest jej elastyczność. Tego typu narzędzia umożliwiają rozwiązanie konkretnych problemów na co najmniej kilka sposobów. Każdy konsultant projektujący procesy w WEBCON BPS ma swój wypracowany styl kreowania obiegów. To, że jest on optymalny do zastosowania u jednego klienta nie oznacza, że jest najlepszym rozwiązaniem w przypadku innego przedsiębiorstwa. Wszystko zależy od oczekiwań klientów i kreatywności w wykorzystaniu platformy.
Temat jeszcze bardziej komplikuje się, gdy za implementacje różnych obiegów odpowiedzialni są różni konsultanci. Wtedy – bez odpowiedniego planu implementacji – w ramach jednego systemu powstaną niespójne rozwiązania. Jakie będą tego konsekwencje? Użytkownik pracujący w aplikacjach wytwarzanych przez różnych konsultantów będzie musiał się przełączać, tak jakby były to aplikacje różnych producentów. W efekcie może czuć się zagubiony. Co więc zrobić, aby nie narażać klienta na to, by pracownicy działali nieefektywnie wskutek braku porządku i narzuconego standardu realizacyjnego?
Intuicyjność Webcon BPS sprawia, że użytkownikom łatwo przychodzi uruchomienie kolejnych aplikacji. Przy narzuconym standardzie realizacyjnym przychodzi to jeszcze łatwiej. Na co więc zwrócić uwagę?
1. Ustal, jaki będzie układ formularza. Przykładowe pytania, które warto sobie zadać to, np.:
- w jakich przypadkach stosowane są grupy i zakładki,
- gdzie znajdują się obszary załączników,
- czy domyślnie na wejściu do formularza wyświetla się podgląd ostatniego załącznika,
- czy wyświetlany jest obszar szczegółów zadania.
2. Ustal, jaki ma być charakter formularza:
- dynamiczny, w którym pola chowają się w zależności od kontekstu,
- sztywny, w którym, jeśli pole jest niepotrzebne w danym kontekście, to się dezaktywuje, ale jednak formularz pozostaje w sztywnym układzie.
3. Ustal kolorystykę i ułożenie przycisków ścieżek.
W swoich wdrożeniach zwykle przyjmujemy, że przyciski akceptujące/kierujące obieg dalej są ułożone od lewej strony formularza i oznaczone kolorem zielonym. Przyciski, które cofają obieg są żółte, a te, które go anulują, oznaczone są kolorem czerwonym.
4. Nadawaj krokom nazwy odwzorowujące jego status lub czynności i zadania realizowane w danym kroku.
Unikaj mieszania nazewnictwa i wplatania w nie nazwy grupy osób odpowiedzialnych za czynność. Bądź konsekwentny. Nazwy typu “wprowadzanie 1”, “wprowadzanie 2” i “wprowadzanie 3”, bez znajomości obiegu, na nic się zdadzą. A co, gdy będzie potrzeba biznesowa, która wymusi powstanie dodatkowego kroku pomiędzy “wprowadzaniem 1” a “wprowadzaniem 2”? Dawny krok “wprowadzania 2” stanie się “wprowadzaniem 3” czy utworzymy nowy o nazwie “wprowadzanie 1 bis” lub “wprowadzanie 1,5”?
Ryzykowne jest również nazywanie kroków konkretną rolą np. “księgowość”. A co, gdy w obiegu faktury kosztowej potrzebny będzie udział księgowości również zaraz na początku obiegu dla zastosowania procedury antyfraudowej? Wtedy zrobimy w obiegu kroki “księgowość 1” i “księgowość 2”? A co w wypadku gdy procedurę antyfraudową przejmie w zakresie swojej odpowiedzialności dział administracji? Zmiana nazwy kroku?
Jak widzisz, już samo tłumaczenie konsekwencji nieintuicyjnego nazewnictwa jest bardzo zawiłe. A co dopiero praca w takim systemie?
5. Zadbaj o wygenerowanie aktualnych schematów i pokaż użytkownikowi, jak może sobie taki schemat wyświetlić.
Dużo czytelniej wygląda schemat ułożony liniowo, w którym ścieżki alternatywne są poza główną linią przebiegu procesu. Kolorowanie ścieżek wpływa znacząco na czytelność schematu.
6. Opisz atrybuty i ścieżki w tzw. tooltipach/hintach/chmurkach.
Zadbaj o to, by użytkownik wiedział, do czego służy dany atrybut, co przechowuje oraz do czego służy dany przycisk.
7. Do obiegu dołącz pełną instrukcję w pdf – dostępną jako link w panelu bocznym.
8. Kiedy obieg umożliwia importowanie danych z excela, koniecznie przekaż użytkownikom wzorzec, według którego mogą przygotowywać swoje dane do zaczytania.
Najlepiej, aby taki wzorzec był możliwy do ściągnięcia z formularza, aby był łatwo dostępny i użytkownik nie musiał go szukać.
9. Jeśli obiegi są między sobą powiązane, koniecznie zadbaj o to, by na obiegu, który powołuje się na inny znajdowała się czytelna informacja o takim powiązaniu i by można było łatwo przejść do obiegu powiązanego.
Przykład? Na umowie fakt powiązania z projektem lub kontrahentem. Analogicznie na obiegach projektu czy kontrahenta dobrze, by znalazła się tabelka z listą powiązanych z nimi umów z podstawowymi jej informacjami z możliwością podglądu z tego miejsca zawartości umowy lub przejścia do formularza tej umowy. Uważaj na uprawnienia, by nieświadomie nie pokazać zbyt dużo użytkownikom, którzy nie są do tego uprawnieni.
10. Ustal standardy nadawania sygnatur, czyli ciągu znaków stanowiących jednoznaczny, niepowtarzalny identyfikator dokumentu.
Najlepiej, aby któryś z elementów sygnatury stanowił akronim identyfikujący typ dokumentu.
Aby miało to jeszcze większy efekt, konieczne jest, aby przed wdrożeniem nauczyć użytkowników, jakie przyjęto zasady budowy obiegów, jak poruszać się po Webcon BPS, jak obsługiwać raporty i wyszukiwać żądane dane.
Pamiętajmy, że elastyczność platform typu low-code zobowiązuje wszystkich do szczególnej dbałości o komfort użytkowników. Tylko w ten sposób, będą mogli korzystać z pełnych możliwości tego narzędzia. Dzięki zastosowaniu powyższych wskazówek korzystanie z systemu, a co za tym idzie, Twoja współpraca w ramach projektu, będzie o wiele bardziej efektywna.
