Vaativa erityiskäyttäjätestaus – Case Ruutibudjetti

Tämä tutkimusraportti on saatavilla myös PDF-muodossa alla.

1 Johdanto

Tässä asiakirjassa raportoidaan Helsingin kaupungin nuorten Ruutibudjetti –palvelulle tehdyn käyttäjätestauksen tulokset. Testauksen tarkoituksena oli ymmärtää, miten saavutettava palvelun äänestysvaihe on nuorille henkilöille, joilla on erityisiä digipalvelujen käyttöön liittyviä haasteita. Tämän perusteella testaus tehtin pelkästään ns. erityiskäyttäjillä, joilla oli useita kognitioon tai aistien toimintaan liittyviä rajoitteita. Kaikki testaajat olivat nuoria, ammattikouluikäisiä.

Testauksen tulosten perusteella tehtiin joukko suosituksia palvelun äänestysosion käytettävyyden parantamiseksi. Tuloksista ja niistä johdetuista yksittäisistä suosituksista on kerrottu tarkemmin raportin luvuissa 3 ja 4. Testauksen järjestelyt, testikäyttäjien profiili ja testitapaukset on kuvattu alla seuraavassa luvussa.

2 Tutkimuksen asettelu

2.1 Taustaa

Ruutibudjetti on osa Helsingin kaupungin osallistuvan budjetoinnin verkkopalvelukokoniasuutta. Siinä kaupunki tarjoaa helsinkiläisille mahdollisuuden vaikuttaa oman alueensa kehittämiseen kaupunkilaisten itse ehdottamien hankkeiden avulla. Ruutibudjetti on 6.-9. luokkalaisille suunnattu osallistuvan budjetoinnin muoto, joka toteutetaan yhdessä koulujen ja nuorisotalojen kanssa. Se toimii verkkosivustona, jossa nuoret voivat ehdottaa ja äänestää oman koulunsa alueella toteutettavia hankkeita.

Kaikki Helsingin osallistuva budjetoinnin palvelut noudattavat ”äänestyskierroksia”. Kun uusi kierros alkaa, käyttäjät voivat ehdottaa hankkeita, jotka osallistuvat äänestykseen. Ennen äänestystä hankkeita kuitenkin karsitaan ja kehitetään sekä käyttäjien että asiantuntijoiden yhteisvoimin. Varsinaisen äänestysvaiheen tulokset (sekä edeltävien vaiheiden aineisto) jäävät näkyviin verkkosivustolle.

Ruutibudjetissa erityispiirteenä on, että nuoret voivat ehdottaa ja äänestää hankkeita alueelta, johon oma oppilaitos kuuluu. Oppilaan kotialue- tai kunta ei ole merkityksellinen. Kaupunki huomioi äänestystuloksen, kun se kierroksen päätyttyä arvioi ehdotusten toteuttamista kullakin äänestysalueella.

2.2 Tavoitteet

Käyttäjätestauksen tavoitteena oli selvittää, miten saavutettava Ruutibudjetti—palvelun äänestysvaihe on käyttäjille, joiden on normaalia selvästi vaikeampi toimia verkossa. 

Tässä raportissa puhumme lyhyesti erityiskäyttäjistä.

Erityiskäyttäjillä tarkoitetaan varsin laajaa joukkoa erilaisia ihmisiä. Osalla on aistivammoista ja motorisista rajoitteista johtuvia haasteita, joiden vuoksi verkkopalvelujen käyttäminen on vaikeaa. Näkövammainen henkilö voi esimerkiksi joutua toimimaan pelkän ruudunlukuohjelman varassa tai turvautumaan voimakkaaseen suurennukseen ja suurikontrastiseen näyttötilaan.

Usein myös henkilön kognitiiviset kyvyt aiheuttavat esteitä verkossa toimimiselle. Esimerkiksi kielitaito, lukutaito, ja muistiin ja ymmärtämiseen liittyvät rajoitteet saattavat merkittävästi vaikeuttaa tietotekniikan ja digipalvelujen hyödyntämistä tai käytön oppimista. Jos henkilöllä on vielä samanaikaisesti sekä aisti- että kognitiivisia rajoitteita, lisääntyvät haasteet edelleen. Tällöin voidaan puhua monirajoitteisesta käyttäjästä. Nyt raportoidussa käyttäjätestauksessa kaikki osallistujat luokiteltiin monirajoitteisiksi erityiskäyttäjiksi.

Käyttäjätestauksen tavoitteena oli siten selvittää, miten hyvin Ruutibudjettipalvelu soveltuu monirajoitteisille nuorille käyttäjille. Erityisesti haluttiin tietää, miten testikäyttäjät suoriutuvat palvelussa äänestämisestä, joka on Ruutibudjetissa suurimmalle osalle käyttäjistä kaikista tärkein toiminto.

Perusteluna palvelun ja testaajien vallinnalle oli, että Ruutibudjetti on suunnattu poikkeuksellisen laajalle ja moninaiselle ryhmälle käyttäjiä, jotka ovat lisäksi nuoria ja kansalaisvaikuttamiseen harjaantumattomia. Käyttäjän tulisi siten voida pärjätä palvelussa ilman erityistä taustatietoa osallistuvasta budjetoinnista. Lisäksi hänen pitäisi suoriutua äänestyksestä ainakin auttavasti silloinkin, kun hän toimii palvelussa apuvälineen varassa tai kun hän ei halua tai kykene keskittymään sivuilla oleviin ohjeteksteihin ja käyttöliittymän sisältöihin. Palvelun on toisin sanoen oltava erityisen helppokäyttöinen.

2.3 Testikäyttäjät

Testikäyttäjät valitsi Helsingin kaupungin yhteistyökumppani, jolle monirajoitteisten erityiskäyttäjien kanssa toimiminen on osa päivittäistä työtä. Toimeksiannossa käyttäjiksi toivottiin aistirajoitteiden osalta ainakin näkövammaisia käyttäjiä, jotka toimivat verkossa apuvälineen varassa. Koska tiedossa oli, että testaajat ovat joka tapauksessa monirajoitteisia, ei muita vaatimuksia asetettu.

Kaikki testaajat olivat nuoria ja vastasivat ikäjakaumaltaan peruskoulun päättäneitä toisen asteen opiskelijoita.

Oheisessa taulukossa on kuvattu käyttäjien aistirajoitteet ja testausympäristö. Käyttäjien kognitiivisia rajoitteita ei ole eritelty tarkemmin, sillä niistä ei ollut käytettävissä virallista tietoa. Vaikutukset ovat kuitenkin huomioitu testaushavainnoissa.

#	Aistirajoite	Testiympäristö
1	Käyttäjä on sokea.	Oma kannettava tietokone, jossa Jaws–ruudunlukuohjelman uusin versio.
2	Ei aistirajoitetta.	Oma älypuhelin.
3	Käyttäjä on kuuro.	Oma älypuhelin. Avustajina kaksi tulkkia, joiden avulla käyttäjä kommunikoi.
4	Näkövammainen käyttäjä, joka voi toimia näönvaraisesti.	Oma kannettava tietokone, jossa ZoomText—suurennusohjelma.

2.4 Testausmenetelmä

Testausmenetelmänä oli käyttäjätestaus, jossa testitilanteeseen kutsuttu henkilö suoritti joukon etukäteen laadittuja, kaikille käyttäjille yhteisiä tehtäviä (kts. luku 2.5). Testaukset suoritettiin lokakuussa 2021 Helsingin kaupungin yhteistyökumppanin tiloissa pääkaupunkiseudulla.

Testaustilassa oli vain yksi testaaja kerrallaan, eivätkä muut osallistujat nähneet tai kuulleet muiden testien suoritusta. Kuhunkin testiin oli varattu 60 min, mutta testaus päätettiin tarpeen mukaan jo aiemmin, jos kaikki testitapaukset ja testaajan haastattelu oli suoritettu.

Testiympäristönä oli poikkeuksetta käyttäjien omat laitteet (kts. taulukko 1 edeltä).

Ennen testin alkua testaajalle kerrottiin yleisesti, mistä testattavassa palvelussa oli kyse ja miten testitilanne vietäisiin läpi. Suorituksen aikana Siteimproven asiantuntijat opastivat käyttäjää, jos tämä ei osannut enää jatkaa tehtävän suoritusta tai jos käyttäjä oli auttamatta eksynyt sivuun oikeasta käyttöpolusta; muuten käyttäjän piti pyrkiä toimimaan itsenäisesti.

Suorituksen jälkeen testaajan kanssa keskusteltiin lyhyesti testin kulusta ja testaajan omista havainnoista testin aikana. Varsinainen testin analyysi tehtiin erikseen, Siteimproven asiantuntijoiden kesken testien jälkeen.

2.5 Testitapaukset

Testitapauksia oli 5 kpl. Lisäksi varalla oli ylimääräinen testitapaus, jota voitiin tarpeen mukaan arvioida käyttäjillä, jotka suoriutuvat varsinaisesta äänestysprosessista sujuvammin.

1. Äänestysputkeen siirtyminen

• Tavoite: Käyttäjä on siirtynyt palvelussa ns. äänestysputken ensimmäiseen näkymään, jossa käyttäjä kirjautuu äänestäjäksi Helsingin kaupungin testitunnuksilla.
• Aloitustilanne: Verkkoselain on avattuna ja Ruutibudjetti-palvelun osoite on kirjoitettuna osoitekenttään valmiiksi. Käyttäjä hyväksyy sen ja aloittaa sivulla toimimisen itsenäisesti, kun sivu on latautunut.
• Suorituksen aikana: Testihenkilöä pyydetään kertomaan, mitä hänen käsityksensä mukaan äänestys palvelussa tapahtuu. Ts. ymmärtääkö testaaja, miten hänen tulisi palvelussa toimia.

2. Oman äänestysalueen valinta

• Tavoite: Käyttäjä on valinnut omaksi äänestysalueeksi ”Maunula”.
• Aloitustilanne: Käyttäjä on tunnistautunut. Testikäyttäjä opiskelee Stadin ammatti- ja aikuisopistossa.

3. Ehdotuksen tietoihin tutustuminen (Kokkikerho)

• Tavoite: Käyttäjä on löytänyt ja avannut oikean ehdotuksen (Kokkikerho) tiedot, ja selvittänyt, mikä ehdotuksen sijainti on. Käyttäjä on palannut ehdotuksen tiedoista selausnäkymään.
• Aloitustilanne: Äänestysputken selausnäkymä on avattuna.

4. Ehdotusten lisääminen äänestyskoriin (Yhteisöllisyys + Kallahden Maja)

• Tavoite: Käyttäjä on poiminut äänestyskoriin kohteita, joita haluaisi äänestää. Käyttäjä on lisäksi listannut ehdotukset budjetin mukaan pienimmästä suurimpaan. Käyttäjä on siirtynyt esikatselunäkymään.
• Aloitustilanne: Äänestysputken selausnäkymä on avattuna.
• Suorituksen aikana: Käyttäjää pyydetään ensin muuttamaan ehdotusten listausbudjetin mukaan järjestetyksi niin, että halvimmat ehdotukset listataan ensin.

5. Äänten jättäminen

• Tavoite: Käyttäjä on äänestänyt ja kirjautunut ulos palvelusta.
• Aloitustilanne: Käyttäjä on valinnut äänestettäviä kohteita.

6. Ylimääräinen testitapaus: Käyttäjä selvittää, miten toteutettavat ehdotukset valitaan sekä milloin ehdotuksia toteutetaan.

• Tavoite: Käyttäjä jatkaa palvelussa uloskirjautuneena ja saa tiedon, miten toteutettavat hankkeet valitaan sekä milloin hankkeita toteutetaan

3 Tulokset

3.1 Yhteenveto

Ruutibudjetti on teknisesti saavutettava ja yhteensopiva apuvälineohjelmien kanssa. Käyttöliittymässä havaittiin silti vielä joitain yksittäisiä apuvälinekäyttöön liittyviä puutteita (jotka ovat raportoitu jo aiemmin OmaStadi—käyttäjätestausraportin yhteydessä), mutta ne olivat siinä määrin vähäisiä, että ne eivät rajoittaneet testaajien kykyä toimia palvelussa ruudunlukuohjelmalla. Tekninen toteutus on jo niin kypsä, että testitapausten onnistuminen riippui testaajien omista apuvälineen käyttötaidoista.

Testauksen tärkein havainto olikin, että Ruutibudjetin äänestyksessä on teknisten puutteiden sijaan käytettävyyteen liittyviä ongelmia, joiden vuoksi se on liian vaikea käyttäjille, joilla on merkittäviä kognitiivisia rajoitteita.

Syynä on, käyttäjän on samaan aikaan sekä ymmärrettävä useita hänelle entuudestaan vieraita sekä ylipäätään vaikeita käsitteitä, että osattava hahmottaa näiden käsitteiden välisiä riippuvuussuhteita äänestysputken käyttöliittymässä. Ilman tätä hahmotuskykyä käyttäjä kykenee vain sattumanvaraisesti etenemään palvelussa, eikä äänestystulos vastaa välttämättä käyttäjän todellisia toiveita.

Vaikeita käsitteitä olivat esimerkiksi ehdotukset, ehdotusten selailu vs. valinta, ehdotuksen poimiminen äänestystä varten ennen itse äänestystä, sekä mikä kunkin äänestysputken työvaiheen tarkoitus on.

Osin palvelun käytettävyysongelmat johtuivat testaajien omista rajoitteista, jotka ovat Ruutibudjetin kontekstissa merkittäviä, onhan kyseessä keskimääräistä monimutkaisempi tehtävä (äänestys). Näille rajoitteille palvelun tarjoaja ei voi mitään.

Silti myös Ruutibudjetin käyttöliittymässä ja ohjeistuksessa havaittiin puutteita, joita korjaamalla sivuston käytettävyyttä voidaan parantaa kaikille, erityisesti Ruutibudjetin kohteena olevilla nuorille, jotka voivat ilmentää erityiskäyttäjilläkin havaittavia rajoitteita; näitä ovat esimerkiksi haluttomuus tai kykenemättömyys lukea ohjeita sekä malttamattomuus käyttöpolkujen jäsentämisessä. Alle on eritelty keskeisimpiä ongelmakohdista.

Yhteistä listatuille puutteille on, että ne keskittyvät äänestysvaiheen näkymään, jossa käyttäjä valitsee äänestettävät ehdotukset. Vaikka testaajilla oli vaikeuksia jo tätä näkymää ennen ja osin sen jälkeenkin, olivat nämä haasteet enemmän henkilökohtaisiin rajoitteisiin liittyviä, kuin käyttöliittymästä riittävissä määrin yleistettäviä, joten niitä ei erikseen raportoida tässä yhteydessä.

