Sari A. Laakso - cs.helsinki.fi · Sari A. Laakso (2015) Simulointipohjainen käyttöliittymäsuunnittelu 4 Sari A. Laakso(2015) Erityyppiset käliongelmat Sekundääriset ongelmat

Simulointipohjainenkäyttöliittymäsuunnittelu

Helsinki 13.1.2015

Kurssin luentomonisteHELSINGIN YLIOPISTOTietojenkäsittelytieteen laitos

Sari A. Laakso

Sisältö1 Käyttöliittymän ominaisuudet ........................................ 1

1.1 Käyttötilanteet ohjelmiston käyttöönottovaiheessa .............. 11.2 Erityyppiset käyttöliittymäongelmat (Kuva-arkisto)................. 2

Tehokkuus ............................................................................ 3Opittavuus ............................................................................ 3Sekundääriset ongelmat ......................................................... 4Kulmakivet ........................................................................... 5Puuttuva toiminnallisuus tai tietosisältö ................................... 5

1.3 Määritelmiä kirjallisuudesta................................................... 61.4 Simulointimenetelmien idea .................................................. 71.5 Esimerkki tehokkuusongelmasta (Asiakasrekisteri) ................. 9

2 Käyttöliittymän arviointi ............................................... 102.1 Simulointitestaus ................................................................. 10

Vaihe 1. Testitapausten selvittäminen ..................................... 11Vaihe 2. Vaihtoehtojen ja loppuratkaisun selvittäminen ............ 12Vaihe 3. Oikean polun selvittäminen ....................................... 13Vaihe 4. Kuvasarjan laatiminen .............................................. 15Vaihe 5. Testitulokset ........................................................... 18Muita simulointipohjaisia asiantuntija-arviomenetelmiä ............. 22

2.2 Käytettävyystestaus ............................................................ 23Testitehtävät ........................................................................ 24Testikäyttäjät ....................................................................... 26Muut testivalmistelut ............................................................ 27Testitilanteen ohjaaminen ..................................................... 27Testitulokset ........................................................................ 30Kustannustehokas testaus ..................................................... 33

3 Käyttötilanteet ............................................................. 343.1 Käyttötilanteet testitapauksina............................................ 343.2 GDD:n käyttötilanteet .......................................................... 363.3 Käyttötilanteiden kerääminen haastatteluilla ...................... 38

4 Käyttöliittymän suunnittelu .......................................... 404.1 Erilaisia suunnitteluprosesseja ............................................ 414.2 GUIDe-malli ja GDD-suunnitteluprosessi ............................. 444.3 Käyttöliittymän piirtäminen GDD:llä .................................... 47

Suunnitteluperiaatteet .......................................................... 48Simulointi ............................................................................ 49Ongelmalistan käyttö ............................................................ 53Esimerkki 1: PDA-bussiaikataulut ........................................... 55Esimerkki 2: Kirjastohakujärjestelmä ...................................... 64

Lähteitä ........................................................................... 74

Sari A. Laakso (2015)

Simulointipohjainen käyttöliittymäsuunnittelu

1

Käyttöliittymänominaisuudet

Viimeistään ohjelmistonkäyttöönottovaiheessa järjestelmänavulla ryhdytään tekemään oikeitatyötehtäviä ja suorittamaantodellisia käyttötilanteita. Tällöinpuutteet ohjelmistonhyödyllisyydessä jakäytettävyydessä tulevatviimeistään esille.


Käyttötilanteet ohjelmistonkäyttöönottovaiheessa

Monesti ohjelmisto toteutetaan ja otetaan käyttöön ilmanminkäänlaista käyttötilanteiden suorittamiseen (todellisen työntekemiseen) perustuvaa arviointia tai testausta.Tällöin ohjelmiston käyttökelpoisuus tavallaan testataan vastakentällä, ja ongelmien korjaaminen on kallista.



2


Käyttötilanteet ohjelmistonkäyttöönottovaiheessaEsimerkkejä ongelmista:

Työtehtävien suorittaminen on vaivalloista ja aikaavievää.Kaikki työnkulut eivät edes ’mene läpi’, vaan osa vaiheista onsuoritettava kiertoteitse paperilla tai muilla ohjelmistoilla.

Järjestelmästä puuttuu toimintoja.Järjestelmästä puuttuu työtehtävissä tarvittavaa tietosisältöä, taitiedot on organisoitu käyttäjän työtehtävän kannalta väärin.

Käyttäjät eivät keksi, miten järjestelmää pitäisi käyttää.Käyttäjät tekevät turhaan virheitä, ja koulutukseen kuluu paljonresursseja.Järjestelmässä ylläpidetään toimintoja tai tietoja, joita kukaankäyttäjä ei oikeasti missään tilanteessa tarvitse.


Erityyppiset käliongelmatEsimerkki: Kuva-arkisto

Kuvatoimittaja täydentää Paavo Lipposesta kertovaa lehtijuttuasopivilla kuvilla.



3


Tehokkuus:1. Mekaaninen työ: Käyttäjä joutuu tekemään valtavastiturhia edestakaisia navigointitoimenpiteitä.2. Kognitiivinen työ: Käyttäjä joutuu pitämään mielessääntähän mennessä löytämiään hyviä vaihtoehtoja japoissuljettuja vaihtoehtoja sekä näiden sijainteja.

Sopivien kuvien valitsemisen monivaiheinen polku:

BackBack

Back


Opittavuus: Käyttäjä ei ymmärrä ohjelmantoimintalogiikkaa eikä keksi, mitä ohjelman toiminnottarkoittavat ja miten niitä käytetään.



4


Erityyppiset käliongelmatSekundääriset ongelmat

Käyttäjän tekemien virheiden korjaamisesta seuraava turhatyö on eri asia kuin ensisijaisiin tehokkuusongelmiin sisältyväturha työ (mekaaninen tai kognitiivinen). Virheen korjaamiseksivaadittu turha työ on seurausta toisesta ongelmasta, kun taasvarsinainen turha työ sisältyy sisäänrakennettuna vaatimuksenatehtävän suorittamiseen.Sekundääriset ongelmat johtuvat jostain toisesta ongelmasta:

Virheet johtuvat tyypillisesti tehokkuusongelmista (esim. turhakognitiivinen työ) tai opittavuus- tai muistettavuusongelmista.Muistettavuusongelmien takana on opittavuusongelmia.Käyttäjän tyytyväisyys syntyy osin kaikkien neljän osa-alueenpohjalta (tehokkuus, opittavuus, muistettavuus, virheet). Lisäksityytyväisyyteen vaikuttavat mm. visuaalinen ulkoasu ja ylipäätäänkäyttöliittymän esteettisyys. Näihin emme perehdy tällä kurssilla,mutta ne on tärkeää tiedostaa ja ottaa huomioon muilla tavoin.


Opittavuus: Käyttäjän on vaikea päätellä neljästäsamantapaisesta printteripainikkeesta, mistä tulostuisihänen tarvitsemansa iso kuva.Muistettavuus: Vaikkahän onnistuu löytämäänoikean painikkeen jaylittämään opittavuus-kynnyksen, seuraavallakinkerralla on vaikea muistaa(palauttaa mieleen), mikäoli oikea toiminto.

=>

Edellisten seurauksia:Em. opittavuus- jamuistettavuusongelmientakia käyttäjä helpostivalitsee väärän toiminnon(virhe) ja joutuupalaamaan takaisinyrittämään uudelleen(turhaa työtä).



5


Erityyppiset käliongelmatKulmakivet

Nielsenin esittämät neljä ensimmäistä käytettävyyden osa-aluetta (tehokkuus, opittavuus, muistettavuus, virheet)näyttävät palautuvan kahteen kulmakiveen:

Tehokkuus: mekaaninen ja kognitiivinen työOpittavuus

Muissa osa-alueissa näkyvät ilmiöt (virheet, muistettavuus, osinmiellyttävyys) ovat valtaosin seurausta näistä.Opittavuus- ja muistettavuusongelmien sekä virheiden määräsaadaan minimoitua optimoimalla tehokkuus.

Tehokas käyttöliittymä sisältää vain vähän opittavuuskynnyksiä(työvaiheita on vähän ja käyttäjä on koko ajan yhdessä paikassa).Käyttäjän on helppo korjata myös inhimillisten erehdystenseuraukset, koska kaikki näkyy koko ajan ja käyttäjä voi säätää ei-toivotut seuraukset samantien takaisin.


Puuttuva toiminnallisuus tai tietosisältö: Ohjelmastapuuttuu toimintoja tai tietoja, joita käyttäjä tarvitsisityönkulkunsa osaksi.

Yksittäisten kuvien poimimistoiminto(ns. ostoskori) puuttuu:

=>

Seurauksia:Käyttäjän on keksittäväkiertoteitä tehtävänsähoitamiseksi, esim.tulostettava valitsemiaankuvia paperille ja haettavamyöhemmin samoja kuviakuvanumeron avulla(turha työ). Työtä tuleevaltavasti ja riski virheillekasvaa.



6


1. Hyödyllisyys (utility): Voiko tehdä oikeaa asiaa?

Tehokkuus(efficiency)

Onko turhia vaiheita, onko turhaakognitiivista työtä

Opittavuus(learnability)

Keksiikö käyttäjä, mitä pitäisi tehdä jamitä tiedot tarkoittavat

Muistettavuus(memorability)

Onko selvää, kun on kerran keksinyt

Virhealttius(errors)

Houkuttaako käli virhetoimintoihin, jamiten käyttäjä selviytyy virheistä

Tyytyväisyys(satisfaction)

Kokeeko käyttäjä käytön miellyttävänä

Määritelmiä kirjallisuudestaKäytettävyyden osa-alueet (Nielsen)

[Nielsen93, s. 25;Nielsen03]

Jos oikean asian pystyy tekemään jotenkin:2. Käytettävyys (usability): Onko tekeminen sujuvaa?

Onko järjestelmässä sellaiset toiminnot ja tietosisältö (Nielsen: vain toiminnot),että työtehtävien tekeminen ’menee läpi’ – vaikka vaikeasti ja vaivalloisestikin?

Käyttökelpoisuus (usefulness)


Ero Nielsenin määritelmään:Tehokkuus sidottu työn määrään

