Users First

Az internetes korban annyi információnk van, hogy hajlamosak vagyunk autoritív módon gondolkodni. 

A véleményeket nem támasztjuk alá, nincsenek érveink: sok esetben csak kölcsönvesszük őket. Ha nem értesz velem egyet, "nem vagy velem", frontvonalak húzódnak, a vita a legritkább esetben nyugszik szakmai érveken. 

Ezért a legtöbb dolgozatomban (prezentációk, jelentések, akár sima e-mailek) a szövegeknek ott az indoklása is: Nielsen-felmérések eredményei, a projekt interjúiból idézetek, vagy épp szakirodalmi hivatkozások - és ott se mindenre. A címzett számára elérhető szakirodalom (nem csak nyelvében, beszerezhetőségében, de mélységében is annak kell lennie!) is gyakran fel van tüntetve.

"Radikális" vagyok, szeretek visszamenni a gyökerekhez: a UX minden mozdulatát az emberek kognitív és biológiai képességeiből eredeztetni, a felületet az interjún elhangzott igényekből, és nem vagyok hajlandó holmi divatnak bedőlni.

Ez kell a konzisztenciához: az ember nem változik. Ahogy Rams mondja, a jó dizájn időtálló. 

Egyszer egy munkatárs megkérdezte:

- Ádám, te miért ceruzával és vonalzóval tervezel még mindig? Nem csak a gépeset adod le úgyis?

- De, de azt akarom, hogy minden egyes ceruzavonásnak költsége legyen.

Amikor Jobs, Ive, Rams, Spiekermann, Alexander interjúkat nézek (hogy ne csak dizájndolgok legyenek itt: igaz ez a Dijsktra interjúkra is) akkor mindig ugyanez a radikális szemlélet köszön rám vissza: míg a mai dizájn valamiféle egyeztetések-kompromisszumok halmaza (a személyes játékok kiszolgálása), addig ezeknek az embereknek a világa mindent igyekszik a gyökereket folyamatosan szem előtt tartani, és távol tartani maguktól a terméket magát: nem az a kérdés, "igazam van-e", hanem hogy azok az elvek, amelyek mentén játszunk, mennyire teljesülnek.

Ezeket az elveket senki nem vonja kétségbe. A mindennapi kommunikációban azonban - legalábbis Közép-Európában - valahogy elsikkadnak a kiszolgálás mellett. Nem véletlenül mondja Conway: egy számítógépes szoftver struktúráját a létrehozó szervezet belső kapcsolatrendszere határozza meg!

Persze van, amikor ezek az elvek ütköznek: Astriddal néha napokat vitatkoztunk, ha a térképészet és a UX igényei nem találkoztak egymással. Délután 4-kor elkezdtük, folytattuk hajnali 2-ig, mindenki elment aludni, fél 9-kor bementünk a melóhelyünkre, és folytattuk tovább. 

De ennek van értelme. A "nem hiszem, hogy erre a feladatra alkalmazható lenne a SCRUM, mert nincsenek iterációink" mondatra viszont itthon az a válasz, hogy "akkor nem vagyunk barátok".

Így működünk. De ez ellen nincs más ellenszer, csak az oktatás. Addig viszont keresnem kéne valami barlangot, vagy csak egy sarkot, ahol lehet vitázni...

Ugye ismerjük a mantrát: "The Content is The Interface" - de mindig jó ez a felhasználóknak?

A 90-es évek elfeledett hőse*, Tog szerint nem: az oka pedig az állandó pozíció és láthatóság hiánya.

Mindig furán nézek, amikor egy webapp scrolloz: számomra egy alkalmazásnak stabil toolbar-ja (eszköztára) van, amit bármikor elérhetek. A facebook esetén amúgy ez adott: ha tetszik, ha nem, a legtöbbet használt funkciók folyamatosan elérhetőek maradnak.

A Facebook legfontosabb 3 gombja mindig velünk marad

Ez nem mindig szükséges választás: akkor kell, ha egy naponta használt alkalmazásról beszélünk. 

Akkor ugyanis előjönnek azok a reflexszerű mozdulatok, amit az angol "muscle memory"-nak, izomemlékezetnek hív. Azaz, gyakorlatilag anélkül, hogy odanéznék, reflexszerűen viszem a kezem a célterületre, és kattintok.