3.2 Erityiskäyttäjän näkökulma Ruutibudjettiin

Havaintojen tulkinnassa tärkeää on ymmärtää, miten erityiskäyttäjät, sekä eritoten testissä mukana olleet monirajoitteiset käyttäjät, palvelussa pyrkivät toimimaan.

Erityiskäyttäjät jäsentävät yksittäisestä sivunäkymästä pienemmän osan kuin ns. peruskäyttäjät, koska heille jo verkkosivun peruskäyttökin on hidasta ja kuormittavaa. He pyrkivät selaamaan sivustoa ”taloudellisesti” ja optimoidusti, eivätkä siten tutki näkymää enempää kuin kokevat välttämättömäksi. Selaustavassa korostuu sivurakenteen (otsikointi, tekniset alueet, selausjärjestys) merkitys, sillä ohjeita ei kielellisten rajoitteiden vuoksi jakseta tai edes osata lukea.

Seuraa, että käyttöliittymän kontrollien (painikkeet, linkit, hakukontrollit) ja ohjeiden tulisi olla mahdollisimman yksinkertaisin sanoin laadittuja ja aina yhdenmukaisia palvelun eri osissa. Toisin sanoen synonyymit voivat estää käyttäjää yhdistämästä toimintoja toisiinsa, vaikka kyseessä on sama käsite; samoin vaikeita ovat yhdyssanoista muodostetut käsitteet, jotka eivät tarkoita yleiskielessä mitään konkreettista. Erityiskäyttäjä ei välttämättä kykene purkamaan käsitettä toiminnoksi, jonka hän ymmärtää.

3.3 Kontrollien nimet

3.3.1 Ehdotusten tietojen avaaminen

Ehdotuksen tietosivu (dialogi) avautuu linkistä, joka on osa ehdotuskorttia. Useilla testaajilla oli vaikeuksia hahmottaa, että linkin kautta voi saada lisätietoa ehdotuksesta. He kyllä havaitsivat kortin otsikkolinkin ja alaosan linkin (Näytä ehdotus), mutta käyttäjä koki, että koska hän jo tarkasteli ehdotusta, ei linkki auta häntä, sillä hänen tarkoituksenaan on selvittää ehdotuksen sijainti, ei katsella ”lisää” sitä. Käyttäjä jäikin etsimään sijaintia kortista.

3.3.2 Ehdotuksen dialogin sulkeminen

Dialogin sulkemiseen tarkoitettu ”ruksi”painike on nimetty avustavalle teknologialle loogisesti ”Sulje”. Koska käyttäjät eivät kuitenkaan ymmärtäneet dialogin roolia käyttöliittymärakenteena, ei sulkeminen (sanana tai visuaalisena ruksina) ollut toiminto, jota he etsivät. He pyrkivät enemminkin palaamaan edelliseen näkymään.

3.3.3 Äänestysputkessa siirtyminen

Sivunäkymän alaosassa olevat painikkeet, joista käyttäjä voi siirtyä seuraavaan ja edelliseen työvaiheeseen, olivat nimetty kahdella sanalla, joista ensimmäinen oli esimerkiksi ”Siirry” ja toinen työvaiheessa suoritettava tehtävä.

Kaikilla paitsi yhdellä käyttäjistä oli vaikeuksia ensin ymmärtää, mitä painikkeista tapahtuu. Käyttäjä #1 esimerkiksi arasteli painikkeen klikkausta, ja #2 ja #4 eivät meinanneet löytää etenemisvaihtoehtoa lainkaan.

Syynä oli, että käyttäjät eivät osanneet yhdistää seuraavan vaiheen nimeä tavoitteeseen, joka oli ”eteenpäin siirtyminen”. He eivät enää muistaneet, mitkä prosessin työvaiheet olivat, eivätkä siten tienneet, että eteneminen on sama asia, kuin tietyn nimiseen toimintoon siirtyminen. Toiminnon nimi taas ei irrallisena abstraktina käsitteenä myöskään ollut selvä, joten kun muisti (tai alunperinkin puutteellisesti jäänyt käsitys vaiheista) ehtyi, myös linkin tarkoituksen käsittäminen estyi.

3.3.4 Selailunäkymän hakutoimintojen nimeäminen mobiilinäkymässä

Hakukenttä ja muut hakukontrollit ovat mobiilinäkymässä oletuksena piilotettu. Käyttäjän on paljastettava ne ”Suodata”—painikkeesta. Kuten edellä, myöskään tässä testikäyttäjät eivät ymmärtäneet, mikä on suodatuksen yhteys ehdotusten etsimiseen. Peruskäyttäjällekään se ei välttämättä ole itsestään selvä – suodatus voi viitata ennemminkin jo esitettyjen tulosten käsittelyyn. Toisaalta suodatustoiminto teknisesti ”filtteroi” tuloksia, joista oletuksena esitetään kaikki. Joten nimi on looginen alustan kannalta, mutta ei välttämättä se, joka käyttäjällä puolestaan on mielessä.

3.3.5 Äänestettäväksi lisääminen

Elementti, josta ehdotus valitaan äänestettäväksi, oli nimetty ”Valitse ehdotus.” Nimi oli testaajien kannalta liian epäsuora: He eivät osanneet yhdistää kontekstitonta ”valintaa” äänestykseen valitsemiseksi, vaikka kyseessä olikin työvaihe, jossa kehotettiin valitsemaan äänestettävät ehdotukset.

Kuten edellä olevissa havainnoissa, tässäkin toistuu tarve antaa spesifisempää ja konkreettisempaa tietoa, kuin mitä peruskäyttäjä tarvitsisi. Erityiskäyttäjä ei osaa sijoittaa toimintoa ”isoon kontekstiin” vastaavalla tavalla.

3.4 Visuaalinen tyyli ja asettelu

3.4.1 Ehdotuskorttien alku- ja päättymispiste vaikea hahmottaa

Näönvaraisesti toimiville käyttäjille oli yllättävän vaikeaa hahmottaa, miten yksittäinen ehdotuskortti erottuu muista ehdotuksista selailunäkymässä. Käyttäjiltä menivät osin sekaisin, mikä tieto oli vielä edellistä korttia ja mikä jo seuraavaa.

Syynä oli, että kortit ovat visuaalisesti melko korkeita ja niiden sisällä on paljon ”tyhjää” valkoista tilaa, jolla kortin eri alueet erotetaan. Käyttäjälle, jolla on hyvä näkökyky ja normaalit kognitiiviset taidot, kortit muodostavat silti melko selkeän ruudukon tai pinon. Testikäyttäjille sen sijaan kortin yksittäiset tiedot ovat jo lähtökohtaisesti vaikeita ymmärtää, jolloin myös yhden korttikokonaisuuden hahmotus vaikeutuu. Iso määrä tyhjää tilaa kortissa tuntui pahentavan tätä ongelmaa.

Korttien ympärillä on kehys, mutta se on todella himmeä. Lisäksi kehystä käytetään rajaamaan kortin sisällä myös esimerkiksi päivämäärä-, suosikki-, kommentit- jne. tietoja. Tämä tyyli teki kortin päättymiskohdan entistä epäselvemmäksi testikäyttäjille.

3.4.2 Ehdotusten listauksen järjestyksen muuttaminen

Mobiililaitteella näönvaraisesti testanneet käyttäjät kokivat tulosten järjestelyvalikon hankalaksi löytää. Testaaja #3 tarvitsi jopa apua valikon paikannuksessa, vaikka hänellä oli hyvä näkökyky.

Syynä tuntui olevan, että käyttäjien oli kognitiivisesti vaikea ymmärtää ja siten ennakoida, mistä toiminnosta on kyse, ainakin ennen sen löytämistä. Siten näkymän jäsentäminen silmällä muuttui paljon työläämmäksi, kuin peruskäyttäjällä, joka automaattisesti osaa muodostaa mielikuvan, miltä valikko voisi näyttää tai missä sijaita. Erityiskäyttäjillä silmän hahmontunnistus ei siten samaan tapaan napannut valikosta kiinni, vaikka katse sen poimikin. Näkemiseen liittyi yhtäaikaisesti myös tarve ymmärtää valikon funktio ja siinä oleva teksti, ei vain ”nähdä” se.

3.5 Ohjeet

Palvelun ohjeteksteistä tehtiin jonkun verran havaintoja jo käyttäjätestaukseen valmistautumisen yhteydessä.

3.5.1 Äänestysputki

Katso luku 4.3.

3.5.2 Tietoa palvelusta

Ohjeiden tyyli ei työryhmämme mielestä ole riittävän selvä palvelun kohdeyleisölle, eli peruskoulua käyville oppilaille. Teksti tuntuu kirjoitetun enemmän kaupungin itsensä kuin oppilaan näkökulmasta. Esimerkki:

Tiedonkeruu: ”RuutiBudjetti alkaa keväisin tiedonkeruulla. Kaikki nuorisopalveluiden yksiköt toteuttavat tiedonkeruun alueen nuorille sopivalla tavalla. Usein tietoa kerätään esimerkiksi sähköisillä kyselyillä tai tapahtumissa. Tiedonkeruussa kartoitetaan nuorten toiveita, huolia ja ideoita. Tiedonkeruuseen osallistutaan yleensä koulupäivän aikana.”

Tekstissä kerrotaan ensin, että Ruutibudjetti alkaa tiedonkeruulla. Sen jälkeen kerrotaan, ketkä sitä tekevät – mutta ei, mitä tiedonkeruu tarkoittaa. Sitten kerrotaan vielä työmenetelmistä. Vasta toiseksi viimeisessä virkkeessä mainitaan, mikä tiedonkeruun tarkoitus on ja mitä siinä tehdään. Lukijan tulee nyt palata tekstin alkuun ja lukea se uudelleen, jotta hän voi oikeasti ymmärtää, mitä tekstin alussa sanottiin, sillä vasta nyt virkkeiden tiedoille on olemassa konteksti, johon ne kognitiivisesti sijoittuvat.