Huomaa, että olemme aiemmin määritelleet tehokkuudenkäyttäjältä vaadittavan mekaanisen ja kognitiivisen työnmäärän avulla (vrt. usage patterns [Hornbæk 2006, s. 85]).Nielsen (ks. esim. [Nielsen 1993, s. 30-31]) sitoo tehokkuudentehtävän suorittamiseen kuluvaan aikaan, esim. kuinka montaminuuttia testikäyttäjältä kuluu käyttötilanteen suorittamiseen(vrt. task completion time [Hornbæk 2006, s. 84].Ensimmäinen perustuu käyttötilanteen suorittamisessavaadittujen resurssien analysoimiseen ilman testikäyttäjiä:tietynlainen käyttöliittymäratkaisu vaatii käyttäjältä tietyttoimenpiteet ja ’miettimistyön’, olipa käyttäjä millainentahansa. Jälkimmäinen perustuu testikäyttäjien avullasaatavaan mitattavaan aineistoon: paljonko aikaa käyttäjiltäoikeasti meni.



7


Määritelmiä kirjallisuudestaISO-standardi

Vastineetvapaastikäännetty;termit onyhdistettytällä kurssillakäytettyihinkäsitteisiin.

ISO 9241-11 –standardissa käytettävyys on määritelty laajemmin:

Usability = Extent to which a product can be used by specified usersto achieve specified goals (vrt. käyttötilanteet) with effectiveness,efficiency and satisfaction in a specified context of use.

Effectiveness: the accuracy and completeness with which specified userscan achieve specified goals in particular environmentsTuloksellisuus: kuinka täsmällisesti ja kattavasti käyttäjä pystyytekemään työnsä; onnistuuko eteen tulevien käyttötilanteidensuorittaminen kokonaan ja loppuun asti (vaikka olisi työlästä)

Efficiency: the resources expended in relation to the accuracy andcompleteness of goals achievedTehokkuus (kustannustehokkuus): kuinka paljon mekaanista jakognitiivista työtä käyttäjän on tehtävä tilanteen suorittamiseksi

Satisfaction: the comfort and acceptability of the work system to itsusers and other people affected by its useTyytyväisyys: kuinka miellyttävä ja mieluinen järjestelmä on käyttäjilleja niille ihmisille, joihin sen käyttäminen vaikuttaa


Simulointimenetelmien ideaKulmakivistä suunnittelumenetelmä

Tällä kurssilla opeteltava simulointitestaus jasimulointipohjainen suunnittelumenetelmä GDD perustuvattuloksellisuuden ja tehokkuuden (effectiveness, efficiency[ISO9241-11]) maksimointiin käyttötilanteita vasten (vrt.”specified goals”, [ISO9241-11]). Opittavuus huomioidaanvasta lopuksi. Tämä riittää tuottamaan hyvän käyttöliittymän.Käyttötilanteiden suorittamisessa tarvittavat toiminnot jatietosisältö (toiminnalliset vaatimukset jatietosisältövaatimukset) tulevat simuloinnin kuluessa esille”itsestään”, kun suunnittelija/arvioija hakee tilanteelle parastaloppuratkaisua ja pyrkii keskittymään tehokkuudenoptimointiin. Hän valitsee sellaisia toimintoja ja tietosisältöä,jotka tukevat käyttötilannetta mahdollisimman suoraviivaisesti.Tehokkuudella ja opittavuudella operoidaan siten, että…

ensiksi optimoidaan tehokkuus (mekaaninen ja kognitiivinen) javasta lopuksi korjaillaan opittavuutta, jos tarpeen.



8


Simulointimenetelmien ideaKohti objektiivisuutta

Riittävän optimaalinen käyttöliittymäratkaisu on mahdollistalöytää käyttötilanteita vasten varsin objektiivisesti. Kunkäyttötilanteet on valittu, niitä pystytään tukemaan paremmintai huonommin erilaisilla käyttöliittymäratkaisuilla.Käyttöliittymäratkaisun arviointi muuttuu epämääräiseksimielipidekysymykseksi heti, jos käyttötilanteet otetaan pois jakäyttöliittymiä tai sen osia yritetään tarkastella ilmankäyttötilanteiden simulointia.Simuloitaessa erilaisten mielipiteiden esitteleminen alkaamuuttua tarpeettomaksi ja korvautuu yhteiselläongelmanratkaisulla, kun simulointia seuraavat henkilötpyrkivät optimoimaan käsillä olevan tehtävän suorittamistakäyttöliittymän avulla.


Simulointimenetelmien ideaToimintojen ja tietosisällön rooli

Käytettävyyttä ei voida lisätä virheellisesti määritellyntietosisällön tai toiminnallisuuden päälle.Tietosisällön ja toiminnallisuuden määrittely on osakäyttöliittymäsuunnittelua, ja se sisältyy tällä kurssillakäsiteltäviin simulointimenetelmiin.



9


Tämän esimerkkijärjestelmän (asiaskasrekisteröinnin sovellus) kaikkitoiminnot suunniteltiin ilman käyttötilanteita. Osa toiminnoista saatiinvanhasta merkkipohjaisesta järjestelmästä.Aluksi laadittiin hierarkkisesti organisoitu toimintoluettelo, jonkapohjalta käyttöliittymä suunniteltiin. Eri hierarkiahaarojen toiminnotpäätyivät tyypillisesti omiin ikkunoihinsa.Tämän tuloksena yhden käyttötilanteen suoritus (työnkulku) kulkeemonen eri ikkunan kautta. Suorituspolku on pitkä ja monimutkainen =>sekä käyttöliittymän tehokkuus että opittavuus ovat huonoja.

Esimerkkijärjestelmä ja kuva: [Kolehmainen06]Antti Latva-Koivisto, Sari A. Laakso (2006)

Esimerkki tehokkuusongelmasta:Asiakasrekisteri


Tässä tarkastellaan yhdentyypillisen, yksinkertaisenkäyttötilanteensuorittamista em.sovelluksella.Kuvan tilanteessa käyttäjälisää uuden asiakkaanasiakasrekisteriin.Kuvaan on visualisoitutehtävän suorittamisessatarvittavat näytöt janäyttöjen välinennavigointitarve.

Asiakasrekisteri(jatkuu)

Esimerkkijärjestelmä ja kuva: [Kolehmainen06]

Antti Latva-Koivisto, Sari A. Laakso (2006)



10

Käyttöliittymän arviointiTestauksen tarkoituksena on löytäämahdollisimman paljon käyttöliittymänongelmakohtia tai esimerkiksi asettaa erilaisiakäyttöliittymäratkaisujaparemmuusjärjestykseen.Käytettävyystestaus on hyvin tunnettu,kirjallisuudessa kuvattu testausmenetelmä,jossa testikäyttäjät käyttävät arvioitavaajärjestelmää. Simulointitestaus onkehitteillä oleva menetelmä, jonka suorittaaasiantuntija, ilman testikäyttäjiä.Molemmissa menetelmissä testitapauksena onrealistisia käyttötilanteita (työtehtäviä), joitalähdetään suorittamaan.

SimulointitestausSimulointitestaus on kehitteillä olevakäyttöliittymän arviointimenetelmä, jokaon käytössä joissain yrityksissä (lisätietoja:Sari A. Laakso, [email protected]).

Menetelmässä on yhteisiä piirteitämuiden, käyttötilanteiden suorittamiseenperustuvien menetelmien kanssa.Menetelmä löytää tehokkuusongelmienlisäksi puuttuvaa tietosisältöä jatoiminnallisuutta. Kantavana ideana onpaikantaa päätöksenteossa tarvittavatieto ja minimoida turha työ(mekaaninen ja kognitiivinen työ).



11


Simulointitestauksen tekeminenYleiskuva menetelmästä

Lähtökohdaksi arvioija selvittää jonkin tosielämässä käyttäjälleeteen tulevan konkreettisen käyttötilanteen.Arvioija selvittää, mikä olisi valitussa käyttötilanteessakäyttäjälle paras loppuratkaisu riippumatta siitä, milläjärjestelmillä tilanne hoidetaan.Seuraavaksi arvioija selvittää, mikä on käyttöliittymän tarjoamaoikea polku parhaan loppuratkaisun saavuttamiseksi:

Mitkä mekaaniset toimenpiteet käyttäjän pitää tehdäMitkä kognitiiviset toimenpiteet käyttäjän pitää tehdä:

• mitkä näytöltä poimittavat tiedon palaset vaikuttavat hänenpäätöksentekoonsa,

• mitä tiedonkäsittelyä hänen on tehtävä päässään, esim. laskutoimituksia,vaihtoehtojen suhteuttamista toisiinsa ja päätösten tekemistä.

Arvioija laatii oikeasta suorituspolusta kuvasarjan.Arvioija poimii kuvasarjasta käyttöliittymänparannusehdotuksen tai raportoi ongelmakohdat.


Vaihe 1:Testitapausten selvittäminen

Lähtökohdaksi arvioija selvittää ne konkreettiset käyttötilanteet, joitakäyttäjän pitäisi pystyä järjestelmällä suorittamaan. Tähän käytetäänkäyttäjien työn havainnointia, kontekstuaalisia haastatteluja ja erillisiäkäyttäjähaastatteluja.Käyttötilanteet jäsennetään niin, että tilanteen lähtöasetelma,aktivoitumishetki, ongelman virittävä ristiriita ja erityisesti käyttäjäntietämys ja puuttuva tietämys tulevat selvästi esille.Simulointitestaukseen arvioija valitsee tarkasteltavaksi yhdenkäyttötilanteen kerrallaan.



12


Vaihe 2: Vaihtoehtojen jaloppuratkaisun selvittäminen

Arvioija selvittää, mitkä ovat käyttötilanteen päätöksentekovaiheessarelevantit vaihtoehdot, joiden välillä käyttäjän päätöksentekotapahtuu. Esimerkiksi baletin väliaikatarjoilutilanteessa arvioidaan,mitkä leivokset voisivat tulla kyseeseen valitun käyttäjän tilanteessa, taiPariisin matkaoppaan valintatilanteessa tutkitaan, mitkä kirjat sopisivattähän tarkoitukseen parhaiten. Arvioija valitsee vähintään kolme hyväävaihtoehtoa. Ei ole merkitystä, minkälaisen käyttäjän mieltymyksiinarvioija asettuu, mutta on tärkeää, että kyseessä on realistinen jariittävän tyypillinen asetelma.Arvioija selvittää (käyttöliittymästä riippumatta) käyttötilanteeseenmahdollisimman hyvän loppuratkaisun: mihin relevanteistavaihtoehdoista käyttäjän juuri tässä tilanteessa kannattaisi päätyä, joshän tietäisi kaiken sen, mikä tilanteessa on keskeistä tietää.Jos tilanteen suorittamiseen ei sisälly lainkaan päätöksentekoa, arvioijaselvittää pelkän loppuratkaisun. (Yleensä tällöin käyttötilanteensuorittaminen voidaan automatisoida eli käyttöliittymä voidaan tältäosin poistaa.)


Vaihe 2 (jatkuu)Loppuratkaisun selvittämisestä

Arvioijan on hankittava mahdollisimman kattavasti kaikki todelliseentarjontaan liittyvä tieto, jotta hän pystyy päättelemään, mikä olisikäsillä olevassa tilanteessa käyttäjälle paras (mahdollisimman hyvä)loppuratkaisu.Arvioijan tietämys on tässä eri asia kuin todellisen loppukäyttäjäntietämys realistisessa käyttötilanteessa.Järjestelmän avulla selville saatava paras ratkaisu voi olla eri kuintodellisuudessa paras loppuratkaisu. Menetelmässä haetaantodellisuudessa parasta (mahdollisimman hyvää)loppuratkaisua.Jos järjestelmän avulla selville saatava paras ratkaisu on huonompi kuinmuilla keinoilla löytyvä ratkaisu, se saattaa johtua esimerkiksikäyttöliittymän tietosisältöongelmasta: järjestelmässä ei ole sellaistatietosisältöä, jonka avulla käyttäjä voisi löytää tilanteeseensaparemman ratkaisun.



13


Vaihe 3:Oikean polun selvittäminen

Arvioija selvittää käyttötilannetta simuloimalla, mikä onkäyttöliittymän tarjoama mahdollisimman yksinkertainentoimenpidepolku relevanttien vaihtoehtojen vertailemiseksi jatilanteen suorittamiseksi loppuun:

Mitkä toimenpiteet käyttäjältä vaaditaan (mekaaninen työ)?Arvioija merkitsee tarvittavat toimenpiteet näyttökuviin.Missä kohdissa käyttäjän on poimittava tietoja näytöltä, vertailtavavaihtoehtoja mielessään ja tehtävä päätöksiä (kognitiivinen työ)?Arvioija merkitsee näyttökuviin, mitä tiedon palasia käyttäjähyödyntää päätöksenteossaan:

• Mitkä tiedon palaset vaikuttivat päätöstä tehdessä siihen, ettäkäyttäjä poimi tämän vaihtoehdon relevanttien joukkoon.

• Mitkä tiedon palaset vaikuttivat siihen, että käyttäjä päättisivuuttaa tämän vaihtoehdon.

• Kuinka käyttäjä hakee puuttuvan tietosisällön toisestajärjestelmästä.

HUOM. Arvioija ei itse toimi tässä testikäyttäjänä vaan asiantuntijana.


Vaihe 3 (jatkuu)Menetelmän olettama tietämys

Oikean polun suorittamisessa simuloidaan sellaista käyttäjää,jolla on

käyttöliittymän toimintalogiikasta epärealistisen täydellinentietämys (ei simuloida todellisen käyttäjän mahdollista realististaharhailua ja väärien toimintojen käynnistämistä),mutta käyttöliittymän tietosisällöstä realistinen tietämys(esimerkiksi käyttäjä ei voi etukäteen tietää, onko ravintolassa tilaahaluttuna iltana, tai käyttäjä tietää, että McDonald’s tarjoaahampurilaisia ja pikaruokaa).

Tarkoituksena on selvittää ensisijaisesti hyödyllisyys- jatehokkuusongelmia, ei opittavuusongelmia.

Vrt. esim. kognitiivinen läpikäynti, jossa oikeaa suorituspolkuatarkastellaan käyttäjän ensimmäisen käyttökerran näkökulmasta elikäyttäjä ei tunne käyttöliittymän toimintalogiikkaa lainkaanOpittavuusongelmia.Menetelmät olettavat eri ääripäät toimintalogiikan tuntemuksesta.



14


Vaihe 3 (jatkuu)Arvioijan vs. käyttäjän tietämys

Arvioijaselvittäätoimenpiteet,joillakäyttäjä saanämäselville.


Kun testataan käyttäjän päätöksentekoa sisältäviävertailutilanteita, arvioijan tulee simuloida riittävänkehittyneellä päätöksentekoprosessilla, jotta kognitiivisetongelmat (mm. mielessä pitämisen ongelmat) saadaan esiin:

Testisekvenssissä käyttäjän tulee osua vähintään kolmeenrelevanttiin vaihtoehtoon: käyttäjä punnitsee näitä keskenään jaarvioi, mikä olisi paras tässä tilanteessa.Käyttäjälle tulee eteen myös useita huonoja vaihtoehtoja, jotkahän jättää sivuun.

Jos arvioija testaa epärealistisen yksinkertaista päätöksentekoa(esim. käyttäjä menee Turkuun aamun ensimmäisellä junalla,oli se mikä tahansa) tai valitsee pelkästään helppojaerikoistapauksia (junia menee Kemijärvelle vain yksi päivässä),keskeiset ongelmakohdat eivät nouse esille testauksessa.

Vaihe 3 (jatkuu)Päätöksentekokohdan vertailu



15


Vaihe 3 (jatkuu)Simulointi loppuun asti

Simulointia ei pidä lopettaa vielätietokoneohjelman käytönpäättymiseen (esim. kun käyttäjä onsaanut varattua hotellihuoneen ja sulkeeohjelman), vaan......se tulee viedä loppuun ainatavoitteen saavuttamiseen asti(esim. kunnes käyttäjä on ajanut autollaperheineen hotelli Mesikämmeneen jamennyt huoneeseensa).Käyttötilanteen loppupään simulointi voipaljastaa yllättäviä ongelmakohtiakäyttöliittymästä. Esimerkiksi ajokartanavulla ei oikeasti löydäkään perille, taihotellihuone ei vastaakaan sitä, mitävarausjärjestelmä käyttäjälle lupasi.

Lähde: www.juvander.fi/yhteystiedot/Company_Location.pdf

Lähde: www.scandic-hotels.fi

Sari A. Laakso, Antti Latva-Koivisto (2006)


Vaihe 4:Kuvasarjan laatiminen

Simulointitestauksen sisältämistä vaiheista kootaan kuvasarja, jostanäkyy käyttäjän jokainen toimenpide. Kuvasarja auttaa arvioimaankäyttöliittymän ongelmakohtia, ja sen avulla on havainnollista esittääsimuloinnin tuloksia.Kuvasarjan ensimmäisenä kuvana on järjestelmän alkutila, jossakäyttäjä ei ole vielä tehnyt ensimmäistäkään toimenpidettä (esim.etusivu www.matkahuolto.fi).Jokaiseen kuvaan merkitään yksi käyttäjän toimenpide, joka ontyypillisesti hiirellä klikkaaminen (merk. nuolikursorin kuvalla) tai tiedonsyöttäminen näppäimistöltä (ympäröi syötteet). Lisäksi merkitäänpäätöksentekoon vaikuttavat tiedon palaset, jotka käyttäjä lukeenäytöltä.Toimenpiteen seuraus eli järjestelmän reaktio esitetään seuraavassakuvassa. Jos käyttäjä esim. täyttää peräkkäin monta syötekenttää,joihin ohjelma ei reagoi mitenkään, nämä toimenpiteet voidaan merkitäsamaan kuvaan. Aina, kun ohjelma reagoi käyttäjän toimenpiteeseenjotenkin, otetaan uusi näyttökuva.



16

Esimerkkikatkelma kuvasarjasta: www.matkahuolto.fiHuom. Alareunan tekstit ovat ohjeita, jotka eivät tule mukaan itse kuvasarjaan.

Alkutilakuvana on sellainen näyttökuva,jossa käyttäjä ei ole vielä tehnytensimmäistäkään toimenpidettä.(Alkutilakuvaan voit merkitä ensimmäisenhiiren painalluksen nuolikursorinkuvalla.)

Näyttö avautuu tämän näköisenä, kunkäyttäjä on tehnyt edellisen kuvantoimenpiteen eli painanut hiirelläAikataulut-linkkiä vasemmasta reunasta.Tähän kuvaan merkitään ympäröinnilläkentät, joihin käyttäjä seuraavaksisyöttää tietoja.


Tässä käyttäjä on syöttänyt ympyröityihinkenttiin ”helsinki” ja ”tampere” ja vaihtanutpäivämäärän. (Tähän kuvaan voit merkitämyös Hae-painikkeen, koska ohjelma eireagoi ennen sitä. Yhtä hyvin voit merkitäHae-painikkeen vasta seuraavaan kuvaan.)

Kun käyttäjä on edellisessä kuvassapainanut Hae-painiketta, näytölle ilmestyyyllä näkyvä punainen teksti ja paripudotusvalikkoa. Seuraavaksi käyttäjäpainaa uudelleen Hae-painiketta.

Esimerkkikatkelma kuvasarjasta (sivu 2/3)




17

Seuraavaksi käyttäjä vierittää sivuaalaspäin nähdäkseen ennen puoltapäivääperillä olevat bussit. Merkitse raahausnuolikursorilla ja katkoviivalla, jokakuvaa raahaamisen suuntaa ja pituutta.

Tässä käyttäjä vertailee eri busseja jayrittää päättää, millä bussilla hänenkannattaisi mennä. Merkitse tärkeimmätpäätöksentekoon vaikuttavat tiedotkuvaan punaisella katkoviivalla. Kirjoitaviereen tekstillä, mitä käyttäjä vertailee,minkä hän valitsee ja miksi. Merkitsevalittu bussi punaisella ympyröinnillä.

Käyttäjä vertaileebussien tuloaikojaja suhteuttaa niitälähtöaikoihin javaihtoihin. Hänvalitsee klo 10.40saapuvan bussin,koska se on perilläsopivaan aikaaneikä vaihtoa ole.

Esimerkkikatkelma kuvasarjasta (sivu 3/3)



Vaihe 4 (jatkuu)Vertailumerkinnöillä valintapäätökset

Vertailumerkintöjen tekeminen auttaa löytämään sellaisiakäyttöliittymän ongelmakohtia, jotka liittyvät käyttäjän mielessätapahtuvaan vaihtoehtojen vertailemiseen ja päätöksentekoon.Vertailumerkinnöillä ympäröidään päätöksenteossa vaikuttavatyksittäiset tiedon palaset eli ne kohteet (sanat, kuvat, taulukon solutjne.), joiden perusteella käyttäjä päättelee, että kyseinen vaihtoehto onhyvä tai huono. Älä ympäröi kaikkea dataa, jota käyttäjä voisi näytöltälukea tai katsoa, vaan ainoastaan ne tiedon palaset, jotka juuri tässäkäyttötilanteessa vaikuttavat valintapäätökseen.Puuttuvan tietosisällön voit simuloida haettavaksi toisestajärjestelmästä. Käytä ensisijaisesti arvioitavaa järjestelmää, mutta josjokin tilanteen suorittamisessa tarvittava tieto puuttuu sieltä kokonaan,sisällytä kuvasarjaan toisen järjestelmän käyttö, josta käyttäjä poimiitarvittavan tiedon, esimerkiksi kännykän kalenteri tai Google Maps.



18


Vaihe 4 (jatkuu)Käyttäjän toimenpiteetMerkitse käyttäjältä vaadittavat toimenpiteet näyttökuviin seuraavasti:


Vaihe 5:Testitulokset

Testitulokset voidaan poimia vertailumerkinnöillä varustetustakuvasarjasta. Menetelmän esille tuomista tuloksista voidaanpoimia käyttötarkoituksen mukaan…

1. tilanteen virittämä optimiratkaisu (ns. parannusehdotus) tai2. käyttöliittymän ongelmakohdat: puuttuvaan tietosisältöön tai

toiminnallisuuteen liittyvät ongelmat sekä tehokkuusongelmat.



19


5.1 Tuloksena optimiratkaisuSuoraan parannusehdotukseen

Optimaalisen käyttöliittymäratkaisun näet poimimallarelevanttien vaihtoehtojen välisessä vertailussa tarvitut tiedonpalaset, jotka arvioija kerää sekä arvioitavasta järjestelmästäettä muista ulkoisista järjestelmistä (puuttuva tietosisältö).

Tietosisältö: Ensiksi kaikki simulointisekvenssissä tarvitut tiedonpalaset organisoidaan samalle näytölle kerralla näkyviin.Toiminnot: Seuraavaksi muodostetaan yksinkertaisin mahdollinentoimenpidesekvenssi, jolla käyttäjä voi säätää em. tiedot esiinjärjestelmän alkutilasta käsin, samalla näytöllä.(Toimenpidesekvenssin logiikan on oltava aukoton. Järjestelmä eivoi maagisesti arvata, että käyttäjälle pitäisi näyttää juuri tämädata nyt.)

Optimiratkaisu muodostuu periaatteessa samalla tavalla kuinGDD-suunnittelumenetelmässä, ks. päätöksentekolähtöinensimulointi: ks. s. 49 alempi kalvo ja selitykset s. 50-51).Ratkaisu virittyy käyttötilanteesta ’itsestään’.


5.2 Tuloksena käliongelmiaEnsin läpimeno, sitten tehokkuus

Ensin katsotaan, meneekö käyttötilanteen suorittaminen läpi,eli onko järjestelmällä mahdollista selvittää parasloppuratkaisu:

Aukot tietosisällössäAukot toiminnoissa

Jos tilanteen suoritus menee läpi, arvioidaan käytettävyyttä:Tehokkuusongelmat eli käyttäjältä vaadittu tarpeeton työ

• Mekaaninen tehokkuus = turhat toimenpiteet• Kognitiivinen tehokkuus = turha miettimistyö ja mielessä pitäminen

(Opittavuutta ei arvioida tässä menetelmässä)



20


5.2 Tuloksena käliongelmiaAukot tietosisällössä ja toiminnoissa

Onko tavoite ylipäätään mahdollista saavuttaa järjestelmänavulla, vai puuttuuko tarvittavia tietoja tai toimintoja:

Tehtävän suorittamisessa tarvittavan tiedon esille kaivamiseentarvitaan ulkoista tietolähdettä, kuten toista ohjelmaa taipaperilähdettä, tai muuten suoritus ei etene (esim. Stockmanninmyymälän katuosoitteen selvittäminen Reittiopasta vartenGooglella; potilaan hoitotietojen etsiminen arkistomapista).Tehtävän suorittamisessa tarvitaan ulkoista apuvälinettä, kutenmuistiinpanopaperia tai itse tehtyä Excel-taulukkoa.Tavoitetta ei voida saavuttaa loppuun asti järjestelmän avulla, vaansuoritus katkeaa kesken kokonaan tai epäoptimaalisesta kohdasta(esim. hotellihuoneiden hinnat ja varaustilanteen voi selvittää,mutta huoneen varaaminen on tehtävä puhelimella tai menemälläpaikan päälle; ajo-ohjetta hotelliin ei ole lainkaan).Tehtävää ei voi tehdä ollenkaan, ei edes osittain.

