Dokumendiregister | Majandus- ja Kommunikatsiooniministeerium |
Viit | 9-1/786-1 |
Registreeritud | 20.03.2024 |
Sünkroonitud | 23.03.2024 |
Liik | Sissetulev kiri |
Funktsioon | 9 Digiarengu korraldamine |
Sari | 9-1 Digiriigi arengu kavandamise ning korraldamise kirjavahetus |
Toimik | 9-1/2024 |
Juurdepääsupiirang | Avalik |
Juurdepääsupiirang | |
Adressaat | Eesti Infotehnoloogia ja Telekommunikatsiooni Liit |
Saabumis/saatmisviis | Eesti Infotehnoloogia ja Telekommunikatsiooni Liit |
Vastutaja | Kristi Hunt (Majandus- ja Kommunikatsiooniministeerium, Kantsleri valdkond, Digiarengu valdkond, Digiriigi arengu osakond) |
Originaal | Ava uues aknas |
Hea minister Riisalo ja teised Eesti e-riigi gurud
Nagu Luukasele reedesel kohtumisel lubatud sai edastan ka kirjalikult ITL liikmete arvamused ja mõtted seoses mRiigiga. Oleme igakülgselt valmis edasisteks aruteludeks.
Eesti Infotehnoloogia ja Telekommunikatsiooni Liit (edaspidi: ITL) ja selle liikmed on jälginud Majandus- ja kommunikatsiooniministeerium (edaspidi: MKM) tegevust Ukraina Diia rakenduse alusel loodud mRiik rakenduse piloteerimisel. Kui meieni jõudis info, et tegemist ei ole piloteerimisega, vaid tegeletakse juba MVP turule laskmise ettevalmistamisega, otsustasime oma seisukohti, muresid ja ettepanekuid MKM-ga jagada, et ära hoida võimaliku kahju. Selleks oleme viimasel kuul korduvalt MKM inimestega kohtunud ja infot vahetanud. Allpool on koondatud ITL liikmeskonna ühisarvamus ja seisukohad mRiik rakenduse osas.
Olles arvesse võtnud kõik MKM-i poolt toodud argumendid ja seni meile teatavaks tehtud informatsiooni mRiik lahenduse kohta, tekitab ITL-i liikmeskonnale laiemalt (so. arvestatavale hulgale IKT sektori ettevõtetele) endiselt muret, et MKM soovib kiirkorras lansseerida lahendust, mis ei paku täna kodanikule ühtegi reaalset funktsionaalsust. mRiik rakenduse aluseks olev Ukraina Diia rakendus on loodud Ukraina riigi vajadustest lähtuvalt. Ukraina riigi ja Eesti e-riigi lahenduste olukord on väga erinev. Allpool selle kohta mõned näited:
Positiivsena tuleb välja tuua, et Diia rakenduses on realiseeritud ka mõningad funktsionaalsused, mida Eesti riik veel ei paku. Ennekõike füüsiline isikutuvastamine mobiiltelefoni abil (s.t. ilma füüsilisi isikuttõendavaid dokumente kaasas kandmata) - nn mDokumendid. Sellest võiks ka Eestis kasu olla. Eestis on selles vallas tööd tehtud: nii avalikus sektoris kui ka erasektoris. RIA viis läbi täpselt selleteemalise projekti "Tõend kui platvorm" kus uuriti, kuidas seda funktsiooni turvaliselt, avatud standardeid kasutades ning EL seadustega kooskõlas realiseerida. ITL liikmed on (muuhulgas ka Eesti riigi toel) tegelenud intensiivselt digikukrute alase uurimis- ja arendustegevusega.
Kuna Euroopa Liit on võtnud eIDAS 2 määrusega selge suuna ühtsete, üle-Euroopaliselt koosvõimeliste, ühtsel seadusandlikul alusel põhinevate digikukrute loomisele ja rakendamisele ning ka Eesti riigiasutused ja ettevõtted osalevad intensiivselt selles protsessis, siis ei tundu mõistlik seadusandliku alust mitteomava, ebaselgete turva- ja privaatsusomadustega adhoc lahenduse kiirkorras kasutuselevõtuks. Tuleb tähele panna, et füüsiline isikutuvastus on paljudes reaalse elu protsessides (tervishoid, pangandus) oluline ja suurt tähendust omav tegevus, mille puhul ebaselge juriidiline alus ning võimalikud turvaprobleemid võivad põhjustada reaalset kahju kolmandatele osapooltele, kes seda oma protsessides otsustavad kasutada.
ITL leiab, et kui riik teeb niivõrd suure ja kontseptuaalse muudatuse ja hakkab pakkuma sedavõrd universaalset ja kriitilist teenust, siis peab see olema igakülgselt läbimõeldud, täielikult seadusandlusega vastavuses ja maksimaalselt osapoolte huve kaitsev. Digitaalsed dokumendi ilma seaduslikku jõuta võivad põhjustada palju segadust.
Lisaks alates 23.06.2021 peavad kõik avaliku sektori mobiilirakendused vastama ka WCAG 2.1 AA nõudele. Oleme kirjale lisanud eraldi analüüsi, kus on väljatoodud murekohad, kus antud nõuetele vastavus pole tagatud.
Kokkuvõtlikult: Ukraina jaoks oli Diia rakenduse kasutuselevõtmine suur samm edasi sellest kohast, kus nemad olid. Eesti jaoks ei oleks mRiik rakenduse kasutuselevõtmine suur samm edasi, sest meie lähtekoht, vajadused ja nõudmised on erinevad. mRiik rakenduse kasutuselevõtmine ei annaks kodanikule just liiga palju uusi ja seniolematuid võimalusi.
Kahjuks on juhtunud nii, et Ukraina pool on Eesti võimalikku Diia sarnase rakenduse kasutuselevõttu hakanud presenteerima suure sammuna ka Eesti jaoks. Narratiiv on, et Eesti digiriik on eilne päev, Ukraina Diia on homne päev ja Eesti otsus Diiat mRiigi nime all rakendada seda just tõestab.
Selliseid kommunikatsioonis Eestit Ukraina kasuks ära kasutavaid juhtumeid on olnud mitmeid ja see on juba mõju avaldanud meid külastavatele delegatsioonidele (hiljutise delegatsiooni juhi esimene küsimus: â€palun näidake meile Diiatâ€). See kahjustab otseselt meie ettevõtete võimalusi eksportida Eesti IT-lahendusi ja põhjustab seeläbi majanduslikku kahju ka Eesti riigile.
Hoolimata sellest, et Ukraina on Eestilt üle võtnud palju ideid ja kontseptsioone, kuidas e-riiki ehitada ning ka reaalset tehnoloogiat, ei paista see välja. Väga paljude riikide jaoks, kes võiks olla Eesti IT-ettevõtete kliendid, on e-riigi fookuses ennekõike teenused kodanikele ja ettevõtjatele, mitte riigi sisemine efektiivsemaks muutmine. Teenuste pakkumisel on ennekõike executive tasemel väga oluline look-and-feel - milline on esitluskiht ehk lõppkasutajale nähtav osa. Kui parim esitluskiht on Ukraina Diia rakendus (mida tõestab väidetavalt see, et maailma eesrindlikeim e-riik Eesti võttis selle üle), siis järelikult see ongi parim e-riigi lahendus. Paraku just nii lihtne ongi tihti otsustusprotsess, millest Eesti ettevõtted peavad end läbi võitlema.
Kui kaaluda plusse ja miinuseid, siis meie meelest oleks mRiik rakenduse sellisel kujul käikulaskmine kahjulik: olulisi uusi probleeme ei lahendata, küll aga tekitatakse suur ja pikaajaline kahju Eesti e-riigi lahenduste ekspordile. Lisaks tekitaks kiirkorras mRiigi lansseerimine segadust ka personaalse riigi kontseptsiooni osas, sest tõenäoliselt avalikkus seda tõlgendaks just sellena.
ITL detailsemad ettepanekud, kuidas liikuda edasi riikliku mobiilirakenduse loomisega oleksid järgmised:
ITL ja ITL liikmed on igati valmis osalema ja aitama oma kompetentsidega mRiigi lahenduse loomisel: on see siis visiooni sõnastamise, rakenduse kasutatavuse ja väljanägemise, tehnilise platvormi, EL süsteemidega haakuvuse, turvalisuse vms osas.
Koostööni
Doris Põld
Tegevjuht
Eesti Infotehnoloogia ja
Telekommunikatsiooni Liit
+372 511 44 11
2023
-07-
UX ekspertarvamus
Riikliku mobiilirakenduse
mRiik beetaversioon
Täitja Trinidad Wiseman OÜ Meistri 14, 13517 Tallinn [email protected]
UX ekspertarvamus 9.07.2023
2
Sisukord 1 Sissejuhatus .................................................................................................................................................. 3
2 Tähelepanekud ............................................................................................................................................. 3
2.1 Tekst ......................................................................................................................................................... 3
2.1.1 Sisutekstid ....................................................................................................................................... 3
2.1.2 Teksti suuruse muutmine ............................................................................................................... 4
2.1.3 Sisuteksti reavahe ........................................................................................................................... 4
2.2 Menüü ................................................................................................................................................. 4
2.2.1 Sulgemisnupud ............................................................................................................................... 4
2.2.2 Kopeeri mRiik kasutaja ID ............................................................................................................... 5
2.2.3 Peamenüü disain ............................................................................................................................ 7
2.2.4 Erinevus teenuste menüü ja põhimenüü vahel .............................................................................. 8
2.2.5 Ebaühtlane nimekirjalahendus ....................................................................................................... 8
2.3 Dokumendid ........................................................................................................................................ 9
2.4 Kasutatavuse vead ............................................................................................................................ 10
2.4.1 Rakendus vaid püstises asendis .................................................................................................... 10
2.4.2 Kopeerimise nupp ......................................................................................................................... 11
2.4.3 Bürokrati disainivead .................................................................................................................... 11
2.4.4 QR kood juhiloa juures ................................................................................................................. 12
2.4.5 UX viga sisselogimisel ................................................................................................................... 12
2.4.6 Otsing ............................................................................................................................................ 13
UX ekspertarvamus 9.07.2023
3
1 Sissejuhatus
Trinidad Wiseman testis ülevaatlikult riiklikku mobiilirakenduse mRiigi beetaversiooni lähtuvalt
WCAG 2.1 standardi AA tasemest. Lähtudes ajalistest piirangutest ja saada piisav indikatsioon
lahenduse tänasest seisust, viidi test läbi üksnes IOS platvormil, kasutades iPhone 12 Pro
mobiiltelefoni. Testi läbiviimiseks, navigeerimiseks rakenduses ja tulemuste saamiseks lähtuti
analüüsis potentsiaalsetest kasutaja vajadustest. Alljärgnevalt on analüüsi tulemused
grupeeritud teemade kaupa. Iga teema all on välja toodud peamised leiud, millele võiks
rakenduse edasise arendamise käigus tähelepanu pöörata.
2 Tähelepanekud
2.1 Tekst
2.1.1 Sisutekstid
Rakenduse sisutekstide font on hetkeversioonis silmale raske jälgida,
mis nägemispiirangute korral võib osutuda suisa raskeks näha.
Soovitatav on sisutekstid kirjutada vähemalt 16pt-ga.
UX ekspertarvamus 9.07.2023
4
2.1.2 Teksti suuruse muutmine
Just nägemisraskustega kasutajaid silmas pidades puudub
rakendusel võimalus muuta teksti suurust rakenduseüleselt. See
funktsioon on küll leitav rakenduse Bürokrati alammenüüs (mis on
ootamatu, arvestades, et rakendusse sisse logides seda võimalust
kasutajale ei pakuta, mistõttu ei oska seda ka sealt eraldiseisvalt
oodata), kuid sealgi on see võimalik vaid arvutit ehk desktop-
versiooni kasutades, kuivõrd selgituses viidatakse klaviatuuri ja hiire
vajalikkusele teksti muutmisel.
Tekstisuuruse muutmise vajadust saaks täita ka telefoni enda
seadete alt üldise tekstisuuruse muutmisega, aga sama
funktsionaalsuse lisamine rakendusse lihtsustab sellegipoolest
kindlasti selle kasutust, eriti neile, kes pole telefoni seadistusi
muutnud või ei oska seda teha.
2.1.3 Sisuteksti reavahe
Lisaks suuremale fondile oleks parem ka suurem reavahe, et teksti oleks hõlpsam lugeda.
Hetkel jääb see liiga tihedaks ja muudab teksti kramplikult kokkusurutuks (vt sama näitevisuaal
eelmise punkti all). See omakorda muudab selle lugemise silmale raskemaks. Soovituslik
reavahe on 1.5. (WCAG 1.4.8)
2.2 Menüü
2.2.1 Sulgemisnupud
Üldiselt ei soovitata rakendustes hüpikaknaid ja modaale kasutada, kuivõrd just ligipääsetavust
arvestades on nende vahel navigeerimine raskendatud. Kui neid siiski kasutada, peavad
sulgemisnupud olema selgelt eristatavad.
UX ekspertarvamus 9.07.2023
5
Olemasolevas beetaversioonis ei ole aga erinevate vaadete sulgemiseks mõeldud nupud
ühtlaselt kontrastsed, sama värviga ja sama kujundusega. Halvema kontrastsuse korral võib
sulgemisnupp üldse leidmata jääda. Soovitus on nupud läbivalt ühtlustada kontrastsetena,
sama kujundusega ja modaali puhul paigutada samasse asukohta, nt nurka või lehe allossa,
kuid mitte läbisegi erinevalt.
2.2.2 Kopeeri mRiik kasutaja ID
Funktsioon on leitav menüüst nii eraldiseisva punktina põhimenüüs kui ka Abi-menüüs.
Viimasel juhul on just beeta-versiooni silmas pidades kasutaja jaoks loogiline teekond, kus teda
suunatakse enne probleemi kirjeldust ja ärasaatmist kopeerima oma ID, et see probleemi
kirjeldusele kaasa panna. Arusaamatuks jääb, miks peab sama funktsioon olema eraldi
saadaval peamenüüs või kuidas kasutaja peaks seda kasutama?
WCAG seisukohalt sisu kordamist ühe menüü ulatuses tuleks vältida, sest see võib olla
ekraanilugejaga kasutajale olla segadusse ajav ja tüütu. (WCAG 2.4.1) Ka Nielsen Norman Grupi
UX ekspertarvamus 9.07.2023
6
poolt välja toodud heuristika reeglite kohaselt konkureerib iga liidese lisateabeüksus
asjakohaste teabeühikutega ja vähendab seeläbi kõigi suhtelist nähtavust.
Seepärast soovitaks peamenüüs olevast punktist loobuda või selgemalt määratleda, miks
punkt eraldiseisvalt peab veel eksisteerima. Kui see on kusagil teenuste kasutamise sektsioonis
vajalik, siis pigem integreerida ID kopeerimise võimalus sinna samasse kohta ja eemaldada
põhimenüüst.
UX ekspertarvamus 9.07.2023
7
2.2.3 Peamenüü disain
Kui avada Menüü, on näha, et „Logi välja“ asub joone all, mis
eristab seda muudest menüüpunktidest kui olulist, mille kaudu
saab rakenduse kasutusvoo lõpetada. Selline eristamine
joonealusena on mõistlik. Ka juhul, kui soovida mõnd muud punkti
menüüs sel moel eristada. Arusaamatu on, miks „Seadete“ punkt
on joonte vahel, aga menüü keskel. Kui ta on mõeldud eristuma
samuti kui olulise tähtsusega menüüpunkt, siis lähtuvalt Gestalti
sarnasuse põhimõttest, võiks „Seaded“ ja „Logi välja“ olla menüüs
grupeeritud ühtekokku kas ühe joone alla või mõlemad joonte
vahel menüü lõpus, sest inimesed tajuvad sarnaseid elemente
grupina.
Antud juhul on „Seadete“ all 2 punkti, ometi punkti väljatoomine
menüüs nii prominentselt tekitab tunde, et see võimaldab midagi
rohkemat. Seepärast võiks kaaluda, kas peamenüüst ei saaks sinna midagi veel lisada – näiteks
„Rakenduse uuendamine“ või ka isikuandmete töötlemise temaatika. Nii saab peamenüü
puhtamaks ja koormab kasutaja vahemälu samuti vähem.
Lisaks, hetkel viivad „mRiik kohta“ ja „Teave isikuandmete töötlemise kohta“ äpist välja, aga
menüüs on nad kujundatud samamoodi kui muud menüünupud, mis viitavad äpi järgmisele
lehele. Seepärast võiks lingina käituvad nupud alla joonida nt, et need ka linkidena mõjuksid. Ja
täiendada noole ikooniga, nagu on tehtud Abi menüüst e-maili saatmise nupu puhul, et selle
funktsioon oleks selge.
Lingid ei tohiks ettehoiatamata avaneda uues aknas või uuel vahelehel. Kasutaja ei pruugi aru
saada, et on sattunud uuele lehele ning võib proovida tulutult veebilehitseja “Tagasi” nuppu
kasutada. Lingid peavad olema muust tekstist visuaalselt eristatavad. Kui lingid pole
allajoonitud, paksemad, suuremas kirjas või muud moodi lisaks värvile muust tekstist
eristatavad, siis peab lingi värv olema vähemalt 3:1 kontrastisuhtes ülejäänud teksti värviga.
(WCAG 1.4.1)
Lisaks, hetkel on nende puhul ka 2 erinevat infoikooni. Kui isikuandmete töötlemise teema
seadete alla viia, siis ei tekiks siin sellega segadust.
UX ekspertarvamus 9.07.2023
8
2.2.4 Erinevus teenuste menüü ja põhimenüü vahel
Rakenduse teenuste menüü
ülesehituses on võrreldes
põhimenüüga kasutatud erinevaid
ikoone, mis toetab nende menüüde
eristumist, aga teenuste menüüs
olevad ikoonid ei pärine Veera
disainisüsteemist. Et Veerast lähtuda,
aga tahaks hoida ka 2 menüü
eristumist, tuleks teenuste menüü
ikoonid disainisüsteemist lähtuvalt
uuesti üle vaadata ja mõelda, mida
saab olemasolevate asemel kasutada.
Või kas nende teenuste osas on
mingeid ikoone juba varasemalt
kasutusele võetud, mida saaks siin ära
kasutada. Eristumist saaks luua ka
menüü taustavärvi muutmisega, kui
ikoonid seda ei võimalda.
Hetkel eristuvad menüüd ka selle poolest, et põhimenüü font on väiksem, mida aga
ligipääsetavust silmas pidades on raskem lugeda, mistõttu võiks sealse menüü tekstisuurust
ühtlustada teenustemenüüga.
Teenuste menüüs on toodud välja ka otsing, mis aga seonduvalt üldisema otsingu teemaga, on
kirjutatud lahti punktis 2.4.6.
2.2.5 Ebaühtlane nimekirjalahendus
Teenuste menüüst saab avada loetelud kasutajapoolsetest kokkupuutepunktidest konkreetse
teenusega. Kui üldiselt avaneb iga teenuse puhul sama ülesehitusega nimekiri, siis „Minu
sõidukite“ alt avaneb erinev vorm. Seda võiks teha täpselt samamoodi nagu „Liikluskindlustuse
ajaloo“ punkt menüüs, millega saaks säilitada ühtse loogika.
Muude nimekirjade ülesehitusega sarnaselt võiks olla ühtlustatud ka retseptide tabeliväljad
lisades vastavalt sellele, et tabelis on välja toodud nii ravim kui ka selle number, ka tabelivälja
nimetuse „Number & Ravim“, samuti ravimi staatuse „Müüdud“ või „Ostmata“.
UX ekspertarvamus 9.07.2023
9
2.3 Dokumendid
Erinevate dokumentide kuvamisel on märgata ebaühtlust andmete esitamisel. Nii on juhiloal
märgitud staatuseks nt „Kätte antud“, aga ID kaardil ja passil mitte. Passil on öeldud Eesti
kodaniku pass, aga ID kaardil lihtsalt ID kaart, mitte Eesti kodaniku ID kaart. Passi puhul pole
öeldud sünnikohta ja kehtivust alates+kuni. Juhiloa puhul on selle number märgitud suurema
fondiga, et tuua seda välja kõige olulisemana, dokumentidel on selle asemel isikukood. ID
kaardil pole dokumendi numbrit aga üldse välja toodud.
Soovitaks teha läbivalt samamoodi, et kasutaja saaks samast struktuurist lähtuda. Kui iga
dokumendi all on isikukood, võiks selle kehtivustärminid, dokumendi number ja staatus olla
kõigi puhul välja toodud. Lisaks võiks päises olla ka suur pealkiri „Dokumendid“, ka lühike
selgitav tekst, kuidas neid dokumente kasutada saab või juhul, kui veel ei saa, siis info, millal
saab. Hetkel peab minema selle küsimuse lahendamiseks minema põhimenüüsse ja otsima
„Küsimuste ja vastuste“ alt.
UX ekspertarvamus 9.07.2023
10
2.4 Kasutatavuse vead
2.4.1 Rakendus vaid püstises asendis
Veebileht või mobiilirakendus ei tohi olla kasutatav ainult portrait või ainult landscape asendis,
vaid nii püsti kui ka külje peal. Erandiks on lehed, mida ei ole võimalik loomupoolest mõlemas
suunas kasutada. (WCAG 1.3.4) Hetkel on mRiigi äpp kasutatav vaid püstisena. Lisaks
võimaldab landscape formaat tabelivaateid ja suuremat tekstihulka paremini kuvada.
UX ekspertarvamus 9.07.2023
11
2.4.2 Kopeerimise nupp
Riigiteenustes pärit andmete kopeerimiseks on äpis võetud
kasutusele ikooniga nupp. Antud ikoon on tuntud, kuid mille
kasutus ligipääsetavust silmas pidades võib olla raskendatud.
Erandkorras on see lubatud, kuid sellele tuleb sel juhul lisada
alt=”…”. Erand tehakse ka olukorras, kus teksti esitamine
pildina on mõtte edasi andmiseks ainus võimalus ning
olukorras, kus kasutaja saab pildil oleva teksti suurust ja värvi
muuta. (WCAG 1.4.5)
Antud juhul oleks kõige selgem lisada ikooni asemel nupp, kus
oleks välja kirjutatud „Kopeeri andmed“ vms või nupp, kus on
ikoon koos tekstiga.
2.4.3Bürokrati disainivead
Bürokrati avamisel avaneb rakenduse vestlusväli väiksemas suuruses kui kogu saadavalolev
telefoniekraan. See on aga ruumi raiskamine, mis tuleb eriti ilmsiks, kui vestlusrobotiga on
vestlus juba edasi-tagasi mõned korrad käinud, sest see tingib vajaduse rohkem teksti kerida,
kuivõrd seda pole ülemise ääre tagant piisavalt näha. Samas tühi ala telefonil seda võimaldaks.
Soovitaks rakenduse vestlust kuvada kogu vaba ala ulatuses.
Bürokrati teenuse puhul avaneb selle menüüst link eraldi tingimuste nupule. See aga ei avane.
Lisaks on Bürokratt disaini poolest erinev kogu ülejäänud rakendusest ja töötab ilmselt
iframe’is. Ideaalis võiks selle disain lähtuda aga samadest printsiipidest, mis kogu ülejäänud
rakendusel. See tagab kasutajapoolse ühtlasema kogemuse ja terviklikuma tunnetuse
rakenduse suhtes.
UX ekspertarvamus 9.07.2023
12
2.4.4 QR kood juhiloa juures
Dokumentide juures on toodud välja QR koodi skaneerimise võimalus ent jäetud selgitamata,
kuidas või millal seda kasutada. Vastust sellele ei leia ka küsimuste ja vastuste alt. Info võiks
olla toodud viimati mainitu all või ka skanneri enda küljes ühe lausega, kuidas kasutada.
2.4.5 UX viga sisselogimisel
Kui kasutaja logib rakendusse sisse, peab ta end tuvastama. Natuke segadust tekitab, mitu
sammu sisse logimiseks teha tuleb. Teise sammu juures on sammu nimetus toodud „Tagasi“
nupu all, mis justkui viitab sellele, et sealt saab tagasi Sammu 2 juurde. Et tegu aga ongi 2.
sammuga, tuleks see pigem märkida pealkirjana või samm-sammulise teekonnana, et saada
aru, mitu sammu üldse teha tuleb ja mitmendas sammus parajasti viibitakse.
UX ekspertarvamus 9.07.2023
13
Lisaks on 2. sammus suur tühi ala täidetud halli tooniga, esimeses sinisega. Veera järgi peaks
see nähtavasti sinine olema, mis tooks ka autentimisviisid paremini esile.
2.4.6 Otsing
Hetkel on rakendus lahendatud nii, et sellel puudub globaalne otsing. Selle asemel on otsing
eraldi toodud välja teenuste menüü kohta ning küsimuste ja vastuste kohta. Mõlema otsingu
puhul kehtib sama seaduspära, et otsida saab vaid täpse märksõnaga. Süsteem ei tunne ära,
kui sisestada ligilähedane märksõna (nt klienditoe (ei leia) vs klienditugi (leiab)). Kui
märksõnaga ära tabada, aitab otsing küsimuste ja vastuste sektsioonis hulga vastuste seast
endale olulise teema leida ja hõlbustab kasutust.
Aga arusaamatuks jääb, miks on teenuste menüü lehel otsing? See võimaldab otsida teenuste
menüüvalikust õige teema/kategooria. Aga et kogu menüü on silmaga kohe haaratav või kui
isegi peab natuke kerima, on see siiski lihtsam ja kiirem kui otsingusse kirjutama hakata. Aga
teenuste sisust otsida ei saa. Seetõttu soovitaks otsingu teenuste menüüst üldse eemaldada
või back-endis ühendada ära kogu teenuste sisu, et sealsest otsingust tuleks kiirelt välja see
info, mida enda kohta otsin ja paigutada otsing päisesse pidevalt kättesaadavasse kohta, et
selleni jõudmiseks ei peaks tegema eelkäike.
UX ekspertarvamus 9.07.2023
14