Millal valida oma projekti UX, millal UI disainer?

UX ja UI disaini ümber keerleb mitmeid müüte ja tihti on disainitööd tellides keeruline mõista, millist disainerit on tarvis konkreetsesse projekti kaasata. Toome järgnevalt Trinidad Wisemani teenusedisaini valdkonnajuhi Hegle Sarapuu-Johansoniga koos selgust, millal tuleks otsustada UX ja millal UI disaineri kasuks ning millal need kaks võiksid olla ühes isikus. 

 

 

UX, UI ja nendega seonduvad müüdid  

UX disaineri (user experience designer) puhul räägime kasutajakogemuse disainerist ja UI disaineri (user interface designer) puhul räägime kasutajaliidese disainerist. UX ja UI on omavahel tihedalt seotud, kuid kummalgi disaineril on omad eesmärgid, täiesti erinevad tööülesanded ning ka erinevad vormistatud töötulemid. 

 

Oleme täheldanud kahte enamlevinud uskumust ehk müüti, mis meie arvates sellise kaks ühes tellimise kaasa toovad: 

 

• UX/UI disainer ei ole muud kui tipptasemel UI disainer ning parima (kõikehõlmava) teenuse saamiseks on igaks juhuks mõistlik teenust tellides rääkida UX/UI disainerist;  
• kui UI ehk kasutajaliides on juba loodud, käib UX disainer sellest piltlikult öeldes võlukepiga üle ja kõik muutub kasutajasõbralikuks. 

 

Mõlemad müüdid tulevad tegelikult kehvasti juhitud projektidest, kus tööde järjestus on halvasti planeeritud. Nimelt UI disaineri töötulem on väga nähtav isegi siis, kui UX disaineri töötulemid jäävad peitu, sest ilma UI-ta toota ei saa.

 

Küll aga halvasti tehtud UX tuleb välja hullemal juhul alles peale toodangusse minekut ja tihti eraldi UX töötulemeid küsida ega oodata ei osata. Ei ole oodatavat töötulemit - ei ole ka tegevusi selle jaoks. Tegevuste puudumisel ei oska me omakorda kirjeldada UX disaineri ülesandeid ning selles olukorras tundub oluliselt lihtsam tellida UX/UI kaks-ühes.  

 

Vaatleme näiteks protsessi suure tarkvaraprojekti puhul. Enne tarkvara või kasutajaliidese tootmisega alustamist tehakse teenuste, kasutaja tööprotsessi ja funktsionaalsuste kaardistamine. See on vajalik selleks, et leida kõige efektiivsem ja motiveerivam viis kasutajate igapäevaste eesmärkide saavutamiseks.

 

See on UX disaineri tööpõld ning seda tööosa teostatakse tihti koos ärianalüütikutega. UX disaineril on kontseptuaalne ülesanne: tööprotsesside ja keskkonna analüüs, detailideni kasutaja vajaduste mõistmine ja piirangutest arusaamine ning kogu info dokumenteerimine selliselt, et teised saaksid sellest tulevikus lähtuda. Seejärel aga luuakse uue lahenduse kontseptsioon, kasutades seda teadmist. 

 

 

Kus lõppeb UX disain ja algab UI disain? 

 

UX disaineri ja UI disaineri tööülesannete jaotus. Prototüüpimine on nende ühine ülesanne.

 

Infokogumiseks, äriliste jt eesmärkide mõistmiseks viib UX disainer läbi asutusesiseseid intervjuusid, küsitlusi ja vestleb tulevikus igapäevaselt tarkvaraga töötavate lõppkasutajatega. Teisisõnu, kaardistatakse hetkeolukord ning kirjeldatakse tulevikuks uus lähenemine.

 

UX disaineri töö tulemusena luuakse strateegia uue tarkvara sulandamiseks olemasolevasse keskkonda nii, et päriseluline ja digitaalne muudatus saaksid saavutatud kõige valutumal viisil.

 

Töö käigus selgitatakse välja muudatuste ulatused ettevõtte ja kasutajate jaoks ning kaardistatakse üleminekuteekond. Veel hinnatakse, kas muudatuste järel on töötamine, tegevuste järjekord, nupud jt detailid kasutaja jaoks loogilised.  

 