Jo oikeaa polkua selvitettäessä (vaiheessa 3) ongelmatpuuttuvassa tietosisällössä tai toiminnallisuudessa tulevat ilmi:


5.2 Tuloksena käliongelmiaTehokkuusongelmat (mekaaninen työ)

Käytön tehokkuutta heikentävät turhat toimenpiteet,esimerkkejä:

Järjestelmä pakottaa käyttämään käsillä olevan tilanteen kannaltaturhia toimintoja tai pakottaa navigoimaan turhan mutkan (taiturhien välisivujen) kautta.Toimintoja on käynnisteltävä vuorotellen eri paikoista, mikäaiheuttaa edestakaisen navigoinnin kahden tai useamman näytönvälillä.Käyttäjän on syötettävä sama tieto tai valinta kahteen taiuseampaan kertaan eri paikkoihin taikka tehtävä samat säädötmonta kertaa, kun ohjelma unohtaa ne välillä.Käyttäjän on syötettävä sellainen tieto, jonka järjestelmä voisihakea automaattisesti toisesta järjestelmästä.




21


5.2 Tuloksena käliongelmiaTehokkuusongelmat (kognitiivinen työ)

Käytön tehokkuutta heikentävä turha kognitiivinen työ eli’miettimistyö’, esimerkkejä:

Käyttäjän on pideltävä mielessään vertailtavia vaihtoehtoja, koskavaihtoehdot on esitetty käyttöliittymässä eri paikoissa eikä niitä olemahdollista saada samanaikaisesti näkyville.Kun käyttäjä löytää itselleen sopivia vaihtoehtoja (esimerkiksisopivia hotellivaihtoehtoja Tukholmasta), hänen on yritettävä pitäälöytämänsä hyvät vaihtoehdot mielessään sen sijaan, että ohjelmamuistaisi ne.Käyttäjän on pideltävä mielessään eri vaihtoehtojen ominaisuuksia,jotka vaikuttavat hänen päätöksentekoonsa, esimerkiksi keväälläjärjestettävien seminaarien sisältöjä ja kokoontumisaikoja.Käyttäjän pitää laskea päässä jotakin sen perusteella, mitä näytöllänäkyy (esim. elokuvan päättymisajan laskeminen lisäämällä kestoalkamisaikaan tai ensi viikon torstain päivämäärän laskeminennäytöllä näkyvän tämän päivän päiväyksen perusteella).



5.2 Tuloksena käliongelmiaOpittavuusongelmat jätetään huomiotta

Simulointitestauksessa ei keskitytä opittavuusongelmiin. Nekyllä näkyvät polun simuloinnissa ’esteinä’, jotka arvioija voisihalutessaan poimia muistiin. Miksi näitä ei kerätä?

Ensisijainen syy: Valtaosa alkuperäisistä opittavuusongelmistayleensä häviää samalla, kun tehokkuusongelmat korjataan.Opittavuusongelmista ei ole juuri mitään apua paremman ratkaisunsuunnittelussa (jos käyttöliittymässä on myös tehokkuusongelmia).Simulointivaiheessa opittavuusongelmiin keskittyminen onarvioijalle helppoa, mutta se heikentää hänen kykyään paikantaakeskeiset tehokkuusongelmat. Arvioijan tarkkaavaisuus kohdistuutulosten kannalta hyödyttömiin pikkuseikkoihin, eivätkä keskeisetilmiöt nouse simuloinnin aikana esille.

Entäpä jos nimenomaan opittavuusongelmista tarvitaan tietoa?Opittavuusongelmien paikantamiseen on olemassasimulointitestausta luotettavampia menetelmiä, kuten kognitiivinenläpikäynti, käytettävyysläpikäynti ja käytettävyystestaus.



22


Millaisia opittavuusongelmat ovatNäitä arvioija ei poimi

Opittavuus = Mitkä toimenpiteet tai niiden seuraukset ovatvaikeita keksiä tai ymmärtää? Esimerkkejä:

Toimenpiteitä, joita on vaikea keksiä:• Kohde, johon liittyvät toimenpiteet eivät ole näkyvissä, esim.

kuva tai tekstinpätkä, josta ei voi tajuta, että sitä voisi klikata.• Toimintopainikkeen tai linkin harhaanjohtava otsikko, joka...

• ei vaikuta oikealta, vaikka todellisuudessa on se oikea, tai• vaikuttaa houkuttavalta, mutta johtaa väärään paikkaan.

• Käyttöliittymän komponentin sisältöä huonosti kuvaava otsikko:käyttäjä ei keksi, mitä esimerkiksi syötekenttään pitäisi kirjoittaaja missä muodossa.

Toimenpiteiden seurauksia, joita on vaikea ymmärtää:• Ohjelman antama vaikeaselkoinen palaute, josta käyttäjä ei

ymmärrä, mitä ohjelma teki, esimerkiksi lähtikö viesti nyt vai ei.• Huono virheilmoitus, josta käyttäjä ei ymmärrä, mitä tapahtui

tai mikä on ongelmana tai miten ongelmaa pääsee korjaamaan.


Muita simulointipohjaisiaasiantuntija-arviomenetelmiä

Kognitiivisella läpikäynnillä (cognitive walkthrough; ks.esim. [Lewis97]) arvioidaan ensisijaisesti jokaisentoimenpideaskelen opittavuutta: keksiikö käyttäjä, mikätoimenpide seuraavaksi pitäisi tehdä. Arvioija simuloi käyttäjäntoimenpiteitä vaihe vaiheelta ja vastaa jokaisen toimenpiteenyhteydessä neljään apukysymykseen.Myös heuristisessa läpikäynnissä (heuristic walkthrough)[Sears97] arvioija tarkastelee käyttäjän toimenpidesekvenssiä,mutta neljän apukysymyksen lisäksi hän etsii ongelmiakäyttämällä Nielsenin tarkistuslistaa [Nielsen94].




23

Käytettävyystestaus

Käytettävyystestissä (usability test)testikäyttäjille annetaan oikeitatyötehtäviä, joista he yrittävätsuoriutua järjestelmän avulla. Näinsaadaan selville ensisijaisestikäytettävyysongelmia.Kirjallisuutta käytettävyystestauksesta:[Nielsen93, luku 6], [Rubin94],[Lauesen05, luvut 1.4 ja 13]

Kuva:Käytettävyystestausta Helsingin yliopistontietojenkäsittelytieteen laitoksen Käyttöliittymät-kurssilla keväällä 1999.


KäytettävyystestausMenetelmä

Käytettävyystestissä jäljitellään todellista työntekotilannetta:testikäyttäjä etsii sopivaa suoritustapaa, jolla hän saisitestitehtävässä kuvatun tilanteen hoidettua.

Testikäyttäjät valitaan järjestelmän todellisesta kohderyhmästä.Testin ohjaaja antaa testikäyttäjälle oikeita käyttötilanteitavastaavia testitehtäviä.Testikäyttäjä suorittaa tehtäviä itsenäisesti parhaaksi katsomallaantavalla ilman testin ohjaajan apua.

Testin ohjaaja tai joku toinen testiä seuraava henkilö tekeehavaintoja käyttäjän toimenpiteistä ja ajatuksista sekä tulkitseeniistä käyttöliittymän ongelmakohtia.




24


TestitehtävätTehtävät todellisia käyttötilanteita

Käytettävyystestin testitehtävät vastaavat simulointitestauksentestitapauksia, vaikka ne kirjoitetaankin hieman erilaiseenmuotoon.Testitehtävät ovat realistisia käyttötilanteita, joita järjestelmänoikeille käyttäjille tulee eteen heidän työssään [Rubin94, s.179].Käyttäjälle annetaan testitehtävässä vain tavoite (lähtötilanne).Tehtävänkuvauksessa ei pidä antaa minkäänlaisia vihjeitätoiminnoista, joiden avulla tehtävää suoritetaan [Rubin94, s.180].



TestitehtävätTehtävien valinta ja muu aineisto

Testitehtävien tulisi koostua käyttäjien yleisimmistä tavoitteistaja käyttötilanteista [Rubin94, s. 102].Testi kannattaa aloittaa lyhyellä ja suoraviivaisella tehtävällä,jotta käyttäjä kokee saavansa jotain tehdyksi ja pääsee hyvinalkuun [Nielsen93, s. 186]. Monivaiheiset ja hankalat tehtävätkannattaa sijoittaa testin loppuosaan, jotta niitä on mahdollistapudottaa pois, jos aika ei riitä.Testitehtävien yhteydessä tulee käyttää todellisuutta vastaavaaaineistoa (dokumentteja, taulukkoja ym.). Epärealistisenyksinkertaisella aineistolla tehty testi ei paljasta kaikkiaongelmia, joita esimerkiksi hyvin laajan aineiston käsittelyssävoi olla.




25


TestitehtävätEsim: VR:n junalippuautomaatti 1/2

Olet pääsiäislomaa edeltävänäperjantaina Helsinginrautatieasemalla. Ensikeskiviikkona aiot lähteäpääsiäisen viettoon vanhempiesiluokse Pieksämäelle viimeisenluentosi jälkeen, joka päättyyklo 16 keskustassaPorthaniassa. Ajattelit hankkiaitsellesi junalipun pääsiäistävarten jo nyt, koska tiedätjunien olevan silloin useintäynnä.

Selvitä, mihin aikaanPieksämäelle menee juniapääsiäislomien aikoihin. Selvitämyös hinnat sekäopiskelijalipuista ettänormaalihintaisista aikuisten jalasten lipuista. Hanki lopuksilippu johonkin haluamaasijunaan.

Selvitä, montako junaa meneearkisin Helsingistä Pieksämäelle.Kuinka monta niistä onInterCity-junia?

Hyödyllinen tehtävä: Ongelmallisia tehtäviä:



TestitehtävätEsim: VR:n junalippuautomaatti 2/2

Asut Riihimäellä, mutta olet olluttänään käymässä Helsingissä.Tapasit kavereitasi ja kävitteostoksilla. Nyt kello on 18.45,kun saavut väsyneenä Helsinginrautatieasemalle. Tiedät, ettäjunia Riihimäelle menee tosiusein, ja ajattelit mennä kotiinseuraavalla sopivalla junalla.Hanki itsellesi junalippu.

Osta junalippu tänään klo19.04 Helsingistä Riihimäellelähtevään junaan.

Osta opiskelijalippuensimmäiseen klo 18.45jälkeen Helsingistä Riihimäellelähtevään junaan.

Selvitä, mikä on nopein junaHelsingistä Riihimäelle arkisinma-pe. Mitkä ovat lippuhinnatnopeimpaan junaan?

Hyödyllinen tehtävä: Ongelmallisia tehtäviä:




26


TestikäyttäjätKäyttäjät oikeasta kohderyhmästä

Testikäyttäjät on tärkeää valita testattavan tuotteen todellisestakohderyhmästä ([Rubin94, s. 119], [Nielsen93, s. 169]).Väärän kohderyhmän käyttäjillä testaaminen voi johtaa siihen,ettei todellisen käytön kannalta keskeisimpiä ongelmia saadaselville.

Softan kehittäjän 25-vuotias nörttikaveri voi nauttien selviytyäkäsittämättömästä toimintoviidakosta, jossa “luodaan hierarkkisiaprofiileja” ja “säädetään IMAP-asetuksia”, mutta tuotteenensisijaiseen kohderyhmään kuuluva käyttäjä ei välttämättä onnistulukemaan sähköpostejaan ollenkaan.Kohderyhmään kuulumattomalta testikäyttäjältä voi puuttua työntekemiseen tarvittavia tietoja ja taitoja. Esimerkiksi kuva-arkistonkäytettävyystesteihin tarvitaan testikäyttäjiksi kuvatoimittajia, jotkatietävät, millä perusteilla kuvia todellisessa työssä lehteen valitaan.



TestikäyttäjätKäyttäjien lukumäärä

Lähde: [Nielsen00]

Jos testaat yhtäkäyttöliittymää, 3-5käyttäjää on yleensäriittävä määrä.

Mitä useammallakäyttäjällä testaat, sitäuseammin samatongelmat toistuvat.Testaukseen käytetytlisäresurssit tuovat enäävain vähän lisää hyötyä.




27


Muut testivalmistelutTestitila ja pilottitesti

Erillistä käytettävyyslaboratoriota ei tarvita, vaan testi voidaanjärjestää esim. tavallisessa työhuoneessa [Nielsen93, s. 200].Testihuone lavastetaan oleellisilta osin todellistakäyttöympäristöä vastaavaksi. Esimerkiksi matkatoimistossakäytettävän järjestelmän testauksessa voisi olla hyödyllistälavastaa jotakin seuraavanlaista:

asiakaspalvelutiski ja asiakkaiden käyntejä,puhelin ja asiakkaiden puhelinsoittoja jamatkatoimistossa käytettäviä paperiesitteitä ja muuta materiaalia.

Ennen varsinaisia testejä kannattaa järjestää ns. pilottitesti eliharjoittelutesti, jonka tuloksia ei oteta huomioon varsinaisissatestituloksissa. Pilottitestin tarkoituksena on harjoitella testinläpivientiä ja korjata jäljellä olevat ongelmat testitehtävistä,testin ohjauksesta ja testattavan prototyypin toiminnasta[Nielsen93, s. 174-175].



Testitilanteen ohjaaminenEnnen testin aloittamista

Yritä saada testin alku rennoksi ja luontevaksi. Käyttäjät ovatusein hermostuneita aloittaessaan testin, kun he eivät tiedä,mitä tuleman pitää. Usein he kokevat myös valtaviasuorituspaineita, joita tarkkailun kohteena oleminen vielä lisääentisestään [Nielsen93, s. 181].Kerro testikäyttäjälle ennen testin aloittamista seuraavattoimintaperiaatteet [Nielsen93, s. 188; Rubin94, s. 148-149]:

Emme testaa sinua, vaan tätä ohjelmaa. Tarkoituksena on löytääohjelmasta niin paljon ongelmia kuin mahdollista.Jos haluat, voit lopettaa testin milloin tahansa.Jos testi videokuvataan: Emme ole kuvaamassa sinua, vaan kameraon sitä varten, jotta muistaisimme jälkeenpäin testitilanteessa esilletulleet asiat.Pyytäisin ajattelemaan ääneen, mitä olet tekemässä [Nielsen93,s. 195].




28


Testitilanteen ohjaaminenTestitilanteen alussa

Kerro käyttäjälle lyhyesti, millaisesta ohjelmasta testissä onkyse, ja kuvaile testitehtävien taustatilanne lyhyesti:

Järjestelmän tarkoitus noin yhdellä lauseella, esim. “Tällä ohjelmallakäsitellään kodinkoneliikkeeseen tulevia asiakasvalituksia.”Kuka käyttäjä on ja missä hän kuvitellusti on, esim. “Olet juuritullut ensimmäisenä työpäivänäsi kodinkoneliikkeen valitustiskilletöihin. Jotkut asiakkaasi tulevat tähän tiskille esittämäänvalituksensa ja osa soittaa sinulle puhelimella.”Jos testiympäristöön kuuluu esim. puhelin, kerro siitä käyttäjälleennen testin alkua, esim. “Tuo puhelin on tässä testissä omatyöpuhelimesi. Jos se soi, voit vastata siihen omalla nimelläsi.”

Tarkoituksena on saada käyttäjän sovellusalueeseen jatestiasetelmaan (mutta ei itse käyttöliittymään!) liittyvätietämys todellista tilannetta vastaavaksi.Järjestelmän toimintaa ei pidä esitellä käyttäjälle etukäteen, joskäyttäjä ei tositilanteessakaan saisi koulutusta ennen käyttöä.


Testitilanteen ohjaaminenTestitehtävien antaminen käyttäjälle

Anna testitehtävät käyttäjälle yksi kerrallaan.Kuvaile testitehtävän sisältämä esimerkkitilanne käyttäjällesuullisesti vapaamuotoisesti.Yleensä testitehtävä kannattaa antaa käyttäjälle myöspaperilapulla [Nielsen93, s. 186], jottei hänen tarvitsisi pitäämielessään tehtävässä annettuja tietoja.Siirry tehtävästä toiseen huomaamattomasti kuvailemalla uuttatilannetta. Älä kommentoi käyttäjän suoriutumista tehtävästä[Nielsen93, s. 190], koska käyttäjän kykyjä ei olla nyttestaamassa.




29


Testitilanteen ohjaaminenUlkopuoliset tarkkailijat

Testitilassa voi olla testikäyttäjän ja testin ohjaajan lisäksimuita henkilöitä (esim. 1-2 henkilöä tarkkailemassa taitekemässä muistiinpanoja), mutta he eivät saa häiritä testiä taiosallistua testin kulkuun [Nielsen93, s. 190].Yleensä ulkopuolisten tarkkailijoiden on parempi seurata testiätestihuoneen ulkopuolella esim. TV-ruudulta tai yksisuuntaisenpeilin läpi (jos testi järjestetään käytettävyyslaboratoriossa).



Testitilanteen ohjaaminenNeuvomisen välttäminen

Älä neuvo tai auta käyttäjää tehtävän tekemisessä äläkä annaminkäänlaisia vihjeitä tehtävän suorittamisesta [Nielsen93, s.183; Rubin94, s. 216, 222].

Jos käyttäjä esimerkiksi keksii uusia tai yllättäviätoimintatapoja, anna hänen tehdä toimenpiteet itse loppuun asti.

• Älä ‘vedätä’ tai johdattele ennalta suunniteltuun suoritustapaan.• Älä näytä yllättyneeltä tai ala hämmästellä tilannetta, vaikka

