Amiről olvashatsz

A felhasználói élmény nem titkos összetevői, egy ritka szakma érdekességei.

Tippek és trükkök, hogyan teheted különösen kedveltté termékedet, weboldaladat, vállalkozásodat.

Bővíz László használhatósági specialista

Bővíz László, használhatósági specialista (szoftver ergonómus) vagyok, a Webergonómia könyv egyik kommentátora.
Felület- és használhatósági-tervezéssel foglalkozom.
Email nekem

Usability - Magyar szótár

Élő könyvjelző

Friss hozzászólások

Használhatóság, szoftverergonómia

2013.08.13. 23:49 Bővíz László - JUEX

A felhasználók ügyvédje

Egy interjú, amit az IDG Computerworld készített velem nemrég.

Szoftver és ember kapcsolatával foglakozik Bővíz László felhasználó-élmény specialista akitől megtudjuk többek közt azt is, hogy a felhasználók nem olvasnak dokumentációt és miért nem szerencsés, ha a programozó egyben UI designer is.

Ön használhatósági specialista (szoftver ergonómus), pontosan mit jelent ez? Mióta foglalkozik ezzel?

Szoftverfejlesztési projektekben dolgozom használhatósági szakértőként. Szokás még felhasználó élmény tervezőnek is hívni, angolul UX designer. A feladatom, hogy megtervezzem a szoftver és ember kapcsolatát megteremtő részeket. Jelentős üzleti értéket képvisel, ha ez a kapcsolat harmonikus, jobban szeretik és vásárolják az ilyen a szoftvereket. Ez egy viszonylag új szakma ezért furcsa lenne, ha azt mondanám, hogy amióta számítástechnikával foglalkozom azóta ez tölti ki az életem, bár lenne benne igazság. Körülbelül tizenöt éve foglalkozom felhasználói felületek tervezésével és készítésével.

Miben tér el a felülettervezőtől?

Az ember és gép kapcsolatát lehetővé tévő részeket interfészeknek hívjuk, ami felületet jelent. Ha ebben a jelentésében használjuk akkor nem tér el. A modern operációs rendszerek lehetőségeit kihasználó grafikus felhasználói felületek tervezését is szokás felület tervezésnek hívni, ez lényeges része a munkámnak, de korántsem fedi le az összes feladatom. A szoftver ergonómus dolga, hogy felmérje, kutassa és érvényesítse a felhasználók igényeit, szinkronba hozva a vállalkozás céljaival.

Hogyan látja, igénybe vesznek-e ilyen szakembert a fejlesztők?

Idehaza még kevesen, inkább csak a nemzetközi piacokon mozgók, de külföldön már sokkal inkább. Ha egy szoftver olyan dolgot tud, amit egyik versenytársa sem, akkor abban az esetben is vásárolják, ha nehezen használható, hiszen nincs választási lehetőségük a felhasználóknak. Ez rendszerint rövid ideig szokott tartani, mert a sikeres termékeknek hamar megjelennek a versenytársaik. Ha az újonnan megjelenő termék ugyanazt tudja, de könnyebb, gyorsabb, élvezetesebb a munka vele, akkor az eredeti termék igen hamar elvesztheti a vásárlótáborát. Ahogy arra rájöttek már itthon is, hogy tesztelő szakemberek nélkül nem lehet garantált minőségben komoly terméket kiadni, úgy kezdik a saját bőrükön tapasztalni azt is, hogy a felhasználói élmény tervezése külön szakembert igényel. A programozókétól eltérő megközelítésre van szükség hozzá, ezért jobb ha nem ők végzik.

A fejlesztés mely fázisában hívják segítségül?

Szerencsés esetben az elején. Ilyenkor a lehetőségek még nagyon rugalmasak, olyan megoldások megvalósítására is van lehetőséget, ami később sokkal nehezebb és drágább lenne. Ez nem azt jelenti, hogy egy futó projektbe ne lenne érdemes beszállnom, csak azt, hogy ott sokkal kisebb lépésekkel, a meglévő körülményeket jobban figyelembe véve lehet haladást elérni. Ami a projekt elején egy egységbe kerül, az a közepén már tíz, a végén pedig száz egységnyi ráfordítást is igényelhet. Új szoftver verzió vagy termék fejlesztésének kezdetekor a felületet érintő helyes koncepcionális döntések jókora lendületet és motivációt biztosíthatnak a projekt teljes ciklusára.

