Interaktsioonidisainer agiilses meeskonnas – seitse väljakutset ja võimalikku lahendust

Me kuuleme palju Kanbanist, Scrumist, ekstreemarendusest ja Leanist. Kogu virvarri keskmes on aga üksik interaktsioonidisainer.

Vastupidiselt levinud arvamusele saavad interaktsioonidisain ja agiilne arendus omavahel väga hästi läbi. See nõuab ainult natuke harjumuste muutmist. Agiilses meeskonnas töötamine võib olla väljakutseid pakkuv, kuna väga detailse arenduse maailma kõrval peab disainer hoidma ka tervikpilti. Tegemist on kahe väga erineva detailsusastmega.
 

Interaktsioonidisaineri rollist

Näitlikult öeldes tegeleb interaktsioonidisainer suure pusle kokkupanekuga. Selleks peab ta lisaks tiimiliikmetele ja tellija esindajale (nt. product owner rollis olija) rääkima paljude majasiseste ning majast väljaspool olevate inimestega. Ühtse tervikpildi asemel antakse talle killuke siit ja killuke sealt. Paraku raskendab see aga hea ühtse terviku kasutajakogemuse loomist.
 

Puuduliku info põhjalt otsuste tegemisel võivad vead olla nii tõsised, et ringi tuleb teha terve süsteem. Tihti on see arendusmeeskonnale täitsa ok aga ettevõtte jaoks on see hulk raisu läinud raha ning väga kallis õppetund. Hea näide on Avoni hiljutine 125 miljoni dollari suurune arendusämber.

Hea kasutajakogemuse loomiseks peab disainer olema teadlik ärilistest eesmärkidest, kasutajate mõttemaailmast ning tehnilistest võimalustest.

Olukorrad, kus interaktsioonidisainer on tööga alustamas ja arendus juba kolmanda sprindi lõpus, ei ole midagi uut. Mõnikord on ka terve kasutajaliides, ilma igasuguse interaktsioonidisainita, "valmis" või "valmis" saamas.

Sellise olukorra vältimiseks peab disainer projektiga toimetama juba enne arendusmeeskonna alustamist. Järgnevalt räägime võimalikest väljakutsetest juba lähemalt.
 

1. Kui palju eeltööd on vaja teha enne, kui progema hakatakse?
   Interaktsioonidisainer vastutab tervikpildi eest. Selle lahtimõtestamiseks alustab ta tavaliselt kasutajauuringutest. Disaineril ei tea sellel hetkel, milline lõpplahendus olema peaks. Äriprobleemist üksinda ei piisa.
   
   Antud faasis ei tohiks keskenduda liigsetele lahenduse detailidele. Samas peab olema valmis oma poolikut tööd näitama, tagasisidet küsima ja inimestega rääkima. Eeltöö hulk sõltub palju projektist ja sellest, mida saab jooksvalt arenduse kõrvalt teha ning mida kindlasti ei saa. Tihti on mõistlik kaasata sellesse etappi ka arendajad. Kui nad veel arendada ei saa võiksid nad aidata kaaluda erinevate lähenemiste plusse ning miinuseid.
   
   Arendajad ei ole tavaliselt õnnelikud, kui disainer teeb intervjuusid ja kogub infot ning ei joonista mull ninast väljas ekraanipilte. Siit tulebki väljakutse. Kui palju on mõistlik puslest enne kokku panna (loe: sinna aega panna), kui arendus pihta hakkab versus kui palju sa julged riskida sellega, et pärast värk viltu kisub ning tuleb välja, et oled kogu lahenduse valesti üles ehitanud või hoopis jäänud suure tempoga ajahätta.
    

2. Mitu meeskonnaliiget peaksid disainiprotsessis osalema? 

   Täiuslikus maailmas on uuringute ja arutelude peal terve meeskond, kuid päriselus pole kellelgi piisavalt aega, et regulaarselt kokku saada ja arutleda. Mida rohkem sa kaasad teisi meeskonnaliikmeid lahenduste välja töötamiseks ja probleemide analüüsimiseks/välja selgitamiseks, seda suurem tõenäosus on, et hiljem ei pea iga lahenduse pärast viimse veretilgani võitlema. Lisaks on muudatusi tulevikus vähem ning valitud parim lahendus projekti piirangutes. Anna neile mõjuv põhjus aruteludel osalemiseks. Samas arvesta ka sellega, et nende aeg on piiratud. Parim praktika on leppida igas päevas regulaarne aeg kokku.
    

3. Kui palju on vaja dokumentatsiooni?
   Agiilse arenduse üks efektiivsuspunkt seisneb üleliigse dokumentatsiooni eemaldamises ning dokumendi sisu sõltub meeskonna ning äripoole vajadusest arendusfaasis, süsteemi edasisest käekäigust ning ka hilisematest arendustsüklitest. Omavaheline kommunikatsioon on ülioluline aga see ei pea dokumentidesse valatud olema. Siiski on vaja otsustada seda, kui palju on vaja dokumenteerida või kui detailselt prototüüpi luua, et teised lihtsalt aru saaksid ning 2 kuu pärast kasutajate intervjuutulemusi mäletaksid.
   
   Hea viis asju dokumenteerida on neid võimalikult visuaalsetena luua. Lisaks saab palju kirja panna juba prototüübi lehe kohta käivate kommentaaridena prototüübi sisse. Lisaks on hea soovitus esitleda töötulemeid, mitte saata neid e-posti või Skype teel. Samuti kogu tagasisidet aruteludena, mitte e-posti teel. See on kõigile osapooltele efektiivsem ning ka kiirem viis. Interaktsioonidisaineri üks ülesanne on lepitada ka erinevaid osapooli ning tõlkida mõtteid ning ideid. 
    