käyttäjä tekisi jotain täysin odottamatonta [Rubin94, s. 220].Jos käyttäjä kysyy sinulta suoraan ohjelman toiminnasta, esim.”Tulostaako tämä, jos painan nyt tästä?”, esitä vastakysymys[Nielsen93, s. 196], esimerkiksi ”Mitä arvelisit? Miltä se sinustavaikuttaa? Voit kokeilla vapaasti kaikkea.”

Testin ohjaajalla on monesti suuri houkutus käyttäjänneuvomiseen testin aikana, mutta neuvominen pilaa helpostitestin tulokset (vrt. [Nielsen93, s. 183]).




30


TestituloksetOngelmien havainnointi

Käyttöliittymäongelmia löytyy hyvin, kun testaaja lähtee siitäoletuksesta, että testikäyttäjä toimii aina järkevästi. Kaikkitestin aikana havaitut käyttäjän virheet ja ongelmat tehtävissäjohtuvat lähtökohtaisesti käyttöliittymän ongelmista japuutteista, eivätkä käyttäjästä. Tavoitteena on löytäätuotteesta syy käyttäjän kohtaamille ongelmille [Rubin94, s.276].Käyttäjän kohtaamien ongelmien syitä eli käyttöliittymän vikojavoidaan päätellä

käyttäjän tekemistä toimenpiteistä,käyttäjän reaktioista jaääneenajattelusta [Nielsen93, s. 195].



TestituloksetToimenpiteiden taltioiminen 1/2

Yritä saada toimenpiteet talteen tekemällä heti testin aikana käsinmuistiinpanoja.

Käyttösekvenssin voi kirjoittaa muistiin yksinkin, mutta sitä on kuormittavaatehdä testin ohjaamisen ohella.Monesti on käytännöllistä pyytää työkaveria avuksi ohjaamaan testiä taitekemään muistiinpanoja. Hyvien muistiinpanojen tekeminen on vaativampaakuin testin ohjaus.Videokamera on hyvä lähinnä varajärjestelynä: videonauhalta voitjälkeenpäin tarkistaa käyttäjän tekemisiä tai puheita, jos et ehtinyt nähdä,mitä käyttäjä teki jossakin tärkeässä kohdassa.

Merkitse muistiin ensisijaisesti se, mitä käyttäjä oikeasti teki (todellisettapahtumat). Testin aikana tehdyt tulkinnat voivat osoittautuamyöhemmin virheellisiksi tai hyödyttömiksi. Jos alkuperäistätapahtumadataa ei ole tallessa, tulkintoja ei voida myöhemmin muuttaavastaamaan testissä ilmennyttä uutta dataa.Vrt. Lauesenin esimerkki käytettävyystestin muistiinpanoista[Lauesen05, s. 440].




31


TestituloksetToimenpiteiden taltioiminen 2/2


Esimerkki YTV:n Reittioppaan käytettävyystestin muistiinpanoista:Ote käyttösekvenssistä ja käyttäjän ääneenajattelusta:…Käyttäjä painoi Hae. Avasi Mistä-pudotuslistan, jossa annettu kaksi eriUnikkotietä. “Ahaa, kaks Unikkotietä, Hesassa ja Vantaalla. Mä vaihdantuoksi Vantaan Unikkotieksi.” Valitsi Vantaan Unikkotien, klikkasiVaihda, järjestelmä tyhjensi kentän. “Mitä ihmettä, mitä nyt tapahtu?”Kirjoittaa uudelleen Unikkotie 6, painaa Hae, valitsee VantaanUnikkotien, klikkaa Hae.


TestituloksetOngelmien jäsentäminen 1/2

Ongelma 1: <Kuvaava otsikko>

Mitä käyttäjä pyrki saamaan aikaan (tavoite/alitavoite)?

Mitä käyttäjä teki (toimenpiteet) ja mitä hän sanoi (ääneenajattelu)?

Mitä käyttäjän olisi pitänyt tehdä?

Mikä ongelma tästä seurasi käyttäjälle?

Ongelman syy käyttöliittymässä?

Käyttöliittymän ongelmakohdat nimetään kuvaavasti, jaongelmat perustellaan käyttäjän toimenpiteistä jaääneenajattelusta tehdyillä havainnoilla.Esimerkki jäsentelystä:



32


TestituloksetOngelmien jäsentäminen 2/2

Mitä käyttäjä pyrki saamaan aikaan (tavoite/alitavoite)? Esim. käyttäjä yritti selvittää, miltäNesteen asemilta ylipäätään saa ruokaa.

Mitä käyttäjä teki (toimenpiteet) ja mitä hän sanoi (ääneenajattelu)? Käyttäjä valitsiyläreunan päävalikosta Neste 24 h –linkin ja sanoi: ”Täällä on varmaan kaikki palvelut.” Mutisityytymättömänä: ”Pitääkö tännekin rekisteröityä.” Jatkoi valitsemalla Rekisteröidy tästä.

Mitä käyttäjän olisi pitänyt tehdä? Hänen olisi pitänyt valita oikeasta reunasta Karttapalvelutai Neste Oil -asemahaku taikka lähteä liikkeelle yläreunan päävalikostavalitsemalla Neste Oil -asemaverkosto.

Mikä ongelma tästä seurasi käyttäjälle? Hän yritti pitkään (yli 10 minuuttia) selvittää, mitenhän saisi käyttäjätunnuksen Nesteen sivustolle, eikä saanut mitään tietoa ruokaa tarjoavistahuoltoasemista. Hän unohti alkuperäisen tavoitteensa ja ryhtyi selvittämään rekisteröitymistä.

Ongelman syy käyttöliittymässä? Neste 24 h -linkin otsikko vaikutti kuvaavammaltaasemien ruokailupalvelujen selvittämiseen kuin mikään linkeistä Karttapalvelut, Neste Oil –asemahaku tai Neste Oil -asemaverkosto . <- HUOMAA: Kun arvioit ongelman syytäkäyttöliittymässä, älä lähde siitä, että ohjeita puuttuu tai että käyttöliittymään pitäisi lisätäohjetekstejä. Yritä löytää ongelman varsinainen syy (tai syitä).

Ongelma 1:Käyttäjä etsi ruokapaikkoja Neste 24 h –linkin rekisteröitymisen takaa.


TestituloksetTestissä näkyviä oireita ongelmista

Mahdollisia oireita käyttöliittymän ongelmista:Käyttäjä ei onnistu tekemään testitehtävää.Käyttäjä luulee tehneensä tehtävän kokonaan, muttatodellisuudessa suoritus on keskeneräinen tai lopputulos on väärä.Käyttäjä tekee suorituksessa virheen, kuten syöttää dataa vääräänkenttään [Rubin94, s. 276], esim. etunimen sukunimikenttään, taihävittää erehdyksessä aiemmin luomaansa dataa, esim. unohtaatallentaa tiedoston.Käyttäjä tekee epäoptimaalisia toimenpiteitä, jotka poikkeavatodotetusta oikeasta suoritustavasta [vrt. Rubin94, s. 276].Käyttäjä käynnistää turhaan väärän toiminnon, avaa vääränikkunan tai menee väärälle sivulle, mutta huomaa virheensä samantien ja korjaa sen (esim. sulkee ikkunan, painaa Back).Käyttäjä epäröi pitkään jossakin vaiheessa tehtävän suoritusta,mutta suorittaa lopulta tehtävän oikein. (Pitkän epäröinnin aikanakäyttäjää kannattaa muistuttaa ääneenajattelusta.)Käyttäjä valittaa ääneen jostakin ongelmasta.




33


TestituloksetOngelmien vakavuuden arviointi1. Puuttuva toiminnallisuus: Käyttöliittymällä ei pysty suorittamaan

testitehtävää. Esim: Käyttäjä yritti tulostaa alennuskoodit tehdäkseenniihin omia merkintöjään, mutta järjestelmästä ei voi tulostaa koodeja.

2. Epäonnistunut tehtävän suoritus: Testikäyttäjä ei pystynytsuorittamaan tehtävää itsenäisesti tai luuli (virheellisesti) tehneensätehtävän jo. Esim: Käyttäjä luuli tehneensä tehtävän ja tuloksen olevantallessa, mutta hänen olisi pitänyt vielä painaa Update-painiketta.

3. Selvästi häiritsevä ongelma: Käyttäjä ei osannut toimiaoptimaalisella tavalla tai hän valitti suullisesti järjestelmän olevanhankala tai kömpelö. Esim: Käyttäjä sanoi, että on täysin älytöntäkulkea kuuden näytön läpi, jotta saisi täytettyä kymmenen kenttää.

4. Melko häiritsevä ongelma: Käyttäjä sai tehtävän suoritettuapitkällisten yritysten jälkeen. Esim: Käyttäjä yritti haun käynnistämistämonella eri tavalla ennen kuin keksi näytöltä opasteen ja painoi F10.

5. Vähäinen ongelma: Käyttäjä löysi ratkaisun muutaman lyhyenyrityksen jälkeen. Esim: Käyttäjä yritti käynnistää haun ensin enterillä,mutta huomasi sitten painaa F10-näppäintä.

Antti Latva-Koivisto (2006)[Lauesen05, s. 12-13]


Kustannustehokas testausVideoidut käytettävyystestit suurilla käyttäjämäärillä ovatkalliita ja vievät paljon aikaa. Muu projekti voi ehtiä edetä jopitkälle, kun testejä vasta analysoidaan.Monesti yhden laajan testin sijaan kannattaa kerätä nopeastitietoa pahimmista ongelmista järjestämällä monta kevyttä jaedullista testiä. Testien välillä korjataan pahimmat ongelmat.

Järjestä testejä esim. tavallisessa työhuoneessa tai neukkarissa.Valitse 3-4 todellista käyttäjää, mutta älä koodaaja-työkavereita.Laadi testitehtäviksi aitoja tilannekuvauksia.Tee ongelmakohdista muistiinpanot testin kuluessa, ja puramuistiinpanot heti testin jälkeen. Voit hoitaa testit yksinkin, muttajos mahdollista, pyydä työkaveria avuksi joko muistiinpanojentekijäksi tai testin ohjaajaksi.




34

KäyttötilanteetKäyttötilanteita tarvitaan sekätestitapauksiksi että käyttöliittymänsuunnittelun syötteeksi.Testitapauksena oleva käyttötilannekuvaa käyttötilanteenlähtöasetelman ja motiivit mutta eivielä järjestelmän käyttöä (mitäkäyttäjä tekee ja miten järjestelmäreagoi), koska juuri tätä on tarkoitusryhtyä testaamaan. Käyttötilannevirittää aina jonkin ongelman, jonkaratkaisemisessa tietojärjestelmän ontarkoitus auttaa.


Hyvä testitapaus on riippumaton testattavastajärjestelmästä: testitapauksessa ei kuvata vielä järjestelmänkäyttöön liittyviä tehtäviä tai toimenpiteitä, vaan käyttöäedeltävää tilanneasetelmaa.Seuraavassa esimerkissä testitapaukseksi on valittu todellinentilanne, jossa Marko oli menossa kummipoikansasyntymäpäiville Turkuun ja yritti selvittää, miten pääsisi sinne.

Käyttötilanne: Kummipojan syntymäpäiville TurkuunMarko, 27-vuotias ravintolakokki, on maanantai-iltana kotonaanHelsingin Kalliossa osoitteessa Kolmas linja 23. Hän on menossa ensilauantaina 4-vuotiaan kummipoikansa syntymäpäiväjuhliin Turkuun.Juhlat alkavat klo 14 kummipojan kotona Rauhankadulla, joka sijaitseeTurun keskustassa rautatie- ja linja-autoaseman lähellä.

Testataan nyt käyttöä simuloimalla, miten hyvin Matkahuollonja VR:n sivustot tukevat Markon tilannetta.

Käyttötilanteet testitapauksinaEsimerkki: Matkahuolto ja VR




35

VRMatkahuolto

VR:n ja Matkahuollon sivustojen simulointitestausSivusiirtymät menomatkan aikataulujen selviämiseen asti

1

2

31



Käyttötilanteet testitapauksinaLähtötilanne, ei järjestelmän käyttöä

Lähtötilanne pysyy samana, vaikka tehtävän suoritustapaa jakäyttöliittymää muutetaan (vrt. brief scenario, [Hackos98, s. 324]).Käyttötilanne…

kuvailee tilanteen, joka käyttäjien pitää pystyä hoitamaankäyttöliittymän avulla, muttaei kuvaa sitä, miten käyttäjät tekevät tämän tehtävän nykyiselläkäyttöliittymällä (mitä toimintoja käynnistävät, mitä tietoja katsovatkäyttöliittymästä, missä järjestyksessä jne.).




36


Käyttötilanteet testitapauksinaLähtötilanne, ei järjestelmän käyttöä

Testitapauksen sisältämä lähtötilannekuvaus on syötetestaukselle.Vasta testauksen aikana selvitetään, miten käyttäjä pääseetavoitteeseensa käyttöliittymän avulla. Käytön kuvaus onsiis testauksen tuotos.

Lähtötilanne:Petteri on yliopiston päärakennuksessa viimeistelemässäkonferenssipaperiaan kahden työkaverinsa kanssa. On jo ilta klo 21.15, jakaikilla alkaa olla hirveä nälkä. Kirjoittaminen on vielä ihan kesken, ja senkanssa näyttää menevän myöhään. Kellään ei ole mukana mitäänsyötävää.Ei järjestelmän käyttöä:Petteri avaa hampurilaisravintolan tilauspalvelun ja valitsee 6megaburgeria ja kolmet isot ranskalaiset. Sitten hän syöttää osoitteen japainaa tilauspainiketta. Näytön alareunaan ilmestyy viesti: ”Tilauslähetetty, saapuu puolen tunnin kuluttua.”



GDD:n käyttötilanteetEi päätöksiä ja kiinnitettyjä ratkaisuja

Lähtötilanne, jonka seassa on käyttäjän tekemiä päätöksiä jakiinnitettyjä ratkaisuja (alleviivattu):Helsinkiläinen kardiologi Terhi on menossa kuuntelemaan ensi viikontorstaina Turussa klo 12 alkavaa Urheilijan sydän –seminaaria. Hän onkatsonut Matkahuollon verkkopalvelusta bussien aikatauluja ja ostanutliput. Koska seminaari alkaa klo 12, hän valitsi tarpeeksi varhaisen bussin,joka lähtee Helsingistä jo klo 8. Seminaarin viimeinen esitys pidetään klo17.15-17.45, joten hän päätyi klo 18.30 lähtevään bussiin. Lopuksi häntilasi ostamansa liput sähköpostiinsa ja tulosti ne myös paperillevarmuuden vuoksi. Hän tietää, että seminaaripaikka on keskustassaosoitteessa Brahenkatu 10 noin viiden minuutin kävelymatkan päässä linja-autoasemasta.

Miten korjataan:Siirrä tilanteen aktivoitumishetki niin varhaiseksi, ettei käyttäjä ole

vielä tehnyt päätöksentekoon tähtääviä toimenpiteitä (esim. ”on katsonutbussien aikatauluja”, ”valinnut klo 6.42 lähtevän bussin”).

Poista kiinnitetyt ratkaisut (esim. lippujen tilaaminen sähköpostiin).



37


GDD:n käyttötilanteetKäyttäjän tavoite (motiivi)

GDD:n vaatimaan käyttötilannekuvaukseen sisältyy käyttäjäntavoite (motiivi): mitä hän on yrittämässä tehdä ja miksi?

Testauksen kannalta ei ole juurikaan merkitystä, mikä motiivitilanteessa on, kunhan se on realistinen ja riittävän tyypillinen.Jos motiivi puuttuu, testaaja ei pysty ottamaan huomioontilanteeseen tyypillisesti vaikuttavia tekijöitä. Tästä seuraa, etteitestauksella saada esiin kaikkia keskeisiä, todellisessa tilanteessaeteen tulevia ongelmia. Esimerkki:

Käyttötilanne: Ensi viikon torstaina TurkuunHelsinkiläinen kardiologi Terhi on menossa ensi viikon torstainaTurkuun. Perillä pitää olla klo 12, ja paluu on klo 18.


Puuttuvan motiivin takia aikatauluhaun testauksesta menisiongelmitta läpi huono käyttöliittymäratkaisu, joka näyttäisi kerrallavain ensimmäisen paluubussin (esim. klo 18 lähtevän), vaikkamonissa todellisissa tilanteissa Terhin kannattaisikin valitamyöhemmin (esim. klo 18.30 tai klo 19) lähtevä bussi.


GDD:n käyttötilanteet”Käyttäjä haluaa” -ongelma

Testitapausta laatiessa kannattaavälttää ylimalkaista ilmausta”Käyttäjä haluaa/haluaisi/tahtoo”,koska tällöin testitapauksen motiivijää epäselväksi eivätkä kaikkitodellisen tilanteen ongelmat tuleesille (vrt. edellinen kalvosivu).Koska testitapauksesta ei selviä,mihin haluaminen perustuu, osa”haluamisesta” voi ollaepärealistista tai koko testitapausvoi osoittautua virheelliseksi tai niinepätyypilliseksi, ettei sillä kannatatestata.Haluamisen takana olevaninformaation saat esille yleensäkysymällä ”miksi”.

Ei käyttäjän haluamista:Helsinkiläinen kardiologi Terhi onmenossa ensi viikon torstainaTurkuun. Hän haluaa olla perilläklo 12 ja haluaa lähteä takaisinklo 18.

Kuvaa tilannetta ja syitähaluamisen takana:Helsinkiläinen kardiologi Terhi onmenossa ensi viikon torstainakuuntelemaan Turussa klo 12alkavaa Urheilijan sydän –seminaaria, joka alkaaliikuntalääketieteenerikoislääkärin tilannekatsauksella(klo 12-13). Päivän viimeinenesitys pidetään klo 17.15-17.45...




38


