Klikitav prototüüp on veebilehe või rakenduse katsetatav kavand, milles saab läbi mängida kokkulepitud kasutajateekonna enne selle valmis arendamist. Tellimisel tasub määrata, millisele küsimusele prototüüp peab vastama, millised ekraanid ja tegevused selles töötavad ning mida pärast katsetamist arendajale üle antakse. Nii saab hinnata lahenduse loogikat, mitte ainult üksikute ekraanide välimust.
Näiteks võib ettevõte tahta teada, kas klient suudab valida sobiva teenusepaketi, täita hinnapäringu ning mõista, mis pärast saatmist edasi juhtub. Selle kontrollimiseks pole alati vaja valmis ehitada kogu kodulehte. Vaja on piisavalt terviklikku katsetatavat teekonda.
Mille poolest erinevad sõrestikmudel, kujundus ja prototüüp?
Sõrestikmudel ehk wireframe näitab tavaliselt lehe osade paigutust ja tähtsust. Visuaalne kujundus lisab brändi ilme, värvid, kirjad ning pildikeele. Klikitav prototüüp ühendab vaated nii, et kasutaja tegevus viib kokkulepitud järgmise sammuni. Sama kavand võib olla korraga nii visuaalselt viimistletud kui ka klikitav.
Avalike digiteenuste disainimise tööriistakast käsitleb prototüüpi esialgse mudelina, millega saab näidata ja testida kavandatud lahendust. See võib kujutada kogu teenust või ainult üht vajalikku osa. Seetõttu ei tähenda sõna „prototüüp” pakkumises veel automaatselt kogu veebilehe läbiklikitavat versiooni.
Ka klikitav kavand ei võrdu valmis veebiga. Päringunupp võib viia kinnituse ekraanile ilma e-kirja saatmata. Broneeringu vaade võib näidata näidisaegu ilma päris kalendriga ühenduseta. Need piirid tuleb tellijal, disaineril ja arendajal ühtemoodi mõista.
Millal tasub veebilehe prototüüp tellida?
Prototüüp on kasulik siis, kui oluline otsus sõltub kasutaja tegevuste järjestusest või erinevate valikute mõistmisest. Näiteks võib küsimus olla selles, kas hinnakalkulaator küsib sisendi arusaadavas järjekorras või kas mitmeosalises taotluses saab varasemat vastust mugavalt muuta.
Lihtsa infolehe puhul võib piisata põhiliste vaadete kujundamisest. Mahukam prototüüp on põhjendatum, kui veebis on tellimine, broneerimine, paketivalik, iseteenindus või mitme sammuga vorm. Töö maht võiks sõltuda ebakindlatest otsustest, mitte soovist muuta iga link demonstratsioonis aktiivseks.
Kui küsimus on alles selles, kuidas teenused lehtede vahel jaotada, alusta veebilehe struktuuri planeerimisest. Kui soovid esmalt hinnata olemasoleva veebi probleeme, sobib lähtekohaks UX-audit. Prototüüp aitab järgmises etapis uut lahendusvarianti nähtavaks ja katsetatavaks teha.
Pane ulatus kirja tegevuste ja olekute kaudu
Pakkumises olev „viis ekraani” võib tähendada väga erinevat töömahtu. Üks vorm võib vajada tühja algvaadet, täidetud vaadet, veateadet, parandamist ja kinnitust. Kui tellimus sisaldab ainult ilusat algvaadet, jääb oluline osa käitumisest hiljem otsustada.
Järgmine tabel on hüpoteetiline näide teenusepakkuja hinnapäringu prototüübist. See aitab kirjeldada, milliseid olukordi peab saama läbi mängida.
| Kasutaja tegevus | Vajalik kavand | Kontrollitav küsimus |
|---|---|---|
| Valib teenusepaketi | Pakettide võrdlus ja valiku tulemus | Kas inimene mõistab erinevusi ja teab, mida ta valis? |
| Lisab päringu andmed | Vormi algvaade ja täitmise näide | Kas küsitav info on arusaadav ning kasutajal olemas? |
| Parandab puuduvat vastust | Veateade ja parandatud olek | Kas on selge, mis vajab muutmist ja kuidas jätkata? |
| Muudab varasemat valikut | Tagasiliikumine ja säilinud sisend | Kas inimene saab paranduse teha kogu teekonda kordamata? |
| Saadab päringu | Kinnituse vaade koos järgmise sammu selgitusega | Kas ta saab aru, et päring õnnestus ja mida edasi oodata? |
Lepi kokku ka alguspunkt. Otse vormi avav katse ei näita, kas klient oskab teenuselehelt selle vormini jõuda. Samuti täpsusta, milliseid kõrvalteid prototüübis ei käsitleta, et nende puudumist ei peetaks kogemata kujundusveaks.
Kui detailne peaks prototüüp olema?
Detailsust tasub valida uuritava küsimuse järgi. Nielsen Norman Group eristab prototüübi detailsust nii interaktiivsuse, visuaali kui ka sisu tasandil. Seega võib üldiselt lihtne kavand sisaldada väga täpseid vormitekste või hästi läbimõeldud valikute loogikat.
Kui kontrollid sammude järjekorda, pole vaja kõiki pilte lõplikult töödelda. Kui kontrollid pakettide eristamist, peavad nimed, kirjeldused ja tingimused olema piisavalt realistlikud. Ühesugune asendustekst kõigis kastides peidaks just probleemi, mida katse peaks avastama.
Mobiilivaade lepi eraldi kokku. Arvutikujunduse vähendamine telefoniekraani laiuseks ei anna iseenesest läbi mõeldud mobiilset teekonda. Prototüübis peab olema näha näiteks see, kuidas pikad valikud mahuvad, kus avaneb menüü ja milline info jääb järgmise sammu juurde liikudes alles.
Kuidas prototüüpi sisuliselt hinnata?
Erista ettevõtte sisemine kooskõlastus ja kasutajatega katsetamine. Tiim saab kinnitada teenuseinfo õigsust, brändi sobivust ja ärireegleid. Tulevane klient aitab näha, kas lahendus on arusaadav ka ilma projekti tausta teadmata.
Anna osalejale realistlik ülesanne, näiteks: „Otsid oma väikesele kontorile igakuist hooldusteenust. Leia sobiv variant ja küsi pakkumist.” Väldi juhist, mis nimetab juba õige nupu. Palu inimesel kirjeldada, mida ta arvab järgmisena juhtuvat, ning märgi üles kohad, kus ta kõhkleb või vajab abi.
Katse lõpus erista kavandi piirang ja tegelik arusaamisprobleem. Kui klõps ei toimi, sest see haru jäi kokkuleppeliselt ehitamata, ei tõenda see veel halba kasutatavust. Kui inimene ei mõista teenuse nimetust, on see sisuline leid ka siis, kui kõik lingid töötavad.
Koosta tähelepanekutest otsuste loend: mida muuta, miks muuta ja mida uuesti proovida. Väikese kvalitatiivse katse põhjal ei tasu lubada kindlat müügikasvu ega esitada kõigi tulevaste klientide käitumise protsente.
Mida prototüüp ei kinnita?
Disainitööriistas töötav teekond ei tõenda päris veebilehe kiirust, serveri töökindlust, andmete turvalist salvestamist ega liidestuse toimimist. Samuti ei kinnita ekraanide läbiklikkimine kogu valmis veebilehe ligipääsetavust. Need vajavad arendatud lahenduse eraldi kontrolli.
Kui suurim risk on näiteks kalendrisüsteemist vabade aegade kättesaamine, võib visuaalse prototüübi kõrval vaja minna tehnilist katset. Arendaja saab siis uurida konkreetse ühenduse võimalusi. Kujunduse katsetamine ja tehnilise teostatavuse uurimine vastavad eri küsimustele ning pakkumises peaksid need tööd eristuma.
Mida peab tellija üleandmisel saama?
Üks esitluslink ei pruugi olla piisav arenduse alustamiseks. Lepi kokku, millises vormis antakse üle lähtefailid, kujunduse reeglid, ekraanid ja käitumise kirjeldused ning kellel on edaspidi ligipääs.
- Kinnitatud teekonnad: alguspunktid, toimivad harud ja teadlikult välja jäetud osad.
- Olulised olekud: vead, tühjad tulemused, laadimine ja kinnitused vastavalt tellitud ulatusele.
- Vaadete variandid: kokkulepitud mobiili- ja arvutivaated koos paigutuse muutumise selgitustega.
- Sisu ja materjalid: milline tekst või pilt on kinnitatud ja milline vajab asendamist.
- Katsetamise kokkuvõte: tähelepanekud, tehtud parandused ning lahendamata küsimused.
Hinda pakkumist nende väljundite alusel. Hinda mõjutavad muu hulgas teekondade arv, erisugused olekud, sisutöö, seadmevaated, osalejate leidmine ja parandusringid. Kõige soodsam ekraanide komplekt ei pruugi sisaldada katsetamist ega arendajale vajalikku täpsust.
Alusta ühe olulise kliendiülesandega
Kirjelda päringus, kes hakkab lahendust kasutama, mida ta peab saavutama ja milline otsus on praegu ebakindel. Lisa olemasoleva veebi aadress, brändimaterjalid, vajalikud seadmevaated ning arenduse kavandatud tähtaeg. Kogu projekti kirjeldamiseks saad kasutada ka veebilehe lähteülesande juhendit.
Kala Ruuduse veebidisaini ja veebiarenduse teenus hõlmab nii lihtsamaid veebilehti kui ka keerukamaid veebisüsteeme. Saada meile kirjeldus teekonnast, mida soovid enne arendust läbi proovida. Selle põhjal saame arutada, millist kavandamise ja prototüüpimise ulatust sinu projekt vajab.