Moduuli 2, Käyttötapaukset

Tällä sivulla

Moduuli 2

  • Käyttötapaukset kuvaavat, mitä tehtäviä palvelun käyttäjät palvelulta tarvitsevat ja miten nämä tehtävät palvelussa suoritetaan.
  • Hyvin laaditut käyttötapaukset ohjaavat käyttöliittymäsuunnittelua. Niiden avulla palveluun ei kerry turhia toimintoja ja sisältöjä.
  • Käyttötapaukset ovat keskeisiä myös onnistuneessa saavutettavuuden käyttäjätestauksessa.

Käyttötapaukset ja palvelukehitys

Verkkopalvelu luodaan ohjelmistokehitysprosessissa, joka nykyään perustuu yhä useammin ns. ketterään kehitykseen, mutta voi etenkin laajoissa hankkeissa nojata myös perinteisempään vesiputousmalliin tai laatuportteihin, joiden läpi palvelun on kuljettava ennen tiettyjen työvaiheiden valmistumista. Tällaisessa mallissa yksittäiset kehitysvaiheet voivat vastaavasti perustua rekursiivisesti samaan kehitysprosessin, tai toteuttaa siitä erillistä ketterämpään, iteroivaa kehitystapaa.

Riippumatta prosessin muodosta, palvelukehityksessä tulee huomioida käyttötapaussuunnittelu. Näin ei valitettavasti vielä aina verkkopalvelujen kohdalla tehdä, vaan käyttötapaukset katsotaan liittyvän lähemmin ohjelmistotuotteisiin. Verkkopalvelu on kutienkin yhtä lailla ohjelmistohanke, eikä määrittelyn rooli ole siinä vähäisempi – päinvastoin: Kokemus käytännön kehityshankkeista on osoittanut, että erityisesti saavutettavuuteen liittyvistä ongelmista valtaosa syntyy jo määrittelyvaiheessa, joka on puutteellinen tai jota ei aina edes suoriteta. Palvelun kehitys voi jopa alkaa suoraan käyttöliittymän visualisoinnilla ilman päätöstä, mitä toimintoja palvelun ylipäänsä tulee toteuttaa. Ongelma on toistunut myös Helsingin kaupungin palvelujen tilaa arvioitaessa (Palvelukeskus, 2020).

Käyttötapaukset ovat paitsi määrittelyn perusta, myös edellytys tehokkaalle saavutettavuuden käyttäjätestaukselle. Siksi käyttötapauksiin kiinnitetään erityistä huomiota Helsingin saavutettavuusmallissa.

Käyttötapaukset: Use case ja User story

Käyttötapauksella (use case) tarkoitetaan toimintoa tai sarjaa toimintoja, jonka käyttäjä palvelussa suorittaa, jotta palvelu voi täyttää jonkin sille osoitetun tarpeen. Käyttötapauksessa kuvataan käyttäjän ja järjestelmän vuorovaikutusta. Käyttötapaus kertoo, missä tilassa järjestelmä on, miten järjestelmä reagoi käyttötapauksen aikana, mitä poikkeuksia voi ilmetä, ja millaiseksi järjestelmän tila muuttuu, kun käyttötapaus on suoritettu.

Käyttäjätarina (user story), tai skenaario, muistuttaa käyttötapausta, mutta se kirjoitetaan yleensä korkeammalla tasolla ja käyttäjän näkökulmasta: Mitä käyttäjä haluaa palvelussa tehdä ja miksi? Mikä on tämän tehtävän tavoite käyttäjän kannalta? Tarina voi nimensä mukaisesti olla proosallisempi kuvaus, jonka ei tarvitse ottaa kantaa, mitä palvelussa teknisesti tapahtuu.

Käyttötapausten ja skenaarioiden avulla määritetään palvelun toiminnalliset vaatimukset. Menetelmien etuna on, että käyttöliittymään ei pitäisi syntyä turhia toimintoja, jotka etenkin verkkopalvelussa ja niiden pääsivuilla voivat kuormittaa käytettävyyttä huomattavasti, kun jokainen palveluun liittyvä intressitaho on tuonut sinne omat nostonsa ja upotteensa ja lomakkeensa ilman, että kaikki tämä ”bloat” tosi asiassa liittyy tehtävin, joita varten palvelu käyttäjille tarjotaan.

Kaikki käyttöliittymätoiminnot pitäisikin luoda pelkästään käyttötapauksista, ja käyttötapauksia puolestaan iteroida, kun havaitaan, että käyttöliittymästä vielä uupuu joitain palvelulle asetettuja perusvaatimuksia, tai vaatimukset sisältävät piirteitä, joita ei osattu ennakoida. Käyttötapaukset- ja tarinat sopivat siten erityisen hyvin ketterään kehitykseen ja MPV (minimum viable product) julkaisemiseen.

