Ma 2 éve hogy fut a UXStratégia, ezalatt elég sok projektet vittünk végig, így nagyjából leírható, mi az általános folyamat. Mostanában többször kellett, így ide is leírom.
1. Kutatás
Mi minden projektet kutatással, méghozzá rendszerint kvalitatív, moderált kutatással kezdünk. A kutatásnak (projekttől függően) több eleme lehet:
- felhasználói interjúk és használhatósági tesztek
- konkurenciavizsgálat mintaelemzéssel
- IA feltérképezés
- Analitikák bekérése és elemzése (HotJar, GA)
Interjú és/vagy teszt mindig van. Van, hogy “egymondatos” startup ötletekkel dolgozunk és akkor csak interjúzunk, van hogy kész termék redesignjáról beszélgetünk, és akkor az interjúkat használhatósági tesztek követik.
A kutatási csomagjaink standard árasak, tartalmaznak workshopokat, jelentéseket. Ez azért van, mert ezek rendkívül jól formalizáltak nálunk, azaz tudjuk, hogy 5 interjú az akkor is 5 interjú ha a világ legbonyolultabb szoftverén dolgozunk meg akkor is, ha egy jegyzettömb a megoldás, könnyen árazzuk előre.
A kutatás kimenete rendkívül szerteágazó, de alapvetően itt jön létre a UX stratégia, azaz itt dől el, milyen eszközöket fogunk alkalmazni, milyen irányokba megyünk és milyen területekre fókuszálunk.
2. Tervezés
Nagyon sok a tisztán kutatási projekt. Ennek több oka van – ez egy szép elválási pont, van amelyik ügyfélnek, főképp Service Design területen tisztán ennyire van szüksége, van hogy valamelyikünknek nem szimpatikus a másik, de gyakran ajánlatot se tudunk adni a tervezésre a kutatás vége előtt, hiába kéri ezt tőlünk több ügyfél is.
Ha tervezünk, akkor azt rendszerint Sketchben tesszük újabban, a cél pedig adott feladatok köré interaktív prototípusok építése, amiket aztán vihetünk tesztelésre.
A tervezés alapja mindig a kutatás: ez határozza meg a stratégiai irányokat. Lehetne 3 fázisra különválasztani:
- IA
- drótváz
- vizuál
de az IA nagyon gyakran együtt készül a vizuális világ alapjaival, hisz nagyon sok a redesign projekt, ahol az IA alapvetően marad, az interakciós modell és a szövegezés változik. Ha nem ez történik, akkor jogi vagy gyakorlati folyamatok határozzák meg, esetleg konkurenciák viselkedését ötvözzük.
Ahogy leírom a jegyzettömbe azzal az erővel rögtön a Sketch-be is felpakolhatom az elemeket, így az IA egyszerűbb projekteken megszűnik önálló fázis lenni. Gyakran egymás után hasonlítgatom össze a drótvázat
- a kutatási jegyzetekkel,
- a journey/perszóna anyagokkal,
- a meglévő termékkel
- és a konkurenciákkal
hogy minden meglegyen.
Persze van, hogy külön IA tervek készülnek, de ezek rendszerint belső felhasználásúak – az ügyfélnek nem érdemes őket mutogatni, értelmes feedbacket leginkább a kattintható és végleges grafikájú prototípusról lehet kapni. Mind az IA-ban, mind a drótvázban szoktak lenni olyan vitatott elemek, amik csak a végleges grafikán tűnnek fel a megrendelőnek, így helyén kezeljük hogy a visszavezetés innen történik, az egész egy munkafázis.
Nem egyszerre tervezzük le az egész appot, 2-3 hetes “sprint” csomagok vannak nálunk. Ne tévesszen meg senkit: van, hogy egy csomag 3 hónapnyi fejlesztést tartalmaz, egyszerűen ez a feldolgozható adatmennyiség.
A tervezés kimenete mindig prototípus, ami mindig tesztelhető, tehát adott feladatokra nagyjából konzisztens. Ha ez egy webshop, akkor van olyan bevásárlási lista amit végig lehet vele venni, ha e-mail editor, akkor van olyan e-mail, amit meg lehet benne szerkeszteni, stb.
3. Tesztelés
Ha tervezünk, akkor tesztelünk is: teszteletlen prototípust ügyfélnek nem adunk oda, a legkisebb modul is minimum gerillatesztelt valamelyik törzshelyünk felszolgálóin (köszi mindenkinek!!! Pusz :).
A tervezési “sprintek” 3 tesztet szoktak tartalmazni RITE módszerrel, azaz a terveket még legalább 3x javítjuk az alapján, a felhasználók mennyire tudták használni. Ritka az hogy egyáltalán ne kelljen belenyúlni, de a 3 teszt legtöbbször elég szokott lenni egy sima élményhez. A tesztek valós (de legalábbis hihető) feladatokkal, adatokkal mennek, amiket kutatásból veszünk.
Ezzel amúgy lassabbak vagyunk mint a legtöbb grafikai ügynökség, hiszen a végleges termékterv nem egy belső megbeszéléssorozat eredménye, hanem tartalmaz külső inputokat. Az első teszt után sokszor bevonjuk az ügyfél szakértőit is, hogy ne érje őket meglepetés, de a legfontosabb, hogy azt lássuk, zökkenőmentes a használat,a feladatokat
- hezitálás,
- visszalépés, és
- különösebb gondolkodás
nélkül hajtják végre a felhasználók, miközben a feladat és a felületek komplexitása nem tér el nagyban a várható valóságtól.
Természetesen a teszteléshez mindenféle recruitment módszerek tartoznak, ezért rendszerint a sales segítségét kérjük abban, hogy elérjük a potenciális vagy meglévő ügyfeleket. Tekintve hogy ez rendszeres és kiszámítható esemény (a sprint második felében, napokra elosztva, hogy ki tudjuk javítani közben a felmerülő hibákat), jól lehet vele előre tervezni.
4. Specifikálás
Miután egy modulcsomag sikeresen átment minden teszten, itt az ideje, hogy specifikáljunk. Itt vissza kell nyúlni az összes kutatási anyaghoz, egy ilyen specifikációnak ugyanis nem elég elmondania, hogy mik a képernyőtervek, azt is el kell mondania,
- mi miért lett kitalálva, és
- ezt a felhasználók hogy fogadták, valamint
- hogy kell elképzelni az egyes helyzeteket.
Alapvetően stratégiai tanácsadóként nem az az elsődleges kérésünk a fejlesztőpartnereink felé, hogy a pixelek stimmeljenek, hanem hogy azt a problémát, amit a felhasználók és ügyfelek számára megpróbáltunk megoldani az adott tervezői döntéssel, azt közösen megoldjuk.
A fejlesztők felé fontos, hogy konzisztens legyen az anyag amit leadunk és kezelje le azokat a különleges helyzeteket, amik műszakilag vagy logikailag gondot okozhatnak. Nagy a hangsúly a szélsőeset-kezelésen, de még így is jöhet olyan, rendszerint műszaki eredetű probléma, amelyre nem gondoltunk. Ekkor ezeket is belerajzoljuk a prototípusba, és ha szükséges, újrateszteljük.
A specifikációnak több eleme van:
- tartalmazza a követelményeket user story formátumban (még nem álltunk át Jobs To Be Done-ra mint ahogy partnereink sem),
- tartalmazza a bejárási forgatókönyveket,
- az adatmodelleket, a
- prototípusokat,
- az animációk képleteit,
- és képernyőkre, vagy komponensekre lebontva az összes interakció feltételeit és pszeudokódját.
Ezt egy 2 hetes sprint esetén egy 10-20 A4-es oldal közti dokumentumként kell elképzelni, amely egy nagyobb csomag része (természetesen digitális, de van mellette kattintható prototípus, a méretek lemásolásához PSD helyett Zeplin, sőt, gyakran még egy narrált videó is tartozik a fő forgatókönyvekhez).
Projektmenedzsment
A terveket és azok tesztelési eredményeit rendszerint a Marvel vizuális kommentelőjével kezeljük, azaz itt lehet hozzá megjegyzéseket fűzni, és ezt kezeljük a projektmenedzsment alapjaként. A specifikációkat Confluence kezeli, szintén adott pontokra beszúrt kommentekkel dolgozunk.
Épp ezért ritka hogy külön projektmenedzsment eszközt használjunk, legalábbis a saját céljainkra, a feladatainkat világosan le lehet követni ezeken a platformokon. A kutatás és a tervezés közt általában a trello különböző nézeteit hívjuk segítségül, de ez projektenként változik. Van, hogy az információs architektúra része a specifikációnak előre elkészül, ez adja a feladatlistát a folyamat többi részéhez. A Post-Itre havonta elköltött összeg pedig orbitális…
Tervek utókövetése
Több ügyfél is kéri tőlünk, hogy mi vegyük át a fejlesztőktől a fejlesztéseket, ugyanis mi ismerjük a legjobban a követelményeket. Ez sokszor nehéz dió, főleg, ha a megrendelő papiron a fejlesztőcég, de természetesen visszük ezt a részét is a szolgáltatásnak.
Szóval gyakran a QA folyamatokat, de akár a pre-sales folyamatok CRM és hibakövetés részét is felügyeljük, teszünk javaslatokat az analitikai beállításokra, vagy végezzük el az első néhány hónap analitikáinak elemzését. Nem ritka, hogy mi vagyunk a first level support a béta időszakban, természetesen rálátunk minden ügyfélszolgálati csatornára és igyekszünk reagálni, amennyire lehet.
Szerencsés esetben az utókövetés tartalmaz egy adag (5 fős) usability tesztet, esetleg elégedettségi (SUS vagy NPS) kérdőíveket, ez alapján igyekszünk megállapítani, a projekt célt ért-e.
Ami magyar sajátosság, hogy a célkövetés gyakran nem rajtunk sorvad el: az ügyfél jobban megbízik a prototípusaink usability tesztjeiben mint mi magunk, néha hiányzik az előző rendszerből az analitika, így nincs mihez viszonyítani, vagy (bár mi rendszerint adunk egy lépésről-lépésre forgatókönyvet), az átállás olyan hirtelen lépésekben zajlik, hogy nincs értelme összevetni.
Nyilván legkésőbb élesbe kerülés után 1-2 hónappal elengedjük a projektjeinket: egy több éve sikeresen futó szoftver esetleges hibáiért nem érzünk akkora felelősséget mint kutatási félreértésekért vagy kifelejtett komponensekért.
A piac
Néha elgondolkozom, miért mi kapjuk mindig a heavyweight projekteket (orvosi ügyvitel, vasúti értékesítés és incidenskezelés, ügyvédi ügyvitel…), aztán mindig rájövök: a többit elviszi a piac többi része!
Nyilván ha valakinek csak az kell, hogy valaki megrajzoljon szépre „valamit”, nem minket fog választani, akik a kvalitatív kutatási csomag nélkül el se indítják a projektet. Ezért van az hogy nem értem mi az hogy „nálunk nem engednek kutatást” – az az ügyfél nálunk a sales-en már kiesett.
Részünkről persze sok értelme nem lenne, hisz anélkül mi is csak rajzolgatunk meg okoskodunk, de az ügyfelet is meg lehet érteni: kiad alsó hangon 150.000 ft-ot és még csak egy olyan jelentéscsomag van a kezében hogy merre kell indulni, se egy drótváz, se egy vizuális elképzelés… szép dolog
- a perszóna,
- a feature map,
- a user journey,
- a usability jelentés meg
- a termékstratégia,
de ha neki konkrét elképzelése van, amit igazából valakivel csak meg akar valósíttatni, akkor ezek neki nem kellenek.
Nyilván ez az alapvető különbség is egy stratégiai tanácsadócég meg egy grafikai ügynökség közt.
Ami azonban meglepett, hogy a startupok nagy része nem igényli tőlünk a piac feltérképezését, a feature matching felállítását vagy épp a prototípus validációt, akkor sem, ha ezzel amúgy nem rendelkeznek, és életükben nem találkoztak még potenciális célközönségükkel. Egy-egy tiszteletreméltó kivételtől eltekintve ezekre a szolgáltatásainkra nem voltak kiváncsiak, csak „szép” „intuitív” rajzokat akartak enélkül, így nem is jött létre együttműködés.
Hogy bánom-e? Valahol nem: a nyilvánvaló anyagiakon túl sokkal nyugisabb egy olyan projekt ahol nálunk vannak a kutatási adatok, nem véleményháborús meetingeken ülök egyfolytában, nem kell az ügyfelet sokat kérdezni (alapvetően megoldást szeretnének), az információk forrása heterogén (van hogy az ügyfél tudtával körbeküldök egy kérdőívet a teljes felhasználói bázison, annál szélesebb merítés nem lesz, volt, hogy a harmada kitöltötte), bármikor tudok kérdezni rengeteg embert, egyáltalán: új embereket, élethelyzeteket ismerünk meg.
Egyszóval, azon túl hogy sokkal-sokkal több projektünk lenne, ha bevállalnánk kutatás nélkül is dolgokat, annyival másabb mind a munkaélmény, mind a felhasználói és ügyfélélmény a végén, hogy nem éri meg bevállalni.