Bár minden valószínűség szerint az emberi agyban hamar kialakul az egér kezelése is, ez touch eszközöknél még a szokásosnál is fontosabb: egy touch eszközt rendszerint egy-két féleképpen tartunk, tehát a relatív fizikai térben kéne állandó pozíciónak lennie, nem csak a tartalom síkjában!

Jó kérdés, a felfele scrollozás kialakít-e egyfajta helyérzetet, ami alapján ezt a műveletet képesek lennénk megtenni úgy is, hogy felscrollozunk az oldal tetejére, majd lekattintjuk a menüpontot. Tartok tőle, hogy nem.

EPAM Requirements Tracker (2010): persze, úgy néz ki, mintha egyenesen a Windows elevenedett volna meg weben, de úgy van tervezve, hogy minden reflexszerűen kézreálljon.

Amikor az EPAM-nál meguntam a papír checklistek használatát, gyorsan - az ügyfél eltűnt 1-2 napra, ennyi időnk volt - lefejlesztettem egy alkalmazást, hogy gyorsan fel lehessen vinni a követelményeket (hosszú, hogy miért nem szabadott Jira-ba vinni). Ez is, és sok más intranet alkalmazásom stabil, nem scrollozó eszköztárral rendelkezett, a fontosabb gombokhoz ikonnal. 

Fel se merült bennem, hogy másképp is lehetne: ezeket a gombokat napi szinten többször meg kellett nyomnom, zavaró lett volna, hogy minden egyes alkalommal felscrollozzak.

Hasonlóan a CognoLink belső keresője is állandó elemekként tartalmazta azokat, amiket a tartalomtól függetlenül sokat kellett használni. 

Jó, ronda, nem úgy néz ki mint egy weboldal, nem ez volt az érdekes. Az volt az érdekes, hogy odaültél egy kolléga mellé egy kávéval / teával, és 20 percig nézted, mit csinál. Ha azt láttad, hogy

minden egyes elemhez

1. felscrollozik,
2. megáll egy pillanatra(!),
3. megkeresi a menüelemet, 
4. rákattint, elvégzi a műveletet, 
5. visszascrolloz az előző elem alá

akkor tudtad, hogy valami nem stimmel: hiszen meg kellett állnia gondolkozni!

Naponta fejenként átlag 8-szor használták ezt a szolgáltatást (tehát kb. óránként), akkor 4-10 elemet választottak ki a listából. Finoman szólva unalmas lehetett.

Mégegyszer mondom: ez a szabály nem mindig érvényes: napi használatú alkalmazásoknál azonban a szépérzékünket, és a "weben így szoktuk" gondolkodásmódot jobb, ha felülirja egyszer-egyszer a praktikum.

* Bruce "Tog" Tognazzini a 90-es évek híres interfész-specialistája, ma a hazánkban inkább Nielsenen keresztül ismert Nielsen-Norman Group partnere. Ő találta ki pl., hogy a Mac OS alkalmazások látszólag egyetlen fájlként viselkedjenek, lehetővé téve ezzel egyszerű telepítésüket és eltávolításukat. Dolgozott a Sun-nak és a WebMD-nek is. 

A weboldalak, szoftverek nagy részét konzumer kiszolgálásra tervezzük, a felhasználóknak nincs különösebb speciális háttérismeretük az adott témáról. De mi van akkor, ha ez nem áll?

most pedig koncentráljunk erősen arra, mit gondolna ilyenkor a felhasználó...

Mindig szükséges hogy ne csak magunktól kérdezzük meg, mit csinálnánk, mire lenne nekünk jó az oldal. Ugyanígy fontos, hogy a végterméket se csak magunkon teszteljük.

Ha a háttérismeret nem fontos tényező, vagy könnyen elérhető csoportról van szó, egyszerűen előkapok barátokat, vagy a kávézóba a kezébe nyomom a mobilomat véletlenszerűen valakinek (igen, a törzshelyemen ehhez van pofám, nyilván olyan hely is kell). De egyre több projekt van ami szakembereknek, rétegközönségeknek szól. 

Két történetem van a hétről

Az első történet főszereplője egy szó szerint fehérköpenyes tudósoknak készült szak-szoftver honlapja. 

Az első, ami feltűnt rajt, hogy oldalt ki volt írva, a "miért válasszon minket" szlogen alatt: "mert user-friendly!" - mondom, igen? Akkor ezt miért kell kiírni? Ráadásul "intuitív" is, hisz rögtön ezalatt "első látásra használható"!

