Kuidas anda prototüübile tagasisidet?

Sissejuhatus

Prototüüpimine on tähtis osa veebilehe, rakenduse või infosüsteemi loomise protsessist, sest võimaldab anda tulevasele süsteemile tagasisidet juba väga varases projekti staadiumis.

Kuid kuidas anda efektiivset tagasisidet, eriti kui erinevaid huvigruppe, kelle arvamust ja soovitusi tuleb arvesse võtta, on palju?

Kuidas panna kõiki osapooli rääkima, kuid samal ajal arutelu ohjata?

Oma töös oleme näinud, et see ei ole sugugi lihtne. Selle digiraamatu olemegi loonud just selleks, et see aitaks iseseisvalt prototüüpi analüüsida ning asjalikku ja projekti edasiviivat tagasisidet anda. Et kliendi koostöö disaineri ja kasutajakogemuse spetsialistiga oleks sujuvam!

Igas peatükis on toodud rida kontrollküsimusi. Kontrollküsimuste plokid toimivad praktiliste tööriistadena, mis aitavad projekti soovitud suunas edasi juhtida. Koos projektimeeskonnaga neile vastuseid otsides koondubki kokku projekti edasiviimiseks vajalik tagasiside.

Peatükkide juures olevad kokkuvõtted annavad lühidalt edasi põhilise, mida meeles pidada.

Disainer rõhutab

Rubriigis anname edasi meie kogemusi, kuidas levinud pudelikaelu protsessis vältida ja koostööd sujuvamaks muuta. Samuti anname vihjeid, milliseid tegevusi võib ja mida kindlasti ei tasuks üht uut süsteemi luues “vahele jätta”.

Kõiki juhendi osi võib kasutada nii prototüübi viimastele kui ka esimestele versioonidele tagasiside andmiseks.

Loodame, et meie kogemus ja näpunäited on teile kasulikud.

TWN meeskond

Mis on prototüüp?

Prototüüp on mustand-versioon süsteemi kasutajaliidesest, mida kasutatakse esialgse mulje loomiseks, tagasiside kogumiseks, arutelude inspiratsioonina ning tegevuste ja sammude läbiproovimiseks.

Prototüüpimine on tõhus meetod, mis võimaldab lihtsalt ja kiirelt tuvastada võimalikke vigu, testida funktsionaalsust ja kasutatavust ning demonstreerida disainialternatiive projekti juba projekti varajases staadiumis enne arendustöid.

Disainer rõhutab!

Enamasti ei ole prototüübis värve, õigeid fonte ega lõplikke fotosid – need lisatakse hiljem visuaalse disaini staadiumis. Kujundusega prototüübi tegemine nõuab rohkem aega ning töömahtu ning ei ole varases faasis optimaalne.

Prototüübi evolutsioon

Prototüüpe kasutatakse kogu disainiprotsessi jooksul. Vastavalt detailsusastmele võib neid jagada kahte kategooriasse – low-fidelity (lo-fi) ehk madala detailsusega ja high-fidelity (hi-fi) ehk kõrge detailsusega prototüübid.

Lo-fi prototüüpe kasutatakse pigem mõtete kavandamiseks ja läbimõtlemiseks ning nende eelised on kiirus, odavus ja lihtsus. Lo-fi prototüüpi on väga lihtne ja kiire muuta. Näiteks kasutatakse lo-fi prototüübina sageli paber-prototüüpimist.

Hi-fi prototüübid on juba digitaliseeritud versioonid, mis sarnanevad veidi enam lõpp-produktile (kuigi need ei ole veel lõpliku visuaalse kujundusega). Hi-fi prototüübid on kasulikud projekti võtmeisikutega suhtlemisel (aitavad koguda tagasisidet) ning aitavad läbi viia kasutatavuse testimist lõppkasutajatega. Kuigi taolise prototüübi loomine võtab kauem aega, on ka see etapp väga oluline, sest aitab tuvastada võimalikud funktsionaalsusega ja kasutatavusega seotud probleemid enne arendusprotsessi.

Kokkuvõte

Prototüübi kuju ja detailsus on ajas muutuvad, alustada võiks lo-fi prototüübiga ning lõpetada hi-fi prototüübiga.

Miks on prototüüp kasulik?