Minden felhasználói felülettel rendelkező szoftvernek szüksége van használhatósági tervezésre?

Kevés felhasználónak, nagyon speciális szakterületen belső használatra szánt programnál kimondottan nem ajánlanám, mert nem éri meg. Szerencsés, ha néha elgondolkodnak, hogy az elkészült felület elég logikus-e, de külön szakembert ilyenkor nem érdemes bevonni. A tömeges használatra szánt vagy az üzletileg és biztonságilag kritikus folyamatokkal rendelkező szoftvereknél elengedhetetlen, azok szoftverergonómusért kiáltanak.

Milyen fázisokból áll az Ön munkája?

A konkrét szoftvertől és a rászánt költségektől függ, hogy milyen mélységű tervezést érdemes csinálni. Elsőként szükség van egy előzetes felhasználói kutatásra, ami a terepen zajlik, ahol a leendő használó még szoftver nélkül, vagy annak korábbi verziójával végzi a munkát. Grafikus felületek tervezésére mindig szükség szokott van. Különböző terv változatokat, majd azokból prototípusokat készítek. Ezeket előzetes tesztelésnek vetjük alá még fejlesztés előtt. A programozók és a tesztelők munkáját támogatom speciális felületi tervek, interakciós diagramok elkészítésével. Érvényesítem a használhatósági szempontokat a fejlesztés során a fejlesztő csapatban. Részt veszek a szoftverrel kapcsolatos döntések meghozatalában. Leginkább olyan, mintha a leendő felhasználók ügyvédje volnék.

Milyen eszközöket használ?

Legtöbbször papírt és ceruzát, néha ollót is. Továbbá nagyon hasznos célszoftver a szakmánkban a felület modellek elkészítését segítő alkalmazás, ami ismeri a mobil és asztali operációs rendszerekben, illetve a webes környezetben alkalmazott felületi alapelemeket. Ezekkel az alkalmazásokkal elég gyorsan el lehet készíteni sok felület változatnak a prototípusát programozás nélkül, amik hasonló módon kattinthatóak és kipróbálhatóak, mint a majdan elkészülő végleges változat. Az szokásos feltételezéssel ellentétben grafikus rajzoló eszközök nem feltétlen szükségesek a tervező munkához.

Ez egy külön szakma, vagy elég, ha a fejlesztő-dizájner ért hozzá?

Külön szakma, mert más készségeket igényel, mint a programozóé. Sokszor önmagával kerül ellentmondásba a magát fejlesztő-dizájnernek valló kolléga, elmondom miért. A jó felületek fejlesztése általában megnöveli a ráfordítandó fejlesztési időt. Ez nem jelent problémát, mert később üzletileg megtérül. Viszont a fejlesztő úgy gondolkodik, hogy szeretné a fejlesztési feladatát minél egyszerűbben megoldani, ami az ő programozó irányultságú szemléletével teljesen érthető is. Ha ő tervezi a felületet is, akkor azt fogja tapasztalni, hogy vagy gyorsan csinálja meg vagy jól használhatóra, ugyanis a kettő gyakran fordítottan arányos egymással. Ilyenkor ha nincs külső kontroll, akkor üzleti szempontok lesznek figyelmen kívül hagyva a kódolás szempontjai miatt, aminek a végeredménye egy rosszul vagy nem annyira jól használható végtermék. Vannak azért kakukktojások, akik jó fejlesztők és UX designerek is egyben, de ez elég ritkaság. A két szerepkör olyan sok különböző jellegű feladatot takar, hogy külön embert kíván. Egy UX designer 5-10 fejlesztőt ki tud szolgálni.

Jelenleg sok esetben a fejlesztés után a cég tanfolyam keretében eladja a betanítást is. Ha megfelelő a használhatóság, ez kieshet?