Sajnos a "heurisztika" azt mondatja velem, hogy az állítás nem állja meg a helyét: már magában a szoftverben is volt felesleges informatikai kifejezés, a honlapon pedig egyenesen olyan "fícsörök" szerepeltek, amiket a műegyetemen informatikusként a képzés utolsó két évéig nem is hallottunk.

Túl a megfelelő nyelvezeten és a tesztelés fontosságán: bármely User Centered Design módszer egyes melléktermékei jól használhatóak marketinganyagként is: a storyboardjainkból prezentációk, reklámok lettek, a perszónák céljaiból szlogenek, más anyagokból szolgáltatásbemutató videók. Ezen az oldalon a nyomát se lehetett látni ezeknek...

Barátaim körében kerestem és találtam is azonos piacon mozgó szakembert (köszi, Feri!), ennek segítségével sikerült a költségeken belül megoldást javasolnunk nekik a honlap rendbetételére.

A másik történet szereplői nagyvállalatok magasrangú vezetőinek szolgáltató cég. A brief szerint a honlapnak közvetítenie kell közvetlenségüket, emberközpontúságukat, személyes kapcsolatukat a piaccal

Itt első körben azt mondtam: szeretnék meginterjúztatni néhány embert, akik közvetlen ügyfélkapcsolatban állnak. "Hát azt nem lehet". Mondom, miért? "nem lehet."

Itt jött képbe, hogy oké, akkor részletes célközönségprofilokat kérek és ez alapján keresünk ügyfeleket. 

User nélkül ugyanis nem megy. Ülhetek én itt a karosszékben és kitalálhatok dolgokat, de ha nem ütköztetem ezt a véleményemet másokkal - lehetőleg olyanokkal, akik akár használnák is a szolgáltatást - akkor úgy járok, mint a tudósoknak szolgáltató cég, amely önmaga rakta össze "user-friendly" szoftverét.

Jó lenne egy amolyan User Experience Expert Network. Az Expert Network olyan cég, amely kért tapasztalatokkal rendelkező emberekkel biztosít konzultációs lehetőséget telefonon, vagy személyesen. Tipikusan befektetési bankoknak teszik ezt, így ha valaki mondjuk nem tudja, a szíriai harcok miatt érdemes-e olajba fektetnie, kérhet konzultációt valakitől, aki ott dolgozik - és pár órán belül már beszélhet is valamelyik közel-keleti olajipari cég magasrangú vezetőjével.

Sajnos volt munkáltatóm, a CognoLink, bár zavarbaejtően jó hatékonysággal teszi ezt, az áraik nem feltétlenül erre a viszonylatra vannak tervezve, mégha a saját piacukon nem is drágák. Valamint nekünk sokszor elegendő lenne az egyszeri könyvvizsgáló, vegyész, térképész stb is, nem menedzserekkel szeretnénk beszélgetni, hanem felhasználókkal.

Addig viszont marad a minden egyes nem-konzumer projekt elején kétségbeesett keresés az ismerősi körben, hátha valaki ismer olyat, aki...

(Képek forrása: Tara Mackey / sxc )

A See What I Mean egy egész jó kis könyv Storyboardingról, a képregények "ipari" felhasználásáról. Nem célja felsorakozni a kötelezők - McCloud és Eisner - mellé, de mindenképp egy hasznos bevezető mind a képregényírásról, mind ennek ipari alkalmazásairól.

A List Apart mellékletében talált részlet fordítása következik magyarul (de jelent meg részlet belőle a Smashing-on is)

A fordítás átnézéséért, javaslataiért köszönet Anónak!

Nagy munkában ég az Onlinemarketing.hu, B2B szoftvert tervezünk!

Részleteket persze nem mondhatok, de alapvetően néhány folyamatot próbálunk egyszerűsíteni az ügyfeleinknek. 

(Ez csak a vázlat..) 

Egy ilyen munka mindig a célközönség definiálásával kezdődik, ami UX-es módszertanban perszónákat jelent. Őszintén megmondom, nem készültek külön mélyinterjúk ügyfelekkel a perszónák létrehozásához: eleget beszélek, interjúzok velük minden más ügyben. Legfeljebb annyi történt, hogy amíg Konrád beszélt, igyekeztem ezzel a szemmel is figyelni a reakciókat, esetleg egy-két ártatlannak tűnő mellékes kérdést tettem fel.

Ezután összeültünk a vezetőséggel, és megvitattuk ezen perszónák igényeit, rajzoltunk pár nagyon egyszerű filctollas wireframe-et közösen.