“Miten Ruutibudjetti etenee?” –ohjeen kuvaus ”Neuvottelut”—vaiheesta on vielä heikompi. Se on niin byrokraattinen ja sekava, että työryhmämme ei ymmärtänyt sitä ensi lukemalla. Ohje on kuitenkin laadittu 12-16 vuotiaille.

4 Suositukset

4.1 Keskeisimpien kontrollien nimiä tulisi selkiyttää

4.1.1 Ehdotusten tietojen avaaminen

Ehdotuksen kortissa olevan linkin ”Näytä ehdotus” nimeen voisi lisätä jonkin sanan, joka viestii, että linkin avulla ehdotuksesta voi tuoda esiin lisää tietoja tai sen koko kuvauksen. Esimerkiksi: ”Näytä koko ehdotus.” Tämä ei ole vielä erityiskäyttäjille kaikista helpoin, mutta voi onnistua ilman käyttöliittymämuutoksia. Toisaalta entä jos alkuun laitetaan verbi, joka vastaa tavoitetta, joka lisätietojen näyttämisellä on? ”Tutki ehdotusta” voisi siten olla myös nykyistä parempi vaihtoehto.

4.1.2  Ehdotuksen dialogin sulkeminen

Dialogin sulkemiseen tarkoitettu ”ruksi”painike voidaan halutessa korvata tekstipainikkeella, jossa lukee ”Palaa” (ja ehkä vasemmalle osoittava väkänen / nuoli tekstin edessä). Toisaalta dialogin alaosassa on jo tekstipainike, mutta sen löytäminen ei ollut käyttäjille suoraviivaista, koska dialogi on melko pitkä.

4.1.3  Äänestysputkessa siirtyminen

Sivunäkymän alaosan painikkeet tulisi nimetä ”Seuraava” ja ”Edellinen” (tai vastaavat synonyymit). Korjauksen ei pitäisi vaikuttaa ns. peruskäyttäjiin, jotka löytävät prosessin työvaiheet (ja linkit) sivun yläosasta ja jotka saattavat muistaa ne muutenkin. Lisäksi käyttäjät ovat tottuneet lomakkeissa ja asiointipalveluissa vastaavaan nimeämistapaan sivulta toiseen siirryttäessä. Erityiskäyttäjille taas on tärkeää, että he voivat selvästi havaita, mistä tehtävää voi jatkaa. Tieto, mikä seuraava vaihe on, ei ole heille etukäteen olennainen. He jäsentävät kunkin näkymän aina kerrallaan. Prosessi päättyy, kun se päättyy.

4.1.4 Selailunäkymän haku—ja rajaustoimintojen nimeäminen mobiilinäkymässä

Painike, joka näyttää suodattimet, voitaisiin nimetä ”Etsi ja rajaa ehdotuksia” ”Suodattamisen” sijasta. Lisävaihtoehto on, että rajaimista hakukenttä tuodaan mobiilissakin aina näkyviin, ja vain muut filtterit ovat painikkeen takana (jolloin painike tulisi nimetä vähän eri tavoin).

Perusteluna on (oikein tai väärin), että hakusanahaku voi olla rajauksista suosituin nuorten käytössä, jos on tyypillistä, että esim. kaverilta kuultua ehdotusta halutaan äänestää tai tutkitaan, onko skeittaukseen tai kokkaamiseen liittyviä hankkeita.

Ehkä palvelun hakulokidata kertoo, onko muutos perusteltu. Jos niin on, olisi sen myötä ainakin joku hakutoiminto aktiivisesti tarjolla myös mobiilissa ilman, että käyttäjän on osattava avata rajausdialogia.

4.1.5 Äänestettäväksi lisääminen

Elementin, josta ehdotus valitaan äänestettäväksi, tulisi kertoa selkeämmin, mikä valinnan tulos tai tarkoitus on. Pelkkä valinta ei ole tässä riittävän selvä tekemisen kohde.

”Äänestä ehdotusta” voisi olla hyvä, mutta siinä on puutteena, että käyttäjähän ei vielä äänestä kohdetta, joten väärinymmärtämisen riski on olemassa. ”Valitse äänestettäväksi” on ehkä vähemmän sitovan kuuloinen.

4.2 Visuaalinen rakenne

4.2.1  Ehdotuskorttien alue tulisi olla visuaalisesti erottuvampi

Ehdotuskortin ulkokehystä voidaan tummentaa suurempikontrastiseksi ja/tai kortille voidaan luoda taustaväri. Kortin sisällä olevat osiot (suosikit, päiväys, kommentit, jne.) tulisi kehystää tyylillä, joka erottuu selvästi kortin ulkokehyksestä; ts. pitää näkyä selvästi, että kortti ei pääty tähän.