A jó használhatóság nagy részben kiválthatja a tanfolyamokat. Van egy alapelv, ami szerint, "A felhasználók nem olvasnak dokumentációt!". Ezt, mint valami mantrát, ismételgetem a kollégáimnak, mert ha elhiszik, akkor könnyebben megértik, hogy mit miért csinálunk. Normális esetben egy szoftver használatát nem kell tanítani! Van sok fejlesztő cég, amelyik nem tartja fontosnak, hogy termékét a saját felhasználóira szabja, hogy azok különösebb fejtörés nélkül képesek legyenek működtetni. Ők a gyatra teljesítményüket próbálják ilyen tanfolyamokkal leplezni. Ez főleg egyedi fejlesztéseknél fordul elő, ahol a megrendelő elvárásai nem voltak teljesen tisztázottak, így a szerződésbe sem került bele ezzel kapcsolatos elvárás. Fogyasztók nagy tömegeinek készülő alkalmazás esetén erről szó sem lehet, mert mint mondtam tényként kezelhető, hogy nem olvasnak dokumentációt, illetve ha valamit nehéz használni, azt nem fogják használni. Érdekes módon már az is elrettenti őket, ha csak úgy látszik, hogy nehéz használni, ezért számít az első benyomás. Speciális iparágak, mint például a repülésirányítás szoftvereinél, ahol a kiemelt biztonsági előírások miatt sok idő telik el egy javított program verzió kiadásáig, ott nincs más megoldás, mint a pilótáknak megtanítani az éppen használt szoftver használhatósági hibáit és begyakoroltatni azok kiküszöbölésének módját. Nekik kell írásos dokumentáció, de nem ez az általános.

Egy felhasználói szempontból jól megtervezett felület alkalmas-e az olyan, monoton vagy gyorsaságot igénylő munkavégzésre, mint például az adatrögzítés, könyvelés, ahol az adatok bevitele során szinte fel sem néznek a gép előtt ülők?

Ilyen szoftvereknél éppen az lesz a felület jóságának mércéje, hogy vajon az adatrögzítők gyors munkáját is megfelelően támogatja-e. Ha a tipikus felhasználóink villámkezűek, akkor nem tehetjük meg, hogy ezt figyelmen kívül hagyjuk. Az igazi kihívás abban rejlik, hogy hogyan szolgálja ki egyszerre a gyors gépelőket és a kezdő felhasználókat a termék. Jelenleg épp ilyen projekten dolgozom, amiben látszólag ellentétes igényeket kell egyszerre kiszolgálni. Minden szoftvernek lehetnek kezdő, haladó és profi használói, akiknek az elvárásait, a felület különböző interakciós rétegeivel lehet tökéletesen lefedni. Például a profiknak kellenek gyorsbillentyűk, különleges működési módok, míg a kezdők számára jól érthető és egyszerű kifejezések és magyarázatok segítik a megértést első látásra.

Használati érték - ez mérhető-e? Kinek kell mérni, a fejlesztőnek? Felhasználónak? (gondolok itt arra, hogy én, mint felhasználó, "visszaadhatok-e" egy szoftvert, amennyiben azt nem tartom jól használhatónak)

Természetesen mérhető, nem csak egy ködös fogalom. Mérhető, hogy a felhasználók mennyi idő alatt tudnak elvégezni egy adott feladatot a programmal. Mennyit és milyen mértékű hibákat követnek el vele, ami szintén lehet a rossz felület miatt. Mennyire könnyen tudnak ezekből a hibákból "kimászni", milyen érzelmi állapotba kerülnek a használat során és még számos egyéb jellemzőt lehet vizsgálni. Ilyen, úgynevezett használhatósági teszteket rendszeresen csinálunk a tervezés során. A felhasználók kulcsszereplők, gyakorlatilag ők tesztelnek miközben megfigyelem a viselkedésüket. Ha van rá mód bevonom a fejlesztőket és tesztelőket is, mert nagyon hasznos tapasztalatokra tesznek szert, olyanokra, ami az egész csapat felhasználó központú gondolkodását elősegíti.