Annab võimaluse õppida varakult ja väga kiiresti

Tarkvara kasutajaliidese loomine võtab arvestatava aja. Prototüüp annab võimaluse väga varakult läbi arutelu panna paika kõige olulisem, anda edasi ideid ning tuua välja puudusi - see on oluliselt kuluefektiivsem.

Tagab võtmeisikute ja kasutajate rahulolu

Prototüüpimise protsessi kaasatakse võtmeisikud, kasutajad ja teised projekti osapooled juba idee varajases staadiumis. Selle tulemusena arutatakse võimalik lahendus väga detailsel tasemel läbi ning erinevate osapoolte vajadused saavad paremini kaetud.

Vähendab riske

Paljud tarkvaraprojektid ei jää ebapiisava info põhjal tehtud mahuhinnangute ja valede eelduste tõttu määratud aja ja eelarve piiridesse. Prototüüp aitab arendustööde mahtu täpsemini hinnata.

Kokkuvõte

Prototüüp hoiab kokku kogu süsteemi loomise aega ja raha ning annab kindluse, et kõik osapooled on loodavast süsteemist ühtmoodi aru saanud.

Tagasiside tähtsus ja eesmärk disainiprotsessis

Prototüüpimine on oluline ka selleks, et tõsta kasutatavust süsteemis. Kasutatavus tähendab kasutajatele erinevat väärtust sõltuvalt nende eesmärkidest. Prototüüp aitabki kasutajate erinevatest eesmärkidest ja eelistustest paremini ja kiiremini aru saada.

Prototüüpimise faasis on tagasiside oluline selleks, et erinevad projekti osapooled - näiteks võtmeisikud - varajases disainistaadiumis vajalikud otsused saaks vastu võtta.

Kokkuvõte

Prototüübile õigeaegne tagasiside kogumine aitab erinevate kasutajate eesmärkidest ja väärtustest kiiremini aru saada ja teha äriotsuseid kasutatavuse piisavuse kohta.

Millal ja millises vormis võiks tagasisidet koguda?

Tänase disainimaailma parim praktika on küsida tagasisidet võimalikult varakult ning enamjaolt viimistlemata töötulemite pealt – see väldib ressursside raiskamist mittesobivate lahenduste detailideni viimistlemise arvelt.

Soovitame tagasisidet koguda pingevaba, kuid fookusega arutelu vormis.

Hea, kui igal kohtumisel oleks küllaltki konkreetne eesmärk - näiteks arutada esilehe uudiste sektsiooni ülesehitust, esilehe infopaigutust, otsingu toimimisloogikat vms.

Disaineril on prototüübi ja suuliste selgituste abil lihtne oma ideid tutvustada ning vajadusel kiireid muudatusi teha. Osalejatel on võimalus saada vastuseid tekkinud küsimustele, edastada oma mõtteid ja vajadusi ning lõpuks kinnitada, et antud nägemus vastab ootustele.

Disainer rõhutab

Ükski osa ei ole „kivisse raiutud“ – kõike on võimalik praegu veel muuta, täiendada ja isegi mitu versiooni teha. Ära pelga ideid pakkuda ja küsida. Praegu on just õige hetk, prototüübiga otsimegi just piirangute raames parimat lahendust.

Kuidas tagasisidet struktureerida?

Arutelu käigus tekkiva info võiks kõigile osapooltele arusaadavalt jagada nelja gruppi. See aitab vältida valesti mõistmist ning võimaldab disaineril lihtsamini mõista tagasisidel põhinevaid edasisi tegevusi.

  • Meeldivused – osad, mis mulle meeldivad kõige enam

  • Küsimused – osad, mida ma ei mõista

  • Kriitika – osad, mida saaks parendada

  • Ideed – uued ideed, mida võiks kaaluda

Kokkuvõte

Tagasiside prototüübile võiks anda varases projekti staadiumis, arutelu vormis ning jaotada meeldivusteks, küsimusteks, kriitikaks ja ideedeks.

Neli tagasiside kategooriat

Millele täpsemalt tagasiside andmisel keskenduda?

Prototüüpi tuleks analüüsida osade kaupa, vastates erinevatele küsimustele. Sõltuvalt prototüübi detailsusastmest võivad osad küsimused mingis sammus või kategoorias olla mittesobivad või vähem prioriteetsed.