Az elkészült wireframe-eket azonban ehhez a dokumentumhoz még nem használtam fel.

A számítógép ugyanis egy interaktív médium, a hangsúly a folyamatokon van. Hiszek abban, hogy a dolgok egymásra következése sokkal jobban számít nagytotálban, mint hogy konkrétan mi is van a képernyőn. Az, hogy a felhasználó milyen kulcsképernyőkkel, milyen e-mailekkel (!) találkozik, milyen döntésének milyen következményei lesznek az interakció további menetére vonatkozóan sokkal jobban számít, mint hogy pontosan milyen elemek is szükségesek ehhez a döntéshez - azzal is foglalkozunk, előtte ÉS utána.

Az itt használt ábrarendszer megkülönböztet 

• fő forgatókönyvet
• mellékforgatókönyveket
• felhasználói kulcsképernyőt
• felhasználói értesítést
• adminisztrációs kulcsképernyőt
• adminisztrációs értesítést.

Bármennyire is szeretnénk, ez utóbbi kettőn hajlamosak leszünk vágni: nem cél se a mobilkompatibilitásuk, se a tipográfiai egységességük. Mentségünkre legyen mondva: magunkat szivatjuk a puritán, jól kezelhető de kidolgozatlan felületekkel, nincsenek adminisztrátorhadak akik 8 órában szenvednek ezzel...

Csak és kizárólag a folyamatokban szereplő képernyők alapján állhat össze az oldaltérkép, oldalstruktúra. A felhasználó nem azért jött, hogy a menüt nézze, hanem hogy a céljait elérje. A térkép csak ahhoz kell, hogy megtalálja az ehhez szükséges ajtókat, de először azt kell tisztázni, hány szobán is kell átmennie annak, aki a király fele lányát szeretné?

Az oldaltérkép (sitemap) már betekintést nyújt a projekt méreteibe - de ha irtani akarunk, akkor nem az oldalakat írtjuk!

Irtani csak úgy lehet, hogy vagy kevesebb folyamatot támogatunk (pl. nem lehet majd cukorkát venni az oldalon mégse), vagy a folyamatokat próbáljuk meg egyszerűsíteni, egységesíteni. 

Ezekhez készül aztán el wireframe: mind asztali, mind mobil változatban.

Az RWD ugyanis nem jelent egyszerűsítést tervezési szempontból: mi felhasználói élményt tervezünk, azaz meg kell terveznünk a mobilélményt és az asztali élményt is. A többiről csak reméljük, ez a kettő (vagy több) kifeszíti jól azt a teret, ahol az élmény jó, élvezhető.

A Mobile First nem lehet ekvivalens azzal, hogy megtervezzük mobilra, asztalon a maradék  90%-nak meg majd valamilyen lesz. Nyilván nem fogunk külön explorer és firefox élményt tervezni, ha nem muszáj, de valamilyen szintig végig kell gondolnunk a média különbözőségét, legyen az mobil, tablet, vagy felolvasóprogram.

Ha nem is mindenben dupla a RWD, jelentős többletterhet okoz. Gondolni kell persze a színvakokra is, meg egy csomó más dologra, de a leginkáb az a fontos, hogy a többféle találkozási mód többféle interakciót, így több élményt, több tervezést jelent.

Imádom az iPademet. Gyerekkoromban mindig arról ábrándoztam, hogy majd rajztábla méretű számítógépek lesznek, amik hol zongorává, hol rajzasztallá, hol jegyzettömbbé válnak, mikor mire van szükség, de lehet rajt fényképeket is kezelni.

Paper prototyping iPaden (szó szerint)

Az iPad ennek a valósága.

Viszont amikor először próbáltam használni a szövegszerkesztőjét - Pages - rájöttem, nagyon kényelmetlen a billentyűzet-részről felemelni a kezem, és ott megérinteni a formázógombokat. 

Nagyon kényelmetlen átnyúlni a tartalmon

Azt gondoltam, billentyűzettel, kitámasztóval talán kényelmesebb, de nem: a billentyűzetről a képernyőre váltani még a virtuális billentyűzésnél is kényelmetlenebb.

Nem megoldások a MarkDown-szerű nyelvek se, hisz ehhez üzemmódot kell váltani a billentyűzeten.

A régi időkben az ilyesmiket funkcióbillentyűkhöz rendeltük, és aranyos matricák voltak arra hogy mi mit jelent, pl. itt:

Egy IBM POS billentyűzet cserélhető funkcióbillentyű-feliratokkal

