Nyilván minden projektben meg lehet és meg is kell találni azt a pontot, ahol hasznosnak érezheted magad. Igen, még egy brand site esetében is, viszont mindig is a szívem csücske volt az olyan feladat, amikor egy komoly problémára adhatok megoldást, amikor emberek munkáját és életét tehetem egyszerűbbé, könnyebbé. Mindezt azért írom, mert egy aktuális fps-es projektünk pont ilyen és ezen keresztül szeretném megvilágítani számodra, hogy az ügyféllel való egyeztetések és az irodában tervezgetés nem elegendő. A későbbiekben szándékosan ködösítek a projektet illetően, illetve a fotókat is elkentem itt-ott, nem kell mondanom miért.

Az ügyfél egy konkrét megkereséssel érkezett. Elmondta, hogy egy kórházi osztályon dolgozik és az eljövendő műtéteket szeretnék egy rendszerbe rögzíteni naptárszerűen. Jelenleg egy határidőnaplót használnak többen erre a célra. Ezt kellene leváltani. Pontosan elmondta mire van szüksége, skiccel, funkciókkal, adatokkal egyetemben és ajánlatot kért. Csinálhattuk volna ezen a ponton, hogy néhány egyeztetés után megvalósítjuk a kérését, de természetesen nem ezt az utat jártuk.

Let's go outside

Felemeltük a kis fenekünket az irodai székekről és kimentünk a kórházba. Beültünk többször, több órán keresztül a rendelésre, és valós helyzetben megfigyeltük mi történik, hogyan használják azt a bizonyos naplót, milyen körülmények között. Jöttek is sorjában a meglepetések. Kiderült, hogy nem is egy, hanem két napló van. :) Több helyiségben történnek a műtétek bejegyzései, sőt más, külső helyszínekről (rendelőkből) is. Telefonon hívogatják egymást, keresik a naplókat és kérik meg egymást arra, hogy írd be légyszi.

Fény derült arra az apróságra is, hogy nem is műtétek nyilvántartásáról és beosztásáról van szó, hanem csak azok előjegyzésről. Óriási különbség. Ráadásul a naplók már eleve felhasználói hackelés eredményei, tudniillik van egy monumentális és ennek megfelelően rendkívül lomha kórházi software rendszer, ami rendelkezik ilyen funckióval. Ez sajnos olyannyira lassú és használhatatlan a hétköznapokban erre a célra, hogy az ott dolgozóknak ki kellett találniuk valamit. Így születtek meg a naplók. Azokkal meg a korábban említett problémákon túl, olyan bökkenők vannak még, hogy egyrészt olvashatatlanok a bejegyzések (orvosok írása ugyebár), másrészt egyszerűen leragasztják és átírják egymás előjegyzéseit. Ezeken felül az egy napra előjegyezhető műtétek (és típusainak) maximum számát se lehet kontrollálni ebben a formában. Csendben jegyzem meg, hogy ebből kifolyólag – több ízben is –, a hónapokra előjegyzett műtét elmaradásáról, csupán előző nap értesül a beteg, és úgy teszik át műtétjét későbbi időpontra. Ilyenkor bizsereg bennem valami, jó dolgot lehet csinálni és jobbá lehet tenni az emberek életét.

Íme az egyik naplóról készített fotó:

Nem arról van szó, hogy a megrendelő/ügyfél (aki egyben maga is felhasználó) szándékosan félre akart volna vezetni minket. Sokkal inkább arról, hogy ő a saját perspektívájából szemléli a problémát, vagyis a tudás átka rajta van és már végig is gondolta valamilyen szinten a megoldást, amit közvetített felénk.

A legfontosabb volt megfigyelni magát a folyamatot, amibe illeszkedni fog az új megoldás, és aminek a lehető legjobban kell passzolnia a „beégett” és kialakult szokásrendszerbe. Az sem utolsó szempont, hogy magát a problémá(ka)t és annak gyökerét érthettük meg így. Mindezeken felül a majdani webes alkalmazást futtató környezetet is szemügyre tudtuk venni. Nem kell megfeledkezni arról sem, hogy a használt kifejezéseket, szófordulatokat is bőszen jegyzeteltük, figyeltük hogyan és milyen formában írják, rögzítik az adatokat, milyen egyéb software-eket használnak. Ezek köszönnek vissza az új rendszer felületén, hogy ismerős, intuitív legyen számukra.

Fotó a rendelésről:

A környezet elképesztően zajos, jellemző a fókuszhiány: állandóan csörögnek a telefonok, emberek jönnek-mennek, kérdeznek, papírokat adnak egymás kezébe, beszélnek a beteggel, egymással. Mindeközben használják a számítógépeket. Egyértelmű volt, hogy vizualitásban nagy betűméretet és jól látható interakciókat és visszajelzéseket kell alkalmazni. Mindenhol alapvetés, de itt kiemelkedő fontosságú az alkalmazás sebessége, a gyors használat. Funkcionális designra van szükség minden sallangtól mentesen. Ezt sem tudhattuk volna az irodában ücsörögve. Látnod kell, saját szemeddel a kontextust!

Szóval fotódokumentáltunk, figyeltünk, kérdeztünk, jegyzeteltünk. Aztán persze a későbbiekben prototípus készült, amit teszteltünk a tényleges felhasználókkal, majd magát a webes alkalmazást szintén teszteltük velük, méghozzá éles helyzetben, a saját környezetében. Ez utóbbi kardinális. Hiába a belső funkcionális tesztelés, esnek ki olyan problémák, amire nem gondoltunk, de nem is gondolhattunk. Most startol a rendszer és naná, hogy tesztelni fogjuk még…

Szóval, menjetek terepre, figyeljétek meg a felhasználókat, beszéljetek velük, enélkül csak egy újabb hacket hoztok létre, amit rövid időn belül le kell váltani, vagy ha nem is, akkor nem segítesz a megoldással, hanem újabb nyűgöt varrsz az emberek nyakába.

Zárásként költői kérdésem:

Mi lenne, ha a több milliárdos software rendszeren már eleve dolgoztak volna UX-esek?