Alant a Frontend Meetupos előadásom diái, ill. a (hosszadalmas) szöveg amit nagyjából el szerettem volna vele mondani.
Az általános vélemény az, hogy túl hosszú lett, ezt tényleg sajnálom, egy váratlan esemény miatt sokkal kevesebb időm volt készülni, és nekem rövidíteni nehéz a mondanivalót, nem hosszabbítani.
Aztán az is igaz, hogy kevésbé az agilitásról szól: valójában egy „Szent SCRUM-os” rendszerben a UX elsődleges feladata az, hogy előkészítse mindazt, ami a SCRUM-hoz szükséges: a programozókat user story-kkal lássa el, összefüggő történet-halmazokat hozzon létre (epic-ek). Voltaképpen PO feladatot hajt végre… A fejlesztői kickstart meetingekből groomingok lesznek, a user testing pedig az iterációk feedbackjeit biztosítja. Ha valami technológiát ki kell próbálni concept-szinten, abból pedig Spike-ok lesznek.
Megtehettem volna, hogy a prezentáció végén lévő táblázattal kezdek, és elmondom mi micsoda: ez nem is lett volna negyed órával több. Ez is volt a terv…
De a veletek való beszélgetésekből az derült ki, hogy nem lenne így mit hazavinnetek: se komolyan vett SCRUM, se tényleges user-fókusz nincs sok helyen, emberek gondolnak dolgokat felületekről a saját ismereteik és belső megérzéseik alapján.
Ezért gondoltam, hogy elhozom azt, hogy hogy lehet ezt a gondolkodást megváltoztatni, hogy lehet bevezetni az igazi UX gondolkodásmódot egy céghez.
Erről szól ez a prezentáció.
Agilis UX
Három dologról lesz ma szó:
– Mi az a UX és hogyan kapcsolódik a fejlesztéshez
– Hogyan viheted be a UX-et egy cégbe
– Egy (szerintem) ideális workflow hogy néz ki.
Hányan vannak itt fejlesztők?
És hányan dizájnerek?
Beszélgettem néhányotokkal arról, ők hogy érzik a UX-et, ill. mi az amit érzékeltek belőle. Azt mindenki érzi azért, hogy a UX az nem egy rakás wireframe, sokan említettek olyasmit is hogy „a UX-esnek a miértekre és hogyanokra is kell tudnia válaszolni”, de először szeretném tisztázni, mit szoktunk UX alatt érteni.
[Wireframe] -> [Dizájn] -> [Fejlesztés]
A User experience valami régi wikipedia definíció szerint „mindazon érzések és gondolatok összessége, amelyeket a felhasználó átél a rendszerrel való kapcsolata során”
A User Experience valami olyasmi, ami
– Lejátszódik minden alkalommal amikor valaki találkozik a szoftverrel
– Egyszeri
– Egyedi
– Megismételhetetlen
– Valaki más fejében zajlik
Igazából olyan, hogy User Experience Design nincs. Van User Experience orientált dizájn, ez picit olyan, mint a kukoricaolaj meg babaolaj kérdéskör.
Hogyan lehet erre orientálva tervezni?
Szóval először is mérni kell.
Namost mivel ez
– Egyszeri
– Egyedi
– Megismételhetetlen
– Valaki más fejében zajlik
Ezért a mérés hagyományos módja a tesztelés.
Ez egyben a legolcsóbb, legcélszerűbb módja a dolognak
Mi kell a teszthez?
HWSW
– Mikrofon, esetleg webkamera
– Képernyőfelvevő szoftver
Kell még:
– Egy szoftver, amit tesztelsz
– Egy user
– Egy feladat
Ez tulajdonképpen meg is adja, mit fog előállítani a UX, mert ahhoz hogy ezek meglegyenek, ahhoz kell mindenféle UX-specifikus dolog majd meglátjuk.
Kezdjük a userrel
Nincsen semmiféle mágikus tudás. A User Experience valaki más fejében zajlik. Ezt fontos megértenetek, hogy az a másik ember teljesen más dolgokkal van elfoglalva, és fogalma sincs, mi miért úgy van ahogy ti azt kitaláltátok.
Ennek van egy nagyon fontos következménye. Kétféle tipikus hibába szoktak esni emberek, az is lehet, hogy valaki magára ismer ezekből.
Az egyik azt mondja, hogy hát én az interneten nőttem fel, naponta használok appokat, én igazán tudom, mi kell a számítógépnek.
A másik azt mondja, én nem vagyok kocka, én a technika és a humán területek határán vagyok, én tudom, hogy kell egy számítógépet emberivé tenni.
Az a baj mindkét hozzáállással, hogy önreflexióra épül. Elgondolkozunk azon, hogy más ember hogy használná az appot, ahelyett, hogy ezt mérnénk. Belső emberként teljesen más érzelmi viszonyunk van a projekttel és akárhogy is próbáljuk, sokkal többet tudunk róla. Ez picit olyan, mint a kódolás a unittesztek előtt – a program lefutott, kipróbáltam.
Szóval kell user, aki nem mi vagyunk.
Gyakran hallom, hát ahhoz itt nincs hozzáférés.
Mik a user tulajdonságai?
– Nem tagja a projektteamnek (lehetőleg nem is programozó)
– Nem érdekli és nem ismeri a rendszer működését
– Vannak valós céljai amiket el akar érni
– (ritkán) szakterületi fogalmi ismeretekkel rendelkezik
– nem (feltétlenül) figyel arra amit csinál
Bárki aki ennek megfelel, az tesztelési szempontból user
– Titkárnő
– Recepciós
– Másik projekt menedzsere
– Tesó
Sztorik
Ami nagyon fontos: amikor az első videóval kész vagyunk, mindenkit, akinek csak köze van a projekthez, tereljünk be egy meetingszobába, és mutassuk meg nekik: nem elég linkként elküldeni, nem elég egy összefoglaló prezentációt látni. Az első élménynek közvetlennek kell lennie.
Tegyük fel hogy van user, de nincs kész program, mit csináljunk?
Ki emlékszik, mit csinált 3 hete?
Én megmondom őszintén, 3 hét alatt elkészülő minimal viable productot nem láttam az utóbbi években.
De eleve ez egy nagyon hosszú idő, amit az emberi agy már nem kezel jól.
Tegyük fel, hogy a programozók kapnak nettó félmillió forintot, azzal könnyű számolni, és vannak négyen egy csapatban. Akkor az heti félmillió forint, három hét másfélmillió. Nettó. A fene fogja ezt kidobni.
Ezért a UX kénytelen prototípusokkal előállni ha tesztelni akar. Ennek leginkább az a módja, hogy vagy kattinthatóvá teszik a wireframe-eket, vagy elkezdik a lapozós játékot játszani, a végén lesz rá példa.
Egy Excel táblázat is lehet prototípus, áramszolgáltató példa
Namost ahhoz hogy a prototípus kattintható legyen, végig kell gondolni, mi mi után következik, és melyik gomb mit csinál. Ennek gondolom nem kell ecsetelnem a járulékos előnyeit. Ehhez előállítunk mindenféle flowchartokat, amikkel most nem foglalkozunk, de a UX dolga ezek előállítása is.
LMI paper prototyping példa
Végül pedig beszéljünk a feladatról.
Semmilyen szoftver nem lehet felhasználó-barát, ha nem oldja meg egy felhasználó értelmes problémáját. Ismerek ilyen programot, nem is egyet… A startup-világ teli van vele.
A probléma, amit tesztelünk, nem lehet túl konkrét – nyomd meg a kék gombot a képernyő jobb felső sarkában, kérjük, s teszteken jól is működik, de valamiért az igazi rendszerben az emberek mégse jutnak el a regisztrációig, amit mi pajkosságból „Zúzzá velünk” felirattal illettünk.
Namost a nagy kérdés, ami felmerül: ha még nincs prototípusunk se, akkor mit csináljunk?
Akkor teszteljük a történeteinket.
Az emberek történetvezéreltek. Mindenki az.
A jelenlévők közül járt valaki a Holdon?
Akkor honnan tudja, hogy a Föld körül forog?
Ez egy történet, amit elfogadunk hitelesnek és valósnak.
A valóságosság egy nagyon pici kapcsoló az emberi agyban: valójában az emberi agy képtelen megkülönböztetni a valós és képzeletbeli történeteket alap működése során.
Így történhetett meg, hogy emberek Magyarországon elkezdtek pénzt gyűjteni Isaurának, az egyik első brazil szappanopera főhősének, hogy ugyanmár gazdája szabadítsa fel a rabszolgasorsból.
Fodor Zsókát is gyakran állították meg az utcán, vén, pletykás szipirtyónak titulálva Magdi anyus szerepe miatt.
A történeteket a UX-ben hagyományosan például képregényformában próbáljuk eladni, ennek a neve a Storyboard. A fent látható képregény egy tájépítészeti projekthez készült, az a nagy szürke tömb egy térkavics, amire QR-kódot gravíroztak.
A történetekről nem szeretnék sokat mondani, Cheng Lásd Amit Mondok könyve kiváló kiindulási alap.
De attól még, hogy egy történet hiteles, nem biztos, hogy valóságos is. Lehet, hogy mint történet megmozgatja az embereket – ki ne akarna egy jetpacket? – de nem biztos, hogy létező problémákat old meg.
Ezért fontos, hogy a történeteink dokumentarista történetek legyenek, valós emberek való életbeli problémáiról szóljanak.
Ahhoz hogy ezeket kiszedjük ha még nincs termék, meg kell tanulnunk jól kérdezni, ez a User Interview kérdésköre.
Az interjúk azért is jók mert az idézeteket használhatjuk a programozók és menedzserek meggyőzésére.
Valójában a user testing is ezért működik jól mint bevezetési eszköz: letagadhatatlanul valós történeteket ad a kezünkbe idézetekkel.
Ezzel pedig nagyjából össze is áll a Workflow.
Kezdetben vala a fejlesztés. Ezt minden esetben meg kell hogy előzze a dizájn, hiszen mi alapján becsülünk? A sprintbe már csak teljesen ledizájnolt elemek kerülhetnek.
A tényleges megvalósítás gyakran különbözik a tervtől, ezért is kell mindenképp tesztelnünk a kész terméket: ne feledjük, a User Experience a végtermékkel történik, nem a terveinkkel!
Mivel a fejlesztés lassú, és nekünk már előbb kell feedback arról, hogy milyen is lenne az elkészülő felület, ezért prototípusokat készítünk. Ehhez végiggondoljuk, hogyan és milyen módon kapcsolódnak az egyes elemek egymáshoz, mi egy adott feladat flow-ja szerintünk.
Ahhoz viszont, hogy megtudjuk, mik is azok a feladatok, amikre megoldást keresünk, kénytelenek vagyunk megkérdezni embereket, és kénytelenek vagyunk concepteket mutatni nekik.
A concept és a wireframe közti különbség nagyon fontos: míg a végleges dizájn és wireframe egy „előírás” (prescriptive) a majdan születő program működésére vonatkozólag, a concept inkább egy „kérdés” (explorative), hogy mi lenne, ha így működne. Ezért én a conceptjeimet leginkább ceruzával rajzolom.
A concept egyik formája a storyboard, amik segítenek véleményeket gyűjteni egy problémakörről.
Végül pedig álljon itt egy teljes és részletes folyamat. Nagyjából ilyesmit használtunk ebben az említett környezetben.
