Blog

Mis teeb veebi kasutatavamaks?

Üsna tihti küsitakse mult muu hulgas: kuidas te garanteerite, et teie tööst muutub toode või teenus paremaks ja toob rohkem kasu?

Ainult sellest, et peame ennast kogenud kasutatavuse spetsialistideks, ju ei piisa 🙂 . Oleme pidanud nentima, et jah, ega tihti olegi võimalik väga kokkuvõtvalt selgitada, kuidas me tulemuseni jõuame. See nõuab pikemat jutuajamist.

Et veebilehte paremaks muuta ei piisa ka ainult oma kogemuste põhjal hinnangu andmisest. Iga toode ja teenus, nagu ka projekt, on erinev. Kui palju te usaldaksite spetsialisti, kes ütleb et alati, igas projektis, on ainult need viis asja, mille korda tegemine lahendab kõik teie probleemid?

Spetsialistiks olemise juurde kuuluvad ka teadmised võimalikest läbiproovitud töövõtetest ja needsamad äraproovitud töövõtted ongi tegelikult need, mis garanteerivad tulemuse.

Iga töövõte eeldab erinevas koguses ajaressurssi ning eelnevat rakendamiskogemust. Täpselt nagu iga valitud töövõte toob erineval määral kasu.

Seega ei sõltu tulemuse saavutamine niivõrd isikuomadustest ja oskusest viriseda kunagi kellegi tehtud töö kallal (mis on küll vahel samuti oluline), vaid pigem meetodite kasutamise ja valimise oskusest.

Eestis tehtava töö jaoks on meil välja kujunenud meetodite kogum, mis näib üpris paljudel juhtudel hästi töötavat ja on mõnevõrra säästlikum kui muud.

Seega kirjeldan siin seda tihti kasutatavat tegevuste jada, mis aitab garanteerida, et tehtud tööst on kasu.

  1. Planeerimine
  2. Ütleme, et meil on veebileht, mis on oma infohulgalt küllaltki suur ja vajab hädasti ülevaatamist, kuna sealt on pea võimatu vajalikku infot üles leida.

    Selle projekti peamine eesmärk on infot korrastada ja muuta see kiiresti ning loogiliselt leitavaks.

    Nagu igale projektile kohane, läbime enne tööleasumist planeerimisfaasi. Selles faasis püüame aru saada, mis on töö täiendavad eesmärgid, kuidas mõõta töö edukust, milline on olemasolev info, milliseid töid me tegema hakkame ja kes millise ülesande eest vastutab.

    Tihti koostatakse projektiplaan ja räägitakse läbi, kuidas üht või teist ülesannet täita, millise tulemuseni soovitakse jõuda ning mida kindlasti teha ei tohiks. Samuti on siin oma koht riskide hindamisel – näiteks, mis siis saab, kui mitte keegi ei ole nõus meile intervjuud andma…

  3. Info kogumine
  4. Kui projekti tööd ja tegemised on läbi arutatud, tuleb hakata infot koguma. Enamasti tehakse seda intervjuude või küsitluste vormis. Kui kasutatakse intervjuusid, siis on vaja ka planeerida, keda intervjueerida, mida me tahame teada saada ning milliseid küsimusi tuleb selleks küsida.

    Siin tuleb pöörata tähelepanu ka meie projekti peamisele soovitud tulemusele – paremini korrastatud informatsioon. Selle tulemuseni jõudmisel on sageli abiks kaartide sorteerimine (ingl card sorting). Seda tehakse enamasti intervjuu käigus: intervjueeritaval palutakse teemakaarte niimoodi grupeerida, et need moodustaksid tema jaoks loogilise terviku.

    Samuti käib info kogumise alla olemasoleva süsteemi kasutatavuse test. Seda on mõistlik teha pärast kasutaja vajaduste analüüsimist, nii on sellest rohkem kasu. (Kasutatavuse testi juurde tuleme hiljem veel tagasi.)

  5. Kasutajate vajaduste analüüs
  6. Siit jõuamegi kasutajate vajaduste analüüsimiseni. Seda sammu on vaja peamiselt selleks, et kogutud infost oleks võimalik üheselt arusaadavaid järeldusi teha.

    Vajaduste analüüsi tulemusena saame loetelu nõuetest, mis peaksid veebilehe uues versioonis kindlasti täidetud olema. Sellesse loetellu on koondatud just selle konkreetse veebilehe kasutajate ning omaniku vajadused ja ootused. Need ei ole tavaliselt samad, mis üldised kasutatavuse reeglid. (Kasutatavuse üldistest reeglitest tuleb ka kindlasti kinni pidada, aga ilma kasutajate konkreetsete vajaduste analüüsita ei pruugi neist olla kuigi palju kasu.)

  7. Hindamine
  8. Kui kõik nõuded on teada, tuleb asuda hindma, kuidas on need nõuded täidetud olemasoleval veebilehel. Siin tuleb tihti appi juba eespool mainitud kasutatavuse või, teisisõnu, kasutajate test. Selle testi tulemusena saame loetelu veebilehel olevatest probleemidest.

    Kasutatavuse testi asemel võib kasutada ka muid hinnangu andmise viise. Kõige lihtsam on muidugi valida eksperthinnang, aga siinjuures tuleb mainida, et eksperthinnangu kasutamine ei pruugi olla sama tulemuslik kui mõni muu meetod, kuna ekspert on siiski ainult üks kasutajate esindaja, kes enamasti ei ole isegi kasutaja.

  9. Disainimine
  10. Kui probleemsed kohad on leitud, tuleb need veebilehel parandada. Selleks on mõistlik luua veebilehe prototüüp, mida saab ka enne süsteemi arendamist testida.

    Muudatuste kavandamisel tuleb kindlasti pöörata suurt tähelepanu elementaarsetele kasutatavuse ja ligipääsetavuse nõuetele ning vajadusel neid eraldi hinnata ja parandada. Mõned kasutatavuse põhinõuded saab formuleerida, hinnata ja täita alles arendamise käigus.

  11. Uuesti hindamine
  12. Kui veebilehel on probleemid lahendatud, tuleb lahendus uuesti üle vaadata, et näha, kas lahendused täidavad oma esialgset eesmärki, ning vajadusel analüüsida, kuidas saaks kasutatavust veelgi parandada.

    Sageli tulevad väiksemad probleemid välja alles siis, kui suured on eest ära. Seega on mõistlik lahendada probleeme nende olulisuse järjekorras (“top 10” alusel) ja aeg-ajalt tervik uuesti üle hinnata, et „suurt pilti“ mitte silme eest kaotada.

