Pred tromi mesiacmi ste spustili nový systém. Školenia prebehli dobre, dashboardy vyzerajú skvele v prezentácii pre vedenie. A v utorok ráno má niekto z prevádzky aj tak vedľa neho otvorenú tabuľku v Exceli, lebo „takto je to rýchlejšie“.
Je ľahké nazvať to odporom k zmene. Podľa našej skúsenosti je to zvyčajne spätná väzba. Ľudia vám jediným spôsobom, aký majú, hovoria, že nový nástroj im prácu sťažuje.
Krátka odpoveď: Zamestnanci nový softvér odmietajú najmä vtedy, keď sú ich každodenné úlohy pomalšie, rizikovejšie alebo neprehľadnejšie ako po starom. Riešením zriedka býva ďalšie školenie. Je ním rozhranie navrhnuté okolo skutočných úloh: menej krokov, prehľadnejšie obrazovky, kontroly priamo v systéme a testovanie s reálnymi používateľmi pred spustením.
Prečo zamestnanci odmietajú nové technológie?
Výskum má na to dobre známu odpoveď. Model akceptácie technológií Freda Davisa (MIS Quarterly, 1989) ukázal, že to, či ľudia systém používajú, závisí od dvoch presvedčení: že im pomáha robiť prácu lepšie (vnímaná užitočnosť) a že sa s ním pracuje bez námahy (vnímaná jednoduchosť). V jeho štúdiách mala užitočnosť silnejšiu väzbu na používanie a jednoduchosť sa ukázala ako jej predpoklad. Nástroj, s ktorým sa ťažko pracuje, nepôsobí užitočne, nech má akékoľvek funkcie.
V praxi, keď sedíme s tímami, počúvame takéto dôvody:
- „Je to na viac klikov ako predtým.“ Nový postup je dlhší ako obchádzka, ktorú mal nahradiť.
- „Nič tam neviem nájsť.“ Informácie potrebné na jednu úlohu sú rozhádzané po záložkách, obrazovkách alebo iných nástrojoch.
- „Bojím sa, že niečo pokazím.“ Obrazovka nedáva jasne najavo, čo akcia spôsobí, takže ľudia všetko kontrolujú dvakrát, alebo sa nástroju vyhýbajú.
- „Nesedí to na to, ako naozaj pracujeme.“ Softvér kopíruje proces na papieri, nie ten skutočný, so všetkými výnimkami.
- „Nikto mi neukázal, čo mne to prinesie.“ Prínos ide do reportov pre vedenie, kým zadávanie dát navyše padá na toho, kto robí samotnú prácu.
Iba posledný bod je naozaj o riadení zmeny. Prvé štyri sú problémy dizajnu.
Záleží na dizajne interného softvéru?
Interné nástroje dostávajú menej pozornosti ako zákaznícke produkty, lebo „naši ľudia to aj tak musia používať“. Musia. Nemusia ho však používať dobre a nájdu si spôsob, ako ho obísť. Toto dizajn rozhrania v internom systéme mení.
Šetrí čas pri každej úlohe, každý deň
Obrazovka navyše alebo chýbajúci filter stojí pár sekúnd. V internom nástroji sa tie sekundy opakujú stokrát denne v celom tíme.
Cena prepínania medzi nástrojmi sa dá zmerať. V štúdii Harvard Business Review (2022) výskumníci sledovali 137 ľudí v 20 tímoch v troch firmách z rebríčka Fortune 500, väčšinou v administratívnych a podporných pozíciách. Ľudia prepínali medzi aplikáciami a webmi asi 1 200-krát denne a opätovné zorientovanie po týchto prepnutiach ich stálo necelé štyri hodiny týždenne, zhruba 9 % pracovného času. Autori za príčinu označujú to, ako je navrhnutá práca a softvér, nie ľudí.
Preto sa veľká časť práce na CRM Aero pre OVB týkala spojenia piatich nástrojov do jedného pracovného priestoru, aby poradca našiel klienta, naplánoval stretnutie a dokončil úlohu bez prepínania systémov.
Predchádza drahým chybám
Neprehľadné obrazovky ľudí nielen spomaľujú. Spôsobujú chyby, ktorým sa školením úplne zabrániť nedá.
Najznámejší príklad pochádza z bankovníctva. V auguste 2020 chcela Citibank poslať veriteľom firmy Revlon úroky vo výške asi 7,8 milióna dolárov a omylom k nim poslala aj takmer 900 miliónov dolárov vlastných peňazí. Podľa zistení súdu a rozhodnutia odvolacieho súdu bolo na zastavenie odoslania istiny potrebné zaškrtnúť v úverovom softvéri tri nejasne pomenované políčka (FRONT, FUND a PRINCIPAL). Zamestnanec zaškrtol iba PRINCIPAL a transakcia aj tak prešla schvaľovaním troch ľudí.
V zdravotníctve vidno rovnaký vzorec vo veľkom. Štúdia v JAMA (Howe, Ratwani a kol., 2018) prešla 1,735 milióna hlásení o bezpečnosti pacientov a našla 557, ktoré možné poškodenie pacienta výslovne spájali s použiteľnosťou elektronického zdravotného záznamu, napríklad keď sa dátum predvolene posunul na nasledujúci deň a lekár si to nevšimol. Autori upozorňujú, že ide pravdepodobne o podhodnotené číslo, lebo hlásenia sú dobrovoľné.
Vaša firma asi nehýbe 900 miliónmi ani nepredpisuje lieky. Mechanizmus je však v každej firme rovnaký: predvolená hodnota, ktorú si nikto nevšimne, pole, ktoré znamená niečo iné, ako hovorí jeho názov, akcia, ktorá vyzerá vratne, ale nie je.
Prináša prehľadnosť: ľudia vedia, čo urobiť ďalej
Dobrá interná obrazovka odpovie na tri otázky bez toho, aby sa ktokoľvek musel pýtať kolegu: kde som, čo je hotové a čo ešte chýba?
Keď sme stavali ZKD, proces onboardingu klientov v OVB, postup musel zvládnuť jednotlivcov, domácnosti aj firmy, a k tomu overenie totožnosti, súhlasy, kontroly proti praniu špinavých peňazí a podpis. Postavili sme ho ako vedený postup, v ktorom poradca vidí, čo je hotové, čo treba skontrolovať a ktoré údaje ešte chýbajú, kým záznam dokončí. Pravidlá sú priamo v rozhraní, takže noví aj skúsení poradcovia postupujú rovnako.
Zvyšuje adopciu, a z nej pochádza návratnosť
Systém sa vráti, až keď ľudia doň naozaj presunú svoju prácu. Písali sme o tom v článku Investícia do systému sa vráti, keď ho ľudia používajú. Ak si ľudia nechávajú Excel „pre istotu“, platíte za dva procesy. Dobrý dizajn je spôsob, ako urobiť nový proces tým jednoduchším.
Ako navrhujeme interný softvér, ktorý ľudia naozaj používajú
Takto postupujeme, keď navrhujeme a staviame interné systémy. Dizajn je súčasťou vývoja, nie samostatný projekt. Vychádza z rovnakých krokov ako náš produktový dizajn: výskum, rozhovory, klikateľný prototyp, testovanie s používateľmi, UI dizajn a dizajn systém.
1. Najprv sledujeme skutočnú prácu
Začíname tým, že si sadneme s ľuďmi, ktorí budú systém používať, a sledujeme ich pri bežných úlohách. Nie prezentáciu procesu, ale skutočné utorkové ráno. Hľadáme:
- tabuľku otvorenú na druhom monitore,
- lepiace papieriky s kódmi alebo číslami zákazníkov,
- chvíle, keď sa niekto pýta kolegu,
- údaje prepisované z jedného nástroja do druhého.
Každá obchádzka je požiadavka, ktorú nikto nespísal. Pri našej práci pre IDS BK na verejnej doprave zahŕňal výskum desiatky rozhovorov s cestujúcimi ešte pred začiatkom dizajnu.
2. Navrhujeme úlohu, nie obrazovku
Tímy často žiadajú „krajšie rozhranie“. Väčšinou však potrebujú kratšiu cestu cez jednu úlohu. Preto najprv zmapujeme najčastejšie úlohy (nájsť klienta, schváliť žiadosť, uzavrieť prípad) a spočítame kroky, obrazovky a polia, ktoré každá potrebuje. Potom odstránime nepotrebné a spojíme, čo k sebe patrí.
Pravidlo, ktorého sa držíme: každodenná úloha by mala byť zvládnuteľná na jednej obrazovke alebo v jasne vedenom slede krokov, bez opustenia systému.
3. Pravidlá dávame do rozhrania, nie do príručky
Ak je chyba drahá, obrazovka ju má sťažiť. V praxi:
- Pomenúvame veci jazykom firmy. Žiadne interné kódy ako „FUND“ alebo „STS 01“, ktoré si človek musí pamätať.
- Ukazujeme dôsledky. Pred akciou, ktorá posiela peniaze, maže dáta alebo upozorňuje klienta, ľudskou rečou povieme, čo sa stane.
- Volíme bezpečné predvolené hodnoty. Dátumy, sumy a príjemcovia majú byť predvyplnené najčastejšou správnou hodnotou a výrazne upozorniť, keď ňou nie sú.
- Ukazujeme postup a chýbajúce údaje. Čo ešte chýba, povieme pred uložením, nie potom chybovým kódom.
- Dávame spätnú väzbu po každej akcii. Malé potvrdenie alebo zmena stavu povie, že systém urobil, čo človek chcel. Takúto spätnú väzbu na obrazovke sme použili pri redizajne CloudTalku.
4. Klikateľný prototyp testujeme s piatimi ľuďmi v každom kole
Pred vývojom testujeme dôležité postupy na klikateľnom prototype s reálnymi používateľmi, keď sú zmeny ešte lacné. Veľkú štúdiu netreba. Výskum Nielsen Norman Group ukazuje, že testovanie s približne piatimi používateľmi odhalí v kvalitatívnom teste väčšinu problémov s použiteľnosťou a že viac malých kôl je lepších ako jedno veľké. Ako sme takéto testy robili pre IDS BK, sme opísali v článku o testovaní použiteľnosti.
Pri internom softvéri je testovanie ešte jednoduchšie ako pri zákazníckych aplikáciách: vaši používatelia už pre vás pracujú. Hodina s piatimi ľuďmi z rôznych pozícií stačí na to, aby ste videli, kde váhajú.
5. Konzistenciu držíme dizajn systémom
Keď niečo funguje, má to fungovať všade rovnako: rovnaké filtre, rovnaké tlačidlá na rovnakých miestach, rovnaké zobrazenie chýb. Spoločný dizajn systém drží interné nástroje konzistentné aj pri pridávaní nových modulov, takže sa ľudia nemusia produkt učiť odznova s každou verziou. Pre CloudTalk sme navrhli viac ako 450 obrazoviek pre desktop aj mobil na jednom spoločnom dizajn systéme.
6. Spúšťame po tímoch a meriame dokončenú prácu
Spúšťame postupne a spätnú väzbu každej skupiny berieme ako vstup do ďalšej verzie, ako pri postupnom spúšťaní Aera. A meriame dokončenú prácu, nie počet prihlásení (pozri tabuľku nižšie).
Ako merať adopciu softvéru?
Prihlásenia hovoria, že ľudia systém otvorili. Nehovoria, či starý proces zmizol. Toto meriame najradšej:
| Čo merať | Čo vám to povie | Ako to zistiť |
|---|---|---|
| Úlohy dokončené celé v novom systéme | Či starý proces naozaj nahradil nový | Udalosti v systéme v porovnaní s pôvodným objemom |
| Čas na dokončenie kľúčovej úlohy | Či dizajn šetrí čas | Krátke pozorovania pred spustením a po ňom |
| Obchádzky, ktoré sa stále používajú | Kde systém ešte nestačí | Otázka: „Čo ešte robíte mimo systému?“ |
| Chyby a opravy | Či obrazovky spôsobujú chyby | Záznamy opráv, tikety podpory, nálezy auditu |
| Žiadosti o pomoc pri úlohe | Ktoré postupy nie sú samovysvetľujúce | Tikety podpory, otázky vedúcim tímov |
| Používateľmi vnímaná jednoduchosť | Ako sa so systémom pracuje | Krátky dotazník, napríklad System Usability Scale (SUS) |
Buďte úprimní v tom, čo ktoré číslo znamená. Pri Aere OVB uvádza zlepšenie efektivity práce o 20 až 30 %, ale ide o výsledok dotazníka medzi používateľmi: je to vnímanie, nie zmerané ušetrené hodiny. Pri Multiprotokole OVB uviedla o 50 % kratší čas prípravy protokolov. Oboje sú užitočné signály a ani jedno nie je sľub pre inú firmu.
Rýchly test: spôsobuje dizajn vášho interného nástroja odpor?
Ak ste zaškrtli tri a viac, ďalšie školenie to pravdepodobne nevyrieši. Prácu potrebuje samotný nástroj. Presne takýto problém opisujeme na stránke o nízkej adopcii softvéru.
Ako to vyzerá v našich projektoch
- OVB Aero: päť nástrojov spojených do jedného CRM, ktoré denne používa 2 000 poradcov, s vyhľadávaním a filtrovaním doladeným podľa každodennej práce a s postupným spúšťaním.
- OVB ZKD: vedený onboarding, ktorý ukazuje, čo je hotové a čo chýba, s povinnými kontrolami v každom kroku.
- CloudTalk: redizajn rušných postupov pri hovoroch na desktope aj mobile, s jasnejšou hierarchiou, konzistentnými ovládacími prvkami a spoločným dizajn systémom.
Váš ďalší krok: vyberte jednu úlohu, ktorú váš tím vo vašom hlavnom internom systéme robí najčastejšie. Sledujte dvoch ľudí, ako ju robia od začiatku do konca, a spočítajte kliky, obrazovky a každú chvíľu, keď systém opustia. Ten zoznam je vaše prvé zadanie pre dizajn.
Tieto skúsenosti pochádzajú z našej práce na projektoch Aero, ZKD a CloudTalk. Ak váš tím systémy stále obchádza, napíšte nám, ako vyzerá váš postup, a pomôžeme vám zistiť prečo. Navrhujeme a staviame interné systémy podľa toho, ako vaši ľudia naozaj pracujú.
Časté otázky
Prečo zamestnanci nepoužívajú nový systém?
Najčastejšie preto, že im sťažuje každodennú prácu: viac krokov, neprehľadné obrazovky, vyššie riziko chyby alebo zlý súlad s tým, ako sa práca naozaj robí. Výskum akceptácie technológií ukazuje, že ľudia používajú systémy, ktoré považujú za užitočné a jednoduché. Najprv opravte úlohy, potom školte.
Prečo tím nepoužíva CRM?
Bežné dôvody sú dvojité zadávanie údajov, pomalé vyhľadávanie, chýbajúce informácie potrebné na úlohu a obrazovky navrhnuté pre reporty, nie pre človeka, ktorý údaje zadáva. Keď CRM ľuďom ušetrí čas pri ich vlastnej práci, používanie zvyčajne príde.
Vyrieši nízku adopciu softvéru ďalšie školenie?
Samo osebe len zriedka. Školenie pomáha pri naozaj nových pojmoch. Ak ľudia potrebujú školenie na bežnú každodennú úlohu, rozhranie je zvyčajne príliš zložité a je lacnejšie opraviť ho v dizajne, než ho znova vysvetľovať každému novému kolegovi.
Ako zlepšiť adopciu softvéru vo firme?
Sledujte ľudí pri skutočných úlohách, skráťte najčastejšie postupy, vložte kontroly priamo do obrazoviek, pred vývojom otestujte prototyp s približne piatimi používateľmi v každom kole, spúšťajte po tímoch a merajte dokončené úlohy namiesto prihlásení.
Ako merať adopciu softvéru?
Sledujte úlohy dokončené celé v novom systéme, čas na kľúčovú úlohu, obchádzky, ktoré sa stále používajú, chyby a opravy a žiadosti o pomoc. Krátky dotazník, napríklad System Usability Scale, pridá pohľad používateľov. Samotné prihlásenia nestačia.
Záleží na UX pri interných nástrojoch?
Áno. Interné nástroje sa používajú hodiny denne, takže malé zdržania a mätúce kroky sa v tíme sčítajú a neprehľadné obrazovky môžu spôsobiť drahé chyby. Dobre zdokumentovaným príkladom je prípad bankového prevodu v Citibank.
Koľko používateľov treba na testovanie použiteľnosti?
Pri kvalitatívnom testovaní Nielsen Norman Group odporúča približne päť používateľov v jednom kole, potom opraviť nájdené problémy a testovať znova. Pri interných nástrojoch vyberte ľudí z každej pozície, ktorá systém používa.
Zdroje
- Davis: model akceptácie technológií (1989)
- Harvard Business Review: cena prepínania medzi aplikáciami (2022)
- Prevod Citibank: zistenia okresného súdu (2021)
- Prevod Citibank: rozhodnutie odvolacieho súdu (2022)
- Howe, Ratwani a kol.: použiteľnosť zdravotných záznamov a bezpečnosť pacientov, JAMA (2018)
- Nielsen Norman Group: prečo testovať s piatimi používateľmi
- Outloud: OVB Aero
- Outloud: OVB ZKD
- Outloud: OVB Multiprotokol
- Outloud: CloudTalk
- Outloud: IDS BK