Saavutettavuus käyttötapauksessa

Saavutettavuuteen liittyviä vaatimuksia on yleensä suoraviivaista tuoda käyttötapauksiin. Ne näkyvät mm- rajauksina, joita tehtävään liittyy: Käyttäjällä ei esimerkiksi voi tarkastella koko sivunäkymää kerralla tai näe yhtä elementtiryhmä edemmäs (ruudunsuurennuksen tai ruudunlukuohjelman vuoksi); käytössä voi olla pelkkä näppäimistö ilman osoitinlaitetta (hiiri, kosketusaktivointi); käyttäjä ei tunne yleisiäkään tietoteknisiä konventioita, kuten valikko-, tallennus-, tai paikannus/sijainti-symboleja (seniorikäyttäjä); kieli ja lukeminen voivat tuottaa haasteita; jne.

Silti saavutettavuusvaatimusten huomioiminen ei aina ole itsestään selvää, varsinkin, jos näkökulma on vielä vähemmän tuttu. Erityisesti avustava teknologia, kuten ruudunlukuohjelma, voi vaikuttaa eksoottiselta ja hankalalta sijoittaa konkreettisiin käyttötapauksiin. Toisaalta jo pelkästään ikääntyvien käyttäjien kohtaamat hyvin perustason haasteet verkkopalvelujen käyttöliittymissä voivat yllättää yksinkertaisuudellaan. Mitä tarkoittaa symboli, jossa on kolme viivaa päällekkäin? Onko se ehkä koriste? Uskaltaako sitä koskea hiirellä? Mitä jos tämä linkki avaakin sellaisen ei-verkkosivun toiseen ohjelmaan, jota en nyt halua, kun haluan avata verkkosivun?

Avuksi voi ottaa seuraavan keinon: Aloita käyttötapausten laadinta korkeamman tason käyttötarinoilla, jotka kirjoitetaan sellaisen käyttäjän näkökulmasta, jolle toiminnon kuvitellaan olevan toisaalta tärkeä, toisaalta mahdollisesti hankala. Käyttäjä voi jopa olla johdonmukaisesti jokin ns. erityiskäyttäjä: Henkilö, jolla on aisti- tai kognitiivisia rajoitteita esimerkiksi kielitaidon, lukutaidon, vamman tai ikääntymisen vuoksi.

Jos käyttötapaus laaditaan niin, että kyseinen käyttäjä siitä selviytyy, on luultavaa, että myös muut käyttäjät pärjäävät tehtävän kanssa – jopa varsin helposti. Tällöin käyttötapauksesta johdettaviin ohjelmistovaatimuksiin on myös suoraviivaisempaa sisällyttää esimerkiksi apuvälineisiin liittyvät erityishuomiot ja sitä kautta lain edellyttämä WCAG-kriteeristö, joka voi muuten näyttäytyä isona ja vaikeasti konkretisoitavana joukkona melko abstrakteja vaatimuksia.

Esimerkki

Käyttäjätarina / skenaario

Käyttäjä X vierailee palvelussa ensi kertaa. Hänen äidinkielensä on Y, mutta hän osaa myös jonkin verran englantia. X tarvitsee verkkoselaimen kanssa ruudunlukuohjelmaa, jota hän käyttää sekä älypuhelimessa että tietokoneen kanssa. X huomaa, että palvelun kieli on luultavasti suomi, jota hän ei juurikaan ymmärrä. X kuitenkin havaitsee, että palvelun kielen voi vaihtaa; käyttäjämme huomaa samalla, että englanti on yksi tuetuista kielistä, joten hän valitsee sen. Käyttöliittymän kieleksi vaihtuu englanti, ja apuvälineohjelman syntetisaattori kertoo nyt palvelun sisällöstä ymmärrettävästi. X aloittaa palvelun pääsivun sisällön tutkimisen uudestaan.

Käyttötapauksena

Käyttäjä voi vaihtaa palvelun kielen joksikin seuraavista: suomi, ruotsi tai englanti.

Käyttötapauksesta seuraava tarkennettu käyttötapausjoukko

  1. Käyttäjä havaitsee vaivatta, että hän voi vaihtaa palvelun kielen.
  2. Käyttäjä havaitsee, että kielen voi vaihtaa jokisin seuraavista kielistä, kuitenkin niin, että jo valittuna olevaa kieltä ei voi asettaa: Suomi, ruotsi, englanti.
  3. Käyttäjä vaihtaa kielen. Muutos astuu voimaan koko palvelussa.