Van megoldás: csináljunk szerkesztőlécet! Ilyet látunk pl. a LogMeIn felületén is:

A LogMein iPad kliense a funkcióbillentyűket egy szerkesztőlécre rakta

Na de hol legyenek pontosan a gombok? Ahol kényelmes! Hol kényelmes? Nézzük meg...

1. Fogtam egy A4-es papírt, félbehajtottam, s ráraktam az iPadre.
2. Az iPaden bekapcsoltam a billentyűzetet, s igyekeztem átrajzolni (figyelni kell: ha nem csak a ceruzával érsz a papírhoz, nyomásnak érzi, ha nem érsz hozzá sokáig, kikapcsol)
3. Felérajzoltam egy lécet
4. ismét az iPad fölé tartva a lapot, megpróbáltam megtalálni azt a pontot, ahol kényelmes lenne a gyakran használt félkövérítés és döntés gomb
5. Megpróbáltam megkeresni, hol lenne értelme a stílusok menüjének (felugrana vagy legyező-szerűen terülne szét?), a képfeltöltésnek (vajon hová tennénk az ablakot), ésatöbbi.

Ezután az egészet megírtam HTML/JavaScript-ben. A legnehezebb azt volt megtalálni, melyik esemény fut le, amikor megjelenik egy billentyűzet (jelenleg a focus és blur eseményeken van, de voltak más variációk is, ez annyira nem megbízható)

A HTML/JavaScript prototípus 

Sajna a keresőlécet nem lehet leírtani egy webes alkalmazásról iPaden, de egy natív alkalmazás ezt megtehetné.

1-2 embernek kezébe adtam, pár percet gépelgettek rajt, remélhetőleg sikerült jól eltalálnom a méretet.

Legszívesebben egy blog.hu alkalmazást látnék, dehát ugye a bloghu számára az iPad egyelőre nem létezik...

Ha van iPaded, nyugodtan próbáld ki a demót te is. Mi a véleményetek?

Azt hiszem, a UX Booth cikke a két agyról talán az egyik legfontosabb cikk az elmúlt évben, amit UX-ről írtak, és sokszor kell majd elmesélnünk programozóknak.

Miért hülyék az emberek?

Vegyünk egy egyszerű matekpéldát, és kérlek, kapásból vágd rá a választ magadban, vagy ha teheted, hangosan is:

Egy baseball ütő és egy labda együtt 110 dollárba kerül. Az ütő 100 dollárral több mint a labda. Mennyibe kerül a labda?

A legtöbben azt válaszolnák, 10 dollárba. Ekkor azonban a kettő együtt már százhúszba kerülne, így a helyes megoldás az, hogy ötbe.

Az emberek többsége az esetek többségében "robotpilóta" üzemmódban él: az agyuk egy, az alapvető dolgokhoz szükséges alacsony aktivitási szinten üzemel. Ez valamelyest tanítható a napi rutin elvégzéséhez, komplexebb matematikai műveletekre azonban pl. alkalmatlan (kivéve, ha Esőember-szerű autista vagy).

Persze egy ilyen egyszerű feladatot mindenki meg tud oldani, ehhez azonban észre kell vennie hogy "vészhelyzet van", és fel kell ébresztenie az igazi pilótát, avagy: meg kell állni gondolkozni! Amíg nem érződik fontosnak a kérdés, a gondolkodni képes pilóta nem ébred fel. **

Így van hát, hogy "csak krízishelyzetekben vagyunk valódi önmagunk" *.

Miért fontos ezt elmondani a programozóknak?

A jó programozó onnan ismerkszik meg, hogy minél kevesebbet fut a robotpilótája. Egy jó programozó folyamatosan átgondolt, végiggondolt döntéseket hoz, ez az, ami igazán jó programozóvá teszi őt.

Mi több: mind egyetemi vizsgái, mind a céges felvételik ezt a tulajdonságot keresik benne. Tudom: voltam olyan vizsgán, ahol pályatársamat "magolásért" vágták ki (tudta az anyagot, de csak robotpilótáját tanította be rá), és több mint száz szakmai felvételit vezettem, és sok-sok interjún vettem részt. 

Ebből következően a jó programozó hajlamos abba a hibába esni, hogy

• úgy hiszi, ő mindig ilyen (nem, bár az átlagnál többször)
• úgy hiszi, mások is ilyenek, kivéve a nagyonhülyéket