Käyttötilanteiden kerääminenhaastatteluilla

GDD:ssä käyttäjähaastattelujen tarkoituksena on kerätä pelkästäänkonkreettisia tilanneasetelmia, joissa näkyy motiivi ja käyttäjänkeskeinen tietämys tai puuttuva tietämys. (Samalla tavalla kerätyttilanteet sopivat myös käytettävyystestauksen tai muidenarviointimenetelmien syötteeksi.)Keskeisin vaikeus haastatteluissa: käyttäjät yleistävät asioita.

He yrittävät puhua kaikkien käyttäjien puolesta sen sijaan, että he kertoisivatomista kokemuksistaan.He tekevät yhteenvetoja aiemmin sattuneista tilanteista tai kertovat niistäniin yleisellä tasolla, ettei kertomuksista saa aikaan käyttötilannekuvauksia.

Haastattelijan tulee houkuttaa käyttäjä konkretisoimaan:Kohdenna kysymys konkreettiseen tapahtumaan: “Milloin sinulle viimeksikävi niin? Mitä silloin tapahtui? …”Jos haastateltava ei anna esimerkkejä, kannattaa itse laatia nopeastiesimerkki ja pyytää häntä korjaamaan keksittyä esimerkkiä.


GDD:n käyttäjähaastattelutKäyttäjä välttelee esimerkkejä

Haastattelija kysyy liian yleisesti eikä saa mitään selville:Käytätkö usein yliopiston verkkosivuja? Mihin tarkoitukseen?

”Kyllä minä oikeastaan aika usein katson erilaisia ammattiasioitayliopiston sivuilta.”

Millaisia ammattiasioita?”Aivan kaikenlaisia.”

Antaisitko esimerkin?”No siis ne voivat olla aivan mitä tahansa.”

Kertoisitko yhden?”Se riippuu ihan tilanteesta.”

Millä tavalla se riippuu tilanteesta?”Jollain viikolla voi olla kiire ja silloin en välttämättä käytäollenkaan… Joskus kun on vähän tyhjää aikaa, rupean selvittämäänsitten jotain käytännön asiaa.”

Millaista käytännön asiaa?”Sellaista, mikä olisi hyvä hoitaa mutta on jäänyt...”



39


GDD:n käyttäjähaastattelutHaastattelija houkuttaa konkretiaan

Haastattelija kohdistaa kysymyksen äskettäiseen hetkeen:Käytätkö usein yliopiston verkkosivuja? Mihin tarkoitukseen?

”Kyllä minä oikeastaan aika usein katson erilaisia ammattiasioitayliopiston sivuilta.”

Milloin viimeksi katsoit jotakin ammattiasiaa verkosta?”Taisi olla eilen...”

Mitä katsoit?”Henkilöstöhallinnon sivuja.”

Mitä etsit sieltä?”Että mitä liitteitä virkahakemuksessa pitää olla ja milloin ondeadline.”

Miksi?”No joo, siis... Laitoksella on assistentin virka auki ja olen miettinyt,että voisin hakea...” jne. [Nyt haastattelija pääsee selvittelemäänensimmäistä konkreettista tilannetta.]


GDD:n käyttäjähaastattelutUnicafe-esimerkki

Kun olet päässyt kiinni esimerkkitilanteeseen (”Milloin viimeksi…?”),jatka selvittämällä, miksi ko. henkilö teki niin kuin teki (motiivi).Esimerkki: Unicafe-käyttäjähaastattelu verkkosivujen kehittämiseksi

Milloin viimeksi olet syönyt Unicafessa? Missä? <- KIINNI TILANTEESEENMiksi menit sinne? <- ALETAAN HAKEA MOTIIVIAMitä teit juuri sitä ennen? Missä olit? Miksi? <- MOTIIVIN HAKU JATKUUMinne olit sen jälkeen menossa? Miksi?

Seuraavalla sivulla on esimerkki käyttäjältä selvitetystä Unicafe-tilanteesta (alkuperäisen tilanteen selvittäjä on Joonas Gustafsson, 2004;editoitu luentomateriaaliin sopivaksi).

Huomaa, että todellisessa tilanteessa kyseinen haastateltava oli vainyksinkertaisesti kävellyt Ylioppilasaukion Unicafehen ja katsonut sielläruokalistaa ja valinnut sieltä parhaan tai vähiten huonon vaihtoehdon.Käyttötilannekuvauksessa ei kiinnitetä toteumaa ja juututa siihen, esim.käyttäjä tietää Ylioppilasaukion ja menee sinne. Käyttöliittymänsuunnittelussa GDD:llä selvitetään ensiksi, minne käyttäjän tässätilanteessa olisi oikeasti kannattanut mennä (saattaa olla eri kuinYlioppilasaukio).



40


Unicafe-esimerkkiJoonas Gustafsson, 2004 (lyhennelmä)

Nyt on ke 20.10. klo 12.15. Mikko onlähdössä kotoaan Leppävaarasta.Leffa alkaa Kinopalatsissa klo 13.30.Ylioppilasaukion Unicafen ruokalista:

Broilerperhonen, lämmin kasvisUunilohta valkoviinissäBroileria hunaja-sinappikastikkeessaSoijabolognese-spagetti

Kt 1: Lounasta ennen leffaaMikon tavoite 1: Mikko on kaverinsakanssa menossa Kinopalatsiin katsomaan13.30 alkavaa Super Size Me -elokuvaa.Mikon tavoite 2: Mikko ei ole syönytvielä aamupäivällä mitään. Hän ontottunut käymään keskustassa erityisestiYlioppilasaukion ruokalassa. Hän eikuitenkaan tiedä, onko siellä tänäänmitään erityisen hyvää pöperöä.

Tilatietoja:

Rautatieasema

Minne Mikon oikeasti kannattaisi mennä?Millä perusteella pystyy valitsemaan?

KinopalatsiSari A. Laakso (2006)

Käyttöliittymän suunnitteluKäyttöliittymän systemaattista tuottamista ontoistaiseksi tutkittu varsin vähän. Esimerkkejäsystemaattisista suunnitteluprosesseista ovatmm. Lauesenin ja Cooperin prosessit sekäCarrollin skenaariopohjainen suunnittelu.Tällä kurssilla käsitellään Interacta Designissaja Helsingin yliopiston tietojenkäsittelytieteenlaitoksella kehitettyyn GUIDe-malliin sisältyvääsimulointipohjaista GDD-suunnitteluprosessia(lisätietoja: Sari A. Laakso, [email protected]),jossa on yhtymäkohtia kaikkien edellämainittujen prosessien kanssa.



41


Erilaisia suunnitteluprosessejaLauesen, Carroll ja Cooper

Hyvien käyttöliittymäratkaisujen syntymistä ja systemaattistaluomista on tutkittu todella vähän. Tällä hetkelläkirjallisuudessa kuvattuja menetelmiä ovat lähinnä seuraavat:

Søren Lauesenin järjestelmällisesti etenevässä Virtual Windows -menetelmässä [Lauesen01, Lauesen05] käyttöliittymä suunnitellaanensin pelkän tietosisällön avulla ja toiminnallisuus lisätäännäyttökuviin vasta suunnittelun loppuvaiheessa.Scenario-Based Design [Carroll00] -menetelmässä käyttöliittymääsuunnitellaan kirjoittamalla tekstimuotoisia skenaarioita eli tarinoitasiitä, miten kuviteltu käyttäjä toimisi järjestelmän kanssa.Alan Cooperin Goal-Directed Design [Cooper03] –menetelmässäkuvataan tulevia käyttäjiä ja heidän korkean tason tavoitteitaan.Sen jälkeen näiden käyttäjien näkökulmasta kirjoitetaantekstimuotoisia käyttöskenaarioita, joiden sisältämät tiedot jatoiminnot lopulta organisoidaan käyttöliittymän näkymiksi jakomponenteiksi.

Copyright © 2006 / Antti Latva-KoivistoSari A. Laakso, Antti Latva-Koivisto (2006)


Erilaisia suunnitteluprosessejaLauesenin Virtual Windows

Lauesenin Virtual Windows –menetelmässä käyttöliittymäsuunnitellaan ensin pelkän tietosisällön avulla, ja toiminnotlisätään vasta suunnittelun loppuvaiheessa.

Ensin selvitetään käyttäjän tehtävät (tasks), jotka järjestelmälläpitäisi voida tehdä, ja niistä kirjoitetaan tekstimuotoiset kuvaukset.Sitten tietosisältö jaetaan ns. virtuaali-ikkunoihin simuloimallakäyttäjän tehtäviä ja soveltamalla Lauesenin antamiasuunnittelusääntöjä. Tietosisältöä voidaan katsoa tässä vaiheessamyös esimerkiksi tietomallin kuvauksesta.Virtuaali-ikkunoista piirretään visualisoituja oikean näköisiänäyttökuvia. Näissä graafisissa virtuaali-ikkunoissa ei kuitenkaanole vielä lainkaan toimintoja eikä niitä ole sovitettu mahtumaanlopulliseen näyttökokoon (voivat olla liian pieniä tai isoja näytölle).Lopuksi virtuaali-ikkunoihin lisätään toiminnot ja virtuaali-ikkunatsovitetaan lopulliseen näyttökokoon. Tämä tehdään taassimuloimalla käyttäjän tehtäviä.




42


Erilaisia suunnitteluprosessejaCarrollin skenaariomenetelmä

Carrollin skenaariomenetelmässä [Carroll00] käyttöliittymääsuunnitellaan ensisijaisesti tekstimuodossa, ja siirtyminentekstiskenaarioista näyttökuviin jää osin avoimeksi.

Aluksi tehdään skenaarioiden laatimisen pohjaksi kenttätutkimusta:käyttäjien haastatteluja ja heidän nykyisen toimintansa tarkkailua.Tekstimuotoisten skenaarioiden avulla tehdään rinnankäyttöliittymäsuunnittelua ja työnkulkujen uudelleensuunnittelua.Käyttäjän työnkulun etenemistä ja käyttöliittymän toimintalogiikkaaideoidaan ja kuvataan skenaarioina, joita kirjoitetaan moneenkertaan (iteratiivinen suunnittelu). Käyttöliittymän tietosisältöä taitoiminnallisuutta ei systemaattisesti visualisoida näyttökuvina, kutenLauesenin prosessissa, mutta apuna voidaan käyttää kuviakin.Kun skenaarioiden kirjoittamisen yhteydessä tulee esille erilaisiasuunnitteluratkaisuja, niitä verrataan ns. väittämillä (claims).Väittämiin kirjataan ratkaisuvaihtoehtojen hyvät ja huonot puolet,jotta niitä voidaan verrata keskenään.



Erilaisia suunnitteluprosessejaCooperin Goal-Directed Design

Cooperin Goal-Directed Design -menetelmässä [Cooper03, s.16-20, 39-90] kuvataan tulevia käyttäjiä ja heidän tavoitteitaansekä laaditaan keskeisimmistä tilanteista skenaariokuvauksia.

Aluksi tehdään tulevista käyttäjistä ns. persoonakuvauksia mm.käyttäjähaastattelujen ja –tarkkailujen perusteella. Jokaisellepersoonalle selvitetään/luodaan korkean tason tavoitteet.Seuraavaksi laaditaan käyttöskenaarioita (context scenarios)hieman vastaavaan tapaan kuin Carrollinkin menetelmässä.Skenaariossa kuvataan käyttäjän kannalta mahdollisimman hyvätoteuma tulevalla järjestelmällä, mutta se myös kiinnittää jokarkealla tasolla uuden järjestelmän toimintoja ja käyttöliittymänsuunnitteluratkaisuja.Skenaarioista tulkitaan käyttöliittymässä tarvittavat toiminnot jatiedot. Sen jälkeen ne organisoidaan käyttöliittymän näkymiksi japaneeleiksi ”top-down” eli aloittaen karkeista näkymistä ja siirtyenvähitellen kohti näytön yksityiskohtia.




43


Suunnitteluprosessin valintaLopputulos testataan käyttötilanteilla

Kaikille suunnittelumenetelmille yhteistä on se, että niidentuottama lopputulos aina viime kädessä testataan todellisillakäyttötilanteilla, kun järjestelmä otetaan käyttöön ja käyttäjätryhtyvät ensimmäistä kertaa tekemään sillä todellista työtään.Kaikki edellä kuvatut prosessit ottavat suunnittelussa huomioonkäyttäjien työtehtävät tai käyttäjille eteen tulevatkäyttötilanteet.(Käyttäjien työnkulkuja optimoivat ainakin GDD-prosessi,Carrollin skenaariomenetelmä sekä Cooperin prosessi.)



Suunnitteluprosessin valintaKäyttöliittymäratkaisun kiinnitys

Käyttöliittymäratkaisun kiinnittäminen eri menetelmissä:Carrollin skenaariomenetelmässä ja Cooperin prosessissakäyttöliittymän tietosisältöä ja toimintalogiikkaa kiinnitetääntekstimuodossa skenaarioiden avulla.Lauesenin Virtual Windowsissa ja GDD-prosessissa tietosisältö jatoimintalogiikka kiinnitetään piirtämällä näyttöjä.

• Virtual Windowsissa kiinnitetään ensiksi tietosisältö, lopuksi toiminnot.• GDD-prosessissa kiinnitetään sekä tietosisältö että toiminnot yhtä aikaa.

Käyttöskenaarioiden ja näyttökuvien etuna on se, ettäjärjestelmän vaatimuksia voidaan arvioida/testata jo varhain.

Skenaarioiden avulla käyttäjät saavat paremmin selville todellisiatarpeitaan, koska he voivat simuloida järjestelmän toimintaamielessään [Go04]. Suunnittelijat voivat arvioida skenaarioidenavulla suunnitteluratkaisuja ja paikantaa ongelmakohtia [Carroll94].Näyttökuvien avulla järjestelmän toimintaa ja tietosisältöä voidaantestata varhaisessa vaiheessa (esim. simulointitestaus taikäytettävyystestaus).




44

GUIDe-malli jaGDD-suunnitteluprosessi

GUIDe-malliin sisältyvä simulointipohjainenGDD (Goal-Derived Design) on kehitteilläoleva, joissain yrityksissä käyttöön sovellettukäyttöliittymän suunnitteluprosessi (lisätietoja:Sari A. Laakso, [email protected]).

GDD:ssa kantavana ajatuksena on käyttääsuunnittelussa samaa menettelyä kuintestauksessa ja järjestelmän todellisessakäytössä: käyttöliittymä suunnitellaankäyttötilanneasetelmien pohjalta.Tällä kurssilla opetellaan GDD-prosessistayksinkertaistettua versiota, jossa mm.tavoitepohjaiset käyttötapaukset on korvattuyksinkertaisemmilla käyttötilannekuvauksilla.


GUIDen ja GDD:n periaatteetVaiheet ja idea

GUIDe-malli (Goals – User Interface Design – Implementation) [Laakso04]määrittelee rungon vaatimusten kartoittamiselle jakäyttöliittymän laatimiselle. Se rakentuu kolmesta karkeastavaiheesta:1. käyttötilanteiden kerääminen vaatimuksiksi,2. käyttöliittymäratkaisun generointi simulointipohjaisella

menetelmällä (Goal-Derived Design, GDD) sekä3. käyttöliittymän ja sen vaatiman toiminnallisuuden ohjelmoiminen

em. vaiheiden jälkeen. Järjestelmää voidaan alkaa toteuttaa mitätahansa prosessia noudattaen, esim. XP:n tai Scrumin pohjalta.

GUIDe ja GDD perustuvat käyttötilannelähtöiseensuunnitteluun.



45


GUIDen ja GDD:n periaatteetGUIDen päävaiheet

Käyttötilanteiden kerääminenAluksi selvitetään kenttätutkimusten avulla käyttötilanteet, joita on tarkoitustukea järjestelmän avulla. Nykykäytännöistä erotellaan niiden takana olevattavoitteet ja ongelman virittämä ristiriita.Käyttötilanteet kategorisoidaan siten, että saman datan organisoinninvirittämät tilanteet niputetaan yhteen. Suunnitteluun valitaan näistäedustavat instanssit ja tarvittavat variaatiot.

Käyttöliittymäratkaisun generointi simuloimallaSimuloitavaksi valitaan kerrallaan yksi käyttötilanne, jota ryhdytäänpiirtämään auki käyttöliittymäksi (tietosisältö ja toiminnot). Piirtämisenaikana kiinnitetään käyttötilanteelle mahdollisimman suoraviivainenminimaalinen toteuma: sekä käyttöliittymäratkaisu että työnkulku.Päätöksentekodata näytetään kerralla, ja käyttäjältä vaaditut säätämistoimettämän näkymän esille saamiseksi minimoidaan. Tehokkuus optimoidaan.Kun muutaman käyttötilanteen suorittaminen ja niissä tarvittutoimintalogiikka ja tietosisältö on piirretty samaan käyttöliittymään, viriäämahdollisesti refaktorointitarve. Refaktorointi tähtää yksinkertaisempaanratkaisuun, joka kuitenkin virittyy samoista käyttötilanteista.


GUIDen ja GDD:n periaatteetVaatimusten selvittäminen

GUIDen kahden ensimmäisen vaiheen sisällä on samoja piirteitä kuin mm.ketterässä ohjelmistokehityksessä: valitaan käyttötilanteita ja piirretäänniitä vastaavaa käyttöliittymäratkaisua yksi tilanne kerrallaan, vrt.esim. käyttäjätarinat.testivetoisessa kehityksessä (Test-Driven Development, TDD):suunnittelu pohjautuu samoihin käyttötilanteisiin, jotka ovat myöstestitapauksia; tosin GUIDessa ne kategorisoidaan tietyllä tavalla ennensuunnittelun aloittamista.Lean-ohjelmistokehityksessä: sekä käyttöliittymäratkaisussa ettäsuunnitteluprosessissa tavoitellaan minimaalista ratkaisua, josta kaikkiroska (waste) on eliminoitu.



