Liigu sisu juurde

Veeb, tehnoloogia ja sisu sinu ettevõtte jaoks.

ALTOSTRATUS d.o.o.
ET
Veebiarendus

Kas sinu ettevõte vajab veebilehte või portaali?

Enne veebilahenduse tellimist tasub selgeks teha, kes seda kasutab ja milleks. Vaatame, millal piisab veebilehest ning millal vajab sinu ettevõte portaali, arvestades ka sisu, kujunduse, liidestuste ja hilisema hooldusega.

Autor: ALTOSTRATUS d.o.o. toimetus Avaldatud Lugemisaeg: 7 min

Milliseid ülesandeid külastaja veebis lahendab?

Veebilahenduse valik algab küsimusest, mida inimene sinu veebis tegelikult teha soovib, mitte sellest, milline avaleht sulle meeldib. Külastaja võib otsida teenuse kirjeldust, võrrelda võimalusi, küsida pakkumist või jälgida juba esitatud tellimuse käiku. Pane need tegevused kirja kasutaja vaatenurgast, sest ettevõtte sisemine struktuur ei pruugi talle midagi tähendada. Iga tegevuse juures täpsusta, millist infot inimene vajab ja millise tulemuseni ta jõudma peaks. Nii saad otsustada, kas piisab avalikust sisust või peab veeb võimaldama ka isiklikke toiminguid.

Erista seejärel juhukülastaja vajadused nende inimeste omadest, kes tulevad veebi korduvalt kindlat ülesannet täitma. Esmakordne huviline vajab enamasti selgitust, usaldust toetavat teavet ja arusaadavat võimalust sinuga ühendust võtta. Korduvkasutaja võib tahta näha enda dokumente, muuta andmeid või jätkata pooleli jäänud tegevust ilma uut kirja saatmata. Kirjelda mõlema jaoks teekond esimesest saabumisest soovitud tulemuseni ning märgi üles kohad, kus vajalik info praegu puudub. See aitab vältida olukorda, kus kogu tähelepanu läheb tutvustavale sisule, aga tegelik asjaajamine jääb endiselt ebaselgeks.

Ära eelda siiski, et iga korduv tegevus vajab kohe eraldi portaali või keerukat iseteenindust veebis. Uuri esmalt, kas ülesande saab lahendada selgema juhise, sobiva vormi või olemasoleva töövahendi abil. Kui kasutaja peab sama infot korduvalt sisestama või ootama üksnes andmete käsitsi edasi saatmise järel, tasub protsess põhjalikumalt läbi mõelda. Valiku aluseks võiks olla kasutaja eesmärk koos ettevõtte suutlikkusega vajalikku sisu ja töökorraldust ajakohasena hoida. Arutelu alustamiseks sobivad järgmised küsimused, mille vastused aitavad soovid konkreetseteks nõueteks muuta, ilma lahendust ennatlikult lukku panemata.

  • Mida külastaja saavutada tahab?
  • Millist infot ta selleks vajab?
  • Kas tegevus eeldab isiklikke andmeid?
  • Kes sisu ja toiminguid haldab?

Millal piisab tavalisest veebilehest?

Tavalisest veebilehest piisab sageli siis, kui sinu peamine eesmärk on tutvustada ettevõtte teenuseid ja aidata huvilisel ühendust võtta. Teenuste kirjeldused, tööprotsessi selgitused, korduvad küsimused ja kontaktivorm võivad katta kogu vajaliku kasutusteekonna ilma sisselogimiseta. Oluline pole lehtede rohkus, vaid see, kas külastaja leiab oma küsimusele vastuse ja mõistab järgmist sammu. Ka mahukas sisukogu võib toimida veebilehena, kui info on avalik ning selle kasutamine ei sõltu inimese isikust. Seetõttu ei tähenda suurem sisumaht iseenesest vajadust portaali arendada.

Veebileht sobib ka siis, kui päringule järgnev suhtlus toimub muus kanalis ja külastajal pole vaja selle seisu veebist kontrollida. Näiteks saab vormiga koguda pakkumise koostamiseks vajalikku infot, ilma et huviline peaks esmalt endale konto looma. Vorm peab küsima ainult seda, mida sul päringu käsitlemiseks tõesti vaja läheb, ning selgitama, mis pärast saatmist edasi saab. Kui asjaajamine vajab personaalset arutelu, ei pruugi selle viimine portaali kasutaja jaoks midagi lihtsamaks teha. Mõistlik lahendus toetab olemasolevat teenindusprotsessi, mitte ei lisa sellele tarbetut lisasammu.

Lihtsama veebilahenduse valimisel tasub siiski läbi mõelda, kes hakkab tekste, pilte ja teenuste kirjeldusi hiljem muutma. Sisuhaldus peab sobima tegelike ülesannetega, et igapäevane muudatus ei nõuaks ebavajalikku tehnilist sekkumist ega ebaselget töökorraldust. Samuti võiks sisu ülesehitus lubada lisada uusi teemasid nii, et menüü ja lehtede omavahelised seosed jäävad arusaadavaks. Kui tulevikus võib tekkida vajadus iseteeninduseks, kirjelda see võimalus lähteülesandes, kuid erista seda praegu vajalikust funktsionaalsusest. Nii ei pea sa tellima portaali üksnes oletuse põhjal, et seda võib kunagi tarvis minna.

Millal on vaja kasutajakontodega portaali?

Kasutajakontodega portaal muutub põhjendatuks siis, kui inimene peab veebis nägema või muutma infot, mis on seotud just temaga. Selleks võivad olla taotlused, dokumendid, tellimused või muud toimingud, mille juurde tuleb hiljem tagasi pöörduda. Konto eesmärk pole lihtsalt külastajat ära tunda, vaid võimaldada talle sobivat ligipääsu ja järjepidevat asjaajamist turvalisel viisil. Kui sama tegevuse andmeid vajavad ka ettevõtte töötajad, peab portaal toetama nende tööd samavõrd kui kasutaja oma. Vastasel juhul võib nähtav iseteenindus peita enda taga jätkuvalt ulatuslikku käsitööd.

Enne portaali kavandamist kirjelda, millised kasutajarühmad seal tegutsevad ning mida igaüks neist näha ja teha tohib. Ühe organisatsiooni esindaja võib vajada ligipääsu ühistele dokumentidele, teine kasutaja aga ainult enda esitatud andmetele ja toimingutele. Samuti tuleb otsustada, kuidas konto tekib, kes selle õigusi kinnitab ja mis juhtub siis, kui kasutaja roll muutub. Need küsimused mõjutavad nii kasutusmugavust kui ka andmete kaitset ning neid ei tasu jätta kujundamise järel lahendamiseks. Portaali vajadust näitab siin erinevate õigustega asjaajamine, mitte pelgalt soov lisada veebile sisselogimisnupp.

Portaali valik tähendab ka kohustust hoida korras kasutajakontod, ligipääsud, teavitused ja nende taga olevad tööprotsessid kogu lahenduse kasutamise vältel. Mõtle läbi, kes aitab inimest konto kasutamisel ning kes lahendab olukorra, kus kuvatud andmed vajavad parandamist või täiendamist. Kui info liigub teistest süsteemidest, tuleb selgitada, kust pärineb õige teave ja kuidas kasutajale võimalikke tõrkeid arusaadavalt näidatakse. Võrdle seetõttu portaali mitte ainult veebilehe arendusmahuga, vaid ka igapäevase halduse ja teeninduse vajadustega. Sobiv valik annab kasutajale sisulise võimaluse asju ajada ning jätab sulle hallatava töökorralduse.

Veebidisain lähtub sisust ja kasutusteekonnast

Veebidisaini kavandades pane esmalt kirja, millist sisu külastaja otsib ja millise tegevuseni see teda juhatab. Teenuse tutvustus, võrdlustabel ja taotlusvorm vajavad erinevat ülesehitust, sest nende lugemise eesmärk ja kasutamise olukord erinevad. Paiguta otsustamiseks vajalik teave sinna, kus küsimus tekib, mitte eraldi lehele, mille leidmine nõuab oletamist. Kujundus peaks aitama eristada peamist kõrvalisest ning tegema järgmise sammu nähtavaks ka esmakordsele külastajale. Nii saad hinnata iga kujundusvaliku otstarvet selle järgi, kas see toetab sisust arusaamist ja soovitud tegevust.

Kirjelda kasutusteekonda konkreetse ülesandena, näiteks teenuse tingimuste leidmise, päringu saatmise või oma avalduse seisu kontrollimisena veebis. Vaata seejärel üle, millist teavet inimene igas etapis vajab ning millised valikud võivad teda kõhklema panna. Nupu tekst võiks öelda, mis vajutamise järel juhtub, ja vormi väljad peaksid küsima ainult vajalikku teavet. Kui mõni tegevus eeldab ettevalmistust, selgita vajalikke dokumente või andmeid enne, kui inimene täitmist alustab. Katseta teekonda arusaadavate ülesannetega ning palu katsetajal kirjeldada, millest ta valikuid tehes lähtub.

Mobiilivaade ja ligipääsetavus tasub siduda kujundamisega kohe, sest need mõjutavad nii sisu järjestust kui ka juhtnuppe. Kontrolli, kas teksti saab mugavalt suurendada, klaviatuuriga liikuda ning vormi veateadet mõista ka värvierinevusi märkamata. Piltide kõrval peab oluline mõte olema tekstina olemas, et info ei sõltuks üksnes visuaalsest tajust. Pikema sisu puhul aitavad kirjeldavad vahepealkirjad ja selged lõigud leida vastuse ilma kogu lehte läbi lugemata. Sama loogika peaks säilima nii avalikul veebilehel kui ka sisselogitud kasutaja vaates, kuigi võimalused võivad erineda.

Liidestused ja ligipääsuõigused vajavad läbimõtlemist

Liidestusi kavandades alusta andmete liikumisest: kust info tuleb, milleks seda kasutatakse ja millises süsteemis seda muudetakse. Kui sama kontaktandmestik paikneb mitmes kohas, tuleb otsustada, milline allikas on muudatuste korral teiste jaoks määrav. Muidu võib veebis kuvatav teave erineda sellest, mida töötaja näeb oma tavapärases töövahendis päringut lahendades. Pane kirja ka see, kas andmeid on vaja edastada kohe või sobib nende perioodiline uuendamine. Valik peaks lähtuma tööprotsessist, mitte soovist ühendada omavahel kõik kasutusel olevad rakendused lihtsalt tehnilise võimaluse pärast.

Ligipääsuõiguste puhul kirjelda tegevusi, mitte ainult kasutajate nimetusi, sest sama nimetuse taga võivad olla erinevad vajadused. Üks inimene võib vajada dokumentide vaatamist, teine nende muutmist ning kolmas muudatuste kinnitamist enne avaldamist veebis. Anna igale kasutajale ainult tema ülesannete täitmiseks vajalik ligipääs ning mõtle läbi õiguste hilisem muutmine. Eraldi tähelepanu vajavad konto sulgemine, ajutised asendused ja olukorrad, kus inimene tegutseb mitme organisatsiooni nimel. Kui portaalis liiguvad isikuandmed, peab andmete kogumise eesmärk olema selge ning nende nähtavus vastava ülesandega põhjendatud.

