Bent ülök egy nagyvállalat meetingjén… elhangzik, hogy a rendszert a felhasználók “rosszul használják” – ismerős? Kérdezem: “mind?”, “nem de sokan”…
Így kell elképzelni? (Lemmings – Joachim Lille festménye)
Emberi mulasztás
Mesélek egy történetet. Egy fiatal mérnököt meghívtak a Csernobil előtt néhány évvel történt a pennsylvania-i Three Mile Island atomerőmű-baleset vizsgálóbizottságába. A mérnök frissen diplomázott kognitív pszichológiából…
Erről a UI-ról beszélünk első történetünkben (Kenneth K. Lam/Baltimore Sun File/July 14, 1998)
“Emberi mulasztás áll a baleset mögött”, áll a vizsgálóbizottság jelentésében. De mi is történt? Egy túlmelegedés miatt az operátorok kinyitottak egy szelepet – probléma, de rutinmód kezelendő, mint ahogy mi is ráfrissítünk egy weboldalra ha elmegy a mobilunkról a térerő. Aztán becsukták, illetve azt mondták az automatikának, csukja be. A “szelep nyitva” lámpa ki is kapcsolt. Az operátorok megnyugodtak, minden rendben, a helyzetet kezelték.
Egyetlen hiba volt benne: a szelep nem csukódott be. A lámpa valójában azt jelentette csak, “A nyitó motor nincs áram alatt”, azaz a szelepnek be kellett volna csukódnia – ha nem szorul be. Nem volt más jele ennek? De, az áramlásmérő, ami jelezte is: a csövön folyadék folyik. Igen ám, csakhogy az operátorok tudták, hogy a szelep egy ideje szivárog, így nem lepődtek meg ezen, hisz alacsony intenzitással mindig folyt. Amit nem láttak, hogy most szó sem volt alacsony intenzitásról: az erőmű rövid idő aladt leolvadt, és nem sokon múlt, hogy a környékből nem lett Pripjaty-szerű szellemváros.
Én ezen a napon tanultam meg, hogy a UI hiba lehet halálos is (fotó: Telegraph)
Hasonló eset történt az Air France 447-es járatával is: egy pánikoló kezdő pilóta a lassú zuhanást azzal igyekezett megállítani, hogy felfele húzta a gépet – bármennyire is ez lenne mindannyiunkban a reflex, a felhajtóerőhöz valójában lefele kell nyomni azt. A tapasztalt kapitány persze azonnal kapcsolt, és a saját kormányát minden erejével lefele nyomta, az pedig le is ment – csak épp a repülő nem követte. A kezdő pilóta ugyanis félelmében szorította magához az övét, a gép pedig addig a korábbi kormányt vette irányadónak, amíg az nem került nyugalmi helyzetbe. Az eredmény több száz halott.
Ma már mindkét hibát tervezési hibának tekintjük, az első külön hibakategóriát kapott, ez a “visibility of system status”. Abban az esetben, ha a megfelelő végzettséggel rendelkező emberek tömegesen hasonlóan döntenek a rendelkezésre álló információk alapján, ezeket rendszerszintű hibaként kezeljük, és mindent megteszünk a kiküszöbölésükért – bár mind a kiküszöbülésük, mind a megtartásuk rendszerint hatalmas költséggel jár.
A UX kezdetei
A fiatal mérnököt Don Normannak hívták, és ő volt az, aki a User Experience szót kitalálta, a történet pedig a könyve, a Design of Everyday Things 2002-es második kiadásából származik (a 2013-as harmadik kiadásban ennyire már nem részletes).
A UX szempontjából nincsen olyan, hogy tömeges felhasználói hiba, annak áthidalása tervezési feladat. Egy ember-számítógép rendszerben a szoftver jellegéből adódóan a legkönnyebben változtatható komponens: ettől “szoft”. Sokkal olcsóbb elsőre jól megírni, de még a hibáit is kijavítani, mint több száz, vagy akár több ezer embert egy újfajta gondolkodásmódra átterelni, főleg, ha nem ismerjük annak a gondolkodásmód kialakulásának pontos okát.
Természetesen minden kellően komplex rendszernek vannak könnyen félreérthető elemei. Gyakran ezek pont akkor mondanak csődöt, amikor egy évben egyszer szükség van rájuk… De még ennél is nagyobb a baj, ha a könnyen félreérthető elemet naponta többször is félreértik. Ekkor nincs mentség: az adott rendszerkomponensből eredő hibák általában többe kerülnek a vállalatnak, mint a javítás költsége.
Az emberek óhatatlanul mentális modelleket építenek a rendszerrel kapcsolatban – mint ahogy a “szelep nyitva” lámpa elalvását a “szelep zárva” állapottal azonosították, hiába tudták racionálisan, hogy nem teljesen azt jelenti. Főként egy tranzakcionális rendszerben, ahol percenként váltják egymást a feladatok (pl. egy pénztárgép), a frontális lebeny képességeire nem igazán számíthatunk: oda egy olyan megoldás kell, ami rutinszerűen alkalmazható. A homo sapienstől ugyanis biológiai szinten irreális azt várni, hogy napi 8 órában folyamatosan tudjon hasonló egyszerűsítések nélkül gondolkozni.
Érdekes, de a ritka helyzetekre bár jobban alkalmazható lenne a frontális lebeny, mint látjuk, ott gyakran a stressz az úr, ahogy az egyszeri tréning hatása is sokkal gyengébb. Az egy beszámítandó kockázat, mivel jár, ha az emberek eltévesztik az adott folyamatot, bár a költségek gyakran ránkcáfolnak.
Tanítás vs intuitív rendszer
Fontos tudni: önmagában nincs olyan, hogy intuitív rendszer. Olyan rendszer van, amely az adott egyén képességeiből és korábbi tapasztalataiból triviálisan következik. A korábbi tapasztalat pedig nem csak a többi rendszert, de az előző rendszert és az oktatást is érinti.
Ahogy azonban a fenti példákból is látható: ha a rendszerből hiányzik az adott képesség vagy információ, vagy azt nem logikusan tálalják, az oktatás és a tapasztalat csődöt mond. Hiába volt a világ egyik legtapasztaltabb AirBus pilótája a fedélzeten, ez az utasokon nem segített, ahogy az erőmű üzemeltetői sem egy hétvégi tanfolyamon végeztek.
Ezen csak a lehetséges helyzetek pontos ismeretével tudunk segíteni, amikhez terepismeretekre lesz szükség. Amit viszont nem lehet elégszer elmondani: kutyából nem lesz szalonna, ha tömegesen érzékelünk egy jelenséget az oktatás ellenére, akkor ott terepen kell ellenőrizni a hiba okát, majd szükség esetén áttervezni. Az ellenőrzés kérdései:
- van-e olyan elem a folyamatban ami az irodából nem látszott?
- a felület a szituációknak megfelelő információkat ír ki?
- hogy magyarázzák ezeket az információkat a felhasználók?
- a kialakult protokolok, szokások mögött milyen események állnak? miért csinálják így, mi történne ha nem így csinálnák?
Az áttervezés költségei
Na jó, de mennyibe kerül átírni egy rendszert és mennyibe kerül szólni a felhasználóknak hogy máshogy csináljanak dolgokat?
Túl azon, hogy gyakran nyomós okuk van arra, hogy máshogy csináljanak dolgokat, az oktatás közvetlen és járulékos költségei a felhasználók számától erősen függenek.
Miért?
- Olcsóbb egyetlen felhasználót betanítani mint több ezret, az információátadás hatékonysága pedig a létszámmal csökken
- Ha minden századik felhasználó hibázza el évente, az kétszáz felhasználónál kétszer annyi mint száznál
- Több felhasználói hiba – magasabb költségek mind korrekció, mind support, mind reputáció területén
- Minél rövidebb a tréningidő és a felvételi kritérium, annál olcsóbb munkaerőt szerezni
- Minél könnyebb használni a szoftvert, annál rövidebb a tranzakciós idő, azaz az egy ügymenetre jutó átlagos HR költség
Nyilván egy egygombos rendszert, amit csak Micike használ a titkárságon olcsóbb betanítani mint hülyebiztosra tervezni. Ugyanakkor a Facebook bevételei a milliárdos nagyságrendű felhasználószámával erősen függenek attól, mennyire tudják a felhasználók maguktól kihasználni a rendszer képességeit.
Ezért lett a konzumer (önkiszolgáló) rendszereknél etalon az intuitív használhatóság: a bevételeket jelentősen növeli ha a főbb funkciókhoz nem kell oktatás:
- kevesebb a telepítési költség,
- több potenciális felhasználót érnek el
- könnyebb a sales előadás, sőt, akár online értékesíthető
A UX tehát egy „enabler”: segítségével egy olyan korba kerültünk ahol nagyságrendekkel több embert érünk el informatikai rendszerekkel, nagyságrendekkel olcsóbban. Hasonló enabler mint a mesterséges intelligencia, és az egyre intelligensebb rendszerekkel egyre komplexebb a viszonyunk, így egyre fontosabb a felületek átgondolása.
Az áttervezés költségei pedig nem önmagukban jelentkeznek: azt
- az oktatás költségeivel
- a hiba korrekciós, reputációs és tranzakciós költségeivel
- a hiba gyakoriságával
- a HR költségekkel
kell mindig összevetni. Ha egy atomerőmű egyszer olvad le, onnantól kezdve elég erős reputációs költségekkel kell szembenéznie az üzemeltetőnek, pl. új atomerőművek építésekor, hosszabbítási kérelmek beadásakor.
Azt hogy nem kell annyi supportos ha magától tudja használni mindenki a szoftvert, gondolom mondanom sem kell… de a létszámproblémák nem csak a support oldalon jelentkeznek!
Ha naponta ki kell szolgálni 80 embert, és minden ember 1 óra, akkor 10 munkatárs kell. Ha sikerül 45 percre levinni ezt az időt akkor már elég 8 munkatárs. Egy valódi tranzakciós rendszer viszont maximum néhány perces ügyféligénnyel működik, azaz itt egy 10 másodperces spórolás is könnyen spórolhat a HR-en.
Az se mindegy, hogy 4 hónapig oktatok valakit hogy mindent értsen, vagy megmutatom neki, melyik gombbal tud bejelentkezni és a többit elintézi a rendszer: ha átlag 2 évig lesz a munkatársunk akkor a fizetése 16%-át költöttem csak tréningre, a munkaerőhiányt se tudom azonnal kezelni, és a tanfolyamon ki is hullik majd rengeteg ember anélkül, hogy bármi hasznosat is kezdtem volna velük.
Minden megoldható áttervezéssel?
Az informatika előrehaladtával egyre több minden oldható meg önkiszolgáló módon és egyre kevesebb tréning szükséges az egyes feladatok ellátásához. Míg a 80-as években a bérszámfejtés külön feladatkör volt, 2017-ben az egészet egyetlen gombnyomással intézhetjük a NAV honlapján. A menetrendek.hu képes akár több jármű közti átszállással megtervezni egy utazást pusztán a kiinduló- és célállomás megadásával, ehhez régen kézzel kellett egyeztetni papír könyveket.
Ennek vannak HR következményei is:
- anyukám eredeti szakmája, a műszaki rajzoló már a 90-es évek elejére megszűnt (ma ezt a feladatot az AutoCAD és az ArchiCAD látják el a piacon),
- az Uber és a nem helyi taxisok megjelenését a GPS technológia tette lehetővé
- az utazási irodákat az online utazási rendszerek (kezdetben az Expedia, ma pl. SkyScanner + AirBnB) tulajdonképpen tönkretették
- az egy feladathoz tartozó idő csökkenésével kevesebb ember kell a legtöbb feldolgozó szakmában
Még az olyan szakmákban is, ahol az emberi kontakt elengedhetetlen (pl. egészségügy) az adminisztrálással töltött idő csökkentése mind a dolgozói, mind az igénybe vevő életkörülményeit javítja, ezzel is csökkentve a lemorzsolódást és az ügyfélpanaszokat.
Egy olyan országban ahol az egyik legnagyobb probléma a munkaerőhiány, a UX-nek mind az önkiszolgáló, mind az ügyviteli rendszerekben kulcsszerepe van.
