10 õppetundi, kuidas disaini ja analüüsi ühildamine parandas projekti kvaliteeti
Kas oled olnud olukorras, kus projekt on küll käivitunud, kuid analüütik ja disainer töötavad eri rütmis ja selge ühise arusaamata? Kas oled mõelnud, kas sinu spetsialistid üldse teavad, mida teine pool teeb või kuidas nende töö omavahel kokku sobitub?
Sellised olukorrad võivad tekitada segadust ja tõstatada küsimuse, kas nad üldse omavahel suhtlevad. Meiegi oleme aeg-ajalt selliste probleemidega silmitsi seisnud. Järgnevalt kirjeldamegi ühe projekti näitel, kuidas me sellise olukorra lahendasime.
2022 aasta suvel alustasime kliendiga koostööd integreeritud e-poe ja iseteeninduskeskkonna välja arendamiseks. Kliendi tegevusalaks on digitaalsete toodete müümine ettevõtetele. Keerukust lisab asjaolu, et vajaliku toote saab lõppklient komplekteerida mitmetest alamtoodetest, sest vajadused on varieeruvad.
Tehniliselt keerukas ja kõrge infoturbega valdkond, kus klient edukalt tegutseb, esitas Trinidad Wisemani tiimile kõrged ootused. Trinidad Wisemani ülesanne oli mõtestada lahti praegune seis ja vajadused ning disainida uus platvorm kasutajate vajadustest lähtuvalt. Projektis osalesid Trinidad Wisemani poolt analüütik (AN), kasutajakogemuse (UX) ja kasutajaliidese (UI) disainer, arendajad ning testija.
Kasvuraskused
Projekti esimeses faasis tegutsesid nii analüütik kui ka disainerid, kes asusid läbi töötama olemasoleva süsteemi dokumentatsiooni ja viima läbi intervjuusid kliendi sisemiste osapooltega, et luua ülevaade hetkeolukorrast ning koguda võimalikult palju sisendit ootuste ja vajaduste kohta.
Öeldakse küll, et pealehakkamine on pool võitu, kuid tööde algus ei läinud siiski tõrgeteta. Suvel alanud projekt langes üllatuslikult kokku nii Trinidad Wisemani kui ka kliendi puhkuste perioodiga, mis ei soosinud intervjuude läbiviimist planeeritud tempos.
Nii hakkas ettenähtud ajagraafik tasapisi paigast libisema, kuid teisest küljest ei ole halba heata. Viivitused tegevuste vahel lõid kasuliku pinnase ja ühtlasi vajaduse Trinidad Wisemani uurimismeeskonna siseselt viia end kurssi kõigi etteplaneeritud töödega, et võimaldada puhkuste perioodil üksteise katmist. Selline asjade käik võimaldas kõigil, nii AN-l, UX-il kui ka UI-l, õppida ja arendada oma oskusi ning mõista paremini, mis tegevusi tuleb igast rollist lähtuvalt järjepanu ette võtta. Lisaks aitas see ehitada usaldust üksteise vastu.
Õppetund 1: tiimiliikmete rollide tööde sisuline mõistmine loob usalduse ja võimaldab tegevusi paremini planeerida.
Teine suurem takistus seoses infoliikumisega avaldus samuti üsna pea. Isegi kui puhkuste katmine õnnestus, tekkisid kommunikatsioonitõrked disainitiimi ja analüütiku vahel. Iganädalased tiimi koosolekud tõid projekti arengutes küll korraks selgust, kuid ülejäänud nädala jooksul, mil koosolekuid ei olnud, kiputi üksteisest mööda rääkima.
Põhjuseks võib tõenäoliselt pidada seda, et enamuse nädalast tegeles igaüks oma tööülesannetega iseseisvalt. Suheldi individuaalselt üks ühele ega peetud oluliseks kõigi detailidega üksteist koormata. Nii tekkis valestimõistmisi, topelt tegevusi ja juba tehtud töö ümbertegemist. Seega otsustasime läheneda koostööle teisiti, et muuta tiimitöö paremaks.
Õppetund 2: piiratud kommunikatsioon tiimi sees toob kaasa ebaefektiivsuse ja selle lahendamiseks tasub katsetada alternatiivseid viise info vahetamiseks.
Toimivad metoodikad
Esimene lihtne ja tõhus meetod, mida otsustasime katsetada, oli UX-i, UI ja AN-u ühised regulaarsed koosolekud, kus jagasime päevakajalisi teemasid projektist, genereerisime ideid ning otsisime probleemidele lahendusi.
Samuti lõime selgemad piirid üksteise tööülesannete vahele. Esialgu nägi tööprotsess välja nii, et AN ja UX töötasid ettevõetud tööülesande läbi, valmistasid uue loogika ette ja alles seejärel edastasid info UI disainerile. Info selline edastamine tekitas aga enamasti UI jaoks hulga küsimusi, mistõttu nii AN kui ka UX pidid selgitustele lisaaega hakkama kulutama ja tehtud tööd ümber tegema.
Seetõttu oli loogiline kaasata UI disainer kohe analüüsi alguses uue loogika väljatöötamisse. See tagas edaspidi sujuvama ja kiirema kommunikatsiooni, koostöö ja disainiprotsessi. Kuna nii AN kui ka UX/UI tööprotsess hõlmab endas sarnast mõtteviisi ja meetodeid, aitas koostöö nende rollide vahel kiirendada kokkuvõttes kogu tööprotsessi.
Õppetund 3: analüüs ja disain ei ole iseseisvad töövood, vaid on üksteisest tugevas sõltuvuses. Koostöö peab toimuma nii infokogumise kui ka lahenduste genereerimise ajal.
Enne prototüübi valmimist kogusime intervjuude abil sisendit, et mõista, kes on iseteeninduse peamised kasutajad ning lõime sellele tuginedes kasutajagruppe iseloomustavad persoonad. Nende kirjeldamine toimus eri osapoolte - ANu, UXi, UI, tooteomaniku ja kliendi müügijuhi kaasamisel. Persoonade loomine aitas tagada, et kogu tiim (nii Trinidad Wiseman kui ka klient) mõistab, kellele platvormi loome.
Määratlesime mitmeid erinevaid kasutajagruppe ja nende prioriseerimiseks kasutasime tähtsuse maatriksit, mis aitas välja selgitada kõige enam iseteenindusega kokku puutuvad kasutajad. See võimaldas seada fookuse neile kasutajate probleemidele, millega tuleks esmalt tegeleda ja lahendusi leida.
Õppetund 4: persoonade määratlemine võimaldab defineerida, kellele lahendust luuakse ja nende sisemine kommunikeerimine aitab tiimil fookust hoida.
Peale analüüsi ja vaadete disainimist panime kokku prototüübi, mis võimaldas kasutajateekonnale tagasisidet saada nii tooteomanikult kui ka kliendi teistelt töötajatelt. Lisaks viisime läbi prototüübi testimised ka lõppklientide ehk toodet ostvate ettevõtetega. Kogutud tagasiside aitas enne arendamist välja selgitada, kas meil õnnestus sihtrühma vajadusi prototüübis katta, ühtlasi tuvastada veel allesjäänud kitsaskohad.
Õppetund 5: üksikute vaadete vormindamine terviklikuks prototüübiks võimaldab testida ja saada paremat tagasisidet nii disainile kui ka analüüsile.
Ühes kasutajagruppide kirjeldamisega kaardistasime koos tootejuhiga iseteeninduse kasutaja teekonnad. Intervjuude käigus kogutud info aitas meil paremini mõista kasutajate kogemust, nende vajadusi ja väljakutseid erinevates teekonna etappides ning seda seeläbi ka lihtsustada.
Õppetund 6: kasutajateekondade kasutamine avab uusi nüansse süsteemi disainimiseks.
Projekti muutis sujuvamaks ka kliendipoolne tooteomanik, kes jättis suuresti kõrvale oma muud tegemised ja keskendus vaid sellele projektile. Ta oli alati olemas küsimustele vastamiseks ja lahenduste leidmiseks. Kui projekti algusfaasis oli tooteomanik ühes ülejäänud kliendi tiimiga veidi skeptiline teatud info kogumise vajaduse osas, siis koostöö käigus hakkasid tema ja ta tiim seda mõistma.
Õppetund 7: tellijapoolne tooteomanik on igas olulisemas arendusprojektis kriitilise tähtsusega ja aktiivne osalemine võimaldab talle olulisi õppimiskohti.
Õppekohad
Ühed keerulisemad projekti hetked olid kindlasti eelpool mainitud puhkuseperioodid ja tiimikaaslaste haigestumised. Kuna arendusprojektides on tavaliselt analüütik see, kes suhtleb keskselt erinevate osapooltega, sh arendustiimi, tooteomaniku ja disaineritega, muutub tööprotsess tema puudumisel keerulisemaks.
Meil aitas seda olukorda lahendada interdistsiplinaarsus ja vajadusel täiendava analüütiku kaasamine. Meil olid disainerid alati valmis analüütiku äraolekul iseseisvalt tegutsema ja aktiivsemalt tooteomanikuga suhtlema. Samuti asendas UX/UI puudumisel neid analüütik, kes tegeles ise ka prototüüpimisega.
Õppetund 8: interdistsiplinaarsus võimaldab lühiajaliselt katta üksikute tiimiliikmete puudumisi. Suuremate puudumiste korral aga kaasa täiendavat ressurssi.
Peale eelanalüüsi tegemist selgus, et projekti tegelik ulatus saab olema suurem kui oli esialgu planeeritud. See tekitas tiimisiseseid pingeid ja kliendipoolset muret tähtaja pikenemise pärast, mistõttu tuli ka neil oma plaane ümber teha. See omakorda viis selgete piirangute seadmiseni selles osas, mida me antud skoobis lahendada võtame ja mida ei võta.
Agiilses arendusprotsessis tekib eri osadega tegelemise käigus jooksvalt palju küsimusi ja ideid. Samas kui kõik need lahendused võtta skoopi sisse, läheb eelarve lõhki ja projekt üle aja. Et projekti skoobis püsida, tekitas see õppekoha “ei” ütlemiseks kogu tiimile.
Õppetund 9: skoobi korrigeerimine on OK, kuid õpi õigel ajal “ei” ütlema.
Õppekoht oli ka see, et kuna projekti algul koheselt arendajad tööd ei alustanud, oli hiljem keeruline leida ühist keelt disainerite ja arendajate vahel. Front-end arendaja ja UI vahelise koostöö parendamiseks hakkasime läbi viima regulaarseid kasutajaliidese disainide demosid. Selle eesmärgiks oli selgitada disainiotsuseid ja vastata arendajate küsimustele.
Õppetund 10: ära viivita liigselt arendajate kaasamisega, sest ka tehnilised piirangud mõjutavad analüüsi ja disaini.
Kokkuvõtteks
Projekt eeldas meilt kliendi äri ja teenuste tundmaõppimiseks põhjalikku tööd. Pidev küsimuste laviin muutus igapäevaseks ja aitas järjepidevalt omandada selle keerulise ja kompleksse äri kohta uusi teadmisi.
Hoolimata kõigist väljatoodud õppekohtadest ei tähenda see, et meil oleks olnud projekti elluviimisel ületamatuid raskusi. Pigem tuli meil sujuvama koostöö korraldamiseks seesuguse keerukusega projekti juures katsetada out of the box agiilsemaid lähenemisi, sest traditsioonilised meetodid siin ei toiminud.
Tänu tiimikaaslaste toetavale suhtumisele, avatud kommunikatsioonile ja usaldusele hakkas meie analüüsi- ja disainitöö protsessi käigus paremini toimima. Hoolimata sellest, kas töötasime üksinda, kogu tiimiga või väiksemates tiimides, korraldasime alati nii, et info liikumine oli pidevalt tagatud.
Meie blogist leiad veel põnevat lugemist disaini ja analüüsi metoodikate ning lähenemiste kohta:
