Systemaattisen käyttöliittymäsuunnittelun vaikutus käyttäjän ja asiakkaan rooleihin vaatimusten määrittelyssä

Transkriptio

1 Systemaattisen käyttöliittymäsuunnittelun vaikutus käyttäjän ja asiakkaan rooleihin vaatimusten määrittelyssä Katja Korpela Tietojenkäsittelytieteen laitos Helsingin yliopisto TIIVISTELMÄ Käyttäjäkeskeinen ohjelmistosuunnittelu on yleistymässä, mutta käyttäjän rooli ei välttämättä näy lopputuotteessa. Tässä kirjoitelmassa tarkastellaan GUIDe-prosessimallin vaikutusta käyttäjän rooliin ja edelleen ohjelmistokehitysprosessiin. Tarkoituksena on pohtia yleensä erilaisia vaikutustapoja käyttäjän roolin ja miten systemaattinen käyttöliittymäsuunnittelu vaatimusmäärittelyvaiheessa toteutettuna mahdollistaa käyttäjän roolin hyödyntämisen ohjelmistotuotannossa verrattuna siihen, miten asiakkaan tai ohjelmoijan rooliin painottuva yrityskulttuuri vaikuttaa lopputulokseen. Avainsanat GUIDe-prosessimalli, käyttäjän rooli, systemaattinen käyttöliittymäsuunnittelu, vaatimusmäärittely. JOHDANTO Nykyäänkin tavataan ohjelmistosuunnittelua, jossa käyttäjää ei oteta lainkaan mukaan suunnitteluun. Käyttäjäkeskeisessä suunnittelussakaan käyttäjän tarpeet eivät välttämättä tule itse ohjelmaan [6]. Käyttäjäkeskeinen suunnittelu ei myöskään välttämättä tarkoita, että käyttäjä on mukana suunnittelussa; käyttäjän mukanaolo saattaa jäädä käyttäjähaastatteluihin [12]. Jos käyttäjä on jossain määrin mukana prosessin useimmissa vaiheissa, tämä ei kuitenkaan tarkoita, että käyttäjä olisi mukana kaiken aikaa [3]. Lisäksi käyttäjäkeskeisessäkin suunnittelussa itse käyttöliittymän suunnittelu voi olla ohjelmoijien vastuulla [6]. Yhtenä ongelmana pidetään, että käytettävyyden suunnittelu ei ole osana ohjelmistokehitysprosessia [3]. Ongelmia tulee myös, jos ohjelmistosuunnittelijat tekevät käyttöliittymän välittämättä käytettävyysasiantuntijoiden mielipiteistä [6]. Gulliksen et al. tutkimuksesta ilmeni, että tarkkailua, työnkulkukuvauksia ja kontekstuaalisia käyttäjähaastatteluja käytetään eniten ruotsalaisten käytettävyysasiantuntijoiden keskuudessa ja niitä myös pidetään parhaiten tulosta antavina vaatimusmäärittelymenetelminä käyttäjäkeskeisessä suunnittelussa [3]. Kysyttäessä taas amerikkalaisilta ja eurooppalaisilta käyttäjäkeskeistä suunnittelua käyttäviltä ohjelmistoalan yrityksiltä heidän käyttämistään menetelmistä ilmeni, että usein käytetään kustannuksiltaan alhaisia menetelmiä, vaikka kenttätutkimuksia pidetään parhaimpina [12]. GUIDe-prosessimallissa (Goals User Interface Design Implementation) [8] käytettävät menetelmät ovat samoja, joita yleisesti pidetään parhaimpina käytettävyysasiantuntijoiden keskuudessa [3, 12]. Lisäksi GUIDe-mallissa käytetään systemaattista käyttöliittymäsuunnittelua ja tämä suoritetaan aina ohjelmistoprosessin alussa. GUIDeprosessimalli integroi käytettävyyssuunnittelun käyttöliittymäsuunnittelun ohessa osaksi vaatimusmäärittelyprosessia tuoden siten käytettävyyden osaksi vaatimusdokumenttia. Kirjoitelmassa käsitellään ohjelmistokehitysprojekteissa esiintyviä rooleja, joitain niihin liittyviä ongelmia ja ratkaisuja sekä GUIDe-mallin käytön vaikutusta käyttäjän rooliin ja miten käyttäjän rooliin vaikuttaminen vaikuttaa käyttäjän tietämyksen välittämiseen ohjelmiston (käyttöliittymä) suunnittelijoille. Lisäksi pohditaan asiakkaan ja ohjelmoijan roolia painottavan ohjelmistosuunnittelun vaikutusta käyttäjän rooliin ja miten GUIDe-mallin käyttö voisi muuttaa näitä suhteita. OHEJLMISTOKEHITYSPROJEKTIN ROOLEISTA Puhuttaessa perinteisestä käyttöliittymäsuunnittelusta asiakkaan rooliksi jää yleensä tiedon tuottaminen. Käyttäjä on harvemmin mukana vaatimusten kartutuksessa ja jos on, hän ei yleensä sano mitään. Tiedon tuottamisen aktiivisuuden aste riippuu asiakkaan omasta kiinnostuksesta ja aktiivisuudesta sekä vaatimusmäärittelijöiden käyttämistä menetelmistä. Kun puhutaan käyttäjän mukanaolosta ohjelmistosuunnittelussa, käyttäjän rooli voi olla mitä tahansa aktiivisesta mukanaolijasta, joka osallistuu ohjelmistokehitysprosessin kaikkiin vaiheisiin, puhtaaseen tiedon tuottajaan ja tarkkailtavaan [6]. Yleensä käyttäjän mukanaololla tarkoitetaan, että käyttäjään ollaan oltu yhteydessä. Myös tiedon tuottajan rooli voi vaihdella aktiivisesta hyvinkin passiiviseen, riippuen esimerkiksi käyttäjän kiinnostuksesta ja vastuuntunnosta suunniteltavan ohjelmiston suhteen. Ohjelmistosuunnittelijan tai ohjelmoijan vaikutus lopulliseen ohjelmaan ei ole vähäinen. Ohjelmistosuunnittelijat voivat jättää huomioimatta käyttäjän tarpeet ja käytettävyysasiantuntijoiden mielipiteet [6, 3]. Tällöin käyttäjän rooli kadottaa merkityksensä käyttäjän mielipiteiden ja tarpeiden jäädessä huomiotta. Ongelmia Käyttäjän ollessa mukana ongelmia voi tuottaa käyttäjän taidot ja tietämys ja hänen sitoutuneisuutensa projektiin. Käyttäjän roolin näkymiseen lopputuotteessa vaikuttaa myös ohjelmistotuotantoprojektin muiden jäsenten suh- 1

2 tautuminen käyttäjän mukanaoloon ja tarpeisiin. Seuraavassa esitetään muutamia esimerkkejä eri rooleihin liittyvistä ongelmista. Käyttäjä ei kerro tietämystään. Käyttäjä voi olla mukana haastattelussa, mutta hän ei välttämättä sano mitään, jos samassa tilaisuudessa on esimerkiksi häntä itseään asiantuntevampia työntekijöitä tai hän ei koe olevansa vastuussa ohjelmiston käytettävyydestä tai ylipäätään ohjelmiston toteuttamisesta. Käyttäjä ei ymmärrä, mitä tehtävän suorittaminen vaatii. Käyttäjä tai asiakas ei osaa kertoa, mitä hän haluaa ohjelmalta. Käyttäjä tai asiakas ei tiedä, mitä hän tarvitsee ohjelmalta. Käyttäjä tai asiakas ei tunne teknisiä mahdollisuuksia eikä tiedä, mitä on mahdollista saavuttaa. Käyttäjä tai asiakas on aktiivinen osallistuja ja tiedon tuottaja. Käyttäjä tai asiakas saattaa olla hyvinkin aktiivisesti mukana kaikissa ohjelmistokehitysprosessin vaiheissa, mutta tämä ei takaa hyvää käyttöliittymää. Käyttäjä tai asiakas ei kuitenkaan ole asiantuntija käytettävyysasioissa tai käyttöliittymäsuunnittelussa. Asiakas ei välttämättä itse käytä suunniteltavaa järjestelmää. Asiakas voi myös esiintyä liiankin asiantuntevana ja luetella vaatimuksia vakuuttaen suunnittelijat. Ongelmana voi olla asiakkaan liiankin itsevarma käsitys suunnitteilla olevasta ohjelmistosta. Tämä ei aina ole sama asia kuin asiakkaan tarpeita vastaava ohjelmisto. Vaarana on myös, että ohjelma ei toimikaan halutulla tavalla tai että projektiaikataulu pitkittyy. Ohjelmoijat pitävät itseään käyttäjää parempina asiantuntijoina. Ohjelmoijat saattavat kuvitella tietävänsä kaiken käyttäjistä ja heidän tarpeistaan tai ohjelmoijat voivat kuvitella tuntevansa sovellusalueen käyttäjää paremmin esimerkiksi työskenneltyään itse aiemmin samassa tehtävässä kuin käyttäjä nyt. Ohjelmoijat eivät välttämättä halua puhua käyttäjien kanssa. Ohjelmoijat käyttävät itselleen ennestään tuttuja menetelmiä ja ratkaisuja. Yhteistä kaikille näille ongelmatapauksille on, että käyttäjää enimmäkseen ei oteta mukaan tai käyttäjän rooli on korkeintaan konsultoiva, jolloin heitä ei tarvitse huomioida. GUIDE-MALLIN KÄYTÖN VAIKUTUS KÄYTTÄJÄN ROOLIIN GUIDe-prosessimalli lähtee käyttäjän tarpeista [8]. Se on kokonaisuus, johon sisältyy kenttätutkimus (tarkkailu ja kontekstuaaliset haastattelut), tavoitepohjaisten käyttötapausten laatiminen ja käyttöliittymän suunnittelu käyttötapaus kerrallaan simuloimalla käyttäjän toimintaa. Lopuksi käyttöliittymästä tehdyt näyttökuvat testataan käyttäjällä. Tässä luvussa tarkastellaan, miten käyttäjän rooliin liittyviä ongelmia on pyritty ratkaisemaan. Löydettyjä ratkaisuja sovelletaan GUIDe-prosessimallin vaiheisiin tuoden esille GUIDe-mallin tarjoamia mahdollisuuksia parantaa viestintää käyttäjän ja käyttöliittymäsuunnittelijoiden välillä, käyttäjän mahdollisuuksia tiedon tuottamisessa ja käyttäjien antamaa palautetta. Viestinnän paraneminen Hartwick ja Barki [4] mittaavat tutkimuksessaan viestinnän aktiivisuutta sillä kuinka paljon ja kuinka usein käyttäjä kommunikoi ohjelmistotuotantoon liittyviä asioita projektin aikana. Viestinnän aktiivisuudella he tarkoittavat käyttäjän tekemää toimintoa tai käyttäjän tiedon vaihtoa ohjelmistotuotantoon liittyvissä asioissa minkä tahansa sidosryhmän jäsenen kanssa. Tutkimustuloksena Hartwick ja Barki esittävät, että projektiryhmän jäsenet olivat aktiivisempia kommunikoimaan kuin ryhmään kuulumattomat henkilöt. Tehokas käyttäjän mukanaolo edellyttää tietoa sisältävän viestinnän määrän kasvua, mikä parantaa projektiryhmän tiedonhakuprosessia ja tiedon hyväksikäyttöprosessia [5]. Tämä taas lisää keskinäistä yhteisymmärrystä, mikä parantaa ryhmän toimintatehokkuutta [5]. Vastaavasti ryhmien väliset konfliktit kasvavat ja keskinäinen luottamus laskee ryhmien välisen yhteisymmärryksen laskiessa ja kun tietämys ja odotukset eroavat toisistaan liiaksi. GUIDe-mallin alussa suoritetaan kenttätutkimus, joka ollessaan riittävän pitkä lisää passiivisenkin käyttäjän yhteenkuuluvuuden tunnetta ja sitoutumista projektiin ja siten käyttäjän halua kommunikoida itselleen tärkeitä asioita ja epäkohtia. Myös käyttäjälle omasta työelämästään tutut käyttötapaukset, joilla testausvaiheessa simuloidaan käyttäjän todellisia tavoitteita, ja iteroiva suunnitteluprosessi todennäköisesti parantavat yhteenkuuluvuuden tunnetta. Täten GUIDe-mallin käytön pitäisi parantaa paitsi viestinnän määrän kasvua myös käytettävyysasiantuntijoiden tiedonhakuprosessia ja tiedon hyväksikäyttöprosessia lisäten keskinäistä yhteisymmärrystä. Tiedon tuottamisen paraneminen Beyer ja Holzblatt esittelevät kisälli mestari -mallin, jossa he vertaavat käyttäjää käsityöläismestariin, joka siirtää taitonsa vieressä seuraavalle kisällille [2]. Mestari ei ole luonteva opettamisessa, koska hänen työtänsä ei ole opettaa, vaan olla asiantuntija omassa työssään. Myöskään puhuminen ei ole mestarin työtä ja mestari ei välttämättä pystykään tehokkaasti kertomaan työstänsä. Mestari opettaa tekemällä työtänsä ja puhuen samalla työstänsä. Perinteisessä ohjelmistokehitysprojektissa asiakas tai käyttäjä on helposti opettajan roolissa, jossa häntä pyydetään kertomaan työstänsä ja vaatimuksista ohjelmiston suhteen. Tällöin voidaan törmätä ongelmiin vaatimusten kattavuuden ja oikeellisuuden suhteen, jos käyttäjä ei tiedä, mitä hän haluaa tai ei osaa sitä kertoa tai käyttäjä ei ymmärrä, mitä tehtävän suorittaminen vaatii. Mestari kisälli -mallin mukaan käyttäjä on asiantuntija omassa työssään. Beyer ja Holzblatt esittävät, että omak- 2