Teisalt on oluline, et need küsimused ikkagi küsitud ja vastatud saaks. Siin on abiks struktuurne teemapõhine lähenemine.

Prototüüpi võiks analüüsida vastavalt neljale kategooriale:

  • Äri – Kuidas aitab lahendus saavutada äri, organisatsiooni või süsteemi eesmärke?

  • Kasutaja – Kuidas kasutaja selles süsteemis käitub?

  • Tehnoloogia – Kui keeruline on pakutud lahendus tehnoloogiliselt?

  • Vormistus – Kas projekti meeskond ja teised prototüübi sihtrühmad saavad lahendusest aru?

Disainer rõhutab

Kui mõni teine ettevõte või veebileht midagi edukalt teeb, ei tähenda see, et see mõnes teises kontekstis oleks hea idee või üldse tööle hakkaks. Suured teevadki palju erinevaid katsetusi ning sugugi mitte kõik lahendused pole ka nende jaoks elujõulised.

Disainer rõhutab

Prototüübis võiks olla hädavajalik hulk seal olema hakkavast tõesest informatsioonist. Kogu sisu ja funktsionaalsuste lisamine on projekti praeguses staadiumis ebaoptimaalne. Näiteks ei uuendata kuupäevi, ei lisata alati kõiki valikuid või ei tööta prototüübis konkreetsed otsingusõnad. Kui aga tegeliku informatsiooni kuvamine on kriitilise tähtsusega, et hinnata lahenduse toimimist kasutajate jaoks, tuleb see muidugi lisada.

Äri vaatenurk

Esmalt tuleks selgeks saada, kas kõik mõistavad, mis on käesoleva projekti äriline eesmärk – millist muudatust sellega soovitakse.

Disainiprojektide puhul on peamised eesmärgid näiteks kasutajate käitumise suunamine, tegevuste lihtsustamine või kiirendamine, uute võimaluste loomine või lihtsalt meeldivama välimuse loomine.

  1. Kas pakutud lahenduse prototüüp on projekti eesmärgiga vastavuses?

    Näiteks

    Meie projekti eesmärk on kiirendada arvete väljastamist. Kas sellisel kujul loodud süsteem kiirendab arvete väljastamist?

  2. Näiteks

    Meie kasutajad on müügijuhid, kellelt ootame kohe toote müügil arve väljastamist kliendi e-postile. Kas see on kõige lihtsam viis arvet väljastada? Kas tööprotsess süsteemis soodustab ülesannet kohe ära tegema või hoopis edasi lükkama? Kas kasutaja peab pingsalt meeles pidama, et tal on midagi järgmiseks vaja teha?

  3. Kas me suudame sellist teenust piisavalt kvaliteetselt pakkuda? Kuidas meie organisatsioon muutuma peab.

    Näiteks

    Kui me pakume teenust nii infosüsteemis kui ka üle leti, siis kas kasutaja ikka saab kogu informatsiooni iseseisvalt kätte või meil on vaja telefoniteenindajate hulka kasvatada? Kas saame kuidagi lahendust seda silmas pidades paremaks teha?

  4. Kas tegevuste jada ja funktsionaalsuse tunnetus annab edasi ka brändi prioriteete?

    Näiteks

    Meie brändi prioriteet on meie lubadus klientidele kiiresti mõnda teenust pakkuda. Kas see prototüübitud lahendus nõuab kliendilt vähe tööd ja võimaldab maksimaalse kiirusega teenust tarbida? Kas ooteajad on asendatud välkkiirete vastustega? Kas on kasutatud automatiseerimise ja andmete korduvkasutamise parimaid praktikaid, et vähendada klientide ning teenindajate käsitööd? Kas me sunnime kasutajaid äkki hoopis pikki ja keerulisi tekste läbi lugema selle asemel, et lihtsalt „klikk-klikk ja tehtud“ lähenemist kasutada?

Kasutaja vaatenurk

Kasutaja on isik, kes tulevikus loodavat lahendust kasutama hakkab ja võib olla nii klient kui ka kaastöötaja.

