Kasutajakeskse disaini meetodid on protsess, millega saad parendada nii patja, veebi kui ka teenindusprotsessi. Seetõttu on võimalik läbi sellise tegevuse tõsta oluliselt ka arendusprotsessi efektiivsust ja kliendisõbralikkust.
Õnnestus just läbi viia selline projekt, kus kasutasime näidisprojekti puhul kasutajakesksete meetodite arendusprojektidesse disainimiseks just kasutajakeskse disaini meetodeid. Siit ka lühike kirjeldus kuidas sellist projekti mõistlik läbi viia on:
Planeerimisest me ei saa üle ega ümbert. Vaja on teada: mida soovitakse saavutada, kas tähtsam on arenduskiirus, tellija rahulolu, kasutaja rahulolu või hoopis arendaja rahulolu. Kui kaua on meil aega ja kui palju oleme selleks valmis rahaliselt panustama. Lisaks tuleb kokku leppida ka käesoleva projekti mõõdetavad tulemid.
Projekt ise algab nagu ikka kasutajakesksetes projektides uuringuga 
. Küsitleme täitja erinevaid projektirolle, kasutajaid, tellijaid, ettevõtte juhtkonda. Jälgime kõrvalt, kuidas inimesed tööd teevad, millised on enamlevinud tulekahjud. Selle tulemusena saame erinevate osapoolte vajadused, tänased probleemid ning muidugi isiklikud motivaatorid. Uuring dokumenteeritakse erinevate profiilidena ning tuuakse välja nõudmised uuele protsessile.
Seejärel valime välja sobivad töövõtted, kombineerime neid ning teeme plaani kuidas järk-järgult neid meetodeid töösse lülitama hakkame – moodustame juurutusplaani.
Iga etapi järel hindame tulemusi, ning teeme järgmise etapi jaoks vajalikud täiendused.
Tähtis, nagu ikka iga muudatusi hõlmava protsessi puhul, on muudatuste harjumuseks muutmine ning mitte võtta ette korraga liiga suurt hulka. Iga etapi vahel peaks väike paus olema. Samuti ei tohi ära unustada ka inimestele uute töövõtete koolitamist
Läbi klientide või kasutajate uuringu oma äri disainida on tegelikult ettevõtte kasutatavuse küpsusastme kõrgeim 8-s tase, milleni jõudmine võtab kuuldavasti umbes 40 aastat (http://www.useit.com/alertbox/maturity.html, http://www.useit.com/alertbox/process_maturity.html). Disainides oma tööprotsessi nendest põhimõtetest lähtuvalt on aga tase 7, milleni jõudmine peaks umbes 20 aastat võtma. Uskumatu aeg! Samas kui võtame näiteks selle, kuhu tasemeni meie ettevõtted täna jõudnud on, siis võib juba uskuma hakata küll (enamus meie ettevõtetest on alles tasemetel 2 kuni 3).
Seega käised üles ja uueks aastaks kohe peale pingelist sügist ja eurole üleminekut on ideaalne aeg käivitada oma teenuste täiesti uuele tasemele tõstmise projekt .
Kaks küsimust, kui võib:
1. “Lisaks tuleb kokku leppida ka käesoleva projekti mõõdetavad tulemid. “See on jah alati teada, et võiks ja tuleks
. Oskate heade näidetega illustreerida?
2. Aga miks või mis puhkudel see kirjeldatud kasutajakeskne protsess ei sobi või mis kohtades, nüüd projekti läbinuna, võite öelda, et oleksite võinud rohkem õnnestuda
?
Küsimused on väga teretulnud
Näitena mõõdetavate tulemite kohta:
1. Efektiivsuse kasvu, mida saab mõõta näiteks ühele protsessile kuluva aja kaudu. Mõõdetakse seda enne ja pärast projekti etappi. ROI mõttes korrutatakse see tavaliselt sisemise tunnihinnaga läbi
2. Kliendirahulolu saab mõõta projekti lõpus läbi rahuloluküsitluse või teatud perioodis kliendile kordusmüükide arv
3. Vigade parandusele kulunud aeg protsentuaalselt projekti mahust
4. Ettepandud muudatuste hulk peale funktsionaalsuse arendust (protsentuaalselt projektimahust)
5. Projektimeeskonna tagasiside küsitlus (küsitluste kasutamine mõõdikutena ei ole alati objektiivne. Kui võimalik võiks siiski mõõta fakte, mitte arvamust)
6. Kasutatavust ja kasutaja protsessi pikkust on võimalik mõõta, kui tarkvara kvalitatiivse näitajana
7. Perioodis töölt lahkunud töötajate arv võib olla ka näiteks üks mõõdik
8. Kindlasti arendustöödest saadav kasum, mis on kogu protsessiparendamise majanduslik põhjus
Kõike ei ole mõtet ka korraga mõõta, sest kõiki näitajaid ei parendata ning osa näitajaid võib minna ka mõne teise eesmärgi saavutamise nimel kehvemaks. Mõõdikud tuleb vastavalt eesmärgile valida. Pea alati on võimalik edu/tagasiminekut mõõta (küll vahest läbi kaudsete näitajate).
Antud protsess ei ole nii tulemuslik, kui ettevõttes või arendustiimides on juba pöördumatud konfliktid. Protsess toimib, kui probleemid ei ole isikute tasandil vaid kokkulepete tasandil. Sõltuvalt sellest, kui palju on heitunud töötajaid on mõjutatud uuringute tulemus ning suuresti vürtsitatud isiklikest tugevatest emotsioonidega. Nii on võimalik teatud juhtudel (sõltuvalt uuringu läbiviija kogemustepagasist) tulemuseks saada vale hinnang probleemide tõsidusele. Tulemusena alustatakse vähem tähtsate probleemide lahendamisega, kust kasu nii palju ei tule.
Nagu igas konsultatsioonis ja muudatusi käsitlevas töös tuleb vältida ka konfliktide teket juurutus- ja uuringu protsessis. Olen näinud projekte, mis on selle pärast jäänud kesistele tulemustele või katkestatud. Muudatusi tuleb “müüa” läbi isikliku kasu.