4.2.2  Ehdotusten listauksen järjestyksen muuttaminen mobiilinäkymässä

Voisi harkita, onko valikon tekstin koon muuttamisella tai muilla tyylikeinoin (alueen väritys?) mahdollista erottaa se selvemmin heti alla alkavista korteista. Nyt sekä tulosten määrä että järjestelyperustevalikko tuntuvat jossain määrin sekoittuvan korttilistaukseen.

4.3 Ohjeet

4.3.1 Äänestysalueen valinta

Nykyinen teksti:

Valitse alla olevasta listasta alue, jolla haluat äänestää. Alueet on rajattu nuorisotyöyksiköiden mukaan. Jos et tiedä, mitä alueisiin kuuluu, voit tarkistaa sen tästä.

Koulun Wilma-tunnuksilla sinulle tarjotaan sitä aluetta, jossa koulusi on. Voit vaihtaa alueesi, jos haluat.

Ehdotus uudeksi tekstiksi:

Ruutibudjetissa Helsinki on ajettu alueisiin. Voit äänestetään yhden alueen ehdotuksia. Tutustu, mitä kuhunkin alueeseen kuuluu (=linkki, joka näyttää lisätiedot alueista dialogissa).

Jos olet kirjautunut Wilma-tunnuksella, on alueeksi valittu jo valmiiksi koulusi alue. Voit vaihtaa alueen, jos haluat.

4.3.2 Ehdotusten selaussivun sisältö

Nykyinen teksti:

Lue rauhassa äänestettävät ehdotukset läpi ja mieti miten jakaisit käytössä olevat äänet. Käytössäsi on 3 ääntä.

Voit äänestää enintään kolmea ehdotusta. Kullekin ehdotukselle voit antaa yhden äänen. Halutessasi voit jättää ääniä käyttämättä, jos et halua antaa ääntäsi millekään ehdotukselle.

Ehdotus uudeksi tekstiksi:

Tällä sivulla voit tutkia ehdotuksia ja valita ehdotukset, joita haluat äänestää. Voit valita korkeintaan kolme ehdotusta. Halutessasi voit valita myös vähemmän ehdotuksia, jos et haluaa äänestää kolmea. Äänestys vahvistetaan vasta seuraavalla sivulla.

4.3.3 Esikatselusivun sisältö

Nykyinen teksti:

Alta voit tarkistaa ehdotukset, joita olet äänestämässä. Voit tässä vaiheessa vielä vaihtaa valintaasi, mikäli huomaat virheen. Jos valintasi on hyvä sellaisenaan, paina Äänestä-painiketta.

Ehdotus uudeksi tekstiksi:

Voit tarkistaa tällä sivulla, mitä ehdotuksia olet äänestämässä. Jos haluat vielä muuttaa valintaasi, palaa edelliselle sivulle. Jos olet tyytyväinen valintaasi, klikkaa ”Äänestä” sivun alaosassa.

(Huomautus lukijalle: ”Äänestä” ei ole painike vaan linkki, joten se ei näyttäydy apuvälineille painikkeena. Siksi ehdotamme, että painike—sanaa ei käytetä.).

4.3.4 Onnistuneen äänestyksen jälkeen näytettävä sisältö

Nykyinen teksti:

Äänesi on tallentunut järjestelmään, etkä voi enää muuttaa ääntäsi.

RuutiBudjetti-äänestys päättyy 30.10.2021. Äänestyksen päätyttyä tulos vahvistetaan neuvottelukunnissa. Saat tästä tietoa oman alueesi nuorisotalolta.

Ehdotus uudeksi tekstiksi:

Äänesi on tallennettu. Et voi enää muuttaa antamiasi ääniä. Äänestyksen tulos julkaistaan Ruutibudjetin sivuilla äänestysvaiheen päätyttyä.

Sinun ei tarvitse enää tehdä muuta äänestykseen liittyen. Voit nyt halutessa kirjautua ulos Ruutibudjetista.

Kysymys:

MPASSid –tekstiversio: Jos käyttäjä seuraa välittömästi ehdotettua linkkiä, jääkö hän tietämättään kirjautuneeksi Ruutibudjettiin (evästeiden kautta)? Jos niin tapahtuu, olisi tästä hyvä kertoa; käyttäjää voidaan esimerkiksi kehottaa ensin kirjautumaan ulos. Tai jos käyttäjä pysyy kirjautuneena palvelujen välillä evästeiden ansiosta, niin aiheuttaako OmaStadissa tehtävä uloskirjautuminen myös Ruutibudjetissa uloskirjautumisen, vaikka Ruutibudjettiin ei enää palaa?

4.4 Palvelun jatkokehitys

4.4.1 Kohteena olevat käyttäjät tulisi huomioida paremmin

Ruutibudjetin nykyinen versio on toteutettu Osallistuvan budjetoinnin (OSBU) yhteiselle alustalle. Palvelu on siten perinyt OSBUsta paitsi teknisen toteutuksen, myös hyvin samanlaisen palvelumuotoilun ja sisällöt.