3 suessaan kisällin roolin käyttäjätarkkailussa suunnittelija automaattisesti omaksuu hyvän tiedon keräämiselle välttämättömät asenteet kuten nöyryys, uteliaisuus ja yksityiskohtiin keskittyminen. Samalla kisällin rooli Beyerin ja Holzblattin mukaan vähentää suunnittelijoiden halua esittää abstrakteja kysymyksiä ja saa heidät keskittymään meneilläänolevaan työhön. Opettaminen vaatii myös, että opettajan on etukäteen selvitettävä asian rakenne. Mestarin opettaessa työtä tekemällä rakenne paljastuu työskentelyn aikana. Beyerin ja Holtzblattin mukaan rakenteen selvittäminen kuuluu suunnittelijoille. Lisäksi suunnittelijoiden täytyy selittää havaitsemansa rakenne käyttäjälle varmistaakseen, että ovat ymmärtäneet oikein. Käyttäjän ei oleteta näkevän työnsä rakennetta, mutta käyttäjä kyllä tunnistaa rakenteen oikeellisuuden. Asian voisi myös ilmaista sanomalla, että ilman kenttätyötä asiakkaan tai käyttäjän rooli on yrittää kertoa parhaansa mukaan, mitä hän haluaa ohjelmalta. Ei ole realistista vain kysyä käyttäjältä tai asiakkaalta, mitä he haluavat ohjelmaansa. He eivät aina pysty kertomaan tarkasti haluamaansa ja eivät välttämättä tiedä, mitä vaatimuksia heidän tulisi esittää. GUIDe-mallissa ei oletetakaan asiakkaan tai käyttäjän listaavan tarpeitaan ohjelmistolle vaan asiakkaan työprosessit tuovat nämä esille kenttätutkimuksen aikana. GUI- De-mallilla nähdään myös nopeasti, pystyykö ohjelmalla tekemään käyttäjän työtehtävät sillä käyttöliittymä suunnitellaan simuloimalla työprosessista johdettuja tavoitepohjaisia käyttötapauksia, jotka myös testataan käyttäjällä. Käyttäjien antaman palautteen paraneminen Visser ja Visser [13] uskovat, että käyttäjien hyödyntäminen ohjelmistokehitysprosessin eri vaiheissa motivoi käyttäjiä, saa heidän arvostamaan itseään ja kokemaan vastuuta roolistaan sovellusalueen asiantuntijana. Heidän mukaansa tietoisuuden luominen vie aikaa ja on osoitettavissa, että käyttäjän herkkyys kasvaa ensimmäistä tapaamiskertaa seuraavilla tapaamiskerroilla. Ensimmäisellä tapaamiskerralla käyttäjien reaktiot ovat usein pinnallisia ja he keskittyvät yksityiskohtiin arvioimatta uutta sovellusta mitenkään syvällisesti. Visserin ja Visserin huomioiden mukaan käyttäjät myös prosessoivat vapaaehtoisesti motivaatioitaan, huolenaiheitaan ja toiveitaan liittyen heille esiteltyyn aihealueeseen tapaamiskerran päätyttyä ja ovat halukkaita kommunikoimaan niitä eteenpäin. Käyttäjien uudelleenkäyttäminen oletettavasti poistaa ongelmia liittyen käyttäjän osaamiseen ja tehtäväalueen ymmärtämiseen. Käyttäjän rooli muuttuu myös aktiivisemmaksi itsevarmuuden ja tietämyksen lisääntyessä käyttäjän kuitenkin pysyessä omalla osaamisalueellaan. Myös käyttäjän viestintä lisääntyy ja viestinnän tietomäärä kasvaa. GUIDe-prosessimalli kokonaisuutena mahdollistaa kenttätutkimuksissa käytettyjen käyttäjien uudelleenkäyttämisen testattaessa käyttöliittymää näyttökuvien avulla käyttäjillä. Myös jos kenttätutkimuksen osuus on huomattavan laaja, on odotettavissa, että samoja käyttäjiä käytettäessä käyttäjät syventyvät paremmin aihealueeseen ja heiltä voi odottaa tarkempia vaatimuksia käyttöliittymän ja ohjelman toiminnallisuuksien suhteen. Käytettävyysasiantuntijoiden keskuudessa ollaan yleisesti sitä mieltä, että käyttäjän kanssa on helpompi kommunikoida näyttökuvien avulla. On myös tärkeää näyttää käyttäjälle, että hänen sanomisensa on huomioitu. GUI- De-mallissa käytetään simuloinnissa käyttäjälle tuttuja tavoitepohjaisia käyttötapauksia, jotka kuvaavat hänen omia tavoitteitaan. Tavoitepohjaiset käyttötapaukset ovat konkreettisia ja niissä on selkeästi erotettuna käyttäjän motivaatio ja tilanteeseen liittyvät tilatiedot, mikä tekee niihin reagoimisen ja niiden muokkaamisen helpoksi. Varsinkaan projektin alkuvaiheessa asiakas tai käyttäjä ei voi tietää, mikä kaikki on mahdollista. GUIDe-mallia käytettäessä, asiakas näkee näyttökuvia simuloitaessa, mikä on mahdollista. Käyttäjälle saattaa tulla mieleen asioita, joita hän ei ole aiemmin huomannut ja hän saattaa keksiä uusia vaatimuksia edellisten pohjalta. Käyttäjä saa tilaisuuden kertoa niistä asioista, joita häneen mieleensä on tullut sitten edellisen tapaamisen. Simuloitaessa käyttötapauksia käyttäjälle, käyttäjä näkee myös heti, jos jokin asia ei toimi käyttöliittymällä. ASIAKKAAN ROOLIA PAINOTTAVA OHJELMISTOSUUNNITTELU Tässä luvussa katsotaan esimerkkien avulla asiakkaan asiantuntevan roolin ja voimakkaiden ennakko-odotusten vaikutusta prosessiin ja miten GUIDe-prosessimallin käyttö voisi muuttaa lopputulosta. Hali-projekti Helsingin yliopiston tietojenkäsittelytieteenlaitoksen Hali-ohjelmistotuotantoprojektissa [10] suunniteltiin tietokanta, käyttöliittymä ja ohjelmisto merikotkien pesintätietojen tallettamiselle tietokantaa ja raporttien tuottamiseen. Hali-projekti oli tietokantapainotteinen, ja se toteutettiin vesiputousmallin mukaan osittain siksi, että tietojenkäsittelytieteenlaitoksella oli aiemmin toteutettu vastaavia järjestelmiä. Käyttöliittymä suunniteltiin erillään muusta suunnittelusta prosessin suunnitteluvaiheessa. Heti projektin alussa asiakas kertoi taustatietoja ja projektiryhmälle esiteltiin 4 lomaketta, joihin pesimätiedot kerättiin kentällä pesätarkastuksien yhteydessä. Tietoa oli kerätty samoihin lomakkeisiin jo vuosia ja pesintäpaikalle pääsi käymään vain muutamat valitut henkilöt, joille nämä lomakkeet olivat tuttuja. Ideana oli, että lomakkeissa olevat tiedot talletetaan tietokantaan, josta sitten saadaan raportteja. Tietokannassa olevia tietoja täytyi myös pystyä päivittämään, ja luonnollisesti tietoa piti pystyä hakemaan tietokannasta. Tietokantaa ylläpitäisi ja käyttäisi toimistohenkilökunta. Lisäksi oli joitain etäkäyttäjiä, jotka ajaisivat raportteja. Koko ryhmä oli mukana vaatimusmäärittelyssä. Palavereita pidettiin kaksi viikossa ja ne kestivät yleensä kaksi tuntia. Asiakas ja käyttäjä olivat mukana joissain palaverissa. Jos projektiryhmän jäsenillä oli jotain kysyttävää, vastauksen sai seuraavassa palaverissa tai sähköpostitse. 3