Selleks, et hinnata prototüüpi, tuleks küsida kontrollküsimusi kasutaja, tema ülesande, keelekasutuse ja hädaolukorda sattumise kohta.

  1. Kes on selle lahenduse kasutaja ja mis ülesannet (ülesandeid) ta täidab lehel/ süsteemis? Kas prototüüp on sellega kooskõlas?

  2. Kas protsessi alguses on selge, milline teenus see on ja kuidas see aitab kasutajat paremini ja kiiremini eesmärke saavutada?

  3. Kas see lahendus on kõige kiirem ja lihtsam (vähimate tegevustega) viis, et ülesanne tehtud saaks? Mida saaks teha, et kiirendada ja lihtsustada kasutaja ülesande täitmist?

  4. Kas süsteem läheneb kasutajale personaalselt, justkui tundes tema eelistusi ja ta varasemaid valikuid ning võimaldades kasutajal edasisi tegevusi lihtsamini ja kiiremini teha?

  5. Mis saab siis, kui kasutaja protsessi lõpetab, kas teda informeeritakse sellest? Kas ta viiakse lahenduses kohta, kus ta saab alustada järgneva tegevusega? Kust ta saab tulevikus tagasisidet käesoleva protsessi kohta?

  6. Kui tihti kasutaja peaks seda lahendust kasutama päevas, kuus, aastas? Kas talle on oluline kiire kasutuskord või detailideni seletav kasutuskord? Kas lahenduse prototüüp on sellega kooskõlas?

  7. Kus kasutaja lahendust tarbib ja milliseid seadmeid selleks kasutab (paljudel juhtudel ei kasutata tänapäeval süsteeme kontoris laua taga)? Kas lahenduse prototüüp on sellega kooskõlas?

Disainer rõhutab

Kui küsimustele on keeruline vastata, võib see tingitud olla sellest, et eelnevalt ei ole tehtud piisavas mahus kasutajate uuringuid või intervjuusid. Kasutatavuse testimine võimaldab selles projekti etapis leida kasutatavuse probleemid üles kasutaja kaasabil.

Kas keelekasutus ja tekstide pikkus on põhjendatud?

Kui kasutajaliideses on palju ülemäärast, siis pilt on kirju ja fookus kipub kaduma. Tuleks arutleda selle üle, mida saaks veel eemaldada või kas ekraani võiks saada väiksemateks osadeks/ alamekraanideks jaotada. Oluline on, et see ei vähendaks efektiivsust ekraanil, mida kasutatakse palju kordi päevas.

  1. Kas kasutaja nimetab tehtavaid tegevusi ja välju samamoodi nagu neid on nimetatud prototüübis?

  2. Kas kõik andmed on lahenduses olemas, mida on vaja küsida või näidata?

  3. Kas tekst on õige ja päriseluline? Kui ei, siis kas on vähemasti töös?

  4. Kas on välditud lühendeid, kantseliiti, võõrsõnu ja pikki tekstipõhiseid juhendeid? Kas on eemaldatud kõik ebavajalik nii, et see arusaamist ei takista?

  5. Kas kogu kasutajalt küsitav informatsioon on õigustatud tegevuse tegemiseks/ teenuse tarbimiseks?

Kui kasutaja jääb hätta, siis kuidas ta saab abi?

  1. Kas kasutajal on selge ja turvaline alguspunkt, kuhu ta probleemi korral tagasi saab minna ja uuesti alustada (näiteks esileht)?

  2. Kas kasutajal on lihtne leida koht, kust saab abi?

  3. Kas kasutajatoenumber on kergesti leitav?

  4. Kas veateated on piisavalt informatiivsed, et kasutaja saaks aru, mida ta valesti tegi ja mida ta tegema peab, et viga parandada?

  5. Kas veateadete saamist on võimalik vähendada vormi ümber disainimisega?

Milline on organisatsiooni tehnoloogiline valmisolek?

Hea süsteemi loomiseks on vaja häid ideid, aga ka tehnilist võimekust ja ressursse nende teostamiseks. On aeg üle kontrollida, kui kaugele te olete valmis innovatsiooniskaalal hüppama ja mis see teile maksma läheb.

Ka selle vaatenurga puhul on prototüübi näitamine ja sellega kaasnev arutelu parimaks viisiks, et hinnata, kas ka tehnoloogiliselt on realistlik projekt ellu viia.

