A UX standard
Mikor mondhatjuk, hogy egy tervezési folyamat valóban UX-es?
A “standard” szó, amely eredetileg a római csapatok zászlóoszlopa volt, és így a hovatartozást volt hivatott kifejezni, a középkorban átlényegült: ma standardnak azt nevezzük, amihez képest mérjük dolgainkat. A legismertebb standard talán a méterrúd. Bár ma már a fénysebességgel modellezzük, de sokáig egy méter az volt, amit a párizsiak egy standard rúddal (az etalonnal) egy méternek mértek.
Ezt, hogy mindenkinek valamihez kell mérnie magát, nem csűrheti-csavarhatja kedvére, a francia forradalomnak köszönhetjük. Addig ugyanis városonként eltérő volt, mit értünk egy láb alatt, és egy messziről jött kereskedő, miután közölte, nála egy láb selyem tizedével olcsóbb mint a másiké, csak vásárláskor jelentette ki, hogy az ő városában az emberek lába sokkal-sokkal kisebb.
Ezért a Francia Tudományos Akadémia kijelölte a kor nagyjait, találjanak ki valamit, hogy megszűnjön ez az áldatlan állapot, ez lett a metrikus rendszer. Az 5 francia akademikus bizottságának egyik kései utódja az ISO, azaz az International Standards Organization.
Ez a szervezet számunkra egy fontos dolgot csinál: publikálja az ISO 9241 szabványcsomagot, amely Az Ember-Számítógép Interakció Ergonómiájáról szól, más néven a UX-ről.
Miért van szükségünk UX standardre?
Én azt tudom elmondani, nekem miért van szükségem: kis csapatommal amikor elkezdtünk dolgozni, azt láttam, hogy hirtelen, a divat hatására, mindenki UX-esnek hívta magát:
- az összes tervezőgrafikus, aki valaha rajzolt honlapot, hirtelen UI/UX designernek hívta magát, vajon mind az?
- az üzleti elemzők közölték, hogy ez csak egy új név arra amit eddig is csináltak, de tényleg?
- önjelölt SEO-guruk és online marketing szakértők kínálták véleményüket UX tanácsadás néven, vajon tényleg az?
Eközben a végeredményeik (gyümölcseiről ismeritek meg őket) amelyek kigördültek, általában nem volt túl jól használható, a UX, azaz a felhasználói élmény még a legalapvetőbb feladatok esetén sem volt túl jó, azaz kellemes, hatékony és hatásos.
Na de mivel volnánk mi jobbak? UX-e az, amit mi csinálunk?
A problémák csak sokasodtak, amikor felkértek arra, tanítsak UX-et, sőt, segítsek iskolát olyan diplomát kiadni, amin szerepel ez a két betű: UX. Mitől lesz valaki UX designer?
Sőt: felkértek arra, rendeljek meg UX-et az ország egyik legnagyobb fejlesztővállalatától, aki majd bizonyára ezt kiadja valakinek alvállalkozásba. Na jó, de mit is?
- Mit is kérünk mint UX tevékenységek?
- Honnan fogjuk tudni, hogy az jó?
- Hogy tudjuk megrendelőként minőségbiztosítani a kimenetet?
- Mivel tudjuk megkülönböztetni az önjelölt stúdiókat a valóban UX-es munkát végző (és így használható eredményt előállító) szakemberektől?
Mindezt súlyosbítva azzal, hogy ez közbeszerzés, ami az államban kevésbé jártasaknak azt jelenti, hogy kiadsz a kezedből egy excel és egy word fájlt a követelményeidről, valaki aláír egy szerződést, hogy ezeket teljesíti, és onnantól évekig csak imádkozni tudsz, hogy tényleg, változtatni nem.
Miben különböztünk mi a többi csapattól?
Sejtettük, hogy a “titkunk” az, hogy mi sokkal-sokkal többet beszélünk felhasználókkal: nem az ügyfelekkel, hanem valóban az adott munkát végző, később várhatóan a mi rendszerünket használó emberekkel. Igyekeztünk nagyon formálisak lenni abban, hogyan is beszélünk, mi egy jó interjú kérdés, vagy ha visszajelzést próbálunk valamiről szerezni, azt hogyan kell.
Közben tapasztaltunk dolgokat:
- az interjúk általában “meglepő” eredményeket hoztak (minket már nem lep meg hogy meglep, de az ügyfelet még mindig), gyakran a teljes termék fókusza, alapvető felépítése lett más mint amit magunktól képzeltünk volna
- a teszteken a használhatóság és a vélemény sose volt összhangban — szinte mindenki mindig dicsérte a rendszert, hiába volt a szimulált felhasználói élmény egy hullámvasút előtte 20 percig, ahol mind a résztvevő, mind a moderátor leizzadtak
- újra és újra tesztelni kellett, mert mindent nem lehetett kideríteni a prototípusból, ha egy hibát kijavítottál, előjött másik három, ami eddig nem látszódott, a fejlesztett (béta) termék pedig — részletessége miatt — újabb problémákat hozott felszínre
Csináltunk dolgokat, volt egy folyamatunk, de nem tudtuk:
- Ez-e a helyes irány (azt sejtettük, igen)?
- Mindent csinálunk amit kell?
- Ha sikerül ezt a folyamatot végigcsinálni, biztos jó lesz a felhasználói élmény? Mik a feltételek?
- Nem csinálunk-e esetleg túl sokat, mi az ami csak ceremoniális, elhagyható?
Erre leltünk választ az ISO anyagai közt.
Na de mi a UX standard és mi a lényege?
Arról, hogy egy UX projektfolyamat mikor “UX-es”, az ISO 9241–210:2019 nyilatkozik, aminek címe Interaktív rendszerek ember-központú tervezése. Lelövöm a poént, alapvetően 6 alapelve van:
- A tervezés a felhasználók, feladataik és környezeteik explicit megértésén alapul
- A felhasználók a tervezés és fejlesztés során végig be vannak vonva
- A terv mozgatórugója, a finomítás alapja a felhasználó-központú kiértékelés
- A folyamat iteratív
- A terv a teljes felhasználói élményt lefedi
- A tervező csapat multidiszciplináris képességeket és nézőpontokat foglal magába
De foglaljuk ezeket össze (az összefoglalók a szabvány szövege alapján készültek, a saját kommentár döltbetűs)
A tervezés a felhasználók, feladataik és környezeteik explicit megértésén alapul
Ez azt jelenti, hogy a termék, rendszer vagy szolgáltatás mindazokat figyelembe veszi, akiket érinteni fog, elsősorban akik közvetlenül használni, de azokat is akiket más (közvetett vagy közvetlen módon) érinteni fog — minden projekt első kérdése nálam: ki a user? Szerintem user nélkül nincs UX!
A használhatóság erősen kontextusfüggő, de ez a kontextus nem csak a környezetet jelenti, hanem azt is, a használatnak mi a célja, mi a feladat, amit végre próbálunk hajtani — azaz ha nincs explicit megértésünk arra vonatkozólag, egy adott felhasználó miért és hogy kerül kapcsolatba a rendszerrel, neki nem is fogunk tudni jó élményt tervezni
A felhasználók a tervezés és fejlesztés során végig be vannak vonva
A fenti kontextusról tudása elsősorban a tényleges (leendő) felhasználóknak van, de ezt csak aktív részvétellel tudjuk kiaknázni. Minél több kölcsönhatás van a felhasználók és a fejlesztőcsapat tagjai között, annál hatékonyabb ez a bevonás — azaz nem elég gondolnunk a userre: beszélnünk kell vele; beleképzelni magunkat a helyébe nem elég.
Ez igaz a vállalati szoftverekre is (ott az elfogadást nagyban segíti, ha nem derült égből új rendszer fogadja a felhasználókat), de általános vagy konzumer termékekre is, hiszen ott is a releváns felhasználói csoportok tagjai tudnak érdemi visszajelzést adni a tervezett megoldások tesztelésekor — az eredeti angol szövegben “képviselői” van, nem “tagjai”, de szerintem user nélkül nincs UX, velük kell tesztelni, és attól még, hogy a főnökük, vagy a kinevezett PO rábólintott valamire, nem lesz a felhasználók által is elfogadott az új rendszer.
A terv mozgatórugója, a finomítás alapja a felhasználó-központú kiértékelés
A felhasználói visszajelzés kritikus információforrás a UX-ben. Azzal, hogy velük próbáljuk ki a terveket és visszajelzéseik alapján javítjuk őket, minimalizáljuk annak a kockázatát, hogy nem felel meg nekik, és előkerülnek más módon rejtett, vagy explicit nehezen specifikálható tényezők. Ez azzal kezelhető ha az előzetes terveket “valós esetekben” próbáljuk tesztelni, és folyamatosan javítjuk ez alapján a megoldásokat. Azaz, ahogy Németh elvtárs fogalmaz: tesztelni, tesztelni, tesztelni. Lehetőleg tényleges userrel.
Természetesen ezeket a teszteket a végső elfogadáskor, is el kell végezni, sőt, a hosszútávon jelentkező problémák észlelésére a használatbavétel után is el kell végezni.
A folyamat iteratív
Elsőre általában nem lehet jó rendszert tervezni. Az iteráció (ismételt áttervezés) célja hogy folyamatosan megszüntesse a fejlesztés során a bizonytalanságokat. Ehhez a prototípusokat, specifikációkat, leírásokat folyamatosan frissíteni kell, ahogy új információ érkezik be — én is utálok dokumentációt frissíteni, ennek ellenére garanciában csináljuk, mert így lesz kerek a fejlesztőknek. Minden prototípusunk legalább 3 használhatósági teszten esik át, mire ki merjük adni a kezünkből, azaz iterációnak mi a belső dizájnkritikákat nem is hívjuk, pedig abból is van bőven.
Nem lehet modern informatikai rendszereket ténylegesen teljesen és pontosan specifikálni a legelején: egy csomó szükséglet és elvárás csak a fejlesztés során esik ki, ahogy az érdekelt felek egyre többet értenek meg abból, mire is van szükségük, mik a feladatok, és a felhasználók is könnyebben fejezik ki szükségleteiket potenciális megoldásokat látva — röviden: prototipizálni kötelező, és ezt meg kell mutatni a felhasználónak mielőtt rámondjuk az áment.
A terv a teljes felhasználói élményt lefedi
A felhasználói élmény a teljes hardver-szoftver környezetből, annak beállításaiból adódik, csakúgy mint a felhasználó eddigi élményei, attitűdjei, képességei, szokásai és személyiségei is meghatározóak. A használhatóság nem csak egyszerű kezelhetőséget jelent, de a felhasználó személyes céljairól, munkahelyi elégedettségről és a monotónia megszűntetéséről is szól — azaz nem az a jó UX, ami szépen fut az InVision-ben HD monitoron, hanem ami a tényleges helyzetben, a felhasználó tényleges gépén, tényleges programként jól fut, és nem csak könnyű használni, de jobb is lesz a felhasználó élete tőle.
A felhasználói élmény magába foglalja a dokumentációt, az online súgót, az ügyfélszolgálatot, a képzést, és adott esetben a csomagolást is. A felhasználó eddigi élményei is erősen befolyásolják ezeket — azaz a UX design valahol mindig service design is, a súgót, ügyfélszolgálatot pedig ki kell találni minden rendszerhez.
A tervező csapat multidiszciplináris képességeket és nézőpontokat foglal magába
A tervezőcsapat nem kell hogy nagy legyen, de muszáj, hogy több oldalról képesek legyenek megközelíteni a kérdéseket, hogy jó döntéseket tudjanak hozni előnyök-hátrányok tekintetében — magyarul nem egy rakás UX-esként döntjük el egy szép irodában, milyen legyen a termék. Ha a tervezőcsapatba a fejlesztőket, az ügyféloldali szakértőket, megrendelőket és a felhasználókat is belevesszük, ez a csapat már képes lehet érdemi döntéseket hozni.
Elég ennyi?
Ahogy a fenti kommentárokból is látszik, valójában mi néhol szigorúbbak vagyunk mint amennyit a standard megkövetel, bár a szellemiségen érződik, hogy a közvetlen felhasználóbevonás áthatja, valójában itt-ott vannak higító beszúrások, pl. később megjegyzi, “néha a felhasználó alapú tesztelés anyagilag nem éri meg”, vagy a felhasználói csoportok bevonásánál “tagok” helyett “képviselők” szerepel, és a hivatalos checklistben is csak a “4.3 — a felhasználók aktív résztvevői a folyamatnak” védi ezt. A szövegszerkezet alapján a személyes sejtésem az, hogy ezek valóban higítások, elvégre ez is egy bizottsági munka végeredménye.
Biztos vagyok benne, hogy lesznek sokan, akik azt fogják mondani, igen, a heurisztikus elemzés és az expert walkthrough elfogadott eljárások. Ezen emberek egy része ebből is él, szinte kizárólagos, de legalábbis többségi módszerként ezeket használva felhasználóbevonásos technikák helyett.
A gyakorlati tapasztalatom azt mutatja, hogy komplex rendszerek esetén ezek a “könnyítések” lenullázzák a UX projekt hatásosságát, azaz
ha a felhasználók helyett “képviselőket” ültetünk be, használhatósági tesztek helyett pedig “szakértői” véleményeket kérünk és adunk, a végeredmény az eddigi módszerektől megkülönböztethetetlen lesz — nem csoda, hisz az eddigi módszer pont ez volt.
Megrendelőként pont ezt szeretnéd elkerülni. Ezért azt javaslom, hogy ha UX-et veszünk, ezeket küszöböljük ki, egyes sarokpontokon tegyük kötelezővé a tényleges felhasználóbevonást, így:
- a projekt elején (interjúk formájában)
- több körösen használhatósági tesztelve a prototípusokat, hogy azok folyamatosan javuljanak (legyen minimum körök száma, ami legalább 2! legyenek feltételek aminél kellenek extra körök!)
- a kiadásra jelölt (sprint végtermék vagy béta) termékek használhatósági tesztelésével
- az első üzemeltetési tapasztalatok utáni használhatósági tesztelésekkel
A gyakorlatban vannak még olyan elemek, amiket ez a standard nem fed le (hogyan válasszunk megoldásokat? hogyan építsük fel az információs architektúrát? mik legyenek az elnevezéseink?), de az ISO 9241 csomag jórészt erre is ad válaszokat.
Most akkor mindenki ehhez mérje magát?
Nem tudom. Az én csapatom ehhez méri magát, és ha én rendelek valakitől UX szolgáltatást, ezt kérem számon rajt (és bizony, akkor a felhasználók tényleges bevonását is). Az biztos, hogy ezzel a megerősítéssel azokat az elemeket, amiktől a mi rendszereink használhatósága szerintem jobb szokott lenni mint azok amiket leváltanak, nagyjából tartalmazza.
De hogy ez lesz valóban az elterjedt szabvány kérdéses, hisz ahogy láthatjuk, nem csak Budapesten, de Berlinben is vannak, akik próbálják kihagyni a UX tervezés során a legfontosabb szereplőt — a felhasználót.