4 Asiakkaan roolilla oli voimakas vaikutus projektin kulkuun. Asiakas oli jo muodostanut voimakkaan käsityksen, että järjestelmä muistuttaisi tietojenkäsittelytieteenlaitoksella aiemmin tehtyjä vastaavia järjestelmiä lintujen pesintätietojen tallettamiselle. Asiakas esitti omaaloitteisesti vaatimuksia ja projektin jäsenet kirjasivat vaatimukset ylös. Tiedon yksityiskohtaisen luonteen vuoksi tiedon ja toiminnallisuuden pystyi määrittelemään vain asiakas. Ryhmää ohjattiin ehkä väärään suuntaan, sillä kaikki tieto oli lomakkeilla ja asiakas painotti tietokannan suunnittelun tärkeyttä. Toiminnallisuuteen liittyvät vaatimukset kuvattiin käyttötapauksina, jotka jäivät hyvin pintapuolisiksi ja epätarkoiksi [1]. Suunnitteluvaiheessa projektiryhmän käytettävyysasiantuntijat suorittivat käyttäjähaastattelun ja tekivät paperiprototyypin käyttöliittymästä. Etukäteen oli selvää, että asiakas halusi samantyyppisen käyttöliittymän kuin vastaavissa järjestelmissäkin. Prototyyppiä esiteltiin käyttäjälle, asiakkaalle ja ryhmän muille jäsenille ja siitä kerättiin palautetta. Käyttöliittymän suunnittelussa käytettiin samoja käyttötapauksia kuin vaatimusmäärittelyssä - ne esitettiin ainoastaan tarkemmilla tilatiedoilla. Suunnitteluvaiheessa selvisi muun muassa että ohjelmiston toiminnallisuuden suunnittelusta vastaavien ryhmän jäsenten oli vaikea suunnitella toiminnallisuutta tietokannan ja käyttöliittymän välillä, koska ei ollut tiedossa millainen käyttöliittymä olisi. Suunnitteluvaihe alkoi viikon myöhässä ja vaatimusdokumenttiin tuli korjauksia tietokantakaavioon ja tietosisältöön vielä kahdeksan viikon ajan vaatimusmäärittelyvaiheen päätyttyä. Prosessimallina olevaa vesiputousmallia ei noudatettu tiukasti, sillä se olisi estänyt suunnittelun aloittamisen. Hali-projektin osalta toteutusta jatkettiin Kotkaprojektissa [11], koska ohjelman vaatimusten selvittämiseltä ja ohjelmiston määrittelyltä ei jäänyt enää juurikaan aikaa toteutukseen. Vaatimusdokumentin päivittäminen tietokannan osalta asiakkaan vaatimuksia vastaavaksi ei sinänsä voinut viedä paljoa aikaa, eikä yksinään selittää, miksi projekti ei pysynyt aikataulussaan. GUIDe-mallin vaikutus asiakkaan rooliin ja prosessiin Systemaattisessa käyttöliittymäsuunnittelussa asiantuntija selvittää vaatimukset systemaattisesti, eikä vain kuuntele, mitä asiakkaalla on sanottavaa. Tämä vaatii kuitenkin kokemusta, jota esimerkiksi Hali-projektin jäseniltä puuttui. Voisi kuitenkin ajatella, että GUIDe-mallin käyttö olisi pakottanut projektiryhmä aktiivisemmin selvittämään vaatimuksia sen sijaan, että ryhmä kuunteli, mitä asiakkaalla oli sanottavana. Systemaattinen käyttöliittymäsuunnittelu olisi saanut myös asiakkaan ja käyttäjän miettimään tiiviimmin vaatimuksia. Käyttöliittymäsuunnittelun sijoittaminen prosessin alkuun olisi hyvinkin lisännyt projektiryhmän ymmärrystä siitä, mitä ohjelmalta haettiin. Samalla projektin johto olisi tullut selkeästi projektiryhmälle. Yleensäottaen prosessin alkuun olisi tullut enemmän intensiteettiä ja tiedon vaihto olisi mahdollisesti tullut luontevammaksi. Vaatimusmäärittelyvaihe ei välttämättä olisi lyhentynyt sijoitettaessa käyttöliittymäsuunnittelu prosessin alkuun, mutta suunnitteluvaiheen alussa olisi mahdollisesti ollut kaikki tarvittava tieto käytettävissä. Hali-projektissa tavalliset palaverit eivät tuottaneet ainakaan parempaa tulosta kuin mitä GUIDe-mallin käyttäminen olisi tuottanut. Tiettyjen perusrakenteiden selvittämisessä käyttöliittymäsuunnittelu olisi voinut tuoda nopeammin selvennystä vaatimuksiin. Esimerkiksi merikotkat halusivat pitää useampaa pesää, eivät välittäneet kuntarajoista ja muuttivat reviiriäkin vuosittain. Lisäksi GUIDe-mallin käyttö olisi antanut asiakkaalle enemmän aikaa miettiä tarpeitaan ohjelmiston suhteen ja osa projektiryhmästä olisi voinut keskittyä teknisen osaamisensa kartuttamiseen. SQUID-projekti [7] osoitti, että jos ohjelmistoprojektin jäsenet lähtevät kenttätutkimusmenetelmillään selvittämään asiakkaan ja käyttäjän tarpeita, asiakas ja käyttäjä lähtevät tilanteeseen mukaan, vaikka mitä ilmeisemmin tämä vaati erityisen jämäkkää otetta projektiryhmän jäseniltä. Kun SQUID-projektissa ei tullut tulosta lähdettäessä liikkeelle asiakkaan esittämästä ratkaisusta, projektin jäsenet sivuuttivat asiakkaan ratkaisuehdotuksen ja menivät käyttäjän luo ja määrittivät sitä kautta ohjelmiston vaatimukset. Lopputulos oli SQUID-projektin osalta tuloksekas ja ohjelma sai toimivan ja helppokäyttöisen käyttöliittymän. Asiakas voi olla itsevarma ja hänellä voi mielestään olla selkeä kuva siitä, miten ohjelman tulee toimia. Hali- ja SQUID-projektit osoittavat, että asiakkaan käsitys ohjelmasta oli kuitenkin abstrakti sisältäen puutteita yksityiskohdissa. Jatkuva yksityiskohtien lisääminen tuottaa ongelmia erityisesti vesiputousmallissa. GUIDe-malli tuo käyttöliittymäsuunnittelun prosessin alkuun, jolloin lienee vähemmän tarvetta lisätä tietoa prosessin kuluessa. Samalla asiakkaan rooli muuttuu enemmän tuloksia seuraavaksi. Hali-projektin aikataulujen venyminen ja SQUIDprojektin onnistunut lopputulos antavat viitettä siitä, että projektiryhmän on voitava ja uskallettava sivuuttaa asiakkaan mielipiteet ja häiritä sekä asiakasta, että käyttäjää ja käytettävä heidän aikaansa. Jotta tämä tapahtuisi onnistuneesti, on asiakkaalle annettava mahdollisuus hyväksyä esitetty tulos ennen suunnittelua ja toteutusta. Systemaattinen käyttöliittymäsuunnittelun oikea paikka on vaatimusmäärittelyvaiheessa. OHJELMOIJAN ROOLIA PAINOTTAVA OHJELMISTOSUUNNITTELU Yrityskulttuurilla voi olla voimakas vaikutus siihen, miten käyttäjän mukana olemiseen suhtaudutaan ohjelmistokehitysprojektissa. Iivari on tutkinut yrityskulttuurin vaikutusta käyttäjien mukanaoloon ohjelmistosuunnitteluprosessissa [6]. Tutkimuksessa oli mukana kaksi yksikköä, joilla oli kokemusta käyttäjän mukanaolosta. Yksiköt saivat itse määritellä, millainen heidän työkulttuurinsa oli. Yksikössä A oli kolmen vuoden ajan toiminut käytettävyysasiantuntija ja yksikön johtaja painotti käyttäjän mukanaolon tärkeyttä. Nyt käytettävyysasiantuntijoita oli neljä ja loput ryhmän jäsenet olivat teknisesti suuntautuneita. 4