Näiteks

Kui soovite klientidele veebilehel toote hinda näidata, peab see kuskilt tulema. Kui me seda käsitsi ei soovi sisestada, siis on vaja seda võtta mõnest teisest infosüsteemist. Võibolla tuleb esmalt alustada alusandmetest?

Järgmisena olge valmis oma tehnoloogiaeksperte kaasates küsima järgnevaid küsimusi.

  1. Kas meil on olemas infosüsteem, kus uute teenuste loomiseks on alusinformatsioon olemas? Kas olemasolevast infosüsteemist on seda võimalik kätte saada? Kui palju arendustööd peame tegema, et olemasolev infosüsteem meil uusi lahendusi luua võimaldaks?

  2. Kas meil on juba alustatud mõne alusinformatsiooni pakkuva infosüsteemi loomist, juurutamist või disainimist?

  3. Kas meil on olemas hetkel katki olev infosüsteem? Kas uue loomine on õigustatud ning kas vana võib pärast kinni panna?

Töögrupis osalejate vaatepunkt

Prototüüp ise ei ole lõplik infosüsteem, vaid seda tuleb infosüsteemi valmis tegemiseks erinevatel inimestel kasutada kui lahendusinformatsiooni kandjat. Prototüüpi võib pidada piisavalt hästi vormistatuks kui järgnevatele küsimustele saab selgelt jaatavalt vastata.

  1. Kas kõik elemendid ning nende eesmärk lahenduses on arusaadavad?

  2. Kas kõik kasutaja tegevusele reageerivad ehk interaktiivsed elemendid on selgelt tuvastatavad? Kas nende elementide käitumine peale kasutaja tegevust on selge?

  3. Kas on selge, kuidas ja millal süsteem ühelt lehelt teisele liigub?

  4. Kas prototüübis on puudu osasid, mis ei tohiks puudu olla? N: mitte-avanevad lingid, veateated jne.

Kui vastused nendele küsimustele on ebalevad, siis tuleks disainerit kaasata aktiivselt ka arendusmeeskonna töösse. Sellisel juhul on disaineri ülesanne lahendusi selgitada, täpsustada ning vajadusel ka täiendada.

Millele pöörata tähelepanu prototüübi erinevate osade juures?

Veebipõhisel süsteemil (ja seetõttu ka prototüübil) on tüüpilised kasutajaliidese osad - avaleht, otsing, vormid, navigatsioon. Nendele osadele kehtivad tulenevalt funktsionaalsusest ning eesmärgist mõnevõrra erinevad nõuded ja eesmärgid, mida tuleb arvesse võtta ka tagasiside andmisel.

Kuidas anda tagasisidet avalehele?

Esimene asi, mida süsteemi, kodulehe või rakenduse kasutaja näeb, on avaleht. Seetõttu on tähtis, et see oleks meeldejääv ja arusaadav. Avalehte vaadates peab olema 30 sekundi jooksul selge, mida siin teha saab ja mis ettevõttega on tegemist. Samuti peaks avaleht sisaldama viiteid kõigile olulistele funktsionaalsustele.

Avalehe puhul tuleb sisu ning funktsionaalsus seada väga konkreetsesse prioriteetide järjekorda. Hea praktika on panna 20% kõige olulisemast funktsionaalsusest ekraani murdejoonest ülespoole (kohe lehte avades on see osa näha). 20% kõige tähtsamat tuleks valida selle järgi, milliseid kasutuskordi on kõikide kasutajate kohta kõige enam. Samas tuleb arvestada sellega, et mida rohkem nuppe ja infot esimesel ekraanil on, seda väiksema tõenäosusega kasutaja üldse midagi avalikus veebis vajutab.

Disainer rõhutab

Prototüüpide puhul on küll tavapärane, et alustatakse esilehest ning ehitatakse lisanduv sinna juurde, kuid kui projekt ei ole veel piisavalt küps, et täpselt teada kogu sisu, võib ka teha teisiti ja jätta esilehe hoopis viimaseks.

Kuidas anda tagasisidet otsingule?

Otsing on paljude süsteemide ja veebide juures üks olulisemaid funktsionaalsusi.