46


GUIDen ja GDD:n periaatteetAsiakkaan rooli

Yleensä asiakas osaa antaa tietoa saatujen käyttötilanteidenselvittämistä, priorisointia ja järjestelmän rajaamista varten.

Asiakkaan edustajalta saadaan tietoa keskeisistä kohderyhmistä, joiltakäyttötilanteita kartoitetaan, ja hän pystyy hankkimaan kontakteja näidenedustajiin. Hänellä saattaa olla tietoa siitä, miksi tiettyä käyttötilannetta tulisitukea tai miksi ei, tai tuetaanko ko. tilannetta nyt vai myöhemmin.Asiakasta autetaan tämän tietämyksen käyttöön ottamiseksi, jotta hän voisitehdä oman liiketoimintansa kannalta mahdollisimman hyviä päätöksiä.

Sen sijaan GUIDessa oletaan, että tyypillisesti asiakas ei voi osataselvittää ja kategorisoida käyttötilanteita (selvitämme nämä hänelle) eikälaatia siirtymää valituista käyttötilanteista mahdollisimman optimaaliseen,niitä tukevaan käyttöliittymäratkaisuun (teemme sen hänelle).

Tällä kurssilla opetellaan erityisesti näkemään tätä yhteyttäkäyttötilanteiden ja käliratkaisun välillä, koska se onkriittinen taito, jonka hankkiminen vaatii vaivannäköä jaharjoittelua. Myös käyttötilanteiden selvittäminen helpottuuheti, kun tämä suunnittelutaito kehittyy.


Ketterässä kehityksessä(ilman GUIDea):

Vaatimukset ovat asiakkaanvastuulla.Muuttuvia vaatimuksia pidetäännormaalina ilmiönä, ja ne otetaanvastaan osana ohjelmistonkehitysprosessia.Asiakkaalta saadut muutoksettehdään toimivaan ohjelmaan.

GUIDessa:

Vaatimusten selvittäminen onkäyttöliittymätiimin vastuulla, jaasiakas toimii avustavanasiantuntijan roolissa.Vaatimusten muuttuminennähdään pääosin illuusiona, jokasyntyy siitä, ettei kukaan pyriselvittämään (tai osaa selvittää)niitä systemaattisesti, jolloin nenäyttävät muuttuvan.Käyttöliittymä muuttuukäyttötilanteiden pohjalta kälinsuunnitteluvaiheessa, eikä mitäänvielä ohjelmoida.

GUIDen ja GDD:n periaatteetMuuttuvat vaatimukset/käli



47


GUIDen ja GDD:n periaatteetMuuttuvat vaatimukset/käli

GUIDessa muutoksia vaatimuksiin tulee,jos jonkin osapuolen jokin keskeinen käyttötilanne on epähuomiossa jäänytselvittämättä (=selvitystyössä tapahtunut virhe/puute), taijos asiakkaan liiketoimintamalli muuttuu (esim. lounasravintola päättääkinalkaa toimittaa ruokia myös kotiinkuljetuksella, tai lastentarvikekaupparyhtyykin vuokraamaan hoitovälineitä myymisen sijaan).

GUIDessa muuttuvien vaatimusten määrä minimoidaan.Jäljelle jäävät vain ne muutokset, jotka johtuvat inhimillisen virheenkorjaustarpeesta tai joita olisi ollut mahdotonta saada selville etukäteen.Muutoksia ei synny siitä, että asiakas ei alussa tiedä riittävän täsmällisesti,mitä hän haluaa, tai siitä, että hän tietää paremmin vasta sitten, kun näkee,mihin hänen vaatimuksensa on johtanut. GUIDessakin tätä pidetään”normaalina” lähtötilanteena, mutta se ratkaistaan selvitystyöllä.

GDD-prosessilla tuotettu käyttöliittymäratkaisu voi muuttua,jos joku onnistuu löytämään vielä suoraviivaisemman ratkaisun kuin se, jonkasuunnittelija osasi optimoida käyttötilanteiden pohjalta(=käyttöliittymäsuunnittelijan inhimillinen virhe/puute).

Käyttöliittymän piirtäminenGDD:lla

Suunnitteluun otetaan yksi käyttötilannekerrallaan.Vain käsillä olevaan tilanteeseen liittyväätietosisältöä ja toimintoja piirretään näkyviintehokkuutta optimoiden. Mieleen tulevatmuut toiminnot, ideat, uhkat ja huoletkirjataan muistiin ongelmalistalle jasivuutetaan.Näyttökoko oletetaan rajattoman suureksi.Usein kynällä paperille piirtäminen on nopeintapa tässä vaiheessa: suunnittelijankognitiiviset resurssit kohdistuvatensisijaisesti vaikeimpaan älylliseen työhön.



48


Kälin piirtäminen GDD:llaSuunnitteluperiaatteet 1-7

Käytä simuloinnin aikana seuraavia suunnitteluperiaatteita:1. Vain tässä käyttötilanteessa tarvittavat tiedot ja toiminnot

piirretään käyttöliittymään, ei mitään muuta. Loput ongelmalistalle.2. Kaikki tiedot ja käyttöliittymän osat näytetään kerralla – sen

sijaan, että järjestelmä pihtaa niitä ja käyttäjä pyytelee.3. Käyttäjä pysyy yhdessä näkymässä koko ajan – sen sijaan, että

hän kuljeksii järjestelmässä ympäriinsä näytöltä toiselle.4. Käyttäjä säätää näkymää ja järjestelmä reagoi ”lennossa”.5. Editointi paikallaan: Käyttäjä editoi tökkäsemällä suoraan sinne,

missä kohde näkyy.6. Päätöksentekoa simuloitaessa käyttäjän tulee osua vähintään

kolmeen relevanttiin vaihtoehtoon: käyttäjä punnitsee näitäkeskenään ja arvioi, mikä olisi paras tässä tilanteessa. Käyttäjälletulee eteen myös huonoja vaihtoehtoja, jotka hän jättää sivuun.

7. [Valmiit ratkaisumallit (design patterns). Vähitellen suunnittelijaalkaa tunnistaa simuloinnissa toistuvia, hyviä ratkaisumalleja.]


Kälin piirtäminen GDD:llaSuunnitteluperiaatteiden toiminta

Suunnitteluperiaate 1 varmistaa, ettei järjestelmään synny ylimääräisiätietoja tai toimintoja, joita ei tarvita missään käyttötilanteessa. Lisäksisillä pyritään varmistamaan, että tarvittavat toiminnot ja tietosisältö onsuunniteltu aina niitä hyödyntävien käyttötilanteiden näkökulmasta eikäyleisesti ripottelemalla ympäri järjestelmää (jolloin alkaa syntyä pitkiävaivalloisia polkuja ja tehokkuus heikentyy).Suunnitteluperiaatteilla 2-5 pyritään optimoimaan mekaanistatehokkuutta jättämällä kaikki tarpeettomat suoritusvaiheet pois.Periaatteella 6 optimoidaan päätöksentekokohtien kognitiivistatehokkuutta (joskin samalla saadaan optimoitua myös näiden kohtienmekaaninen tehokkuus). Käyttäjältä pyritään poistamaan tarpeeton,tietojärjestelmän käytöstä syntyvä kognitiivinen työ, joka kuormittaa jahäiritsee varsinaista päätöksentekoa. Tarkoitus on vapauttaamahdollisimman paljon kognitiivisia resursseja itse päätöksenprosessointiin.



49


Kälin piirtäminen GDD:llaSimulointi lyhyesti (tälläkin pärjää)

Ota käyttötilanne 1 ja piirrä sen suorittaminen mahdollisimmansuoraviivaisesti paperille siten, että noudatat annettujasuunnitteluperiaatteita, jotka auttavat optimoimaan tehokkuutta.Lopuksi simuloi tilanne alusta loppuun vielä pari kertaayksityiskohtaisesti ja yritä poistaa turhia toimenpiteitä tai kognitiivistatyötä, jos sellaisia ongelmia on ratkaisuun jäänyt.Ota käyttötilanne 2 ja yritä simuloida sen suorittaminen olemassaolevalla käyttöliittymällä samoin kuin edellä. Tee tarvittavat muutoksetja simuloi pariin kertaan. Lopuksi simuloi käyttötilanne 1, jotta voitkorjata, jos se meni rikki.Ota käyttötilanne 3 ja yritä simuloida se edellisten sekaan. Teetarvittavat muutokset. Simuloi edelliset uudelleen.Ota käyttötilanne 4 jne.


Kälin piirtäminen GDD:llaSimulointi päätöksentekolähtöisesti

Tässä kuvataan 3-vaiheinen simulointitapa, jossa käyttötilanteenpäätöksentekonäkymä rakennetaan aina ensin. Käytä annettujasuunnitteluperiaatteita.Vaiheet:1. Aloita piirtämällä käyttötilanteen keskeltä pelkkä

päätöksentekonäkymä.2. Piirrä puuttuva alkupää: Piirrä käyttäjältä vaadittavat toimenpiteet

järjestelmän alkutilasta em. päätöksentekonäkymään.3. Piirrä puuttuva loppupää: Piirrä käyttäjältä vaadittavat

toimenpiteet päätöksentekonäkymästä käyttötilanteensuorittamisen loppuun asti.



50


Kälin piirtäminen GDD:llaVaihe 1: Päätöksentekonäkymä

Piirrä käyttötilanteen 1 päätöksentekonäkymä näkyviin vertailussatarvittavan tietosisällön osalta: mitä tietoa kohteista näytetään jamiten, jotta käyttäjä voisi vertailla relevantit vaihtoehdot ja päätyäparhaaseen lopputulokseen.

Kun valitset tietosisältöä ja sijoitat sitä näytölle, simuloi jatkuvasti käyttäjäntoimintaa: mitä sellaista tietoa hän lukee, mikä vaikuttaa hänenpäätöksentekoonsa. Sijoita näytölle ainoastaan tällaista tietosisältöä (sitä,mikä merkittiin simulointitestauksessa vertailumerkinnöillä).Kiinnitä erityistä huomiota suunnitteluperiaatteeseen 6: Päätöksentekoasimuloitaessa käyttäjän tulee osua vähintään kolmeen relevanttiinvaihtoehtoon: käyttäjä punnitsee näitä keskenään ja arvioi, mikä olisi parastässä tilanteessa. Käyttäjälle tulee eteen myös huonoja vaihtoehtoja, jotkahän jättää sivuun.Käytä realistista dataa, jota tulee olla realistisen suuri määrä.

Lähtökohtaisesti mitään toiminnallisuutta ei tarvita. Vasta kun jonkintoiminnon tuottama mekaaninen työ on ainoa keino vähentääkognitiivista työtä, lisää ko. toiminto (esim. vertailukori hyvienvaihtoehtojen poimimiseksi, mahdollisuus merkitä hylättyjävaihtoehtoja visuaalisesti, …).


Kälin piirtäminen GDD:llaVaihe 2: Alkutilasta päätöksentekoon

Kun vaiheen 1 päätöksentekonäkymä on valmis, piirrä järjestelmänalkutila erilliselle paperille (kyseessä on sama näyttö, eri tila).

Koska teit vaiheessa 1 ensimmäisen käyttötilanteen päätöksentekonäkymän,tutki ensin, voisiko ko. näkymä olla suoraan järjestelmän alkutila, jolloin eitarvittaisi mitään toiminnallisuutta tämän säätämiseksi näkyviin. Huomaakuitenkin, että järjestelmä ei voi ”arvata”, mitkä kohteet juuri tämä käyttäjätässä käyttötilanteessa tarvitsisi (esim. mitkä kirjaston kirjat tai mitkäautokaupan autot). Järjestelmä ei saa toimia maagisesti taiepädeterministisesti.Näytä alkutilassa maksimaalisen paljon sellaista dataa, josta käyttäjälle onhyötyä juuri tässä tilanteessa.

Laadi minimaalinen joukko toimenpiteitä, joiden avulla käyttäjä pystyysäätämään alkutilasta esille vaiheen 1 päätöksentekonäkymän.

Pidä käyttäjä koko ajan ”samassa paikassa” ja anna hänen vain säätäänäkymää (suorakäsittely, vrt. Direct Manipulation, esim. [Shneiderman98]).Vältä navigointitarvetta viimeiseen asti.



51


Kälin piirtäminen GDD:llaVaihe 3: Päätöksenteosta loppuun

Piirrä minimaalinen joukko toimenpiteitä, jotka tarvitaankäyttötilanteen loppuun saattamiseksi päätöksenteon jälkeen(esim. tilauksen lähettäminen, tuki paikan päälle pääsemiseksi).Simuloi käyttötilanteen suorittamisen loppuhäntä (esim. mitenkäyttäjä osaa kävellä bussipysäkiltä perille lomahotelliinsa taimessupaikalle).


Kälin piirtäminen GDD:llaSeuraavat käyttötilanteet

Kun valitset variaatioita samasta tilanteesta:Kokeile ensin, onnistuuko variaation simulointi suoraan edellistentilanteiden tuottamalla käyttöliittymällä. Jos ei, laadi tarvittavatminimaaliset muutokset tietosisältöön ja toiminnallisuuteen.

Kun valitset aidosti eri kategorian käyttötilanteen:Kun mukaan tulee eri kategorian käyttötilanne, siitä seuraa erilainendatan organisointi eli selvästi toisenlainen päätöksentekonäkymä kuinaiemmin piirtämäsi näkymät.

Piirrä ensin näkyviin uusi datanäkymä vastaavalla tavalla simuloimalla kuin”Kt 1:n päätöksentekonäkymä”. Kokeile sitten simuloimalla, onko nämämahdollista yhdistää yhdeksi näkymäksi niin, ettei kummankaanpäätöksenteko häiriinny. Jos ei, säilytä uusi näkymä erillisenä. Voit sijoittaasen esimerkiksi omalle välilehdelle (tab) aiemman rinnalle.Piirrä käyttötilanne loppuun vastaavasti kuin ”Kt 1:n piirtäminen loppuun”.Alkutilana on nyt se alkutila, jonka olet jo aiemmin laatinut. Nyt on lisättäväminimaalinen joukko säätämistoimenpiteitä, joilla käyttäjä päätyy uuteendatanäkymään. Parhaassa tapauksessa aiemmin laaditut säätimet toimivattässäkin.



52


Kälin piirtäminen GDD:llaKohti realistista näyttökokoa

Kun olet piirtänyt tuen kaikille valitsemillesi käyttötilanteille jarefaktoroinut ratkaisua tarvittaessa, lopputuloksena on suuri näyttö,joka on jäsennetty ehkä parille välilehdelle. Miten tämä saadaansovitettua tietokoneen näytölle tai jopa pieneen puhelimeen?Simuloi jokaisen kategorian keskeisiä käyttötilanteita yksi kerrallaan japaikanna päätöksentekokohtien kriittiset vaiheet, joissa käyttäjäpitää mielessään vertailtavia tietoja tai työstää vaiheittain etenevääprosessia kohti ratkaisua.Säilytä kerralla näkyvissä ne tiedot, joita käyttäjä hyödyntäävertailussa (muussa tapauksessa hän joutuisi pitämään niitämielessään tai navigoimaan edestakaisin näyttöjen välillä). Teenäyttöjaot kognitiivisesti kuormittavien kohtien väliin.Jos on tarpeen sovittaa todella pienelle näytölle, joudut katkaisemaanmyös ”huonoista kohdista”. Yritä tällöin pitää samalla näytöllä ne tiedot,joiden pirstaloiminen kasvattaa mielessä pitämisen kuormaa eniten.Selvitä simuloimalla, missä ne ovat.

GDD-suunnitteluprosessiYhteenveto: Simuloiminen, testaus ja refaktorointi

Toimenpide a. Piirrä yksi käyttötilanne kerrallaan dataa ja toimintojanäkyviin ’yhteen suureen ikkunaan’.

Käyttötilanne 11.1 Piirrä kt 1 käyttöliittymäratkaisuksi simuloimalla käyttösekvenssiä vaihe vaiheelta.1.2 Simuloi ilmeisimmät variaatiot.Käyttötilanne 22.1 Editoi kt 2 edelliseen käyttöliittymään mukaan simuloimalla sitä vaihe vaiheelta.2.2 Simuloi ilmeisimmät variaatiot.2.3 Testaa käyttöliittymää simuloimalla edellinen käyttötilanne 1.Käyttötilanne 33.1 Editoi kt 3 mukaan simuloimalla.3.2 Simuloi ilmeisimmät variaatiot.3.3 Testaa käyttöliittymää simuloimalla edelliset käyttötilanteet 1 ja 2.Käyttötilanne 4...

Toimenpide b. Testaa käyttötilanneketjut (vain mielekkäät tositilanteet).Simuloi esim. ketju 2, 1, 2, 4, 2, 2, 4.Simuloi esim. ketju 1, 1, 3.

Toimenpide c. Refaktoroi käyttöliittymää tarvittaessa.




53


Kälin piirtäminen GDD:llaEsimerkki paperiprotosta

Esimerkki paperille laaditun näyttökuvan yhdestä sivusta:WWWTopi (kurssi-ilmot ja opintojen suunnittelu)

Simuloinnin aikananäyttökuvia kannattaapiirtää nopeasti kynälläpaperille. Varokatkaisemastasimulointiprosessiaturhaan.

Ne osat, joita on aidostinopeampaa tehdäesimerkiksi PowerPointillakuin käsin piirtämällä,voidaan tehdätietokoneella ja tulostaapiirrosten joukkoon.


Kälin piirtäminen GDD:llaOngelmalistan käyttö

