Miks meil ei lubata UX töid tellida?!

Aeg-ajalt saan teadlikuks mõnest juhtumist, kus öeldakse, et me ei saa tööd tellida. Olen nüüd teemasse veidi sisse vaadanud ja tuvastanud viis enamlevinud põhjust, mis siinkohal ka lahti kirjeldan. 
 

1. Me ei soovi nii suurelt projekti ette võtta

Vahest on nii, et oleme teadlikud mõnest tõsisest näpukast. Tähtis on see enne järgmisi samme ära parandada. Vastasel juhul tuleb oodata tükk aega ning just ootamine on kulukas.

Seetõttu eraldatakse eelarvest pisike tükk ettenägematu kulu jaoks. Suuremalt ei saa aga tööd hetkel ette võtta, kuna lihtsalt ei ole selleks planeeritud eelarvet. Ning see kehtib isegi siis, kui tegelikult on teada, et lahendus veidi vildakas on.
 

Mõistlik on väikesed asjad kähku ära teha nii, et see, mis ära tehakse, on ikkagi läbi mõeldud. Sellisel juhul me vahest siiski teeme prototüübi ning kasutame lahenduse valideerimiseks A/B testimist.

Nii saame olla kindlad, et enne, kui arendaja näpud koodiseks teeb, oleme leidnud parima võimaliku lahenduse antud piirangute raames.

Edasiste tööde osas oleks siiski vaja korraliku projektiplaani, eelarvet ning arvutada välja oodatav kasu või investeeringutasuvus. Nii on lihtsam kaitsta eelarvet ning tagada töö tulemi toimivust. Seda siis suurema eelarve puhul.
 

2. Lihtsus ja efektiivsus ei mängi rolli, juba üksnes tegevuse elektrooniline tegemine on kasumlik

Kas planeerida pikemalt ja saada rohkem kasu või teha üks kiire ja kole häkk ning saada vähem kasu kiiremalt? Tegemist on puhta äriotsusega. Oluline on siiski enne panuste tegemist teada, mida üks või teine valik sisuliselt tähendab.

Hea oleks üle mõelda ka see, et kui me teeme mingi koleda häki, siis kas keegi hakkab seda varsti ühest otsast arendama. Millal see „varsti“ on? Vahest tähendab parem planeerimine vaid paar kuud ootamist, kuni arendajad tööle saavad hakata.

Lisaks tuleb uurida, kas hea planeerimine ja asjade korralikult tegemine ikka toob rohkem kasu ja kui suur on tõenäosus, et meie ettekujutus häkist (mis on siiski suhteliselt korralik asi) ei vasta tegelikkusele.

Kogenumad IT projektijuhid võivad kindlasti rääkida „lõbusaid“ jutte sellistest helesinise unistusega projektidest. Samas on siiski tegemist äriotsusega ning olles kindel selles, milline see tulem olema saab, on sellised valikud tihtipeale õigustatud.
 

3. Kasutaja on vähetähtis - meil on suuremaid probleeme

Ilmselt keegi ei ütle seda päris nii välja. Öeldakse hoopis: „Meie kasutajad on väga spetsiifiliste teadmistega inimesed, nad teavad väga palju ning me koolitame neid (ehk lollimatel pole meie süsteemi asja)“. See tundub tihti hea põhjus juhil öelda, et ma ei kavatse kasutaja parema toimetuleku nimel pingutada või sinna investeerida.

Üldiselt olen näinud, et kui sellistel juhtudel ka tasuta konsultatsiooni kingid, ei tule sellest midagi head välja.

Kliendikesksus ei olegi kõikides ettevõtetes prioriteediks. Ja väljastpoolt tulnud isik ei saa seda muuta, ega tohiks ka üritada. Tavaliselt on kasutuses olev ärimudel omanikele piisavalt tulutoov ning igasugune revolutsioon tekitab vaid segadust.
 

4. Arusaam, et UX tööd tulevad lihtsalt tavapärasele arendustööle lisaks, maht kasvab suuremaks

Siin on tegu väga levinud valearusaamaga. Samuti võin öelda, et selline arusaam ei muutu enne kahe veidi erineva ülesehitusega projekti lõpetamist.

Kasutajaliidese projekteerimise tööd ja disainiitegevused viiakse läbi pigem projekti alguses kui lõpus. Seega, kui alustad sammudega, mida tavaliselt projektis ei ole, siis tunduvad need alati lisategevustena.

Olen näinud kahte olukorda:
 

• Parem eeltöö vähendab hilisemat arenduses ümbertegemist;
• Suurem maht kasutatakse alati ära, kui see olemas on (kasvõi mittevajalikule arendusele).
   

Soovitan jagada süsteemi/veebi funktsionaalsus mitmeks väiksemaks projektiks. Nii säilib eelarve kulumise osas parem ülevaade ning on võimalik vajadusel partnereid poolel teel vahetada.

Üldjuhul on hea planeerimise puhul võimalik süsteem ka päris väikese eelarvega valmis saada. Kui soovid rohkem teada saada, võta ühendust. ;)

Kindlasti vajab see paindlikkust. Ka riigiasutustel on võimalik selline paindlikkus sisse planeerida, kui seda juba eelarve taotlemise ajal teha.
 

5. Eeldan, et arendustöö on arendustöö, mida see UX ikka lisab, meie arendajad juba teevad kasutatavaid kasutajaliideseid

Neid teooriaid toidavad nii teadmatud (või ignorantsed) arendusfirmad kui vähekogenud tööde tellijad. Üldiselt on nii, et sa ei saa lihtsalt kuidagi teadlikumalt kasutajaliidest tehes saavutada seda, mida saavutada on vaja.

Kui see õnnestub, on tegemist tohutu vedamisega. Kui ei usu, tee statistikat, mitu hea arusaadavusega või kasutatavusega veebilehte järjest neti.ee-st lahtivõetavatest lehtedest tuvastad? Isegi kui need on ilusad (sul juba vedas), proovi seal midagi teha. Luban, et statistika kajastab päris hästi seda, mida öelda soovin.

Päriselt head kasutajakeskset veebilehte luuakse ikkagi nii, et viiakse läbi eraldi kasutajaliidese disainimise tegevused ning ka testitakse seda, mis valmis sai (eeldatavalt enne, kui keegi arendama hakkab).

Neid tegevusi tegemata ei saa hea kasutatavusega kasutajaliidest ega veebi luua… Võtan sõnad tagasi, kui kavatsed ilma tekstita kahe nupuga veebilehte teha.

Teine teema on veel: arendaja, projektijuht, QA testija tavaliselt neid tegevusi ei tee. Kui sa ei soovi neid just tulevikus suunata ka neid tegevusi tegema, siis on tegu inimeste oskuste ja kogemuste kuritarvitamisega. Sellisel juhul vajavad nad ka vastavat väljaõpet.
 

Selline siis meie nimekiri saigi

Need on peamised otsesed ja kaudsed põhjused, miks ei soovita UX töid tellida või ei lasta seda teha (loe: ei anta eelarvet või ei lubata tuua juurde uusi rolle). Mõned neist on põhjendatud ja mõned on lihtsalt levinud valearusaamad.