Csak buzdítani tudok mindenkit arra, hogy adja vissza a szoftvert, ha nem tarja elég használhatónak. Sőt nem csak a szoftvert. Magam már vittem vissza műszaki terméket emiatt. Szerencsére a szoftverek döntő többségénél lehetőség van az előzetes kipróbálásra. Ha a próbaidőszak alatt kiderülnek a használhatósági problémák, a vásárlásig már el sem jutunk. Kezeljük erős gyanúval, ha egy termékhez nem kínálnak ingyenes kipróbálási időszakot. Azok a gyártók, akik áldoztak arra, hogy szoftvereik használatát élménnyé tegyék, nem félnek az összehasonlítástól, mert joggal bíznak benne, hogy a vevő a próba alatt megszereti a terméket és megvásárolja azt

"Meg kell ismernünk a leendő felhasználók munka- és gondolkodásmenetét és szorosan együtt kell működni velük a tervezés és a fejlesztés alatt is." - mégis gyakran állnak elő a használhatóság szempontjából nem megfelelő igényekkel, valóban a Windows alapozta meg ezeket a rossz beidegződéseket?

Mivel a Windows-t nagyon sokan és régóta használják, a felhasználók megszokták a hibáit is. Beléjük ivódott és gyakran nem tudnak el képzelni jobbat. Emberi tulajdonságunk, hogy ha sokat látunk valamit akkor azt természetesnek véljük. A felhasználó által jól ismert felülettervezési minták más szoftvereknél igényként is felmerülhetnek a megrendelő részéről, akkor is, ha a konkrét feladat kapcsán jobb megoldás is lenne. Arra hivatkozik, hogy ő így szokta meg. Használhatósági szakértőként természetesen nem elégszem meg ilyen magyarázattal és megpróbálok olyan felületet létrehozni, amiről talán még a megrendelő sem tudja, hogy jobb lenne neki. A Windows 7 és idén már a 8 nagyon sokat lépett előre használhatóság tekintetében. Gyorsabban és kényelmesebben kezelhető, magam nem szívesen térnék vissza a Windows-os gépemen az XP-re.

A használhatósági problémák kijavítására van lehetőség utólag is?

Minden szoftverből lehet készíteni újabb verziót, amit a felhasználói szokások és szándékok felmérésével lehet megalapozni. A szoftvert webes szolgáltatásként (Software As a Service) kínáló cégek igyekeznek folyamatosan emelni a használhatóságot. Észrevétlenül is becsempésznek egy egy új megoldást a termékükbe. Tekintsük csak a Gmailt, az utóbbi öt év alatt jelentősen megváltozott a felülete úgy, hogy az alapkoncepciót, az egy személlyel folytatott azonos tárgyú levélváltás egy folyamban mutatását megtartotta, de közben egyre egyszerűbbé vált a használata.

Bemutatná-e a "Tisztázó visszakérdezés"-t? Miért jó ez?

Ez egy interjú technika, amely során addig kérdezem a felhasználót az általa végzett tevékenység mögöttes mozgató erőiről, amíg el nem jutunk a kiváltó okokhoz. Ezek általában olyan alapvető igények szoktak lenni, amelyekre az evolúciós fejlődés során tettünk szert és alig-alig változnak a történelem folyamán. Ilyen a biztonság iránti igény, a megbecsülés igénye, a szeretet vágy, a tudás és megértés iránti vágy, a sikeresen elvégzett munka öröme és hasonlók. Azért hasznos a technika, mert ha az alapigényt ismerve tervezhetem a felületet, akkor a felhasználó nagyon elégedett lesz az eredménnyel. Az adatrögzítő példájánál maradva; ha őt a bevitt adatok mennyisége alapján értékelik, akkor számára a kellően gyors bevitelt lehetővé tévő szoftver hozzájárul a megbecsültség érzéséhez, hiszen jó értékelést kaphat ezáltal a munkájára.

Interjú vége

Címkék: szoftver használhatóság felhasználó felhasználói élmény felület alapelv szoftverergonómia

Szólj hozzá!

A bejegyzés trackback címe:

http://juex.blog.hu/api/trackback/id/tr825459781

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

Nincsenek hozzászólások.