Pysyttele tiukasti vain yhden käyttötilanteen piirtämisessäkerrallaan. Kerää ongelmalistaa, jos kesken piirtämisenmieleesi tulee…

uhka tai huoli, esim. mitäpä jos joku väärinkäyttää järjestelmää taijos käyttäjä vahingossa tuhoaa jotain tai jos käyttäjä ei keksi, mitentätä käytetään (opittavuusuhka), tai jos käyttäjä pelästyy tms.käyttäjän tai asiakkaan hypoteettinen tunnetila,jokin muu käyttötilanne, joka pitäisi huomioida,toiminto, jota saatetaan tarvita muissa tilanteissa, taimuissa tilanteissa ongelmalliseksi osoittautuvia ratkaisuja.

Jos suunnittelija kesken piirtämisen huolestuu uhkatilanteistatai ryhtyy miettimään muissa käyttötilanteissa tarvittaviatoimintoja, piirtäminen etenee hitaasti ja käyttöliittymästä tuleehelposti sellainen, ettei sen avulla olekaan suoraviivaista hoitaayhtään käyttötilannetta.




54


Kälin piirtäminen GDD:llaOngelmalistan purkaminen 1/2

Kun simulointi etenee, ongelmalistalle kerätyt kohteet yleensäalkavat vähentyä, koska uusien käyttötilanteiden mukaanottoratkaisee aiempia ongelmia ”itsestään”.Kun olet piirtänyt kaikki käyttötilanteet mukaan ratkaisuun, käyongelmalista läpi. Vedä yli ne ongelmat, jotka tuli jo hoidettuauusien tilanteiden simuloinnin yhteydessä.Käy jäljelle jääneet ongelmat läpi. Jos listalla on...

…uhka tai huoli: Selvitä, mihin käyttötilanteeseen se liittyy ja onkouhka todellinen vai kuviteltu. Ota tarvittaessa yhteyttäasiakkaaseen (kysyäksesi esim. liiketoiminnan tavoitteista) taikäyttäjiin (kysyäksesi esim. käyttötilanteista tai nykykäytännöistä)tai muihin asiantuntijoihin. Jos uhka on todellinen, ota se huomioonja korjaa ratkaisua. Selvitä, onko se mahdollista hoitaa esim.tarjoamalla perumismahdollisuus tai parantamalla opittavuutta.


Kälin piirtäminen GDD:llaOngelmalistan purkaminen 2/2

…uusi toiminto, jota arvelet jonkun käyttäjän tarvitsevan: Etsi yksikonkreettinen käyttötilanne, jossa kyseistä toimintoa voitaisiintarvita. Jos sellaista ei löydy, jätä toiminto sivuun. Jos löytyy, katsonyt hetken ajan pelkästään löytämääsi käyttötilannetta ja piirrä sentukemiseksi mahdollisimman suoraviivainen ratkaisu. Paras ratkaisuei välttämättä olekaan alunperin mieleesi tullut toiminto.…uusia käyttötilanteita: Kokeile ensin simuloimalla, onnistuukoniidenkin tekeminen. Jos ei onnistu, mutta tilannetta olisi syytätukea, ota uusi käyttötilanne suunnitteluun mukaan.…käyttöliittymän aiheuttama ongelma jonkin muun kuinsuunnittelussa mukana olevan käyttötilanteen kannalta: Selvitäensiksi, mikä tämä muu tilanne on. Sen jälkeen arvioi, onko haittatodellinen. Jos sen korjaaminen heikentää muiden käyttötilanteidensuorittamista, haarukoi sopiva kompromissiratkaisu simuloimallakaikkia ongelmaan liittyviä käyttötilanteita nopeasti peräkkäin.




55

GDD-suunnitteluprosessiEsimerkki 1: PDA-bussiaikataulut

Tässä esimerkissä demotaan GDD-suunnitteluprosessin etenemistä.Suunnittelun kohdelaitteena on PDA:

Syöttölaitteena on kynä.Laitteessa on GPS-paikannus, joka tietäälaitteen sijainnin noin viiden metrintarkkuudella.

Tässä käyttöliittymä on luentomateriaalintiivistämisen vuoksi piirretty pienellenäytölle, vaikka todellisuudessasuunnittelu tehtäisiin ensin ilmannäyttörajoitteita. Esimerkistä kuitenkinnäkyy selvästi, miten tietosisältö jaerityisesti toiminnot kertyvätkäyttöliittymään simuloinnin edetessä.

Kuva:www.infosatellite.com/news/2002/03/a140302mmo2_xda.html


Copyright © 2004 / Sari A. Laakso

KäyttötilanteetKt 1 ja 2

Bussipysäkki

Ma 7.7. klo 15.55 Joonas onTöölön tullin bussipysäkillä(Mannerheimintie 71)Hän on juuri käynyt ostoksillaHänen vanhempansa ovat asuneetviimeiset 20 vuotta Paloheinässäosoitteessa Raiviontie 2Hän tietää, että bussilla 63 pääseeMannerheimintien pysäkeiltävanhempien luoHän tietää, että busseja 63 meneenoin kymmenen minuutin välein

Kt 1: Tältä pysäkiltä vanhempienluo PaloheinäänJoonaksen tavoite: Joonas on Töölöntullin bussipysäkillä klo 15.55. Hän onmenossa pitkästä aikaa tapaamaanPaloheinässä asuvia vanhempiaan.Tilatietoja:

Ma 7.7. klo 15.55 Hanna on koiransakanssa Töölön tullin bussipysäkillä(Mannerheimintie 71)Hän on juuri käynyt ostoksillaHän on varannut eläinlääkärinmäyräkoiralleen Kannelmäkeen(Soittajantie 1) klo 16.30:ksiHän on käynyt siellä kerranaiemminkin tuttavan autokyydilläHän tietää, että busseja meneeKannelmäkeen melko usein, mutteitiedä Kannelmäen bussien numeroita

Kt 2: Tältä pysäkiltäeläinlääkäriin KannelmäkeenHannan tavoite: Hanna on koiransakanssa Töölön tullin bussipysäkillä klo15.55. Eläinlääkärin vastaanotto onKannelmäessä klo 16.30.Tilatietoja:




56


KäyttötilanteetKt 3

Ma 7.7. klo 15.55 Janne onTullinpuomin Shellillä kahvillaHänen isovanhempansa ovat asuneetviimeiset 15 vuotta EspoonTakkulassa (Takkulantie 6)Hän tietää, että busseilla 345 ja 346pääsee Mannerheimintien pysäkeiltäisovanhempien kotiinHän tietää, että bussi 345 jääkauemmas (noin 1 km:n kävely),mutta bussilla 346 pääsee aivanlähelle (muutama sata metriä)

Kt 3: Kahvilasta isovanhempienluo TakkulaanJannen tavoite: Janne on TullinpuominShellillä kahvilla klo 15.55. Hän onmenossa iltapäivällä tervehtimäänTakkulassa asuvia isovanhempiaan.Tilatietoja:

Tullinpuomin Shellin kahvio

Bussipysäkki

Kartta: pathfinder3.meridian.fi/ytv/fi/

Bussi 345(1 km)

Bussi 346(300 m)

Isovanhempien koti



BussiaikatauluesimerkkiGDD-demoon valitut käyttötilanteet

Kt 1: Joonas vanhempien luo PaloheinäänPiirrä käyttöliittymäratkaisuksi simuloimalla vaihe vaiheelta.Simuloi ilmeisimmät variaatiot.

Kt 2: Hanna eläinlääkäriin KannelmäkeenEditoi kt 2 mukaan edelliseen käyttöliittymään simuloimalla.Simuloi ilmeisimmät variaatiot.Testaa simuloimalla edellinen käyttötilanne 1.

Käyttötilanneketjut (ei välttämätöntä testata juuri tässä vaiheessa)Testaa ketju 2->1.

Kt 3: Janne isovanhempien luo TakkulaanEditoi kt 3 mukaan edelliseen käyttöliittymään simuloimalla.(Simuloi ilmeisimmät variaatiot. Jätetty tästä pois.)Testaa simuloimalla edelliset käyttötilanteet 1 ja 2.




57


Kt 1: Joonas vanhempien luoPiirrä käyttöliittymäratkaisu simuloimalla

Seuraavat bussit tältä pysäkiltä

16 16.3040 16.1142 15.5943 16.0763 15.58

231 16.00248 16.08261 16.10315 16.05324 15.56345 16.13346 15.59360 16.08363 16.03452 16.03453 15.58472 16.10485 16.09495 15.59

BussiNyt klo 15:55

Tässä päätöksentekonäkymäsijoitetaan suoraan etusivulle,koska muita käyttötilanteita eivielä ole suunnittelussa mukana.Yhtään toimintoa tainavigointiaskelta ei vielä tarvita.



Kt 1: Joonas vanhempien luoSimuloi ilmeisimmät variaatiot


16 16.3040 16.1142 15.5943 16.0763 15.58

231 16.00248 16.08261 16.10315 16.05324 15.56345 16.13346 15.59360 16.08363 16.03452 16.03453 15.58472 16.10485 16.09495 15.59

BussiNyt klo 15:55 Variaatio 1

Joonaksen vanhemmat asuvatVantaalla osoitteessa Emännänkuja 1.Joonas tietää, että busseilla 453, 472ja 485 pääsee vanhempien kotitalolle.




58


Kt 2: Hanna eläinlääkäriinYritä tehdä kt 2 suoraan edellisellä kälillä


16 16.3040 16.1142 15.5943 16.0763 15.58

231 16.00248 16.08261 16.10315 16.05324 15.56345 16.13346 15.59360 16.08363 16.03452 16.03453 15.58472 16.10485 16.09495 15.59

BussiNyt klo 15:55

Ensin katsotaan, sattuisiko edellinenkäyttöliittymä toimimaan suoraantässäkin käyttötilanteessa 2.Ongelma: Hanna ei selviytyisiKannelmäkeen eläinlääkäriin Joonaksenkäyttöliittymäratkaisulla ollenkaan!

Piirrämme uuden datanäkymän: mitäHannan tilanteessa tarvitaan? Hänelle onnäytettävä ne bussit, jotka menevätoikeaan paikkaan (selvitetään oikeavastaus: 42 ja 43). Eläinlääkärinvastaanottoaika on 16.30, joten hyvissäajoin sitä ennen on oltava perillä(saapumisaika).Piirretään ensin seuraavan sivun kolmasnäkymä, minkä jälkeen mahdollisimmanvähillä säädöillä etusivulta reitti sinne(kaksi ensimmäistä näyttökuvaa).


Kt 2: Hanna eläinlääkäriinEditoi kt 2 edelliseen käliin mukaan

Bussit tältä pysäkiltäKohdeosoite tai -paikka Kaupunki






59

Kt 2: Hanna eläinlääkäriinSimuloi ilmeisimmät variaatiot



Variaatio 1Eläinlääkäriasema sijaitseekinosoitteessa Soittajankuja 4.Myös Vantaalla on Soittajankuja.


Editoidaan pienimuutos.



Testaa edelliset tilanteetTestaa simuloimalla kt 1


Testitulos: Kt 1 toimii edelleen hyvin.




60




KäyttötilanneketjutTestaa ketju: Kt 2->Kt 1


KäyttötilanneketjutTestaa ketju: Kt 2->Kt 1




Ketjun testauksessailmeni tarve uudelletyhjennä-toiminnolle.Lisätään se.




61


Kt 3: Janne TakkulaanYritä tehdä kt 3 suoraan edellisellä kälillä

Ongelma: Entinen käli ei toimi, koskaJanne on nyt Shellin kahviossa, eikä lähinpysäkki ole se, jolta hänen tietämänsäbussit 345 ja 346 menevät Takkulaan.Laite näyttää väärää pysäkkiä ja pelkkiäensimmäisiä busseja.

Shellin kahvio

Takkulaan menevätbussit 345 ja 346

Lähin pysäkki, jonkabusseja laite näyttää



Kt 3: Janne TakkulaanEditoi kt 3 edelliseen käliin mukaan

Kohdeosoite tai -paikka KaupunkiPysäkiltä Töölön tulli, keskustaan Pysäkiltä Töölön tulli, keskustaan

Kohdeosoite tai -paikka Kaupunki

Olet tässä

Kohdeosoite tai -paikka KaupunkiPysäkiltä Töölön tulli, pohjoiseen

Tehdään uusidatanäkymä.Se pystytäänintegroimaanentiseen.




62



Kohdeosoite tai -paikka KaupunkiPysäkiltä Töölön tulli, keskustaan

Testituloksena ongelma: Joonaksenpitäisi päästä lähtemään tältä pysäkiltä,jolle hän on saapunut, mutta laitenäyttää sen pysäkin busseja, jonkakäyttäjä on valinnut edellisellä kerralla.

Suoraviivaisin tapa päästä takaisin kiinnilähimpään pysäkkiin? (Tarvitaan myösHannan kt 2:ssa.)

Käyttäjä voisi valita Pysäkiltä-valikostalähimmän pysäkin käsin, joten tämätilanne on mahdollista suorittaanykyisenkin kälin avulla. Päätämmekuitenkin suoraviivaistaa lähimmässäpysäkissä kiinni pysymistä, ja lisäämmeuuden toiminnon, koska emme keksi,miten voisimme suoraviivaistaa olemassaolevaa valikkovalintaa.



Testaa edelliset tilanteetKorjaa kt 1:n käyttöliittymää

Kohdeosoite tai -paikka KaupunkiPysäkiltä Töölön tulli, kesk Lähin

Kohdeosoite tai -paikka KaupunkiPysäkiltä Töölön tulli, pohj Lähin

Lisätäänmahdollisuuspysyä kiinnilähimmässäpysäkissä.




63




Testitulos: Kt 1 toimii riittävän hyvin.

Huomio: Niin kauan kuin Joonaksella onLähin-checkbox valittuna ja hakukenttätyhjänä, hän pääsee edelleentavoitteeseensa suorinta mahdollistatietä: vain vilkaisemalla laitettatekemättä mitään.

Muissa tilanteissa (riippuen edeltävästäkäyttötilanteesta) hän joutuu

• klikkaamaan Lähin-checkboxin päälleja/tai

• tyhjentämään hakuehtokentän.









64


KäyttötilanneketjutTestaa ketju: Kt 3 -> Kt 1 -> Kt 2 -> ...


Testausta voitaisiin jatkaa uudellakäyttötilanteiden ketjulla, minkä jälkeenkäyttöliittymään integroitaisiin uusikäyttötilanne 4.


GDD-suunnitteluprosessiEsimerkki 2: Kirjastohaku

Tässä esimerkissä suunniteltavanakäyttöliittymänä on yliopistontietojenkäsittelytieteen laitoksen (TKTL)kirjastojärjestelmä.Lähtökohtana on käyttötilanteita, joidenpohjalta käyttöliittymää piirretään GDD-suunnitteluprosessin mukaisesti tilannekerrallaan.Huom. Kaikkia simuloinnin välivaiheita eiole piirretty näkyviin tässä esimerkissä.Esimerkin tarkoitus on havainnollistaa,miten tietosisältö ja toiminnallisuuskertyvät järjestelmään, kun uusiakäyttötilanteita simuloidaan mukaan.

TKTL:n vanhakirjastohakujärjestelmä



65


KirjastoesimerkkiKäyttötilanne 1

Tänään on ma 1.9. klo 9.30.Luento on ti 9.9. klo 10-12.

Cardin kirja: Information VisualizationHannu on aiemminkin lukenut Cardin kirjaa, mutta hänellä eiole omaa kappaletta kirjasta.Omassa tietojenkäsittelytieteen laitoksen (TKTL)lähikirjastossa on 3 kpl, joista 1 on lainassa Inkeri Verkamollaja 2 hyllyssä.

Kt 1: Cardin visualisointikirja omasta lähikirjastostaTutkijan tavoite: Hannu Toivonen tietää, että Cardin kirjassaolisi hyviä glyyfiesimerkkejä hänen Tutkimustiedonhallinnanperuskurssin luentoaan varten, mutta hänellä ei ole Cardin kirjaa.Tilatietoja:


Kansi Tekijä(t) Kirjan nimi Vuosi HyllyssäHae

Card Remy, Dumas Eric,Mevel Franck

The Linux Kernel Book 1998 1

Card Stuart, MackinlayJock, Shneiderman Ben

Readings in InformationVisualization: Using Vision toThink

1999 2

Card Stuart, MoranThomas, Newell Allen

The Psychology of Human-Computer Interaction

1983 1

Cardelli Luca Typeful Programming 1989

Cardenas Alfonso Research Foundations in Object-Oriented and SemanticDatabase Systems

1990 1

Iyer Balakrishna, RicardGray, Varman Peter

An Efficient PercentilePartitioning Algorithm forParallel Sorting

1989 2

Kirjan haku

card

Käyttötilanne 1 (Cardin kirja lähikirjastosta)




66




Cardin kirja: Information VisualizationHannu on aiemminkin lukenut Cardin kirjaa, mutta hänellä eiole omaa kappaletta kirjasta.Omassa tietojenkäsittelytieteen laitoksen (TKTL)lähikirjastossa on 3 kpl, jotka kaikki ovat lainassa:

Juha Tainalla,Inkeri Verkamolla jaHannu Erkiöllä.

Kt 2: Kaikki Cardin visualisointikirjat lainassaTutkijan tavoite: Hannu Toivonen tietää, että Cardin kirjassaolisi hyviä glyyfiesimerkkejä hänen Tutkimustiedonhallinnanperuskurssin luentoaan varten, mutta hänellä ei ole Cardin kirjaa.Tilatietoja:


1

2

1

1

2

Kirjan haku

Kansi Tekijä(t) Kirjan nimi Vuosi

Hae

Card Remy, Dumas Eric,Mevel Franck

The Linux Kernel Book 1998

Card Stuart, MackinlayJock, Shneiderman Ben