Otsingu puhul tuleb läbi mõelda konkreetsed otsingu kasutamise stsenaariumid ja üritada vältida igaks elujuhtumiks sobivat otsingufunktsionaalsust. Sellised otsingud kujunevad pigem kasutajate silmis ebameeldivaks ja ebaefektiivseks.

Arutelu käigus tuleks jõuda konsensuseni, milleni võib jõuda läbi otsingu ja mis on nii kiired asjad, mis vajavad juba eraldi välja toomist menüüs või lehe sisus (ehk mille puhul otsing oleks väärtusliku aja raiskamine).

Vältida tuleks liiga suuri ja paindlikke otsinguvorme esmase otsinguna. Otsingutulemusena tuleb mõelda selle, mille alusel kasutaja otsustab otsitava sisu üle ja oma valiku teeb.

Kui otsingu tulemusena saab erinevat tüüpi objekte, võiks peale otsingut olla võimaldatud täiendavad filtrid.

Kuidas anda tagasisidet erinevatele funktsionaalsustele?

Funktsionaalsus kasutaja seisukohast on põhjus, miks süsteemi kasutatakse. Oluline on tähele panna, et funktsionaalsusele viitavad liikumisteed oleksid nimetatud vastavalt kasutaja ülesandele või funktsionaalsuse kasutamise eesmärkidele.

Funktsionaalsuse alla käib aga ka kasutajaliidese elementide toimimisloogika. Üks lihtsamaid viise veenduda funktsionaalsuse loogilisuses on viia läbi kasutatavuse teste. Samas kehtib ka tõsiasi, et kui meeskonnale tundub kasutajaliidese käitumine „kahtlane“ ja „veidi lahtine“, tuleb see kindlasti ka kasutatavuse testist välja ning eelnevalt korda tehtuna oleksime hoidnud aega kokku. Ehk et alati pole mõtet minna testima asju, mille mittetoimivuses oleme juba ette veendunud.

  1. Kas funktsionaalsusele viitavad elemendid on läbi kasutajaliidese nimetatud sarnaselt ning kas sama funktsionaalsuse elemendid käituvad sama moodi?

  2. Kas on arvestatud nii nende inimestega, kes konkreetset funktsionaalsust kasutavad esimest korda kui ka nende inimestega, kes kasutavad funktsionaalsust iga päev mitmeid kordi?

  3. Kas keerulisemad ülesanded on jaotatud väiksemateks osadeks uute kasutajate puhul?

  4. Kas kogenud kasutajad saavad ülesandeid teha kiiremini ning vähemate liigutustega?

  5. Kas on välditud üleliigseid elemente, sest me ei julgenud/suutnud otsustada, kuidas kasutaja seda kasutada soovib?

  6. Kas kasutajaliidese funktsionaalsus käitub sarnaselt teistele sarnaste funktsioonidega kasutajaliidestele (eriti nendele, millega kasutaja on töötanud varem)?

  7. Kas kasutajaliides käitub kasutatavat seadet arvestades oodatavalt (näiteks telefoni kasutaja oodatav kasutajaliidese käitumine on erinev arvuti kasutaja ootustele)?

  8. Kas kõik kasutajaliidese elemendid käituvad oodatavalt (näiteks raadionuppude hulgast saab valida ainult ühte või valikväli avaneb allapoole)?

  9. Kas süsteem vihjab või selgitab toimuvat kasutajale?

  10. Kas vaikeväärtused jäävad ikka suuremal osal juhtudel muutmata?

  11. Kas kasutajaliides innustab proovima erinevaid kasutajaliidese komponente ja ei karista kasutajat selle eest?

Kuidas anda tagasisidet navigatsioonile?

Selleks, et kasutajal oleks võimalikult lihtne ja loogiline orienteeruda, on vaja hinnata veebilehe navigatsioonisüsteemi. Oluline on, et kasutaja saaks aru, millisel lehel ta on, ning kuidas leida endale vajalikku informatsiooni. Lehekülje olulisemad navigatsiooniviidad peaksid olema selgelt nähtavad, vastavalt nimetatud ning ühtsed. Navigatsiooni toimivuse hindamiseks võib kasutada ka erinevaid meetodeid, näiteks kaartide sorteerimine või kasutatavuse testimine.