UX protsess kulmineerub prototüübiga, kus on täpselt aru saada, kuidas kasutajal tuleb tulevikus töötama hakata. Just prototüüp on ideaalne vahend juba küllalt detailse ettekujutuse tekitamiseks. Väga palju detaile pannakse paika just prototüüpimise protsessi käigus. Prototüüpi tuleb nii kaua muuta, kuniks tööprotsess on lihvitud optimaalseks.

 

"Prototüübiga katsetatakse kasutajate peal selle loogilisust ning otsitakse kasutajate kaasabil üles kõik suuremad kahtluskohad. Prototüübi muutmine on alati kordades soodsam täisvisuaalis kasutajaliidese piltide peal muudatuste tegemisest."  

 

Prototüüpimine võiks olla veel UX disaineri töö, kuna see on kommunikatsiooni seisukohalt soodsam. Kuigi prototüüp sisaldab kasutajaliidese elemente, ei ole siia veel vaja UI disainerit -  v.a turundusliku, väga visuaalse või interaktiivse lahenduse puhul.

 

Kui UX disain on paigas ehk hakatakse edasi tegelema tootmisega, tuleb mängu UI disainer. 

 

Vastavalt UX disaineri kogemusele ja tugevuse fookusele, võib valida prototüübi detailsusastet ja momenti, millal UI disainerile töö edasi antakse. Ehk kui UX disainer on digilahendustes tugev, võib prototüüp olla kõrge detailsusastmega (kuhu on lisatud ka interaktsioone).

 

Samas, digikeskkondadega vähem kogenud UX disaineri puhul, kes on keskendunud rohkem ärile ja kasutajate käitumisele, saab teha üleandmist madala detailsusega prototüübi momendil. 

 

Suure projekti puhul toimub agiilne arendus, kus iga tsükli lõpus valmib mingi osa uuest tarkvarast. UI disaineri ülesandeks on kujundada osade kaupa - kontseptsiooni järgi - reaalset kasutajaliidest, millest lõpptulemusena valmib visuaalne tervikpilt. Ta toodab arendustiimile jooksvalt ette komponente ning vastutab nende äratuntavuse, harjumuspärasuse, ligipääsetavuse jmt eest.

 

Disainisprint agiilses arenduses

 

Hea UI disainer mõistab, kuidas inimesed komponente märkavad – UX-ist on ta omakorda saanud sisendi, mis järjekorras inimene peab neid märkama. Hea UI disainer peab töötama efektiivselt, jagama disainipsühholoogiat, tal peab olema silma ja kompositsiooniloomise oskust. 

 

 

Millal ei soovita hoida ühes projektis UX ja UI disainerit ühes isikus? 

Kujutleme, et projekti on kaasatud tugev UI disainer, kes on väga hea komponentide tootmises. Ta sukeldub UI-sse - hakkab visuaalselt nuppe ja teisi detaile disainima, kuid tervikpilti sellise detailsusastme juures enam ei märka ja tagasitee suure pildini nõuab tõsist pingutust.

 

Ehk olles mõtetega detailsel tasemel, ei saa enam näha asju üldisemal tasemel. See toob kaasa kasutajatele ebamugavused näiteks navigatsioonis, tööprotsessis või kasutusloogikas. 

 

UX disainer peab nägema suurt pilti ning igal ajahetkel mõistma, millist ülesannet püütakse täita; milline on miinimumarv komponente kasutajaliideses iga tegevuse jaoks; millised on tõenäolised stsenaariumid; missugune on kasutajate arusaam oma tegevusest jne.

 

Siin ei ole kohta visuaalsete elementide masstootmisele. UX disainer saab oma tööd hästi teha, kui ta keskendub kasutaja mõistmisele, tema sooritatavatele ülesannetele, käitumisele ning käitumist mõjutavatele teguritele.  

 

Suures projektis järgneb UX disainile UI disain - näiteks enne on tarvis mõista, miks on mingit nuppu vaja ja alles siis saab hakata detailsel tasemel visuaali disainima. Üks tarkvara hõlmab endas tohutult funktsionaalsust, mis tihti jagatakse alamfunktsionaalsuste gruppideks.

 