1999

Card Stuart, MoranThomas, Newell Allen


1983


Cardenas Alfonso Research Foundations in Object-Oriented and SemanticDatabase Systems

1990

Iyer Balakrishna, RicardGray, Varman Peter


1989

18.3.03 Juha Taina 44 22631.3.03 Inkeri Verkamo 44 21915.5.03 Hannu Erkiö 44 253

10.6.03 Petri Myllymäki 44 17312.7.03 Mikael Jokela 44 628

Hae card

Käyttötilanne 2 (kaikki lainassa)

PuhelinHyllyssä Lainassa

Pvm LainaajaHyllyssä Lainassa

Pvm Lainaaja Puh.

Copyright © 2003 / Sari A. LaaksoSari A. Laakso (2003)



67




Waren kirja: Information VisualizationHannu on aiemminkin lukenut Waren kirjaa, mutta hänellä eiole omaa kappaletta kirjasta.Omassa tietojenkäsittelytieteen laitoksen (TKTL)lähikirjastossa ei ole kirjasta lainakappaleita ollenkaan.Hannu ja hänen opiskelijansa tarvitsevat kirjaatodennäköisesti myöhemminkin, koska kirja on mm. hänenTietokonegrafiikka-kurssinsa oheismateriaalina.

Kt 3: Waren visualisointikirjaa ei kirjastossaTutkijan tavoite: Hannu Toivonen tietää, että Waren kirjassaolisi Tietokonegrafiikan kurssille hyviä esimerkkejä rinnakkais-koordinaattien käytöstä, mutta hänellä ei ole Waren kirjaa.Tilatietoja:



Hae

Hyllyssä LainassaLainapvm Lainaajan nimi Puhelin

ware

Neeser Fredy, WareMalcom

Design of a V.34 modem for areal-time multitasking DSPoperating system

1995 1

Putnam Lawrence, MyersWare

Measures for excellence :reliable software on time, withinbudget

1992 1

Kirjan haku

Hae

Käyttötilanne 3 (kirjaa ei ole kirjastossa ollenkaan)




68


Hae

Hyllyssä LainassaLainapvm Lainaajan nimi Puhelin

ware

Neeser Fredy, WareMalcom

Design of a V.34 modem for areal-time multitasking DSPoperating system

1995 1

Putnam Lawrence, MyersWare

Measures for excellence :reliable software on time, withinbudget

1992 1

Kirjan haku Hankintaehdotus

Hae



Pvm Tekijä(t) Kirjan nimi24.10.03

Pvm Tekijä(t) Kirjan nimi

Tila Tekijä(t) Kirjan nimi

Tee hankintaehdotus kirjastoon

Lähetä kirjastoon Tyhjennä

Information visualization:perception for design

Ware Colin

Lähetetyt hankintaehdotukset

Käsitellyt hankintaehdotukset

Hankittava kirja

KustantajaPainopaikkaPainovuosiPainos

ISBN

Hinta-arvioTarvittavien lainakappaleiden lkm

Perustelut

Morgan KaufmannSan Diego, CA, USA

1-55860-511-8

2000

1.

?2

Tietokonegrafiikka-kurssin oheismateriaalia.Lähdemateriaaliksi Visualisointi-seminaariin.




69

Pvm Tekijä(t) Kirjan nimi24.10.03

Pvm Tekijä(t) Kirjan nimi

Tila Tekijä(t) Kirjan nimi

Tee hankintaehdotus kirjastoon

Lähetetyt hankintaehdotukset

Käsitellyt hankintaehdotukset

Hankittava kirja

KustantajaPainopaikkaPainovuosiPainos

ISBN

Hinta-arvioTarvittavien lainakappaleiden lkm

Perustelut

Morgan KaufmannSan Diego, CA, USA

1-55860-511-8

2000

1.

?2

Tietokonegrafiikka-kurssin oheismateriaalia.Lähdemateriaaliksi Visualisointi-seminaariin.

Information visualization:perception for design

Ware Colin24.10.03




KirjastoesimerkkiKäyttötilanne irti järjestelmästä

Älä kiinnitä käyttötilanteessa ratkaisutapoja. Esim. ”kirjanvaraaminen” ei koskaan ole käyttäjän tavoite, vaan kiinnitettyratkaisutapa (tehtävä tai toiminto).Miksei kirjan varaamista pidä kiinnittää käyttötilanteessa?

Laaditaan ensin varauksen tekemisen tarpeeseen osuva kunnollinenkäyttötilanneasetelma ja katsotaan, millainen käyttöliittymäratkaisusiitä seuraa: Otetaan pohjaksi aiempi käyttötilanne 2, muttatehdään siitä uusi käyttötilanne 4 asettelemalla tarjonta niin, ettäomassa lähikirjastossa kaikki kirjat ovat varattuja, mutta kirjaa olisisaatavana muissa kirjastoissa.Piirretään käyttötilannetta 4 optimoiva käyttöliittymäratkaisu. Se vienyt päätöksentekokohdan kartalle (vahva sijaintiriippuvuus), josoletamme työnkulun pysyvän ennallaan (”liiketoimintamalli” eimuutu).



70



Tänään on ma 1.9. klo 9.30. Luento on ti 9.9. klo 10-12.Tarvittava kirja

Hannu on aiemmin lukenut kirjaa, mutta hänellä ei ole omaa kappaletta.Hannu muistaa, että kirjan nimi on jokin ’Information Visualization’ ja yksitekijöistä on Card.Kirjan todelliset lähdetiedot: Card Stuart, MacKinlay Jock, Shneiderman Ben,Readings in Information Visualization: Using Vision to Think.

Kirjan saatavuusOmassa TKTL:n lähikirjastossa on 3 kpl, kaikki lainassa.Lääketieteellisen kirjastossa on 3 kpl: lainassa 2, saatavilla 1.

Hannu ei ole aiemmin käynyt siellä, ei tiedä kirjaston sijaintia.Kasvatustieteellisen ja psykologian kirjastoissa 2 kpl, kaikki lainassa.

Kt 4: Cardin visualisointikirja yliopiston muissa kirjastoissaTutkijan tavoite ja ongelma: Hannu Toivonen pitää Tutkimus-tiedonhallinnan peruskurssin luennon taas ensi viikolla, mutta hänelläei ole sopivia glyyfiesimerkkejä vielä. Hän tietää, että Cardin kirjassaolisi hyviä esimerkkejä ja kuvia, mutta hänellä ei ole kirjaa.Tilatietoja:

Ero kt2:een

Kirjan haku Omat varaukseni


Hae

Card Remy,Dumas Eric, MevelFranck


Card Stuart,Mackinlay Jock,Shneiderman Ben


1999

Card Stuart,Moran Thomas,Newell Allen


1983


Cardenas Alfonso Research Foundations inObject-Oriented and SemanticDatabase Systems

1990

Iyer Balakrishna,Ricard Gray,Varman Peter


1989

card

Kirjan saatavuus(Lainassa olevien lkm sulkeissa)

TietojenkäsittelytiedeTeollisuuskatu 23, ark. 9-16

Esko Ukkonenp. 44 226

18.3.03Inkeri Verkamop. 44 219

31.3.03Hannu Erkiöp. 44 253

15.5.03

(3)

Hankintaehdotus

Saatavilla:1 Varaa

KasvatustieteellinenBulevardi 18, ark. 8-18

(2 lainassa)

PsykologiaSiltavuorenpenger 20 A, ark. 9-15

(2 lainassa)

(2)LääketieteellinenHaartmaninkatu 3, ark. 10-16

Löytyi 26 / 48 559 kirjaa



71

Kirjan haku Omat varaukseni

Voimassa olevat varaukset

TietojenkäsittelytiedeTeollisuuskatu 23

LääketieteellinenHaartmaninkatu 3, ark. 10-16

Hankintaehdotus

Varatut kirjatCard, Mackinlay, Shneiderman:Readings in InformationVisualization: Using Vision toThink.Varattuna ma 10.11. – ke 12.11.

Peru varaus

Ratkaisun suoraviivaistaminen?Suurin ylimääräinen työ syntyy nytkirjan noutamisesta.


Hae

Card Remy,Dumas Eric, MevelFranck


Card Stuart,Mackinlay Jock,Shneiderman Ben


1999

Card Stuart,Moran Thomas,Newell Allen


1983


Cardenas Alfonso Research Foundations inObject-Oriented and SemanticDatabase Systems

1990

Iyer Balakrishna, An Efficient Percentile 1989

card

18.3.03 Juha Taina 44 22631.3.03 Inkeri Verkamo 44 21915.5.03 Hannu Erkiö 44 253

(3)

1 (6) Tänään ma10.11. klo 15mennessä


Tekijä(t) Kirjan nimi Toimitus

Tilaa sisäpostissa

Peru tilausPeru tilaus

10.6.03 Petri Myllymäki 44 17312.7.03 Mikael Jokela 44 628

Omat tilaukseni

Lähikirjasto (TKTL) Muut kirjastotHyllyssä Lainassa Hyllyssä

(lainassa)Toimitusaika

1

2

1

1

2

Esko Ukkonen

Löytyi 26 / 48 559 kirjaa



72


TyönkulkumallitVaraus-tehtävä on kiinnitetty ratkaisu

Työnkulkumalli 1Hannu noutaa vapaanaolevan lainakappaleenkirjastosta.Hannu käypalauttamassa kirjankirjastoon.

Työnkulkumalli 2Hannu tilaa vapaanaolevan lainakappaleenkirjastosta työpaikalleen.Kirja toimitetaansisäpostissa perille vieläsaman päivän aikana.Hannu palauttaa kirjanlähettämällä sen kirjanmukana tulevilla ohjeillatakaisin kirjastoon.

Varaus-tehtävä (task) ontässä tapauksessamielekäs, jotta Hannu eilähtisi kirjastoon turhaan.

Tässä työnkulussa erillistäVaraus-tehtävää ei enää ole.


Työnkulkumallin vaihtaminenPäätöksenteko muuttuu

NoutamismenettelyssäHannu tarvitsee kartallesuhteutettuja kirjastojapäätöksentekonsa tueksi:

Sisäpostimenettelyssä onsamantekevää, missä kirjastosijaitsee:



73


GDD-suunnitteluprosessiTuloksena hyödyllisyys ja käytettävyys

Käyttötilanteiden simuloinnin avullapiirretystä käyttöliittymästä nähdään

tarvittava tietosisältö jatoiminnot.

Konkreettisista käyttötilanteistasaadut toiminnallisetvaatimukset on kuvattu

ymmärrettävässä jatestauskelpoisessa muodossa.


74

Lähteitä

Bias91 Bias R. G.,Walkthroughs: efficient collaborative testing.IEEE Software, Vol. 8, No. 5, 1991, s. 94-95.

Broadbent75 Broadbent D.,The magic number seven after twenty years.Teoksessa Kennedy R., Wilkes A. (toim.), Studies in long termmemory. Wiley, New York, 1975, s. 253-287.

Card99 Card S. K., Mackinlay J., Shneiderman B. (toim.),Readings in Information Visualization: Using Vision to Think.Morgan Kaufmann, San Francisco, CA, USA, 1999.

Carroll94 Carroll J. M.,Making Use A Design Representation.Communications of the ACM, Vol. 37, No. 12, December 1994, s. 29-35.

Carroll00 Carroll J.M.,Making Use. Scenario Based Design of HumanComputer Interactions.The MIT Press, USA, 2000.

Cato01 Cato J.,User-Centered Web Design.Pearson Education, 2001.

Cooper95 Cooper A.,About Face: The Essentials of User Interface Design.IDG Books, USA, 1995.

Cooper03 Cooper A., Reimann R. M.,About Face 2.0. The Essentials of Interaction Design.Wiley Publishing, Inc., Indianapolis, Indiana, 2003.

Cowan01 Cowan N.,The magical number 4 in short-term memory: A reconsideration ofmental storage capacity.Behavioral and Brain Sciences, 24, 2001, s. 87-185.www.bbsonline.org/documents/a/00/00/04/46/bbs00000446-00/bbs.cowan.html

Dubberly87 Dubberly H., Mitch D.,The Knowledge Navigator.Apple Computer, videonauha. Esiintyy videolla Myers B. A. (toim),HCI’92 Special Video Program.

Go04 Go K., Carroll J. M.,The Blind Men and the Elephant: Views of Scenario-Based SystemDesign.interactions, November/December 2004, s. 44-53.

75

Goldstein02 Goldstein E. B.,Sensation and Perception.Wadsworth Publishing, 6th edition, 2002.

Hackos98 Hackos J., Redish J. C.,User and Task Analysis for Interface Design.John Wiley & Sons, USA, 1998.

Hornbæk06 Hornbæk K.,Current practice in measuring usability: Challenges to usability studiesand research.International Journal of Human-Computer Studies, Vol. 64, No. 2,2006, s. 79-102.

ISO9241-11 International Organization of Standardization, ErgonomicRequirements for Office Work with Visual Display Terminals (VDTs),Part 11: Guidance on usability (ISO 9241-11:1998), 1998.

Jacobson92 Jacobson I.,Object-oriented software engineering: a use case driven approach.Addison-Wesley, 1992.

Kolehmainen06 Kolehmainen A.,Ohjelmistolle asetettavien käytettävyysvaatimusten määrittely.Pro gradu –tutkielma, Helsingin yliopisto, tietojenkäsittelytieteen laitos,sarja C-2006-46, 2006.

Laakso00 Laakso S. A., Laakso K.-P., Saura A.,Improved Scroll Bars.ACM CHI 2000 conference proceedings, Extended Abstracts, s. 97-98.www.cs.helsinki.fi/u/salaakso/papers/CHI2000-Improved-Scrollbars.PDF

Laakso04 Laakso S. A., Laakso K.-P.,Hyvän käyttöliittymän varmistaminen GUIDe-prosessimallilla.Helsingin yliopisto, Tietojenkäsittelytieteen laitos, julkaisematonartikkeli, päivitetty 3.10.2004.www.cs.helsinki.fi/u/salaakso/papers/GUIDe-suomeksi.pdfwww.cs.helsinki.fi/u/salaakso/papers/GUIDe-suomeksi.html

Lauesen01 Lauesen S., Harning M.B.,Virtual Windows: Linking User Tasks, Datamodels, and InterfaceDesign.IEEE Software, July/August 2001, s. 67-75.www.itu.dk/people/slauesen/Papers/VirtualWindowsIEEE.pdf

Lauesen02 Lauesen S.,Software Requirements. Styles and Techniques.Pearson Education Ltd, 2002.

Lauesen05 Lauesen S.,User Interface Design. A Software Engineering Perspective.Pearson Education Ltd, 2005.

76

Lewis97 Lewis C., Wharton C.,Cognitive Walkthroughs.Teoksessa Helander M., Landauer T., Pradhu P. (toim.), Handbook ofHuman-Computer Interaction. Elsevier Science B.V., Netherlands,1997, s. 717-732.

Miller56 Miller G. E.,The Magical Number Seven, Plus or Minus Two: Some Limits on OurCapacity for Processing Information.The Psychological Review, 1956, vol. 63, s. 81-97www.well.com/user/smalin/miller.html

Nielsen93 Nielsen J.,Usability Engineering.Academic Press, New York, 1993.

Nielsen94 Nielsen J.,Heuristic evaluation.Teoksessa Nielsen J., Mack R.L. (toim.), Usability inspection methods.Wiley, New York, USA, 1994, s. 25-62.

Nielsen00 Nielsen J.,Why You Only Need to Test With 5 Users.Alertbox, March 19, 2000.www.useit.com/alertbox/20000319.html

Nielsen03 Nielsen J.,Usability 101: Introduction to Usability.Alertbox, August 25, 2003.www.useit.com/alertbox/20030825.html

Norman90 Norman D.,The Design of Everyday Things.Doubleday, New York, 1990.(Alkuperäinen painos nimellä The Psychology of Everyday Things,Basic Books, New York, 1988; suomenkielinen versio nimellä Mitenavata mahdottomia ovia)

Peterson59 Peterson L. R., Peterson M. J.,Short-term retention of individual verbal items.Journal of Experimental Psychology, Vol. 58, 1959, s. 193-198.

Preece94 Preece J.,Human-Computer Interaction.Addison-Wesley, Wokingham, UK, 1994.

Rubin94 Rubin J.,Handbook of Usability Testing: How to Plan, Design, and ConductEffective Tests.John Wiley & Sons, 1994.

Sears97 Sears A.,Heuristic Walkthroughs: Finding the Problems Without the Noise.International Journal of Human-Computer Interaction, Vol. 9, No. 3,1997, s. 213-234.

77

Shneiderman98 Shneiderman B.,Designing the User Interface.Addison-Wesley, 3rd edition, 1998.

Shneiderman00 Shneiderman B., Kang H.,Direct Annotation: A Drag-and-Drop Strategy for Labeling Photos.International Conference on Information Visualisation (IV2000),London, England, 2000.www.cs.umd.edu/hcil/photolib/paper/DirectAnnotation7.doc

Tufte83 Tufte E. R.,The Visual Display of Quantitative Information.Graphics Press, USA, 1983.

Tufte90 Tufte E. R.,Envisioning Information.Graphics Press, USA, 1990.

Ware00 Ware C.,Information Visualization: Perception for Design.Morgan Kaufmann, San Francisco, CA, 2000.

Williamson92 Williamson C., Shneiderman B.,The dynamic HomeFinder: Evaluating dynamic queries in a real-estateinformation exploration system.ACM SIGIR’92 conference proceedings, 1992, s. 338-346.

Documents

Sari A. Laakso - cs.helsinki.fi · Sari A. Laakso (2015) Simulointipohjainen käyttöliittymäsuunnittelu 4 Sari A. Laakso(2015) Erityyppiset käliongelmat Sekundääriset ongelmat