Igal momendil peab kasutaja saama kasutajaliideses vastuse kolmele küsimusele.

Kui see pole võimalik, on vaja prototüüpi muuta:

  1. Kus ma hetkel olen?
    Seda informatsiooni annavad pealkirjad, esile tõstetud menüüelemendid jne.

  2. Kuhu ma siit minna saan?
    Seda informatsiooni annavad elemendid, mis viivad protsessis järgmisele sammule (näiteks väljade täitmise järjestus, informatsioon akna sulgemise kohta) või kinnitavad valikut (näiteks nupud).

Tagasiside andmiseks võiks vastata järgnevatele küsimustele.

  1. Kas on näha selgelt, millist elementi tuleb järgmisena kasutada?

  2. Kas igal ajahetkel paistab kõige paremini välja järgmise elemendina üks konkreetne element ning on välditud liiga paljude elementide vahel valimist?

  3. Kas navigatsiooniks kasutatavad elemendid käituvad järjepidevalt (sarnaselt läbi kasutajaliidese kõikide lehtede)

  4. Kas nimetamine on kasutajale üheselt arusaadav (kas ta nimetaks ise samamoodi)?

Kuidas anda tagasisidet vormidele?

Tihti on veebilehekülgede oluliseks osaks andmete sisestamine, mida kasutaja näeb näiteks vormina. Enamjaolt sisaldavad vormid mitut eri elementi nagu sisestusväljad, rippmenüüd, Call To Action nupp jms.

Et kasutajal oleks võimalikult mugav enda andmeid sisestada ei tohiks vorm olla liiga pikk ega aeganõudev. Lihtne ja loogiline paigutus ning visuaalselt korrektsed sildid, ühtselt paigutatud ja joondatud tulbad annavad samuti palju juurde ning suurendavad kasutusmugavust.

  1. Kas vormi esmamulje on vormistuslikult korrektne, täitmise töökoormus saadava hüve nimel oodatav ning tundub lihtne?

  2. Kas vormi sisaldav leht paistab usaldusväärne ning viitab selgelt ettevõttele/asutusele (link, brändielemendid, kirjavigade vaba, piisavalt ametlik)?

  3. Kas vormi väljad on grupeeritud vastavalt omavahelistele seostele (omavahel temaatiliselt seotud küsimused-vastused on koos)?

  4. Kas selliste küsimuste küsimine, pidades silmas vormi täitmise eesmärki, on õigustatud?

  5. Kas vormielemendid on paigutatud nii, et hiirega kasutatavad elemendid ja klaviatuuriga sisestatavad elemendid on pigem koos?

  6. Kas on välditud pikki hiireteekondi, kerimisi, silmade teekondi, üleliigseid hiireklõpse või klaviatuurivajutusi?

  7. Kas küsimustele saab nii, nagu palutud, alati korrektselt vastata?

  8. Kas kasutaja saab aru, mida küsitakse ning teab kuidas vastust sisestada antud elemente kasutades?

  9. Kas päriselus sellises järjestuses küsides-vastates oleks vestlus sihtrühma liikmega mõistlik?

  10. Kas on selgelt aru saada, millal vorm sai edukalt või mitteedukalt täidetud ning informatsioon edasiste sammude kohta üheselt arusaadav? Kas kasutaja saab selgelt aru, kas ta eesmärk (tavaliselt mingi hüve, soov) on nüüd täidetud või tuleb tal veel midagi selleks teha?

  11. Kas vorm väldib tehniliselt juba sisestatud vormilt andmete kadumist?

  12. Kas vorm on täidetav ainult klaviatuuri kasutades? (Kehtib enamjaolt lõpliku, arendatud vormi puhul, prototüübi loomise tehnoloogia ei pruugi seda alati võimaldada.)

Kuidas anda tagasisidet sisule?

Igal veebilehel ja infosüsteemil on olemas sisu, millega enda sõnumit edasi anda. See peab olema kasutaja jaoks vajalik ning vastavuses lehekülje eesmärkidega. Tekst peab olema loetav ning kirjatüüp selge, piisava tähesuurusega ja õige värviga. Läbi tasub mõelda ka veebilehe tausta ja kirjatüübi värvi kontrastsus.