Esimerkkinä käyttötapaus #1 edeltä: Käyttäjä havaitsee vaivatta, että palvelun kielen voi vaihtaa

Käyttäjä:       Palvelun asiakas

Kohde:          Kaikki palvelussa olevat verkkosivut.

Alkuehdot:   – Käyttäjä toimi palvelussa ensi kertaa, eikä tunne palvelun sivurakennetta.

                      – Palvelun cookies-tiedoissa ei siten ole muistissa valittua kieltä

                      – Käyttäjän äidinkieli on muu, kuin palvelussa oletuksena käytössä oleva kieli.

Rajaukset:    Ei koske julkaisuja, jotka ovat muita, kuin verkkosivuja (esimerkiksi PDF—asiakirjat).

Tavoite:        Kun käyttäjä avaa palveluun kuuluvan verkkosivun ja tarkastelee tai selaa sitä tavanomaiseen tapaan sivun alusta lukien, hän havaitsee ilman erityistä selvittämistä, että palvelun kielen voi vaihtaa.

Kun kaikki kolme tarkempaa käyttötapausta on kirjoitettu auki, voidaan niistä johtaa muun muassa seuraavia toiminnallisia vaatimuksia, jotka määrittävät ohjelmistototeutuksen ja käyttöliittymäsuunnittelun.

Käyttötapausjoukosta seuraavia vaatimuksia

  1. Kielen vaihtaminen tulee sijoittaa vakiosivupohjan banneriosioon.
    1. Tämä takaa, että valinta on tarjolla kaikilla palvelun verkkosivuilla.
  2. Kielivalinta tulee sijaita bannerin alussa heti pääsivullepaluu(logo)linkin jälkeen.
    1. Toiminto on visuaalisesti helppo havaita myös ruudunsuurennuksen kanssa
    2. Ruudunluvun käyttäjä, jonka äidinkieli on muu, kuin palvelun kieli, havaitsee toiminnon helpoimmin, kun sitä ei tarvitse etsiä vieraskielisen sisällön seasta tai vieraskielisen navigointivalikon sisältä.
  3. Kielivalinta ei saa perustua sivun oletuskielellä olevan elementin, kuten valikon, nimen ymmärtämiseen.
  4. Valittavia kieliä on kaksi, koska yksi kieli on aina aktiivinen, eikä sitä voi valita.
  5. Vältetään, jos mahdollista, erityisen kontrollin tai dynaamisesti esitettävän ja piilotettavan sisällön käyttöä, sillä räätälöidyt, raskaat tekniset ratkaisut ovat tässä tarpeettomia ja hankaloittavat kielen vaihtoa apuvälinekäyttäjille.
  6. Kielten nimet tulee kirjoittaa kielellä itsellään: suomi, svenska, English.

Teknisiä ratkaisuja

  • Kielivalinta toteutetaan tavanomaisina HTML –tekstilinkkeinä, jotka ovat aina bannerissa näkyvissä heti pääsivullepaluu(logo)linkin jälkeen.
    • Jos tekstilinkkejä ei voida käyttää responsiivisessa näkymässä, asetetaan ne kielivalikkoon, jonka avaava painike nimetään avustavalle teknologialle niin, että valittavissa olevat kielet luetellaan siinä (esim. svenska, English):
  • Selausjärjestys eli DOM-järjestys, jossa kielilinkit tulevat, vastaa visuaalista taittoa.
  • Linkeistä on esillä vain ne kielet, joihin käyttäjä voi vaihtaa. Linkkejä on siten aina kaksi kappaletta.
  • Linkkien järjestys on vasemmalta oikealle: 1. suomi, 2. ruotsi, 3. englanti.
  • Kunkin linkin HTML—tägissä on kieltä vastaa lang—attribuutti.
  • Koska kyseessä on single page app (SPA) ja sivukontekstin muutos, varmistetaan, että kun kielilinkki aktivoidaan, käyttöliittymän sisältöjen kielen vaihtumisen lisäksi:
    • vaatimus (jo kirjatun muun vaatimuksen nimi) toteutuu (selainkohdistus siirretään sivun alkuun, hyppylinkkiin, kun koko sivukonteksti päivittyy).
    • vaatimus (jo kirjatun muun vaatimuksen nimi) toteutuu (sivun title—tägi päivittyy sivukontekstin päivittyessä)

Jo varsin yksinkertaisella käyttötapauksesta johdetulla analyysillä pystytään tässä paitsi varmistamaan, että tekninen toteutus noudattaa jo alusta alkaen WCAG-kriteeristöä, myös kehittämään palvelun käytettävyyttä.

Alkuperäinen versio: Tero Pesonen
Luotu: 4.3.2021

Jatka opiskelua