Mivel egy programozó barátai is olyanok közül kerülnek ki, akiknek keveset fut a robotpilótája, és kedvesét is hajlamos eszerint választani, egész környezete ezt fogja sugallni.

Mik ennek a következményei a programra nézve?

Ahogy Krug is elmondta: ne törjük a felhasználó fejét! Biztos van olyan része a programnak, ahol muszáj gondolkozni, muszáj figyelni, de az összes másodlagos funkciót, ill. a lényeghez odajutást muszáj, hogy robotpilótával képes legyen bárki megtenni! 

Az emberek amikor kinyitnak egy adott programot, céljuk van. Az nem feltétlenül baj, ha a célhoz érve észnél kell lenni, de a célhoz vezető úton utálnak ők vezetni! 

Az se baj, ha a korlátos számú vészhelyzet esetén észnél kell lenni (ilyen pl. amikor az előttünk haladó autóban hirtelen valaki padlóféket nyom), de pl. jeges úton senki sem szeret vezetni, mert folyamatosan észnél kell lenni!

Szóval szinte az összes olyan usability szabályt amit elmondunk, azt azért mondjuk, mert a robotpilóta ennyire képes. Lehet, hogy amúgy a delikvens képes lenne megoldani a feladatot, de nem szeret, nem akar figyelni! Tartsuk tiszteletben az igényét, és kérjük a figyelmet akkor, amikor tényleg szükség van rá.

* évek óta keresem az idézet forrását, rémlik hogy Kant de nem találom.. a sárga, középiskolás Filozófiai Olvasókönyvből számazik

** Közben Judit (Pónya) figyelmeztet, krízishelyzetekben se feltétlen kapcsol ki a robotpilóta: valóban. Nem tudom, mi váltja ki a robotpilótában hogy kikapcsoljon, azt azért tudjuk, hogy bizonyos kérdésekben, bizonyos helyzetekben, bizonyos események hatására sokakban kikapcsol, pontosabban átadja az irányítást a cikkben "második rendszernek" nevezett gondolkodásnak.

A jó rendszer az, amely képessé tesz jobbá tenni a világot.

Mindannyian szeretnénk jó rendszereket építeni, ki szeretne olyan rendszert, amitől a világ rosszabb hely lesz, nem igaz?

Már a 90-es években szerelmes voltam a utility appokba - akkor még senki nem gondolta, hogy ezek tényleg meg fogják változtatni az életünket...

Azért tanultam informatikát, hogy segíthessek az embereknek jobbá tenni a világot szoftvereken keresztül. Amikor a jo-hely projektet vezettem, a célunk nem az volt, hogy menő gyerekek legyünk a suliban, hanem hogy jobban megértsük mi magunk a várost, annak dinamikáját. 

De az évek során két dolgot vettem észre:

• A fejlesztők nem foglalkoznak a felhasználókkal
• A fejlesztők nem határozzák meg a szoftver alapvető működését

Nincs annál rosszabb, amikor fejlesztőként "hülyeséget" kell implementálnod: valamit, amiről tudod, hogy nem lesz jó senkinek, esetleg tudod, hogy valamilyen szempontból ez megnehezíti majd a jövőben az előrelépést.

A fejlesztőknek nincs kontrolljuk az általuk készített szoftver felett, illetve ami van, azt se használják ki: a fejlesztők tapasztalatlan emberek által írt végiggondolatlan specifikációkat öntenek egy, a gyakorlatban meglehetősen merev formába: ki ne hallotta volna már, "tudjuk, hogy ez így rossz, de most már kész van, hagyjuk így"?

Persze nem szeretnék mindig a UX pártján se lenni: nagyon sok interakciótervező a saját kis mániáit próbálja meg ráhúzni a rendszerre, esetleg tervez nagyon látványos, ámde rendkívül kényelmetlen felületeket.

Nem szerettem azokat a beszélgetéseket, amik arról szóltak, hogy mások hülyeségeit, legyen az menedzser (leggyakoribb eset), vagy csak egy tehetségtelen dizájner (ilyen is van sajna) hogy valósítsam meg. Persze, elő-előfordultak olyan esetek, ahol értelmes, nyitott emberekkel sikerült dolgozni, de legalábbis olyannal,aki a felhasználónak akart jót: akkor könnyedén befogtam a számat.

A felhasználók se mindig tudják, mi lenne a jó nekik és sajnos néha a prototípus se elég. Gondolni kell arra is, hogy lesz valami időtálló, nem tervezhetünk mindent csak a mának.