Kirjeldatud protsess võib olla ka mõnevõrra teistsugune, aga sobib siiski päris paljudel juhtudel. Samuti pole sellisel töödejadal midagi tegemist kogemata tulemuse saavutamisega. Tulemuste saavutamine on siin ette planeeritud ning korduvalt järele proovitud – oletustel pole siin kohta. Nii ei saagi kunagi olla küsimust, kas toode või teenus läheb paremaks, vaid ainult, kui palju ta paremaks läheb ja millise aja jooksul.

Seega, kui keegi küsib meie käest õigustatud küsimuse, et mis ikkagi positiivse tulemuse tagab, saame ikka ja jälle vastata, et seda teevad läbiproovitud ja usalduse võitnud töövõtted kogenud spetsialiste käes 🙂

Huvitavat meetodite avastamist!

Hegle Sarapuu

www.trinidad.ee

PS! Kas teadsid, et inimese geneetiline kood kannab edasi 1,5 GB informatsiooni?

Loading Facebook Comments ...

There are 9 comments .

Andrus

Kui täitsa aus olla, siis jube jube pikk jutt ja kahtlen et keegi seda läbi viitsib lugeda.

Läheb väga sellesse kategooriasse mida teevad paljud esinejad oma powerpoindi presentatsioonidega, et külvatakse infoga üle…

Reply »
kristjan

Ma tegin selle lingi lahti kolm korda ennem kui viitsin seda lugema hakkata. Siis lugesin ka kiirlugemisena selle läbi ja vaatasin, et Andrus on asjakohase kommentaari siia lõppu pannud, mis mulle kõige enam nüüd sellest tekstist meelde jääb.

Reply »
aabram

Heh, tahtsin sedasama öelda, mis Andruski. Alguse lugesin huviga läbi, aga kui veerg muudkui jooksis ja jooksis liigendusteta ja esiletõsteteta, siis teise poole kerisin juba lugemata edasi, lootes lõpust kokkuvõtvaid punkte leida. Kontsentreeritumalt, palun.

Reply »
Miki —

teete tüdrukule kambakat siin või? 🙂
kuigi tõsi ta on, et liigendus (boldid, bulletid jms) teeks asja kergemini hoomatavaks. eriti, kui lugejal ajaga kitsas käes. aga sisu oli ok!

Reply »
Hegle

Whooohaa, mis siin toimub 🙂 .

Tänan teid Miki, Aabram, Kristjan ja Andrus. ma nüüd avan selle edit view ja annan endast parima, et seda viga eemaldada. Andke teada, kas läks paremaks.

Olge tublid ja kambakat võite ikka teha, eriti kui on tegemist kasutatavusega 🙂 .

Reply »
Robin Gurney

making guarantees on the outcome of consultations is a brave thing to do. As with all “pay for performance” hybrids that we have used we have found guaranteeing improved bottom from usability, credibility and even visibility related consultancy particularly troublesome.

Basically we can identify problems and guarantee that if you do x,y and z then you will get % improvement in “results/goals -however they are defined” BUT
what happens when the client only follows advice x and y and forgets about z because of cost/time or other reason?

what happens if the fixes cant be implemented for 6-9 months (easily possible in big organisations)

How do those things affect the guarantee?

Whose fault is it if a client does not follow all the advice?

I have found payment for consultancy based on results requires a legal-mumbo-jumbo contract (which we hate) so we tend to avoid the scenario.

Case studies and testimonials are usually enough for us to get a job but I applaud anyone who is prepared to make guarantees… good luck.

Making guarantees on “campaigns” is MUCH easier. email, online PR, seo and SEM are all easily guaranteeable in fact we do that regularly if asked.

Reply »
Hegle

I completely agree with Robin. We only can use case-studies and our own experience about “to be” performance.This is not precise and hardly enough for pay for performance agreement. That’s why most usability consultants work on an hourly basis.

Reply »
Erki

Robin, you had a valid comment regarding the mambo-jambo of the outcome based projects. In general, management consulting and transaction advisory (M&A, acquisitions etc) consultants work often on the success-fee based contracts. Indeed, majority of the cases there is also retainer for every month/day/week based work done, yet the jack-pot comes after the project (incl. recommendations, action plan etc) have been delivered. In Transaction advisory, it is relatively easy as the end is either deal or no deal. Yet, in general management consulting it is also a fuzz and something difficult to measure. Therefore, often consultants also propose to help and carry through the implementations as then the results could be guaranteed even more. However, if not, then bottom-lines have to be agreed. E.g. out of which we start looking for the success and which parts or ports are actually then implemented. The rules have to relatively defined of the performance measurement.

And, what Hegle said about the case studies – that is true. Yet often (depending on your CF) you can also agree that the sum of performance will be paid (after retainer or hourly fees) in some periods when the actual benefits realization is done by the client.

Reply »

Share Your Thoughts!

Copyright ©2005-. All Rights Reserved.