4. Kui palju võib muuta?
   Muutuste tegemine koos tervikpildi hoidmisega on äärmiselt raske. Tihtipeale räägitakse, et mõlemad on vajalikud, kuid väga keeruline on neid üheaegselt teha.
   
   Disainer peab otsustama, kuhu ta joone tõmbab. Millised detailid võivad muutuda ning millised enam ei tohiks (ehk, millised muudatused kasutuskogemust rikkuma hakkavad). Hea praktika on kasutajate töövood hoida storyboardina seinal ning muudatused seal läbi proovida esmalt.
   
   Üldiselt pole navigatsiooniskeemi muutmine väga hea mõte. Seda võib teha üksnes siis, kui selleks on väga hea põhjus. Kui navigatsiooni osas on kahtlusi, siis soovitame omaltpoolt teha mõned kiired RITE (rapid iterative test) testid. Need ei võta pikalt aega ning saad kiiresti teada, kas üldine suund on õige või mitte. Teinekord on lihtsam leppida kokku kasutajate testimine kui vaielda tunde vormi üle. Üks kasutajaga tehtav test võib võtta 15 minutit aega ja asi on selge - pole siis ju pointi vaielda ega spekuleerida.
    

5. Millal on „valmis“ ka tegelikult valmis?
   Kas selle kohta on kriteeriumid olemas? Millal on funktsionaalsus piisavalt hea, et seda kliendile näidata? Agiilsete meeskondade puhul oleme märganud, et ilma visuaalse disainita läheb arendamine palju kiiremini. Seetõttu ongi mõistlik päris mitu asja arendada ilma roheliste ja siniste nuppudeta :). Ühel hetkel tuleb aga piir tõmmata, kust edasi on juba vaja pikslid paika "tuunida".  
   
   Arenduskiirusest tingitud iteratsioonide vähesuse tõttu tuleb vaadata, et üldine struktuur oleks kohe alguses paigas. Pisimuutuseid saab alati ka hiljem teha. Oluline on mõista, et „valmis“ kriteeriumid muutuvad sel hetkel kui vormile kohandatakse visuaalset disaini.
    

6. Teiste osakondade ja lõppkasutajate protsessi kaasamine
   Hea ülevaate saamiseks peab disainer rääkima võimalikult paljudega. Agiilses arenduses sellele hästi peale ei vaadata, kuna elatakse pidevas ajanappuses. Samas on interaktsioonidisaineri rolliks just diskussioonide arendamine ja seeläbi võimalike lahenduste leidmine.
   
   Meie soovituseks on võtta tootejuht ning pidada temaga vähemalt kaks pooletunnist koosolekut nädalas. Kui tootejuhil on pidevalt kiire, siis on vaja leida teisi inimesi, kellelt infot saab ning paluda tema õnnistust. Nimelt õnnistus just päästab sind ilmselt hilisemast paratamatust konfliktist....
   
   Tootejuhist alati ei piisa. Väga lihtne on rääkida vaid ühe inimesega, kuid organisatsioon ei koosne ainult ühest võtmeisikust. Seega tasub rääkida nii paljudega erinevate inimestega, keda see süsteem puudutab, kui võimalik.
    

7. Kui palju on piisav?
   Ehk siis, kui pikalt kasutajaliidest viimistletakse ja kui täiuslik see peaks olema? Otsest vastust ei olegi. Mõnikord juhtub, et pika protsessi tulemusena jõutakse vormini, millel on ainult üks väli. Teistel kordadel peab disainer laskma mitte-just-väga-ideaalsel versioonil toodangusse minna.
    

Kokkuvõttes taandub kõik heale kommunikatsioonile

Arendus ja interaktsioonidisain saavad väga hästi koos töötada. Selleks peavad nad mõistma, milline on nende töö sisu ja eripära. Disainerid peavad mõistma arendajaid ning sama kehtib ka vastupidi. Alahinnata ei tasu ka kvaliteetse järelevalve olulisust.

Hea kasutajakogemus sünnib siis, kui kõik osapooled sellele kaasa aitavad. Disaini ja arendust pole võimalik isoleerida. Mida rohkem inimesi protsessis osaleb, seda selgemaks saab hea lahendus.

Interaktsioonidisainer peab olema paindlik, koostööaldis ning valmis ka ärinõudeid  painutama. Muidugi ei ole kõik sellega alati rahul, kuid üldjuhul nad leebuvad, kui näevad, kui palju see nende arenduseelarvet mõjutab.
 

Rääkige oma kogemustest!

On teil endal ehk huvitav lugu rääkida? Pole vahet, kas see oli postiivne või negatiivne. Kõik kommentaarid on soojalt oodatud :)

Kui tekkis küsimusi või soovid interaktsiooni- ja kasutajakogemuse disaini kohta rohkem infot, siis kirjuta meile aadressil trinidad@trinidad.ee.