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. Laajoissa hankkeissa saatetaan kuitenkin nojata myös perinteisempään vesiputousmalliin tai laatuportteihin, jotka ohjaavat kehityksen työvaiheita. Tällaisessa mallissa yksittäiset työvaiheet voidaan toisaalta toteuttaa ketterästi.

Riippumatta prosessin muodosta, palvelukehityksessä tulee huomioida käyttötapaussuunnittelu. Käyttötapauksia ei olla aina otettu huomioon palvelukehityksessä, vaikka erityisesti saavutettavuusongelmista suuri osa syntyy jo puutteellisessa määrittelyvaiheessa tai määrittelyn puuttuessa kokonaan. Kehitys saattaa jopa alkaa käyttöliittymän visualisoinnilla ennen kuin on päätetty, mitä toimintoja palvelun tulee toteuttaa.

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. Siinä kuvataan, mitä käyttäjä haluaa tehdä palvelussa ja miksi. Mikä on tämän tehtävän tavoite käyttäjän kannalta? Käyttäjätarina voi olla vapaamuotoisempi ja kuvaavampi, eikä sen tarvitse käsitellä palvelun teknisiä yksityiskohtia.

Käyttötapausten ja skenaarioiden avulla määritetään palvelun toiminnalliset vaatimukset. Näiden menetelmien etuna on, että käyttöliittymään ei synny turhia toimintoja. Tämä on erityisen tärkeää verkkopalveluissa, joissa pääsivuille kertyy helposti liikaa sisältöä eri sidosryhmien vaatimuksista. Liiallinen sisältö voi kuormittaa käytettävyyttä huomattavasti, kun sivuille lisätään tarpeettomia nostoja, upotteita ja lomakkeita, jotka eivät oikeastaan liity palvelun varsinaisiin käyttötarkoituksiin.

Kaikki käyttöliittymätoiminnot tulisi luoda käyttötapausten pohjalta. Käyttötapauksia pitäisi iteroida aina, kun huomataan, että käyttöliittymästä puuttuu vielä joitakin perusvaatimuksia tai että vaatimuksissa on ennakoimattomia piirteitä. Käyttötapaukset ja käyttäjätarinat sopivat erityisen hyvin ketterään kehitykseen ja MVP (minimum viable product) julkaisemiseen.

Saavutettavuus käyttötapauksessa

Saavutettavuuteen liittyviä vaatimuksia on yleensä helppo sisällyttää käyttötapauksiin. Ne voivat näkyä esimerkiksi rajoituksina, jotka liittyvät käyttäjän toimintaan:

  • Käyttäjä ei välttämättä pysty tarkastelemaan koko sivua kerrallaan tai näkemään tiettyä elementtiä ruudun ulkopuolella (esim. ruudun suurennuksen tai ruudunlukuohjelman vuoksi).
  • Käyttäjällä voi olla käytössä vain näppäimistö ilman hiirtä tai kosketusnäyttöä.
  • Käyttäjä ei välttämättä tunne yleisiä tietoteknisiä symboleja tai käyttökonventioita (esim. seniorikäyttäjä).
  • Kielen ja lukemisen ymmärtämisen haasteet voivat olla läsnä.

Näitä asioita huomioimalla varmistetaan palvelun saavutettavuus eri käyttäjäryhmille.

Silti saavutettavuusvaatimusten huomioiminen ei aina ole itsestään selvää, varsinkin kun aihe ei ole tuttu. Erityisesti avustavan teknologian, kuten ruudunlukuohjelman, integroiminen konkreettisiin käyttötapauksiin saattaa tuntua oudolta ja vaikealta. Toisaalta jo pelkästään ikääntyvien käyttäjien kohtaamat perustason haasteet verkkopalveluiden käyttöliittymissä voivat olla hyvinkin yksinkertaisia. Esimerkiksi symbolien merkitykset ja toiminnallisuudet voivat jäädä epäselviksi.

Yksi hyvä tapa on aloittaa käyttötapauksien laatiminen korkeamman tason käyttäjätarinoista. Näitä tarinoita kirjoitetaan sellaisen käyttäjän näkökulmasta, jolle toiminnon voidaan kuvitella olevan sekä tärkeä että mahdollisesti haastava. 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 on suunniteltu niin, että kyseinen käyttäjä siitä selviytyy, myös muut käyttäjät voivat todennäköisesti suorittaa tehtävän. Tästä syystä käyttötapauksesta johdettaviin ohjelmistovaatimuksiin on myös helpompaa sisällyttää esimerkiksi apuvälineisiin liittyvät erityishuomiot ja sitä kautta lain edellyttämä WCAG-kriteeristö, joka voi muuten vaikuttaa monimutkaiselta joukolta 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ä näkee, että kielen voi vaihtaa johonkin seuraavista vaihtoehdoista, mutta jo valittua kieltä ei voi valita uudelleen: 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 evästetiedoissa 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.
    • Tämä takaa, että valinta on tarjolla kaikilla palvelun verkkosivuilla.
  2. Kielivalinta tulee sijaita bannerin alussa heti pääsivullepaluu(logo)linkin jälkeen.
    • Toiminto on visuaalisesti helppo havaita myös ruudunsuurennuksen kanssa
    • 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öä. 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 tilassa, ne sijoitetaan kielivalikkoon. Valikon avaavaa painiketta nimetään avustavalle teknologialle siten, 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ä voidaan varmistaa, että tekninen toteutus noudattaa WCAG-kriteeristöä alusta alkaen ja samalla parantaa palvelun käytettävyyttä.

Alkuperäinen versio: Tero Pesonen
Luotu: 4.3.2021

Jatka opiskelua