Miért beszélj a felhasználókkal mielőtt új projektbe kezdesz?
A termékmenedzser meglepődött: “de biztos csak erre használjátok a programunkat? Hisz annyi mindent tud még a nyilvántartás…”
“Nézd” – válaszolta a felhasználó – “mi valójában ezekkel a dolgokkal csak akkor foglalkozunk, amikor bekerülnek. Magát a nyilvántartást valójában a központi raktár kezeli, a vállalatirányítási rendszeren keresztül, ha egyszer oda bekerült valami, mi már nem tehetünk semmit, ezért minden olyan folyamatot, amit ti a nyilvántartásban vezettek, mi valójában előtte le kell hogy zongorázzuk, emailen, mert oda már csak a végeredményt vihetjük fel ugye.”
A termékmenedzser nem ezen lepődött meg. Hisz sorban a harmadik felhasználó volt a harmadik ügyfélnél, aki szinte szóról-szóra ezt mondta. Amin meglepődött, hogy mindegyik így csinálja, függetlenül az ügyfél méretétől, funkciójától. Holott a jogszabályok, a konkurens programok, az ő eddigi programjuk felépítése, minden amit az irodában ülve megtudhatott, mind mást sugallt eddig.
Egy felhasználói interjún ülünk éppen, az összes projektünk előtt kötelező 5 terepszemle egyikén, ahol egy létező asztali szoftver felhőbe költözésének apropóján tesszük felhasználóbarátabbá a rendszert.
A termékmenedzser a téma elismert szakértője, sok éves tapasztalattal a területen, mi UX tanácsadóként a tervezési folyamatokra figyelünk. A rendszernek van 27 menüpontja. Nem mérték eddig, de egyre erősebb a gyanú, valójában bevezetés után két héttel mindenki csak hármat használ ebből.
A fejlesztési üzletágvezető örült: hatalmas költségeket takarítunk meg, ha a maradék 24 menüpontot nem fejlesztjük le, legalábbis a piacradobás napjára: így is vinni fogják, hónapokkal előbb. A sales sokkal könnyebb, hisz rezonálni fogunk a problémákra. A felhasználók pedig végre nem kell, hogy a gondolkodásukat a gép köré csavarják, ezzel sok munkaórát spórol a vevő is, pedig az egyik épp most vesz fel egy gyakornokot, csak hogy a két logikát áthidalja – az újban erre remélhetőleg nem lesz szükség. Itt most “csak” ennyit spórolunk, meg persze a csoportos “brainstorming” értekezletek költségeit: egyesével interjúzva mindenkinek olcsóbb és hatékonyabb. Máskor ezek az interjúk cégek felemelkedését, hiányuk sokszor bukásukat okozták…
Hogy lehet, hogy erről eddig nem tudtak?
Az előző változatot még az alapján fejlesztették, amit valaki gondolt, hogy csinál a felhasználó, nem azt, amit ténylegesen csinál. Ezt a legtöbb magyar vállalat elköveti, felesleges költségekbe verve mind az elkészítést, mind a használatot – pusztán pár beszélgetés megúszásáért.
A terep és a felhasználó mindig tartogat meglepetéseket, főleg azoknak, akik azt gondolják, hogy az irodában ülve is ki lehet találni dolgokat; ez B2B környezetben nem szokott jól elsülni, de a legtöbb cég ezen ügyfelünkkel ellentétben arra se jön rá, hogy nem sült el jól, hisz sose mennek ki a végfelhasználóik közé, ahol az informatikai rendszerek hozzáadott értéke termelődik.
Egyszerűen van, ami máshogy nem megy: nem tudod a másik helyébe képzelni magad ha nem éled meg a helyzetét, ha nem vagy ott: a felhasználó fejével azért nem tudsz gondolkozni, mert az valaki más nyakán van és máshol, olyat tud, lát, hall, amit te nem, de csomó mindent nem tud amit te igen. Kellenek a személyes élmények ahhoz, hogy jó rendszert tudj tervezni.
Mitől lesz egy rendszer felhasználóbarát?
A “felhasználóbarát” nem egy üres fogalom, ahogy a UX se az. Szabványok, pontos módszertanok vonatkoznak rájuk, elemeiben, ahogy az örkényi papirkakoszorú, nem működik. Ha csak összekeverjük a hozzávalókat, nem figyelve a sorrendre, a receptre, elemeket behelyettesitve pótlékokkal, egy tiramisu se lesz “olyan”, hát még egy informatikai rendszer.
A felhasználóbarát tervezés ISO szabványának első pontja alapján felhasználóbarát rendszert úgy lehet tervezni, ha “a terv a felhasználók, céljaik és környezetük explicit megértésén alapul”.
Az explicit szó fontos: az íróasztalnál vagy tárgyalóasztalnál magukat a felhasználó helyébe képzelők itt kiesnek. Nem lehet „házon belül” UX-elni, ha a használat házon kívül történik.
Mit lehet tenni?
Elsősorban szerezni kell felhasználókat; bármi áron. “Szerezz nekem valakit, aki csinált már ilyet”, szoktam mondani, startup (amiket ismerek) enélkül piacon sikeres nem lett, de ahány pofáraesést láttam az évek során, döntően ezen vérzett el.
Ha új projektbe kezdesz, szerezz tehát 5 felhasználót, akivel beszélhetsz. Nem kell, hogy a meglévő rendszered felhasználói legyenek – lehet a konkurens szoftver felhasználója, de az is lehet, jelenleg papír-ceruza módszerekkel dolgozik.
Ne arról kérdezd, te milyen menő gyerek vagy a projekteddel együtt (biztos az vagy, de most nem te vagy az érdekes, nem visszaigazolást keresünk), hanem hogy ő hogy éli a mindennapjait, mit csinál, miért azt, miért úgy csinálja.
A szoftvervilág nem tud nagyot ugrani, akárhányan próbálják, pont azért, mert emberek használják. A ma felhasználói szokásai határozzák meg a holnapot, azon csak egy-egy elemet lehet változtatni egyszerre.
Persze attól, hogy egyszer elmentél a felhasználókhoz, még nem lesz jó az általad menedzselt szoftver. Hogy mi kell még hozzá, arról viszont legközelebb 🙂
Epilógus
Másnap a sales csapat egy másik gyárban ült ahol szóba került ez a modul is. A leendő ügyfél vezetője felhozta: “dolgozunk ilyen dolgokkal is, de ennek a nyilvántartásnak nagyon kicsavart a logikája” – “Igen” – mondta a termékmenedzser – “a következőben már máshogy lesz”, és elmondta azt, amit tegnap a felhasználótól hallott. “De hisz pont így csináljuk mi is”, kiáltott fel a menedzser, és ott helyben kérte, hogy adják el neki azt a modult is “de most még csak a régi van” – felelték – “az nem baj, amint kész az új, máris hozhatják, most aláírom a papírokat, mi vezetjük be elsőként”.
A cég történetében először adtak el úgy programot, hogy egy sort se írtak még meg.