De mégis, az a vágy, hogy kontrollom legyen afelett, hogy milyen termék kerül ki a kezeim közül, hogy kontrollom legyen afelett, az emberek szeretik vagy utálják-e a kezeim közül kikerült terméket, ez vezetett ahhoz, hogy tavaly - 12 év után - feladtam a fejlesztést, és az addig csak hobbiból űzött UX felé vettem az irányt.

Sokkal kevesebb UX dizájnert keresnek mint fejlesztőt, sokkal kevesebb emberben merül fel az igény, hogy szüksége van UX-re így sokkal nehezebb találni is melókat.

De a cél továbbra is az, mint 12 évesen, amikor eldöntöttem, informatikus leszek: szeretnék olyan szoftvereket építeni, amivel mások jobbá tehetik a saját világukat. Ez a módja, talán, remélem.

Csütörtökön írtam az előkészítésről, gondoltam, most írok picit a tesztelésről is.

Ott tartottunk, hogy az ügyféltől jött egy kérdés: "jó-e ez a menü?", és mellékelve egy excelfájl. A probléma az, hogy az ügyfélnél még nem sikerült összeszedni a perszónákat, illetve amilyen információkat sikerült összeszednünk (ügyfélszolgálaton gyakran ismételt kérdések, mélyinterjúk ügyfélközeli emberekkel), az alapján a tervezett honlap nem fedte az ügyfélkör igényeit, gondolkodásmódját.

Ha a tájépítész lehet "pártos", ahogy Csemez professzor úr írta az építészfórumon, úgy a UX dizájner is pártos: mindig a felhasználó pártján állunk.

Szóval odaállítottunk ezzel az ábrával:

És mondtuk, hogy a következő lépések szükségesek:

• Rájönni, kinek szól az oldal
• Rájönni, ezek az emberek miért nyitják meg az oldalt
• Összeszedni ezekből a kérdésekből, ami az emberek fejében ilyenkor felmerül egy (reprezentatív) maroknyit
• Találni néhány tucat olyan embert, akik rendkívül hasonlítanak azokra, akiknek szól az oldal.

Tehát gyakorlatilag arra próbáltuk használni a treejack-et, hogy az oldal tényleges tervezése elkezdődhessen.

Itt elmondtuk a klasszikus kulcsmondatokat, pl. hogy "ez nem a facebook. Ide nem azért jönnek, hogy elolvassák, hátha van valami újdonság", vagy hogy "amikor feljönnek egy ilyen honlapra, konkrét dologról akarnak tájékozódni, nem csak úgy nézelődni".

A treejack arra teljesen jó volt, hogy előkészítésképp sikerült felrajzolni 3 perszónát, amik az oldal célközönségeit az eddigi ismereteink alapján jól reprezentálják, és sikerült felrajzolni a leggyakoribb perszóna ügyféléletciklusát. (Customer journey). 

A perszónák általános és az életciklus állomásokhoz (pl. ajánlatot akar kérni, már ügyfél) kapcsolódó különböző céljaival már sikerült pár kérdést összeszednünk, amiből a teszthez 10-et szűrtünk le.

Tesztelőket sikerült gyorsan szerezni (köszi, Balázs!).

Amint megvoltak a kérdések, maga a teszt, 100, reprezentációs kritériumok alapján választott emberre nagyjából 3 óra alatt teljesen lefutott.

Tehát a treejack-kel viszonylag olcsón, és rendkívül gyorsan, a tervezési szakasz folyamán meg tudtuk mutatni, hogy a bizottságilag, a különböző részlegek által egyeztetett menüstruktúra (ami, nem meglepő módon, hasonlított a vállalat belső felépítésére) az ügyféligényeknek kevésbé felel meg.

Nagyon sokan választották például az "infovonal" menüpontot: ez olyan, mint a Legyen Ön is Milliomosban a telefonos segítség: Nem tudom mit válasszak az opciók közül, felhívok valakit. 

Nagyon számítottak arra, hogy sok kérdést a GYIK-ben fognak keresni az emberek. Nem így lett. A kapcsolódó interjús tesztekben (magát a tesztet is teszteltük ugyanis!) a tesztelő felhasználó azt találta mondani, "Nem szoktam használni a GYIK-eket, mert a kérdések általában életszerűtlenek, sosincs közük ahhoz, amit valójában akarok kérdezni." Persze eleve rossz jel, ha a gyakran felmerülő kérdések többségét a Gyakran Ismételt Kérdések rovattal szeretnénk megoldani...