Työryhmämme mielestä se ei ole peruskouluikäisille nuorille suunnatussa palvelussa paras ratkaisu. Suuri osa palvelun kielestä (johon jo viitattiin luvussa 3.5) mukailee organisaatiolähtöistä tyyliä, jossa puhutaan käsitteillä miten asiat ovat ja mitä tapahtuu. Nuoren tulee ymmärtää budjetoinnin kierrokset, sekä ehdotukset käsitteinä, sekä kaupungin sisäisen työn suhde niihin, jne.

Voi olla, että tämä on tarkoituksellista, jos palvelulla on myös opetuksellinen rooli. Jos sen sijaan päämääränä on kannustaa ja aktivoida nuoria osallistumaan ja äänestämään, ei nykyinen palvelu tunnu tehokkaimmalta lähestymistavalta. Useat tässäkin raportissa kuvatut erityiskäyttäjien kohtaamat haasteet tulevat juuri palvelun monimutkaisesta rakenteesta, joka heijastuu mm. kontrollien nimissä ja visualisoinnissa, jotka noudattavat alla olevaa teknistä arkkitehtuuria (esim. miten hakutulosten rajaus on nimetty).

Mietimme, voisiko palvelun tulevaisuuden kehitystavoitteena olla käyttökokemus, joka olisi kevyempi ja pelillisempi? Tarvitseeko pelkästään äänestämään tulevan tietää työvaiheista ja alueista?

Entä jos käyttäjältä vain kysytään ensin, mitkä hänen kiinnostuksen kohteitaan ovat (käyttäjä valitsee tietyn määrän aiheita listasta) ja käyttöliittymä tarjoilee tämän jälkeen ehdotuksia yksi kerrallaan, esimerkiksi kuvitettuina kortteina, joille käyttäjä antaa aina ylä- tai alapeukun, tai ”haluan äänestä”/”en äänestä tätä”, tms.

Jokin tällainen suoraviivainen, käsitteet ohittava käyttökokemus olisi myös hyvin käytettävä ja saavutettava. Mutta vastaisiko se edelleen kaupungin Ruutibudjetille asettamia tavoitteita, emme tämän raportin puitteissa osaa arvioida.

5 Yhteenveto

Siteimprove Oy toteutti Helsingin kaupungin Ruutibudjetti –verkkopalvelulle käyttäjätestauksen, jossa selvitettiin, miten saavutettava ja helppokäyttöinen palvelun äänestysvaihe on käyttäjille, joiden on erityisen haastavaa käyttää digitaalisia palveluja. Testikäyttäjiksi valittiin nuoria, joilla oli aisteihin tai kognitioon liittyviä useita yhtäaikaisia rajoitteita. Testauksen kohteena oli palvelun avoin, verkossa julkaistu versio.

Käyttäjätestaus osoitti, että palvelu on teknisesti jo hyvin saavutettava. Apuvälinekäyttäjiä rajoittivat lähinnä heidän omat avustavan teknologian käyttötaitonsa, eivät palvelun tekniset ratkaisut.

Tärkeimmät havainnot koskivatkin palvelun käytettävyyttä. Monirajoitteisille erityiskäyttäjille Ruutibudjetin äänestysvaihe oli liian vaikea suorittaa ilman ulkopuolista apua. Avustettuinakin käyttäjillä oli vaikeuksia ymmärtää, mitä yksittäisiä tehtäviä tai laajempia käyttöpolkuja he palvelussa suorittivat.

Osin syynä oli, että käyttäjien omat toimintarajoitteet olivat niin merkittäviä, että Ruutibudjetin kaltainen monimutkainen palvelu oli heille väistämättä haastava. Ruutibudjetissa käyttäjän on voitava ymmärtää useita monimutkaisia ja toisistaan riippuvia käsitteitä, jotta palveluun luotujen ehdotusten tutkiminen ja valitseminen, sekä äänestysputkessa eteneminen, onnistuvat luontevasti.

Toisaalta testaus paljasti myös käyttöliittymästä puutteita, joihin erityiskäyttäjät reagoivat hyvin herkästi, mutta jotka voivat vaikuttaa muihinkin käyttäjiin, erityisesti palvelun kohteena oleviin nuoriin. Heillähän ei aina välttämättä ole Ruutibudjetin kaltainen sivuston edellyttämää malttia ja keskittymishalua.

Raportissa on ehdotettu korjauksia havaittuihin käytettävyysongelmiin sekä ajatuksia, miten palvelua voitaisiin tulevaisuudessa kehittää. Tavoitteena voisi esimerkiksi olla, että äänestysvaiheesta kehitettäisiin pelillisempi ja siten yksinkertaisempi ja myös saavutettavampi.

Tutkimuksen laatijat

Tero Pesonen

Käyttäjätestauksen työryhmässä mukana:

Kimmo Sääskilahti

Niko Kunelius

Krister Linnas

Siteimprove Oy

Puhelin: +358 40 50 92 034

Unioninkatu 30
00100 Helsinki