Liidestuse kirjeldus peab hõlmama ka olukorda, kus teine süsteem ei vasta või saadab puuduliku sisuga andmed. Otsusta, mida kasutaja sellisel juhul näeb ja kuidas välditakse sama päringu või makse ekslikku kordamist süsteemis. Veateade peaks ütlema, kas tegevus õnnestus, jäi pooleli või vajab kasutajalt uut katset pärast takistuse kõrvaldamist. Tehniliste logide abil peab saama tõrke põhjust uurida, kuid logidesse ei peaks kogunema tarbetuid isikuandmeid ega saladusi. Enne arendamist lepi kokku ka vastutus väliste teenuste seadistamise, ligipääsude haldamise ja muudatustest teavitamise eest.

  • Andmete allikas ja liikumissuund
  • Kasutajate tegevused ja ligipääsupiirid
  • Tõrgete käsitlemine ja vastutus

Veebilehe hooldus algab juba kavandamisel

Veebilehe hooldus algab otsusest, millist sisu ja funktsionaalsust suudad pärast avaldamist tegelikult ajakohasena hoida oma igapäevatöö kõrval. Iga lisatud vorm, sisutüüp ja liidestus toob kaasa kontrollimise vajaduse, isegi kui kasutaja seda taustatööd ei näe. Seetõttu tasub eristada avaldamiseks vajalik lahendus nendest võimalustest, mida saab põhjendatud vajaduse tekkimisel hiljem juurde arendada. Lihtsam lahendus ei tähenda tingimata tagasihoidlikumat kujundust, vaid võib tähendada vähem erandeid ja selgemat haldamise loogikat. Küsi iga lisafunktsiooni puhul, kes seda kasutab, kes hooldab ning mis juhtub selle tõrke korral.

Sisuhalduses määra, kes saab teavet muuta, kes selle üle vaatab ja millal aegunud sisu avalikust vaatest eemaldatakse. Toimetajal peaks olema võimalik teha tavalisi muudatusi ilma kujundust lõhkumata või tehnilist abi iga kord eraldi küsimata. Selleks sobivad selgete väljadega sisumallid, mille juures on arusaadav, milline teave on kohustuslik ja miks seda vajatakse. Hoolduse hulka kuuluvad ka tarkvarauuendused, varukoopiad ja kontroll, et olulised vormid ning kasutajateekonnad jätkuvalt toimiksid pärast muudatusi. Varukoopia olemasolust üksi ei piisa, kui pole läbi mõeldud, kuidas selle abil teenus taastada.

Enne lahenduse valimist võrdle lisaks arendustööle ka haldamisega kaasnevat ajakulu ja sõltuvust välistest teenustest ning nende tingimustest. Tavalisest veebilehest võib piisata, kui külastaja vajab avalikku teavet ja võimalust sinuga mugavalt ühendust võtta talle sobival hetkel. Portaal on põhjendatud siis, kui kasutaja peab turvaliselt oma andmetega töötama või korduvaid toiminguid tegema isiklikus vaates. Mõlema lahenduse puhul peaksid sisu ülesehitus, õigused ja hooldus toetama sama selgelt sõnastatud kasutaja ülesannet, mitte tehnoloogilist eelistust. Vali lahendus, mille vajalikkust saad selgitada kasutaja tegevuse kaudu ja mille korrashoid on sinu jaoks korraldatav.

Põhipunktid

  • Lähtu kasutaja ülesandest Avaliku teabe ja kontaktivõimaluse jaoks võib piisata veebilehest; isiklike andmete ja korduvate toimingute jaoks võib vaja minna portaali.

  • Kavanda sisu ja õigused koos Selge kasutusteekond vajab arusaadavat sisu, põhjendatud ligipääse ning läbimõeldud andmevahetust teiste süsteemidega.

  • Arvesta hooldusega enne arendamist Vali funktsioonid, mille sisu, uuenduste, varukoopiate ja tõrgete käsitlemise eest saad järjepidevalt hoolt kanda.

Allikad

  1. Andmekaitse Inspektsioon
  2. Riigi Infosüsteemi Amet

Artikkel annab üldist teavet ega asenda erialast nõu.

Seotud artiklid