Esmase prototüübi puhul on tavaline, et sisu asemel on ajutine, nö dummy content, sest alguses on olulisem põhifunktsionaalsuse ning navigatsioonisüsteemi testimine. Detailsemates prototüüpides peaks sisu juba reaalsusele vastama ning näiteks Lorem Ipsum tekst sinna enam ei kuulu. Kuna tihti on sisukirjutajad (sageli töötellija spetsialistid) ning disainerid projektis erinevad inimesed, tuleks varakult planeerida ka sisu loomine.

  1. Kas tekst on 100% suurendusega ilma pingutuseta loetav tüüpilisel kasutaja lugemiskaugusel ning kasutatava kuvariga? Teksti suurust peab saama ka suurendada kuni 2x ilma et muud elemendid omavahel kattuma hakkaksid või horisontaalset kerimisriba tekiks. Prototüüp näitab selgelt kätte kohad, kus selline oht tekkida võib (kuigi see ei pruugi suurendamist iseenesest võimaldada).

  2. Juhul, kui teksti visuaalne kuju kandub edasi ka lõplikku disaini, siis kas prototüübis kasutatud font, suurus ja tekstivärv on piisavalt loetavad (enamjaolt kasutatakse prototüübis ajutisi fonte ning värve)?

  3. Kas tekstile on jäetud piisavalt ruumi? Arvestada tuleks nii tõlgetega pikema kirjapildiga keelde (nt vene keel) kui ka üldise teksti ümber oleva kohustusliku tühialaga.

  4. Kas teksti mõte on üheselt sihtrühmale mõistetav? Kas tekst räägib sihtrühma „keeles“ (kui sihtrühmaks on laiem üldsus, siis peaks olema tekst mõistetav 7. klassi õpilasele)?

  5. Kas tekst hoidub ilustavatest, kuid segavatest täiendustest (ebavajalikud sidesõnad, emotsiooni või täiendavat hinnangut andvad sõnad, põimlausete täpsustavad, kuid ebavajalikud osad, kordused, igaks juhuks lisatud reeglistikest kopeeritud tekst)?

  6. Kas tekst võimaldab silmadega kiiresti „üle libistades“ kogu teksti ja iga lõigu mõttest õieti aru saada?

  7. Kas tekst on piisavalt kaasahaarav?

Kuidas anda tagasisidet visuaalsele disainile?

Ühtne disain ja visuaal on veebilehekülje puhul väga olulised, sest annavad võimaluse haarata kasutaja tähelepanu ja huvi. Hea disain on ilus, lihtne ja puhas ning tekitab kasutajas positiivset emotsiooni. Visuaalse disaini hindamisel tasub mõelda, kas see on kooskõlas tellija brändinguga.

Kuigi prototüüpides kujundus pigem puudub, annavad need ettekujutuse lehtede ülesehitusest ning jälgida võiks brändingu elementide jaoks eraldatud ruumi ning nende asukohta ning eesmärki.

  1. Kas meie ettevõtte/ asutuse eristuvate visuaalsete elementide jaoks on planeeritud eraldi ruum? Kas see ruum on piisav?

  2. Kas brändingu jaoks kasutatavad elemendid vähendavad oluliselt kasutaja tööefektiivsust? Kas vähenenud efektiivsus on õigustatud?

  3. Kas tähelepanu koondub kõige tähtsamale järgmisele tegevusele? Mis selle tegevus-elemendiga visuaalselt konkureerib? Kas see konkurents on õigustatud? Kas seda on võimalik visuaalse disainiga lahendada?

Kokkuvõte

Kontrollküsimusi on palju ja igal kohtumisel kõiki ilmselt läbi käia ei jõua. Ühe arutelu jaoks võiks arvestada ühe teema või kategooriaga, pikemate arutelude puhul võib korraga plaani võtta ka terve ühe peatüki.

Usume, et digiraamatust on abi, et neid kohtumisi paremini planeerida ja nende põhjal konkreetsemaid aruteluteemasid eelnevalt kokku leppida.

Kui soovid saada teavitusi meie järgmiste digiraamatute ja ürituste ning uute artiklite kohta, lisa end meie meililisti.



Tulemusrikast tagasiside andmist!

TWNi meeskond