5 Yksikön A jäsenet kokivat olevansa arvostettuja työntekijöitä ja että kaikki ryhmän jäsenet kunnioittivat toisiaan alusta alkaen. He pitivät työn jatkuvaa mittaamista ja valvomista normaalina työnkuvana ja kokivat aikatauluissa pysymisen tärkeäksi. He pitivät myös tärkeänä, että heidän valmistamansa komponentti toimii yhteen koko järjestelmän kanssa. Yksiköllä B oli pitkä historia käyttäjien huomioimisesta ja käytettävyystestauksesta. Yksikkö oli jaettu käytettävyysyksikköön ja tekniseen yksikköön. Käytettävyydestä vastaavassa yksikössä toimi yksi käytettävyysasiantuntija ja graafinen suunnittelija, mutta sekä ryhmän vetäjä että johtaja olivat aiemmin toimineet käytettävyysasiantuntijoina. Toisen yksikön jäsenet olivat ohjelmoijia ja heillä oli oma ryhmän vetäjä. Yksikössä B pidettiin tärkeimpänä pysyä teknologisen kehityksen kärjessä. Heidän mielestään ihmiset haluavat kokeilla uusia asioita ja ihmisiä ei pidä valvoa. Työssä he saavat tehdä mitä haluavaa ja aloitteellisuuteen kannustettiin. Työilmapiirin harmonisuus ei ollut heille tärkeää vaan konflikteja saattoi syntyä, koska ryhmässä oli voimakkaita persoonallisuuksia. Pätevyyttä ja teknistä osaamista arvostettiin. Käytettävyysasiantuntijan mielestä tekniset asiantuntijat pitivät käytettävyysasiantuntijoita ainoastaan palvelijoinaan. Teknisen puolen ryhmän vetäjän mielestä tekniset asiantuntijat arvostivat innovatiivisuutta Miten kävi käyttäjän roolille Kummassakin yksikössä käyttäjän mukanaololla ajateltiin olevan merkitystä siihen, että käyttäjät pystyisivät tehokkaammin käyttämään ohjelmistoa. Käytettävyysasiantuntijoiden käyttämiä menetelmä ei Iivarin tutkielmassa käsitelty. Yksikössä A käytettävyysasiantuntija loi hieman naiivin persoonan nimeltä Eric edustamaan käyttäjän tietämystä ja taitoja tehdäkseen käyttäjät näkyvämmäksi ohjelmoijille. Ohjelmoijat kritisoivat, että Eric on liian tyhmä ja päättivät pitää Ericiä erikoistapauksena, jota ei tarvitse ottaa huomioon ohjelmaa suunniteltaessa. Ohjelmoijat päätyivät huomioimaan ainoastaan kokeneen käyttäjän. Yksikössä B ajateltiin, että kukaan ei halua suunnitella ohjelmistoa, joka ei ota käyttäjää huomioon. He ajattelivat, että heillä on yhteinen tavoite yksikön sisällä. Ohjelmoijat kuitenkin ajattelivat itse edustavansa tyypillistä käyttäjää, mikä ei miellyttänyt käytettävyysasiantuntijaa. Ohjelmoijilla oli kuitenkin vapaus hylätä täysin käytettävyysasiantuntijan laatimat määrittelyt. Käytettävyysasiantuntijan mielestä näyttikin siltä, että yritykselle riittää, että yrityksellä on tieto käytettävyydestä, vaikka se ei päätyisikään lopputuotteeseen. Kuten Iivari esittääkin, käyttäjien rooliksi jää konsultoida käytettävyysasiantuntijoita. Pahimmillaan käyttäjien konsultointi on passiivista esimerkiksi tavanomaisia haastatteluja kontekstuaalisten haastattelujen sijaan. Iivari myös esittää, että näissä tapauksissa ohjelmoijat eivät saa paljoakaan tietoa käyttäjistä ja käytettävyysasiantuntijoiden työksi jää kommentoida ohjelmoijien tuloksia. Ongelmaa lisää, että ohjelmoijat kuitenkin suunnittelevat käyttöliittymän. GUIDe-mallin vaikutus ohjelmistosuunnittelijan rooliin Yrityskulttuurin painottuessa voimakkaasti ohjelmoijan rooliin pelkkä GUIDe-mallin käyttö tuskin riittää. Lundell ja Notess viittaavat siihen, että käyttäjän tarpeet saadaan parhaiten ohjelmaan, jos käyttöliittymäsuunnittelu tehdään prosessin varhaisessa vaiheessa ja käytettävyysasiantuntija on mukana ohjelmiston suunnittelussa ja toteutuksessa yhtenä ryhmän jäsenenä [9]. Käytettävyysasiantuntijan tulisikin aktiivisesti vaikuttaa siihen, että käyttäjältä saatu tieto päätyisi lopputuotteeseen. Käytettävyysasiantuntijan mukanaolo tuotekehitysryhmässä mahdollistaa nopean palautteen ohjelmistokehittäjien ja käytettävyysasiantuntijan välillä. Gulliksenin et al. tekemässä tutkimuksessa [3] ilmenee, että ohjelmistokehitysprosessin jäsenet kaipaavat käyttöliittymäsuunnittelun integrointia osaksi ohjelmistokehitysprosessia. GUIDe-prosessimalli, jossa systemaattinen käyttöliittymäsuunnittelu toteutetaan vaatimusmäärittelyvaiheen alussa, ei juurikaan muuta valitun ohjelmistokehitysprosessin muita vaiheita, mutta tuo suunnitellun käyttöliittymän osaksi asiakkaan vaatimuksia [8]. Lisäksi GUIDe-mallin käyttö mahdollistaa käyttäjän aktiivisen konsultoivan roolin, jossa tietoa siirtyy suunnittelijoiden käyttöön. Jos ohjelmistosuunnittelussa käytetään keksityn hahmon sijaan todellista hahmoa, joka oikeasti tekee työtä, käyttäjän tarpeita on vaikeampi sivuuttaa. YHTEENVETO GUIDe-prosessimalli sisältää kokoelman yleisesti hyväksi havaittuja menetelmiä [12]. GUIDe määrittelee systemaattisen käyttöliittymäsuunnittelun sijainnin prosessin alkuun, mikä osaltaan voisi ratkaista ohjelmistosuunnittelijoiden kokemaa tarvetta käyttöliittymäsuunnittelun integroinnista ohjelmistokehitysprosessiin. Mielestäni GUIDe-mallin käyttö kokonaisuudessaan muuttaa käyttäjän roolia aktiiviseksi tiedon tuottajaksi lisäämällä käyttäjän yhteenkuuluvuuden tunnetta projektiryhmän käytettävyysasiantuntijoiden kanssa. Tämä edelleen lisää viestintää ja tiedon siirtoa käyttäjän ja projektin jäsenten välillä. Käyttäjän uudelleenkäyttäminen testausvaiheessa ja iterointikierroksilla lisää käyttäjän tietoisuutta tulevasta ohjelmasta, tekniikan antamista mahdollisuuksista ja omasta työprosessistaan. Iteratiivinen suunnittelumalli mahdollistaa tulosten esittämisen käyttäjälle ja käyttäjäpalautteen saamisen. Tavoitepohjaiset käyttötapaukset ja niiden simulointi näyttökuvien avulla antavat asiakkaalle ja käyttäjälle mahdollisuuden reagoimalla kommunikoida tarpeitansa ohjelmiston suhteen. Kaiken kaikkiaan käyttäjän rooli tulee selkeämmin ja aktiivisemmin esille säilyttäen kontrollin ohjelmistosuunnittelijoilla (käytettävyyssuunnittelijat). Asiakas ei voi vain luetella vaatimuksia vaan joutuu miettimään tarkemmin sellaisen asiantuntemuksen luotsaamana, jota hänellä itsellään ei ole. Ongelmaksi jää käyttäjätarpeiden muuntaminen vaatimuksiksi, jotka ohjelmoijat voivat toteuttaa. 5