Kasutajauuringuid ei pea tegema korraga kogu tarkvara funktsionaalsusele, vaid läheneda saab temaatiliselt (ehk funktsionaalsuse valitud kogumile). Iga funktsionaalsuse jaoks tehakse eraldi nii UX disain kui UI disain: UX hindab, kuidas iga osa tervikusse ehk suurde pilti sobitub ning UI toodab iga sprindi jaoks ette hulga komponente.  

 

Kujutleme nüüd, et paneme need kaks rolli ühele disainerile – piltlikult ühe käega peab ta tegema intervjuusid, mõistmaks kasutajaid ja tervikpilti ning teise käega peab tootma jooksvalt arendajatele komponente (disainima nuppe, valima värve, looma kompositsioone). 

 

Inimese aju ei ole võimeline samaaegselt keskenduma mitmele teemale - üks jääb paratamatult vaeslapseks ning disainerist saab kiiresti projekti pudelikael. Suure tõenäosusega juhtub nii, et disainer tegeleb esmajärjekorras ajakriitilisemate ülesannetega – toodab arendajatele komponente ning unustab seejuures kasutaja sootuks.

 

Teisisõnu minnakse päästma UI-d, mille tulemusena UX saab ühel hetkel kannatada. Tegeledes aga ainult UX-iga, ei jõua asjad kunagi UI-sse.  

 

On üsna tõenäoline ja inimlik, et piisavalt suures projektis sellises olukorras tekivad vead (nt vale kuupäeva formaadiga väljad, pisut erineva disainiga nupud jne), UI komponente toodetakse aeglasemalt, unustatakse ära kasutaja, olulisi momente lükatakse edasi ja projekt tervikuna venib, kuna disainer füüsiliselt ei jõua.  

 

 

Millal on mõttekas ühildada UX ja UI disaineri rollid? 

Väiksema lineaarse projekti puhul (nt äpi loomisel) on võimalik kasutada UX ja UI disainerit ühes isikus. Siin on disaineril võimalik ühel hetkel keskenduda ühele, teisel hetkel teisele rollile ja selline lahendus on efektiivsem, kuna sama inimene mäletab UX intervjuude jt uuringute tulemusi ning kannab need üle UI-sse.

 

Nii jääb vahelt ära üks kommunikatsiooniaste ja töötunde kulub lõppkokkuvõttes vähem, kuid protsess peab ajas olema lineaarne. Seega, lühikeste 3-6 kuuliste projektide puhul, kus funktsionaalsust ei ole liialt palju ja kaasatud on kuni paar arendajat ja üks disainer, on mõistlik kaaluda UX/UI disaineri teenust ühes isikus.  

 

Sellisel juhul tuleb aga arvestada, et disaineri projektist väljavahetamine on oluliselt keerulisem. Tema töötulemid on küll näha, kuid detailne info on dokumenteerimata, sest väikese tiimi ja lühikese projekti puhul ei ole seda sageli tarvis.

 

Riskide vältimiseks tasub meeles pidada, et suurem ja ajaliselt pikem projekt, kus disaineri töötulemid peavad pikemalt “elama”, nõuab kindlasti põhjalikku dokumenteerimist. 

 

Pelgalt igaks juhuks ei soovita UX ja UI disainerit ühes isikus kasutada. Teadliku otsuse tegemiseks tuleb hinnata projekti olemust ja disaineri töömahtu. Kui töömaht dikteerib mitut inimest - näiteks kogu UI tootmine käib nii kiiresti, et ainuüksi tootmisprotsess nõuab kahte disainerit, tasub UX ja UI eraldi hoida.

 

Tavaliselt ei ole tarvis kahte UX disainerit ega kahte UI disainerit – pigem tuleks langetada otsus ühe UX ja ühe UI disaineri kasuks ning panna nad omavahel meeskonnatööd tegema. Tulemus saab kordades parem võrreldes sellega kui kasutada kahte samaväärset disainerit.  

 

Kokkuvõtteks soovitame hoida UX ja UI disainerit eraldi suure projekti puhul, mis hõlmab palju funktsionaalsust korraga ning UX/UI disainerit ühes isikus piisavalt väikese projekti puhul, kus töötulemid ei pea kaua “elama” ning kommunikatsioonikulu oleks vastasel juhul põhjendamatu.