Hasonló sorsa jutnak a mindenféle "Tudnivalók" rovatok. Az embereknek az egész weboldal jelenti a tudástárat! A különböző közmegegyezéses nevek - mégha egyszerűek is - nem működnek, hisz a sok ezer potenciális ügyfelünk nem volt ott azokon a megbeszéléseken, ahol ez a közmegegyezés megszületett, akkor se, ha az egész vállalat igen. Azt elképzelhetőnek tartom (bár ezt itt nem teszteltük), hogy meglévő ügyfelek esetén már óvatosan alkalmazhatunk bizonyos közmegegyezéseket, esetleg használhatunk magyarázó anyagokat. Érdeklődők esetén azonban ez nincs így.

Mindezek ellenére egy ilyen honlap felhasználóbaráttá tétele nem egyszerű, de nem közvetlenül ezek miatt: kell ugyanis valaki, aki a felhasználók "nagykövete" a cégen belül, lehetőleg egy befolyásos részlegvezető, igazgató. Szerencsés esetben többségben vannak azok az emberek, akik a felhasználó érdekeit tartják szem előtt, de ha nem, kell valaki, aki erre folyamatosan felhívja a figyelmet, akinek a felhasználókutatás a keze alá tud dolgozni.

Persze mi is követtünk el módszertani hibákat, figyelni kell hogy csak a menüszerkezetet teszteljük, vagy esetleg a főoldal tartalmi elemeit is, figyelni kell a megnevezésekre, stb. Legközelebb okosabbak leszünk...

Összességében a teszt jól sikerült, reméljük, még sokszor adódik majd rá lehetőségünk.

Megkaptuk ugye a Treejack licenszet - ezúton is köszi! - és ehhez kapcsolódóan el kellett készítenem néhány dokumentumot.

(szerk: a cikk két hetes, azóta az első Treejack tesztünk is lefutott, erről nemsokára bővebben :)

Mi ugye marketingcég vagyunk, így olyan anyagokkal igyekeztem eladni a cégen belül az új lehetőséget, ami később is használható.

Először is, amikor elküldtem ujjongó levelemet, készítettem egy FAQ-t, hogy mi ez, mire jó, és mi kinél, hogyan fogjuk használni.

Mit kaptunk?

Egy három hónapos treejack előfizut, május 14-ig él

Ez mennyit ér?

350 dollár, nagyjából 80 000 Ft

Mi az a TreeJack?

Nagy weboldalak menürendszerének tesztelésére szolgáló eszköz

Hol tudjuk használni?

(konkrét ügyfélnevek), de akár közepesen nagy webshopokhoz is

Mi kell hozzá?

Leginkább célközönséges traffic, kb. 100 ember tesztenként.

Hogy működik?

Hasonlóan mint a ma már látott chalkmark, csak ezúttal kinyitható menükbe kell az illetőnek megtalálnia a feladathoz szükséges menüelemet.

Ez nekünk miért jó? Ez hülyeség, nem?

Nem az, a statisztikái miatt érdekesek

Ez csak utólag használható?

Nem, sőt, ajánlott előre, a weboldal készítése közben használni.

Hol tudok ennek utánanézni?

http://www.optimalworkshop.com/treejack.htm a termék oldala

See the results as a UX researcher egy mintastatisztika

Aztán készült egy prezentáció arról, hogy milyen eszközöket kínál az OptimalWorkshop és ezek milyen kérdésekre adnak választ.

(A prezentációban a belső, saját ügyfeleknek készült tesztjeink ábráit lecseréltem az Optimal hivatalos oldalán lévő ábrákra, és az árak is pusztán az Optimal saját árai. Ha árakról szeretnél érdeklődni nálunk, írj!)

A Treejack esetén amúgy a nagy kihívás egy reprezentatív és nagy (százas nagyságrendű) tesztelőtábor megtalálása és aktivizálása. Mi kitaláltunk erre marketinges és egyéb eszközöket, de másoknak ez nem feltétlenül egyszerű, és nekünk sem triviális, csak a munkánk része amúgyis.

Csütörtök este pedig beesett egy levél, az egyik nagy menürendszerrel rendelkező ügyfelünktől: "Sziasztok, tervezzük át a honlapot, és erre a menüstruktúrára jutottunk. Szerintetek jó lesz ez így? Mikor tudnánk erről beszélni?"

Gondolom nem kérdés, milyen terméket javaslunk nekik ehhez :)