6 GUIDe-mallin käyttö yksinään ei kuitenkaan riitä siirtämään käyttäjän tarpeita lopputuotteeseen. Ongelmaksi koetaan edelleen johdon tuen puute [3] tai johdon tuen näennäisyys [6], jolloin ohjelmistosuunnittelijat voivat edelleen sivuuttaa käytettävyysasiantuntijoiden mielipiteet. Ongelmaksi jää myös viestintä ja priorisointi käyttöliittymäsuunnittelijoiden ja muun ohjelmistosuunnitteluryhmän välillä. GUIDe-mallin käyttö vaikuttaa käyttäjän rooliin, mutta samalla käyttäjän lisääntynyt yhteenkuuluvuus ja kommunikointi rajautuu käyttöliittymäsuunnittelijoiden ja käyttäjän välille. Voisi ajatella, että GUIDe-malli sopii parhaiten pienten projektiryhmien käyttöön vähättelemättä sen osuutta käyttöliittymäsuunnittelussa yleensä. LÄHTEET 1. Annala, O. et al. Vaatimusdokumentti v.1.7. Ohjelmistotuotantoprojekti Hali, Helsingin yliopisto, Helsinki, Suomi, Beyer, H.R., Holtzblatt, K. Apprenticing With the Customer. Communications of the ACM 38, 5 (1995), Gulliksen, J., Boivie, I., Persson, J., Hektor, A., Herulf, L. Making a difference: a survey of the usability profession in Sweden. In Proc. NordiCHI '04, ACM Press (2004), Hartwick, J., Barki, H. Communication as a Dimension of User Participation. IEEE Transactions on Professional Communication 44, 1 (2001), He, J. Knowledge Impacts of User Participation: A Cognitive Perspective. In Proc. SIGMIS'04, ACM Press (2004), Iivari, N. Enculturation of User Involvement in Software Development Organizations - An Interpretive Case Study in the Product Development Context. In Proc. NordiCHI '04, ACM Press (2004), Kaipiainen, S. Projekti SQUID: Suprajohtavan magnetometrin käyttöliittymä. /tutkielmat/kaipiainen-samuli-squid-tutkielma.pdf. 8. Laakso, S.A., Laakso, K.-P. Hyvän käyttöliittymän varmistaminen GUIDe-prosessimallilla Lundell, J., Notess, M. Human factors in software development: models, techniques, and outcomes. In Proc. SIGCHI'91, ACM Press (1991), Ohjelmistotuotantoprojekti Hali Ohjelmistotuotantoprojekti Kotkat Vredenburg, K., Mao, J-Y., Smith, P.W., Carey, T. A Survey of User-Centered Design Practice. In Proc. SIGCHI '02, ACM Press (2002), Visser, F.S., Visser, V. Re-using users: co-create and co-evaluate. Personal and Ubiquitous Computing 10, 2 (2006),