Ohjelmistoyritysten käytettävyyskäytännöt

Transkriptio

1 Aalto-yliopisto Perustieteiden korkeakoulu Tietotekniikan koulutusohjelma Ohjelmistoyritysten käytettävyyskäytännöt Kandidaatintyö 29. huhtikuuta 2012 Tero Lindholm

2 Aalto-yliopisto Perustieteiden korkeakoulu Tietotekniikan koulutusohjelma KANDIDAATINTYÖN TIIVISTELMÄ Tekijä: Tero Lindholm Työn nimi: Ohjelmistoyritysten käytettävyyskäytännöt Päiväys: 29. huhtikuuta 2012 Sivumäärä: 45 Pääaine: Mediatekniikka Koodi: IL3011 Vastuuopettaja: Ma professori Tomi Janhunen Työn ohjaaja(t): DI Petri Mannonen (Tietotekniikan laitos) Korkeatasoinen käytettävyys tukee ohjelmistojen menestymistä markkinoilla sekä tehostaa käyttäjien työskentelyä. Tätä tavoitetta tukemaan on kehitetty suunnitteluprosesseja, jotka voidaan sulauttaa osaksi tuotekehitysprojekteja. Työn tavoitteena on selvittää noudattavatko Suomen suurimpien ohjelmistoalan yritysten projektit alan standardi suunnitteluprosessimallia, vai varmistetaanko käytettävyyttä lainkaan. Työssä tutustutaan suurien ohjelmistoyritysten tuotekehitysprojekteihin. Projektikertomukset on kerätty yritysten työntekijöitä haastattelemalla. Tuotekehitysprojektien kulkua verrataan ISO standardin mukaiseen ihmiskeskeiseen suunnitteluprosessimalliin. Projektikertomusten perusteella suurten yritysten tuotekehitysprojekteissa käytettävyys varmistetaan käytettävyys arvioinneilla, ainakin kehitettäessä tuotetta omaan käyttöön. On hyvin projektikohtaista, kuinka selvästi ihmiskeskeisen projektimallin vaiheet siitä löytyvät. Löytyi projekteja, jotka noudattavat hyvin formaalisti standardin suunnitteluprosessimallia, mutta myös projekteja, joita ei voida pitää standardin mukaisina. Työn perusteella voidaan nähdä, että käytettävyyden merkitys ollaan yrityksissä tiedostettu ja sitä pyritään kehittämään projekteissa. Tästä huolimatta käytettävyys arviointien tuomaa lisäarvoa, ei yrityksissä juuri mitata ja näin käytettävyydestä saatavat positiiviset vaikutukset saattavat jäädä havaitsematta. Avainsanat: Kieli: ihmiskeskeisyys, käyttäjäkeskeisyys, käytettävyys, ohjelmistokehitys, ohjelmistoyritys, haastattelu Suomi 2

3 Sisältö Käytetyt lyhenteet ja termit 4 1 Johdanto 6 2 Teoreettinen tausta Käytettävyyteen liittyvien termien määritelmiä Ihmiskeskeinen suunnitteluprosessi Ihmiskeskeisen suunnittelun periaatteet Ihmiskeskeinen suunnitteluprosessi Tutkimusaineisto 15 4 Projektikertomusten analysointi Projekti 1 standardin mukainen suunnitteluprosessi sekä vahva käytettävyydenvarmistus julkaisun jälkeen Projekti 2 standardin mukainen sekä vahvasti iteratiivinen Projekti 3 perusteelliset alkuselvitykset Projekti 4 käytettävyyden varmistusta läpi projektin Projekti 5 käytettävyyden varmistuksen karsiminen nopeiden tulosten varmistamiseksi Projekti 6 vahva pohjustus Projekti 7 irrallinen käytettävyyden varmistusprojekti Projekti 8 formaalia käytettävyystestausta Projektien yhteenveto Yhteenveto 32 Lähteet 34 A Liitteet 36 B Liitteet 37 3

4 Käytetyt lyhenteet ja termit Heatmapping Ihmiskeskeinen suunnittelu ISO Iterointi Itsekuvautuvuus Ketterä ohjelmistokehitys Kognitiivinen läpikäynti Käyttäjäpohjainen testaus Käyttöskenaario Leaduser LUCID Nielsenin heuristiikat Proaktiivisuus PACT Kerätyn matriisimuodossa olevan tiedon mallintamista graaffisesti värejä hyödyntäen. Suunnittelumenetelmä, joka tähtää järjestelmien käytettävyyden parantumiseen sekä ihmisten kokeman käyttäjäkokemuksen edistymiseen. Kutsutaan myös käyttäjäkeskeiseksi suunnitteluksi. International Organization for Standardization. Kansainvälinen standardisoimisjärjestö. Menettelytapa, johon kuuluu samojen työvaiheiden toistaminen, kunnes haluttu lopputulos on saavutettu. Ohjelmiston käytön vaiheiden hahmottamisen ilmeisyys. Kuinka ilmeistä käyttäjälle on mitä hän on suorittamassa, kuinka pitkällä suoritus on ja mitä hän seuraavaksi voi tehdä. Yleisnimitys joukolle ohjelmistokehitysmenetelmiä, joille toimiva ohjelmisto, nopea muutokseen reagonti ja välitön vuorovaikutus ovat kattavaa dokumentointia ja suunnittelua tärkeämpiä. Tarkistuspohjainen arviointimenetelmä. Loppukäyttäjät osallistuvat tuotteen arviointiin. Kutsutaan myös empiiriseksi käyttäjätestaukseksi. Kuvaa käyttäjän toimenpiteet halutun päämäärän saavuttamiseksi. Edelläkävijäkäyttäjä. Käyttäjä, joka havaitsee tarpeet jo kuukausia tai vuosia ennen suuria massoja (Hippel (1986)). Logical User-Centered Interaction Design. Vuorovaikutteisten järjestelmien suunnittelumalli. Nielsen (1994) kehittämä tarkistuspohjainen arviointimenetelmä. Aktiivista vastuun ottamista omasta käyttäytymisestä. Valinnat pohjautuvat omiin päätöksiin, eikä toisten mielipiteisiin. (Katajainen et al. (2005)) People, Activities, Contexts, Technologies; A framework for designing interactive systems. Vuorovaikutteisten järjestelmien suunnittelumalli. 4

5 Rautalankamalli SFS Skaalakysymys Sprintti Srum Subjektiivinen evaluointi Tarkastuspohjainen arviointi THA UX Käyttöliittymän sisällön, toimintojen, siirtymien ja ulkoasun luonnosteluun tarkoitettu menetelmä. Suomen standardisoimisliitto SFS ry. Kyselytyyppi, jossa kysymyksille annetaan useita vastausvaihtoehtoja. Samat vaihtoehdot kaikille kysymyksille. 1-4 viikkoa kestävä kehitysjakso, jonka aikana pyritään toteuttamaan tietty osakokonaisuus valmiiksi. Eräs ketterän ohjelmistokehityksen menetelmistä, jossa projektin kulku muodostuu sprinteistä. Yksilön henkilökohtaiseen näkemykseen perustuva arviointi Arviointimenetelmä, jossa tuotteen tai suunnitelman tarkistaa usein käytettävyysasiantuntija erilaisten käytettävyysperiaatteiden perusteella. Kutsutaan myös asiantuntija-arvioksi. Thinking aloud; Ääneen ajattelu. Käytettävyystestissä koehenkilö ilmaisee kaikki ajatukset, tunteet ja ideat mitä hänelle tulee mieleen testin aikana (Holzinger ja Brown (2008)). User Experience; Käyttäjäkokemus. Tuotteen tai palvelun synnyttämät tuntemukset. 5

6 1 Johdanto Tuotteiden käytettävyydestä ja käyttäjän kokemasta käyttökokemuksesta puhutaan hyvin paljon, ja niiden tärkeyttä tuotteen menestymisen kannalta korostetaan usein. On selvää, että käyttäjät käyttävät mielummin tuotteita, joiden käyttö on luontevaa ja sujuvaa, kuin tuotteita, joiden käyttö aiheuttaa jatkuvia ongelmatilanteita. Tietokoneohjelmistoista puhuttaessa myös työnantajat tiedostavat, että sovelluksen loppukäyttäjä pystyy hyödyntämään sovellusta tehokkaammin, mikäli sen käyttö on ongelmatonta ja jouhevaa. Käytettävyydeltään korkeatasoiset tuotteet ovat tyypillisesti myös kaupallisesti menestyvämpiä (SFS-EN ISO (2010)). Ohjelmistojen käytettävyyden testaaminen ja mittaaminen ovat työvaiheita, joilla pystytään tukemaan ohjelmiston käytettävyyden kehittymistä ja käyttäjän kokemaa käyttökokemusta. Käytettävyyttä voidaan testata ja mitata erilaisilla malleilla ja menetelmillä, joiden soveltuvuus kyseiselle ohjelmistolle tulee aina harkita tapauskohtaisesti. Näiden testien organisoiminen kuluttaa niukkoja resursseja, ja siksi on vaara, että niiden toteuttamista laiminlyödään. Käytettävyyden suunnittelu, toteutus ja testaus integroidaan usein osaksi käytössä olevaa ohjelmistokehityskäytäntöä, ja niiden saama huomio saattaa siten jäädä liian vähäiseksi. Lisäksi käytettävyyden tuomaa lisäarvoa ohjelmalle on vaikeata mitata. Tämä saattaa johtaa siihen, ettei käytettävyyden varmistamiselle budjetoida riittävästi varoja ohjelmistokehitysprojektissa. Tämä johtuu siitä, että on vaikeaa vaatia varoja työhön, jonka tuloksista on vaikea saada konkreettista näyttöä. Tilannetta pahentaa se tosiasia, että ohjelman tilaaja ei välttämättä toimi aina itse loppukäyttäjänä ja saattaa näin tavoitella säästöjä karsimalla käytettävyystestausta ohjelmistokehityksestä. Tässä työssä tutustutaan Suomen suurimpien ohjelmistoyritysten tämänhetkisiin käytettävyyskäytäntöihin, eli siihen, kuinka yritykset ovat organisoineet käytettävyyden suunnittelun, toteutuksen testauksen ja arvioinnin osana omaa ohjelmistokehitystään. Nämä tulokset perustetaan yrityksien kertomiin projektikertomuksiin. Projektikertomukset kerättiin kunkin yrityksen työntekijältä, joka on itse osallistunut kyseiseen tuotekehitystapaukseen. Tällä tavalla varmistetaan realistisen ja paikkansapitävän tiedon saanti. Tutkimuksen tarkoitus ei ole selvittää, kuinka käytettävyys tulisi yrityksien tuotekehityksessä huomioida tai kuinka se haluttaisiin huomioida. Työssä tullaan keskittymään, kuinka käytettävyyden huomiointikäytännöt suurissa ohjelmistoalan yrityksissä suhteutuvat alan standardiin. 6

7 2 Teoreettinen tausta Seuraavat kappaleet tulevat esittelemään ihmiskeskeisyyden huomioinnin osana ohjelmistokehitysprosessia. Työn varsinainen analyyttbiinen osuus tulee pohjautumaan seuraavaksi esiteltyyn teoriaan. Suunnitteluprosessi on malli, jonka avulla suunnittelijat kykenevät varmistamaan ihmiskeskeisyyden huomioinnin osana ohjelmistosuunnitteluprojektien kaikkia vaiheita. Tämä tukee tavoitetta rakentaa käyttäjäystävällisiä ohjelmistoja loppukäyttäjien tarpeisiin. 2.1 Käytettävyyteen liittyvien termien määritelmiä Käytettävyydestä keskusteltaessa on syytä määritellä siihen liittyvää terminologiaa, sillä käsitteiden monitahoisuus ja samankaltaisuus saattavat aiheuttaa väärinymmärryksiä. ISO (International Organization for Standardization) määrittelee ISO (Näyttöpäätteillä tehtävän toimistotyön ergonomiset vaatimukset. Osa 11: Käytettävyyden määrittely ja arviointi) -standardissa käytettävyyden seuraavasti: Käytettävyys mittaa, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi (ISO : 1998, s. 6). Jotta käytettävyyttä voitaisiin määritellä ja mitata, tulee hahmottaa seuraavat tekijät: tavoitteet, käytettävyyden mittarit ja käyttötilanne. Tavoitteella tarkoitetaan haluttua lopputulosta, sitä mitä halutaan prosessin lopulta tuottavan. On erittäin tärkeää määritellä tavoitteet yhdessä tuotteen tai palvelun tilaajan kanssa. Muuten koko loppu prosessi saattaa johtaa väärään lopputulokseen. Käytettävyyden mittarit ovat tuloksellisuus, tehokkuus ja tyytyväisyys. Tuloksellisuus tarkoittaa tarkkuutta ja täydellisyyttä, jolla käyttäjät saavuttavat asetetut tavoitteet. Tehokkuus taas osoittaa voimavarojen käytön ja tuloksellisuuden suhteen, käyttäjien saavuttaessa tavoitteet. Tyytyväisyys kuvastaa myönteistä suhtautumista tuotteen käyttöön sekä epämukavuuden puuttumista. Käyttötilanteella tarkoitetaan tuotteen käyttäjien, tehtävien, laitteiden sekä fyysisen ja sosiaalisen ympäristön muodostamaa kokonaisuutta. Käyttäjiksi nähdään kaikki henkilöt jotka ovat vuorovaikutuksessa tuotteen kanssa. Heillä on taas tehtävä, joka kuvaa toimia, jotka käyttäjien on toteutettava tavoitteiden saavuttamiseksi. Nämä toimet voivat olla joko fyysisiä tai kognitiivisia. Tähän he tarvitsevat laitteita eli laitteistoja, ohjelmistoja ja aineistoja. Tekijöiden väliset suhteet on esitetty kuvassa 1. (SFS-EN ISO (2010)) 7

8 Kuva 1: Käytettävyyden osatekijät 2.2 Ihmiskeskeinen suunnitteluprosessi Jotta ohjelmistokehityksessä osattaisiin ottaa huomioon riittävästi ohjelman käytettävyys, on sitä varmistamaan laadittu useita menetelmiä ja suunnitteluprosesseja. Näistä tunnetuin oli ISO (Vuorovaikutteisten järjestelmien ihmiskeskeinen suunnitteluprosessi), jonka korvasi vuonna 2010 julkaistu saman niminen ISO Standardi opastaa käytettävyyden huomioinnissa läpi koko tuotekehityskaaren, aina tarpeiden analysoinnista julkaisun jälkeisiin toimiin. Tällä pyritään varmistumaan siitä, että toteutettavat tuotteet ovat kokonaisuudessaan onnistuneita käytettävyydeltään. Vaihtoehtoisia menetelmiä ovat myös Jakob Nielsenin Usability Engineering Life Cycle, Logical User- Centered Interaction Design (LUCID) sekä A framework for designing interactive systems (PACT). Jakob Nielsenin Usability Engineering Life Cycle sisältää 11 vaihetta, joita seuraamalla käytettävyys kyetään huomioimaan läpi koko ohjelmistokehitysprojektin. Vaiheet ovat: käyttäjän tunteminen, kilpailijoiden analysointi, käytettävyystavoitteiden asettaminen, yhtäaikainen suunnittelu, osallistuva suunnittelu, käyttöliittymän suunnittelu, heuristinen arviointi, prototyyppien toteutus, käytettävyystestaus, iteratiivinen suunnittelu ja käytöstä saatavan palautteen kerääminen. Kaikkia vaiheita ei ole välttämätöntä toteuttaa jokaisessa projektissa, vaan harkinnan mukaan voidaan projektikohtaisesti jättää joitain vaiheita pois. Nielsen (1993) Usability Engineering Life Cycle on sisällöltään hyvin samankaltainen SFS-EN ISO (2010) -standardin kanssa, molemmat myös painottavat iteratiivisuutta sekä käyttäjien aikaista huomiointia. 8

9 LUCID muodostuu kuudesta askeleesta, joita käydään läpi iteratiivisesti, kuten ISO mallissakin. Ensimmäinen askel on visiointi, jolloin muodostetaan selvä visio kehitettävästä tuotteesta. Toinen askel on havainnointi, jolloin selvitetään korkean tason käyttäjävaatimukset. Kolmas askel on perustan suunnitteleminen. Askeleeseen kuuluu korkean tason määrittelyt sekä tärkeimpiä näkymiä mallintavan prototyypin luonti. Luonnosten oikea suunta tulee varmistaa käyttäjätesteillä. Luonnoksia tulee kehittää testeistä saadun palautteen perusteella iteratiivisesti. Neljännessä askeleessa suunnitelmat tarkennetaan lopullisiksi määritelmiksi. Viides askel sisältää tuotteen toteutuksen. Käytettävyysasiantuntijat voivat tukea kehitystä antamalla palautetta kehitteillä olevasta tuotteesta. Viimeinen askel on tuotteen julkaisu, jota varten tulee kehittää suunnitelma käyttäjien tukemiseksi uuden tuotteen käyttöönotossa. Projektin aikana opitut asiat tulee myös dokumentoida ylös. (Cognetics Corporation, Charles B. Kreitzberg (1996)) PACT (People, Activities, Contexts, Technologies) keskittyy lähinnä analysoimaan suunniteltavan tuotteen vaatimuksia eri näkökulmista. Menetelmän toimintaperiaatteen mukaan suunnittelijoiden tulee selvittää eri menetelmiä, kuten käyttäjien seurantaa tai haastatteluja hyödyntäen eri osa-alueiden vaatimukset. Havaintojen varaan voidaan luoda käyttöskenaario, jonka pohjalta lähdetään toteuttamaan itse tuotetta. PACT menetelmän käyttö sijoittuu ohjelmistoprojektien alkuun. (Benyon et al. (2005)) Ihmiskeskeisen suunnittelun periaatteet ISO (2010, s ) -standardin mukaiset ihmiskeskeisen suunnittelun periaatteet ovat: suunnittelun lähtökohtana on käyttäjien, tehtävien ja ympäristön selkeä ymmärtäminen käyttäjät pidetään mukana koko suunnittelun ja kehityksen ajan ihmiskeskeinen arviointi ohjaa suunnittelua suunnitteluprosessin on oltava iteratiivinen käyttäjäkokemus otetaan kokonaisuutena huomioon suunnittelussa suunnitteluryhmän on oltava monialainen Suunnittelun tulee perustua käyttäjien, tehtävien ja ympäristön tarkkaan hahmottamiseen, koska niiden virheellinen tai vajavainen ymmärtäminen on eräs suurimmista syistä järjestelmien epäonnistumiselle. Käyttäjiä ajateltaessa on syytä muistaa huomioida myös muut sidosryhmät, joihin järjestelmän käyttö vaikuttaa suorasti tai epäsuorasti. (SFS-EN ISO (2010)) 9

10 Pitämällä käyttäjät mukana suunnittelussa ja kehityksessä läpi koko prosessin, saadaan heiltä arvokasta tietoa tuotteen käyttötilanteesta sekä sen halutuista toiminnallisuuksista. Käyttäjiltä on myös mahdollista saada välitöntä palautetta tuotetta koskevista suunnitelmista ja usein heiltä saa myös kehitteillä olevaa tuotetta koskevia kehitysehdotuksia. Ottamalla loppukäyttäjät osaksi suunnitteluprosessia, on myös mahdollista saada heidät hyväksymään uusi tuote käyttöön helpommin, kun he voivat nähdä oman panoksensa vaikutukset suunnitteluun. (SFS-EN ISO (2010)) Käyttäjiltä saatava palaute on ihmiskeskeisen suunnittelun kriittinen tietolähde. Käyttäjiltä saatavan palautteen huomioiminen osana suunnittelua sekä siihen reagoiminen, on varma tapa pienentää projektin epäonnistumisen riskiä. Käyttäjät kykenevät havaitsemaan jopa tekijöitä, joita ei ole osattu alunperin määritelläkään. Ihmiskeskeisellä arvioinnilla kyetään myös hyväksyttämään lopullinen tuote asiakkaalla. Näin asiakas kykenee varmistumaan, että vaatimukset on täytetty. Käyttäjätesteistä saadaan myös laajempaa käytettävyystietoutta, jota kyetään hyödyntämään myöhemmin muiden järjestelmien suunnittelussa. (SFS-EN ISO (2010)) Johtuen ihmisen ja tietokoneen vuorovaikutuksen monimutkaisuudesta on hyvin epätodennäköistä, että ensimmäinen suunnitelma vastaisi kaikkia toiveita ja määritelmiä. Tämän takia suunnitelmaa on kehitettävä iteratiivisesti saadun palautteen mukaisesti. Iteraatioiden aikana kehittäjät saavat käyttäjiltä uutta palautetta, kun loppukäyttäjien ymmärrys kehitteillä olevasta tuotteesta paranee tuotteen kehittyessä. Samalla myös kehittäjien käsitys tuotteesta tarkentuu. (SFS-EN ISO (2010)) On virheellistä kuvitella, että palvelun tai tuotteen käytettävyydellä tarkoitettaisiin vain sen helppokäyttöisyyttä. Käytettävyys on käsitteenä paljon tätä laajempi. Se sisältää myös esimerkiksi käyttäjäkokemuksesta syntyviä tunteellisia näkökulmia, eli kuinka miellyttävää tai innostavaa tuotteen käyttö on. Haluttaessa kehittää käytettävyydeltään korkeatasoinen tuote on otettava huomioon tekijöitä käyttäjien koulutuksesta aina tuotepakkaukseen saakka. Myös käyttäjän havaitsema mainonta tai tuotemerkin maine on otettava huomioon tuotetta suunniteltaessa. Näin ollen suunnittelun tulee kohdistua koko käyttäjäkokemukseen. (SFS-EN ISO (2010)) Jotta kyetään suunnittelemaan useita näkökulmia huomioon ottava tuote, tulee suunnitteluryhmästä löytyä monien eri osaamisalueiden edustajia. Ryhmästä olisi hyvä löytyä esimerkiksi käytettävyyden, käyttöliittymäsuunnittelun, markkinoinnin, järjestelmäsuunnittelun sekä sovellusalueen asiantuntijoita. Monialainen suunnitteluryhmä kykenee tunnistamaan kunkin alan tunnusomaiset vaatimukset ja rajoitteet, sekä oppimaan samalla toisten alojen tunnuspiirteitä. (SFS-EN ISO (2010)) 10

11 2.2.2 Ihmiskeskeinen suunnitteluprosessi ISO (2010, s ) -standardin mukaisesti suunnitteluprosessin tulee muodostua seuraavasti: 1. Suunnitelman laatiminen ihmiskeskeisestä suunnitteluprosessista 2. Käyttötilanteen ymmärtäminen ja määrittely 3. Käyttäjävaatimusten ymmärtäminen ja määrittely 4. Suunnitteluratkaisujen tuottaminen 5. Suunnitteluratkaisujen arviointi vaatimusten suhteen 6. Vaiheita toistetaan iteratiivisesti, kunnes suunnitteluratkaisu täyttää käyttäjien vaatimukset Ensimmäisenä on laadittava suunnitelma ihmiskeskeisyyden huomioinnista osana suunnitteluprosessia. Ihmiskeskeisyys on sisällytettävä jokaiseen tuotteen elinkaaren vaiheeseen, niin luonnosvaiheeseen, analyysiin, suunnitteluun, toteutukseen, testaukseen kuin ylläpitoonkin. On tärkeää laatia suunnitelma siitä, kuinka käytettävyyden huomiointi otetaan kussakin aktiviteetissa (käyttötilanteen määrittely ja ymmärtäminen, käyttäjävaatimusten määrittely ja ymmärtäminen, suunnitteluratkaisujen tuottaminen, suunnitteluratkaisujen arviointi vaatimusten suhteen) huomioon. Tällä taataan ettei, yksikään osa-alue jää kokonaan huomioimatta. Suunnittelua laadittaessa on myös huomioitava, kuinka merkityksellinen asia tuotteen käytettävyys on tuotteen käyttötarkoituksen kannalta sekä millaisia riskejä huono käytettävyys saattaa luoda. Ihmiskeskeisen suunnittelun suunnitelmassa tulee tunnistaa mitä menetelmiä ja resursseja tarvitaan suunnitteluprosessin aktiviteettien läpivientiin. On myös tunnistettava henkilöt tai organisaatiot, joiden vastuulla ihmiskeskeinen suunnittelu on, sekä asetettava välitavoitteita suunnittelun eri aktiviteeteille. Jotta käyttäjiltä saatuun palautteeseen ehditään reagoimaan ja suunnittelusta tekemään oikeasti iteratiivista, kuten kuvassa 2 on hahmotettu, on projektin aikatauluun sisällytettävä riittävästi aikaa iteratiivisuudelle. Varsinkin projektin alkuvaiheeseen on varattava riittävästi aikaa yleiselle keskustelulle, ongelmien tunnistamiselle sekä niiden ratkaisemiselle. Ihmiskeskeisyyden huomioimisen aloittaminen heti projektin alkumetreillä on tärkeää, koska ongelmien havaitsemisella projektin alkuvaiheessa, vältytään kalliilta korjauksilta projektin loppuvaiheessa. Ihmiskeskeisen suunnittelun suunnitelma on integroitava osaksi koko projektisuunnitelmaa, sekä sitä tulee kohdella kuten muitakin projektisuunnitelman osia. Suunnitelman toteutuminen tulee olla jonkun vastuulla sekä sen etenemistä tulee valvoa. (SFS-EN ISO (2010)) 11

12 Ihmiskeskeisen suunnitteluprosessin suunnittelun jälkeen lähdetään muodostamaan ymmärrystä käyttötilanteesta. Käyttötilanne muodostuu käyttäjien ominaisuuksista, tehtävistä sekä ympäristöstä. Mikäli kehitettävästä tuotteesta on olemassa jo toiminnassa oleva vanha järjestelmä, voidaan tästä kerätä paljon käyttötilanteeseen liittyvää informaatiota. Vanhaa järjestelmää tutkittaessa tai siitä tehtyjä vanhoja tutkimuksia analysoitaessa kyetään hahmottamaan ja priorisoimaan tarpeita, ongelmia sekä rajoituksia. (SFS-EN ISO (2010)) Käyttötilanteen kuvauksen tulee sisältää SFS-EN ISO (2010) mukaan seuraavat kohdat: 1. Käyttäjien ja muiden sidosryhmien tunnistaminen. Tuotteeseen vaikuttaa myös toissijaisten käyttäjien tarpeet. Heidän jotka eivät ole suorassa kosketuksessa tuotteen kanssa. Myös näiden sidosryhmien tarpeet tulee tunnistaa sekä niiden merkityksellisyys suunnitelmaan on tiedostettava. 2. Käyttäjien tai käyttäjäryhmien ominaisuuksien tunnistaminen. Muun muassa käyttäjien tiedot, taidot, kokemukset, tavat, mieltymykset tai kyvyt voivat vaihdella suuresti kohdekäyttäjäkunnan sisällä. Jotta kaikki kohdekäyttäjäkunnan edustajat kykenisivät käyttämään tuotetta miellyttävästi, on käyttäjien kykyjen erot huomioitava suunnitelmassa. 3. Käyttäjien tavoitteiden ja tehtävien tunnistaminen. On tunnistettava tavoitteet, jotka käyttäjät haluavat tavoittaa tuotteen käytöllä sekä käytettävyyden kannalta olennaiset tehtävien ominaisuudet. Näitä voi olla esimerkiksi käyttäjien tottumukset suorittaa kyseinen tehtävä, tehtävän suorituksen tyypillinen kesto sekä sen riippuvuudet muihin järjestelmiin. On tärkeää myös tunnistaa riskit, joita tehtävän suoritukseen voi liittyä. Esimerkiksi väärän lopputuloksen mahdollisuus tai turvallisuusriskit. 4. Järjestelmän ympäristön tunnistaminen. Ympäristön muodostaa tekninen (laitteet, ohjelmistot ja materiaalit), fyysinen (työskentelyolosuhteet), sosiaalinen sekä kulttuurillinen ympäristö (työkäytännöt, asenteet). Ihmiskeskeisen suunnitteluprosessin seuraava vaihe on käyttäjävaatimusten ymmärtäminen ja määrittely. Tässä vaiheessa tulisi ensisijaisesti tunnistaa käyttäjien sekä sidosryhmien tarpeet, samalla huomioiden käyttötilanne. Myös käyttäjätarpeiden ja käyttötilanteen asettamat vaatimukset, erilaisten standardien asettamat vaatimukset, käytettävyysvaatimukset ja -tavoitteet sekä organisaation käyttäjälle asettamat vaatimukset on tunnistettava. Kehityksen kohteena olevan järjestelmän käyttäjävaatimuksista riippuen, se 12

13 saattaa sisältää myös paineita organisaation ja työtapojen uudistamiselle. Tässä tapauksessa aiheesta on hyvä keskustella myös organisaation sidosryhmien kanssa jo varhaisessa vaiheessa. (SFS-EN ISO (2010)) Lähtökohtien selkeän hahmottamisen jälkeen on vuorossa suunnitteluratkaisun tuottaminen kerättyyn tietoon pohjautuen. Suunnitteluratkaisua rakennettaessa on huomioitava käyttäjätyytyväisyys, käyttäjien tuloksellisuus ja tehokkuus eli käyttäjäkokemus kokonaisuudessaan. Suunnitteluratkaisussa tulisi huomioida SFS-EN ISO (1996) (Ihmisen ja järjestelmän vuorovaikutuksen ergonomia. Osa 110: Dialogin periaatteet.) - standardin mukaiset periaatteet: tehtävään sopivuus, itsekuvautuvuus, yhdenmukaisuus käyttäjän odotusten suhteen, oppimiseen sopivuus, hallittavuus, virhesietoisuus sekä mahdollisuus yksilöllistämiseen. Itsekuvautuvuus kuvaa sitä, kuinka ilmeistä käyttäjälle on, mitä hän on juuri ohjelmalla suorittamassa, kuinka pitkällä suoritus on ja mitä hän seuraavaksi kykenee tekemään (SFS-EN ISO (2010)). Suunnitteluratkaisun tulisi sisältää käyttäjien, tehtävien ja järjestelmän välisen vuorovaikutuksen suunnittelun sekä käyttöliittymän suunnittelun. Nämä tulisi myös käytännössä konkretisoida skenaarioita, prototyyppejä tai muita mallinnuskeinoja hyödyntäen. Tämä auttaa projektin sidosryhmiä hahmottamaan suunnitelmat. Suunnitteluratkaisua on myös oltava valmis kehittämään saadun palautteen tai tehtyjen arviointien perusteella. On myös tärkeää informoida luodusta käyttäjäkokemuksen huomioivasta suunnitelmasta, tuotteen toteutuksesta vastaavia tahoja. Tämä mahdollistaa vuorovaikutuksen tuotekehityksen eri osastoiden välillä, jolloin toteutuksesta vastaava taho kykenee informoimaan käyttäjäsuunnittelijoita teknisistä rajoituksista. Menettely takaa realistisen käytettävyyssuunnittelun. (SFS-EN ISO (2010)) Luotua suunnitteluratkaisua tulee myös arvioida eri menetelmillä, jotta siitä kyettäisiin karsimaan virheitä pois sekä havaitsemaan uusia käyttäjätarpeita. Mitä aikaisemmassa vaiheessa suunnitelmaa arvioidaan, sitä vähäisemmiksi virheistä aiheutuneet kustannukset ehtivät kasvamaan. Arviointimenetelmät voidaan jakaa kahteen pääkategoriaan, käyttäjäpohjaiseen testaukseen ja tarkastuspohjaiseen arviointiin. Jälkimmäistä kutsutaan myös usein asiantuntija-arvioinniksi. Käyttäjäpohjaisessa testauksessa tuotteen loppukäyttäjät osallistuvat tuotteen arviointiin, kun taas tarkastuspohjaisen arvioinnin suorittaa useimmiten käytettävyyden asiantuntija. Molemman tyyppisistä testeistä saatavaa tietoa kyetään hyödyntämään varmistettaessa ennalta määriteltyjen käyttäjävaatimusten toteutuminen. Saatavilla arvioinneilla kyetään myös suorittamaan eri suunnitelmaversioiden keskinäistä arviointia. On muistettava, että ainoastaan testien järjestäminen ei ole itseisarvoista, vaan on muistettava myös analysoida, priorisoida sekä hyödyntää saatuja arviointeja suunnitelman iteratiivisessa kehityksessä. Arviointeja on suoritettava riittävästi, jotta taataan kriittisimpien havaintojen esilletulo. Arviointimenetelmiä valittaessa on harkittava myös käytännöllisyyden, kustannusten ja aikataulujen merkitystä. 13

14 Parhaaseen lopputulokseen päästään yleensä yhdistämällä eri arviointimenetelmiä. Yksi kustannustehokas vaihtoehto voi olla seuraavan kaltainen. Ensin arvioidaan tuotetta tarkastuspohjaisella arvioinnilla ja tästä saatavan tiedon perusteella korjataan tuotteesta merkittävimmät virheet ja vasta tämän jälkeen suoritetaan testausta loppukäyttäjillä. On hyvä muistaa, ettei arvioinnin pitäisi päättyä tuotteen julkaisuun, vaan tuotetta olisi hyvä seurata ja arvioida myös pitkällä aikavälillä. Usein vuorovaikutteisesta järjestelmästä nousee esiin tekijöitä vasta pitkäaikaisen käytön jälkeen. Tällaista informaatiota olisi hyvä kerätä tuotteista uusien vastaavien tuotteiden kehitystä varten. (SFS-EN ISO (2010)) Kuva 2: Ihmiskeskeisen suunnitteluprosessin aktiviteettien keskinäiset riippuvuudet 14

15 3 Tutkimusaineisto Työn lähtökohtana toimi rajauksen mukaisesti Suomen suurimmilta yrityksiltä kerätyt projektikertomukset. Projektikertomukset on koottu yritysten työntekijöille tehtyjen haastatteluiden pohjalta. Enemmistö haastattelun antaneista edellytti projektikertomuksen kuvaamista anonyymisti, joten päätettiin liittää työhön kaikki kertomukset anonyymeinä. Nämä projektikertomukset löytyvät työn liitteestä B. Ensimmäisenä selvitettiin Suomen 20 suurinta ohjelmistoalan yritystä (Liite A). Tämä lista koottiin Tietoviikon ja Talouselämän laatimasta selvityksestä, jossa listattiin Suomen 250 suurinta tieto- ja viestintätekniikka-alan yritystä vuonna 2010 (Tietoviikko ja Talouselämä (2010)). Listalle valittiin selviä ohjelmistoalan yrityksiä niiden liikevaihdon suuruuden perusteella. Seuraavaksi haettiin LinkedIn:in Aalto Usability Group:ista henkilöitä, jotka työskentelisivät työn rajaukseen kuuluvissa yrityksissä. Ryhmästä löytyi 11 sopivaa henkilöä. Kyseistä LinkedIn-ryhmää päätettiin käyttää pääasiallisena yhteystieto lähteenä, koska oli oletettavaa, että kyseisen ryhmän henkilöt, olivat lähtökohtaisesti kiinnostuneita käytettävyydestä ja toivottavasti valmiita myös edesauttamaan siihen liittyvän työn teossa. Sopivia henkilöitä lähestyttiin sähköpostitse, jossa esiteltiin työn tekijä, kandidaatintyön aihe sekä pyyntö haastatteluun osallistumisesta. Sähköpostia saaneet vastasivat hyvin vaihtelevasti haastattelupyyntöön. Muutama henkilö vastasi vielä saman vuorokauden aikana, mutta läheskään kaikki eivät. Noin viikon kuluttua ensimmäisistä yhteydenotoista lähetettiin muistutusviesti henkilöille, joilta ei ollut vielä saapunut vastausta. Muistutusviestiin vastattiin jo huomattavasti aktiivisemmin. Useat ilmoittivat olevansa halukkaita osallistumaan työhön, mutta selvittivät vielä lupaa haastattelun antoon. Muutama henkilö ei kyennyt itse osallistumaan haastatteluun, mutta lupasi joko ajaa asiaa eteenpäin tai antaa uuden yhteystiedon henkilöstä, joka olisi mahdollisesti sopiva haastatteluun. Kuudesta haastattelusta viisi järjestettiin haastateltavan firman tiloissa ja yksi yliopiston käytettävyyslaboratoriossa. Haastattelun kulku noudatti aina samaa linjaa. Haastattelun alussa kerrattiin haastattelun lähtökohdat. Haastattelun kuluessa pyrkimys oli antaa haastateltavan kertoa projektikertomustaan rauhassa omaan tahtiin. Samalla kirjattiin ylös asioita, joihin kaivattiin täsmennyksiä. Nämä asiat käytiin läpi haastateltavan kerrottua projektikertomus kokonaisuudessaan. Koko haastattelu nauhoitettiin ääninauhurilla, ja tämän nauhoituksen pohjalta haastattelut kirjoitettiin myöhemmin puhtaaksi. Puhtaaksi kirjoitetut haastattelut lähetettiin vielä haastatelluille henkilöille tarkistettavaksi ja hyväksyttäviksi, jotta projektikertomukset varmasti vastaisivat todellisuutta. Kaksi yritystä antoi kaksi projektikertomusta, joten tutkimus pohjautuu yhteensä kahdeksaan projektikertomukseen. 15

16 4 Projektikertomusten analysointi Seuraavissa kappaleissa jokaisesta projektista on muodostettu taulukko projektikertomuksen perusteella. Taulukoista nähdään mitä ISO (2010) -standardin ihmiskeskeisen suunnitteluprosessin vaiheita sisältyy projektikertomuksiin. Projektikertomukset löytyvät työn liitteestä. Taulukkoa edeltää vielä sanallisessa muodossa projektikertomuksen sisältö sekä projektikohtaisia havaintoja. Projektit 1-5 ovat yrityksen sisäisiä tuotekehitysprojekteja ja projektit 6-8 asiakkaan tilausprojekteja. 4.1 Projekti 1 standardin mukainen suunnitteluprosessi sekä vahva käytettävyydenvarmistus julkaisun jälkeen Taulukosta 1 nähdään, että projektissa käytiin läpi lähes kaikki ISO standardin mukaiset ihmiskeskeisen suunnitteluprosessin vaiheet, sekä se sisälsi paljon iteratiivisuutta. Käyttäjien huomioimisesta vastasi kokonainen ryhmä, jonka lisäksi testausta tilattiin alihankintana. Koko projektin aikana käytettävyystesteihin osallistui toistasataa loppukäyttäjää. Projektikertomuksesta ei ilmene, kuinka formaalia suunnitelmaa ihmiskeskeisestä suunnitteluprosessista laadittiin ennen käyttötilanteen ja käyttäjävaatimusten selvitystä. Ihmiskeskeisen suunnitteluprosessin välttämättömyys oli kuitenkin selvästi havaittu, koska päätettiin selvittää loppukäyttäjien tarpeet kattavasti aikaa kestävän käyttöliittymän tuottamiseksi. Seuraavaksi selvitettiin käyttötilanne ja käyttäjävaatimukset usealla eri menetelmällä. Hyödynnettiin vanhoja havaintoja ja palautteita, teetätettiin käytettävyystestausta sekä heuristista arviointia. Kerätyn tiedon pohjalta muodostettiin suunnitelma ihmiskeskeisestä suunnitteluprosessista. Suunnitelmaa myös mallinnettiin flash-prototyypeillä, joille suoritettiin käytettävyystestausta. Saatua palautetta hyödyntäen prototyypeistä valittiin yksi, jonka kehitystä jatkettiin. Tämän jälkeen seurasi iteratiivinen suunnitelmien kehitys- ja käytettävyystestausvaihe. Neljännen iteraation päätteeksi versio meni tuotantoon. Tuotteen kehitys ei päättynyt tähän, vaan tuotteelle tehdään kuukausittain käytettävyystesti, josta saadut havainnot järjestetään kriittisyyden perusteella ja niistä kriittisimmät pyritään korjaamaan seuraavaan käytettävyystestiin mennessä. (Liite B: Tuotekehitysprojekti 1) 16

17 Taulukko 1: Projektikertomus 1:n suhteutuminen ihmiskeskeisen suunnitteluprosessin vaiheisiin Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -2. käyttötilanteen ymmärtäminen ja määrittely. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Saatujen palautteiden yhteen keräys ja analysointi. -Käytettävyystestausta vanhalle tuotteelle alihankintana. -Heuristista arviointia omalle sekä kilpaileville tuotteille alihankintana. -TOP 10 listan laatiminen tärkeimmistä kehityskohteista. -1. suunnitelman laatiminen ihmiskeskeisestä suunnitteluprosessista. -Tarkennus suunnitelmaan: panostetaan erityisesti keskeisimpien toimintojen suoritusten käyttökokemuksen kehittämiseen. -4. suunnitteluratkaisujen tuottaminen. -Uuden ulkoasun suunnittelua ja luonnostelua. -Parhaaksi nähtyjen luonnosten mallintaminen flash-prototyypiksi. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypeille. -Käytettävyystestejä järjestettiin ominai- suuksiltaan erilaisille loppukäyttäjille. -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella valittiin prototyypeistä yksi jatkokehitykseen. -Teknisestä toteutuksesta vastaavalta osastolta saatujen rajoituksien huomioiminen suunnitelmissa. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. -Menetelminä käytettiin ainakin loppukäyt- täjän toimien havainnointia sekä heatmapping:iä. jatkuu seuraavalle sivulle 17

18 Taulukko 1 jatkoa edelliseltä sivulta Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella kehitettiin prototyypistä uusi versio. -Palautetta saatiin enemmän, kuin kyettiin huomioimaan. Palautteet priorisoitiin ja merkittävimmät havainnot huomioitiin suunnitelmassa välittömästi. Loput dokumentoitiin myöhempää huomiointia varten. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella kehitettiin prototyypistä uusi versio. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella kehitettiin prototyypistä uusi versio. -Käytettävyystesteistä kerättiin prototyyppikohtaista dataa, jolloin kyettiin vertailemaan prototyypin ominaisuuksien kehittymistä -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. Tuotteen julkaisu -Tuotteen arviointi vaatimusten -Käytettävyystestausta prototyypille. -Kehitysratkaisujen tuottaminen. -Käytettävyystestin aika tehtyjen havaintojen priorisointi ja kehitystarpeiden listaaminen. Kaksi viimeisintä vaihetta toistetaan kerran kuukaudessa. 4.2 Projekti 2 standardin mukainen sekä vahvasti iteratiivinen Projekti 2 eteni hyvin standardin suosittamalla tavalla. Heti projektin alussa projektisuunnitelmaan kirjattiin suunnitelma ihmiskeskeisestä suunnitteluprosessista. Seuraavaksi siirryttiin palvelun ja sen käyttäjien määrittelyyn. Projektikertomuksesta ei selvästi il- 18

19 mene hyödynnettiinkö käyttäjiä määritelmien validointiin. Luodun suunnitelman perusteella suunniteltiin rautalankamalli, jonka pohjalta lähdettiin toteuttamaan toiminnallista prototyyppiä, jota tulevat loppukäyttäjät pääsivät arvioimaan. Tämän lisäksi järjestettiin työpajoja, joissa loppukäyttäjien kanssa keskusteltiin palvelun kehityssuunnista. Toiminnallisen prototyypin iteratiivinen testaus ja kehitysjakso kesti kaksi kuukautta, jonka aikana palvelusta toteutettiin myös varsinainen palvelu. Tämän jälkeen itse palvelua kehitettiin jälleen iteratiivisesti kahden kuukauden ajan. Tähän jaksoon kuului yhä käyttäjien suorittamaa käyttötestausta, työpajoja, mutta näiden lisäksi myös kaksi käytettävyystestitapahtumaa, joiden aikana suoritettiin yhteensä 20 käytettävyystestausta. Käytettävyystesteistä vastasi käytettävyysvastaava. Palvelun kehitys ei päättynyt tuotteen julkaisuun, vaan tuotetta kehittää yhä konseptisuunnittelija sekä käytettävyystestaaja. Palvelun käytettävyys varmistetaan myös aina ennen suuria julkaisuja järjestettävillä käytettävyystesteillä. Yritys on myös onnistunut tuotteistamaan alkujaan omaan käyttöön suunnitellun palvelun. Tätä kautta palvelulle on saatu myös uusia vaatimuksia markkinoilta, joiden mukaan palvelua on uusittu. Palvelua on onnistuttu hyödyntämään myös tehtäviin, joihin sitä ei alunperin oltu suunniteltukaan. (Liite B: Tuotekehitysprojekti 2) Taulukko 2: Projektikertomus 2:n suhteutuminen ihmiskeskeisen suunnitteluprosessin vaiheisiin Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -1. suunnitelman laatiminen ihmiskeskeisestä -Suunnitelmat ihmiskeskeisyyden huomioinmaan. suunnitteluprosessista. nin vaiheista kirjattiin projektisuunnitel- -2. käyttötilanteen ymmärtäminen ja määrittely. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Tavoitteen mukaisen tuotteen palvelukonseptin ja toimintamallin määrittely. -Tärkeimpien toiminnallisuuksien ja loppukäyttäjien määrittely. -4. suunnitteluratkaisujen tuottaminen. -Rautalankamallin luonti suunnitelmien pohjalta. Kuvasi palvelun sisällön, toiminnallisuudet sekä arviointikriteerit. -Prototyypin luonti. -5. suunnitteluratkaisujen arviointi vaatimusten -Käyttäjätestausta demoluontoiselle palve- lulle. -4. suunnitteluratkaisujen tuottaminen. -Demoa kehitettiin käyttäjien antamien arvosteluiden perusteella. jatkuu seuraavalle sivulle 19

20 Taulukko 2 jatkoa edelliseltä sivulta Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -5. suunnitteluratkaisujen arviointi vaatimusten -Käyttäjätestausta demoluontoiselle palve- lulle. - Työpaja palvelun kehityssuunnista. -4. suunnitteluratkaisujen tuottaminen. -Demoa kehitettiin käyttäjien antamien arvosteluiden sekä työpajasta saatujen havaintojen perusteella. -5. suunnitteluratkaisujen arviointi vaatimusten -Käyttäjätestausta demoluontoiselle palve- lulle. -4. suunnitteluratkaisujen tuottaminen. -Demoa kehitettiin käyttäjien antamien arvosteluiden perusteella. -5. suunnitteluratkaisujen arviointi vaatimusten -Käyttäjätestausta demoluontoiselle palve- lulle. - Työpaja palvelun kehityssuunnista. -4. suunnitteluratkaisujen tuottaminen. -Demoa kehitettiin käyttäjien antamien arvosteluiden sekä työpajasta saatujen havaintojen perusteella. -Tuotteen toiminnallisuuden tuottaminen. -Palvelun toiminnallisuuden toteuttaminen. -Tuotteen toiminnallisuuden arviointi vaatimusten -Käyttäjätestausta toiminnalliselle palvelulle palvelun välityksellä. -Käytettävyystestausta. -Tuotteen toiminnallisuuden tuottaminen. -Palvelua kehitettiin käyttäjien antamien arvosteluiden sekä käytettävyystesteistä saatujen havaintojen perusteella. -Tuotteen toiminnallisuuden arviointi vaatimusten -Käyttäjätestausta toiminnalliselle palvelulle palvelun välityksellä. -Työpaja palvelun kehityssuunnista. -Tuotteen toiminnallisuuden tuottaminen. -Palvelua kehitettiin käyttäjien antamien arvosteluiden sekä työpajasta saatujen havaintojen perusteella. -Tuotteen toiminnallisuuden arviointi vaatimusten -Käyttäjätestausta toiminnalliselle palvelulle palvelun välityksellä. -Käytettävyystestausta. -Tuotteen toiminnallisuuden tuottaminen. -Palvelua kehitettiin käyttäjien antamien arvosteluiden sekä käytettävyystesteistä saatujen havaintojen perusteella. jatkuu seuraavalle sivulle 20

21 Taulukko 2 jatkoa edelliseltä sivulta Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -Tuotteen toiminnallisuuden arviointi vaatimusten palvelun välityksellä. -Käyttäjätestausta toiminnalliselle palvelulle -Työpaja palvelun kehityssuunnista. -Tuotteen toiminnallisuuden tuottaminen. -Palvelua kehitettiin käyttäjien antamien arvosteluiden sekä työpajasta saatujen havaintojen perusteella. Tuotteen julkaisu -Tuotteen toiminnallisuuden arviointi vaatimusten -Käytettävyystestausta ennen isompia jul- -Käyttäjiltä saatava palaute. kaisuja. -Tuotteen toiminnallisuuden tuottaminen. -Palvelua kehitetään käyttäjien antamien arvosteluiden sekä käytettävyystesteistä saatujen havaintojen perusteella. -2. käyttötilanteen ymmärtäminen ja määrittelykinoilta. -Palvelulle on saatu uusia vaatimuksia mark- -3. käyttäjävaatimusten ymmärtäminen ja määrittely. 4.3 Projekti 3 perusteelliset alkuselvitykset Taulukko 3 osoittaa, että kyseisen projektin kehitys oli iteratiivista ja loppukäyttäjienkin mielipiteitä selvitettiin käytettävyystesteillä. Projektin kehitysryhmän muodostivat kuusi henkilöä, joista yksi tuli yrityksen käyttäjäkokemuksesta vastanneesta ryhmästä. Projektikertomuksessa ei kuitenkaan mainita lainkaan ihmiskeskeisen suunnitteluprosessin suunnittelemisesta. Joten prosessin muotoutuminen ja kulku oli yksin tuotekehitysryhmään kuuluneen UX(User Experience)-ryhmän edustajan vastuulla. Käyttötilanteen ja käyttäjävaatimuksien määrittelyitä saatiin valmiina jo yrityksen business-puolen määritteleminä, mutta tuotekehitysryhmä tarkensi niitä vielä haastattelemalla loppukäyttäjiä. Määrittelyjen pohjalta luotiin ensin PowerPoint -luonnoksia, joista siirryttiin toiminnallisiin demo-käyttöliittymiin, joita testattiin loppukäyttäjillä. Projekti sisälsi kolme iteratiivista testaus- ja kehityssykliä. Varsinaisen tuotteen teknisessä toteutusvaiheessa ei järjestetty käytettävyystestausta, koska aikaisemmista testeistä oli jo saatu niin paljon palautetta, ettei niitäkään kaikkia kyetty aikataulun puitteissa kehittämään. Tuotteen kehitystä ja käytettävyystestausta jatkettiin seuraavassa projektissa, joka jatkoi kehitys- 21

22 tä siitä, mihin edellinen projekti oli päättänyt, eli kehitys ei loppunut julkaisuun. (Liite B: Tuotekehitysprojekti 3) Taulukko 3: Projektikertomus 3:n suhteutuminen ihmiskeskeisen suunnitteluprosessin vaiheisiin Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -2. käyttötilanteen ymmärtäminen ja määrittely. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Valmiiksi saatuja vaatimuksia tarkennettiin haastattelemalla loppukäyttäjiä. -Vanhan tuotteen muutostarpeen analysointi. -4. suunnitteluratkaisujen tuottaminen. -Uuden ulkoasun suunnittelua ja luonnostelua PowerPoint:lla. -Luonnoksien mallintaminen demo-koodilla. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypeille. -Käytettävyystestejä järjestettiin aidoille loppukäyttäjille. -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella prototyyppiä kehitettiin. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Käytettävyystesteistä saatiin uusia tarvekuvauksia loppukäyttäjiltä. -4. suunnitteluratkaisujen tuottaminen. -Kaikkia käytettävyystesteissä havaittuja tarpeita ei kyetty toteuttamaan aikataulun takia. Kaikki havainnot kuitenkin kirjattiin ylös myöhempää käyttöä varten. -Merkittävimmät tarpeet huomioitiin välittömästi. -5. suunnitteluratkaisujen arviointi vaatimusten -Käytettävyystestausta prototyypille. -4. suunnitteluratkaisujen tuottaminen. -Saadun palautteen perusteella prototyyppiä kehitettiin. -Samalla kehitettiin jo varsinaista tuotetta. Tuotteen julkaisu -Tuotteen arviointi vaatimusten -Käytettävyystestausta tuotteelle. -Kehitysratkaisujen tuottaminen. -Saadun palautteen perusteella tuotteen kehittämistä. 22

23 4.4 Projekti 4 käytettävyyden varmistusta läpi projektin Projektin vaatiman tuotteen määrittelyt haettiin ensisijaisesti jo yrityksen hallussa olevasta käyttäjätiedosta asiantuntijoiden toimesta. Loppukäyttäjien toimia myös seurattiin, määritelmien täsmentämiseksi. Tämän tiedon varaan rakennetun konseptin paikkansapitävyys varmistettiin vielä loppukäyttäjille suoritetuilla haastatteluilla. Projektikertomuksessa ei mainita lainkaan ihmiskeskeisen suunnitteluprosessin suunnittelua, eikä kertomuksessa myöskään kerrota suunnitteluratkaisuiden tuottamisesta millään menetelmillä. Kertomuksen perusteella ei ole selvää, kenen vastuulla koko tuotteen käytettävyys oli. Yksittäisten toiminnallisuuksien käytettävyydestä vastasi yksittäinen käytettävyysasiantuntija. Kertomuksen mukaan kehityksessä siirryttiin suoraan konseptoinnin jälkeen konkreettiseen ohjelmointiin, joka oli hajautettu useille scrum-ryhmille. Jokaiseen ryhmään kuului käytettävyysasiantuntija, joka suoritti erittelemättömän määrän käytettävyystestejä. Tämän lisäksi käytettävyyttä koskevaa palautetta saatiin oheistuotteena funktiotesteistä. Tuotteen viimeistelyvaiheessa suoritettiin vielä kymmenillä loppukäyttäjillä käytettävyystestausta. Määrä nähtiin riittäväksi alussa suoritetun konseptin oikean suunnan varmistamisen sekä tuotekehityksen aikana suoritettujen testien vuoksi. Tuotteen julkaisun jälkeen käyttäjiltä kerättiin vielä palautetta, mutta projektikertomus ei kerro kuinka palautetta hyödynnettiin tuotteen kehityksessä. (Liite B: Tuotekehitysprojekti 4) Taulukko 4: Projektikertomus 4:n suhteutuminen ihmiskeskeisen suunnitteluprosessin vaiheisiin Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -2. käyttötilanteen ymmärtäminen ja määrittely. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Strategian mukaisen tuotteen määritelmiä selvitettiin yrityksen sisäisestä dokumentoidusta käyttäjätiedosta. -Vaatimuksia selvitettiin myös seuraamalla loppukäyttäjien toimintaa heidän toimintaympäristössä. -4. suunnitteluratkaisujen tuottaminen. -Tiedon perusteella hahmoteltiin konseptia. -5. suunnitteluratkaisujen arviointi vaatimusten -Hahmotellun konseptin vastaavuus strategituilla aan varmistettiin kohdemarkkinoilla suorite- yksittäisten loppukäyttäjien haastatteluilla sekä ryhmähaastatteluilla. jatkuu seuraavalle sivulle 23

24 Taulukko 4 jatkoa edelliseltä sivulta Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -5. suunnitteluratkaisujen arviointi vaatimusten taamalle osakokonaisuudelle. -Käytettävyystestausta scrum-ryhmän vas- -5. suunnitteluratkaisujen arviointi vaatimusten myös käytettävyydestä. -Funktiotestauksen ohessa saatiin palautetta -5. suunnitteluratkaisujen arviointi vaatimusten testausta loppukäyttäjillä. -Määrättyjen ominaisuuksien käytettävyys- Tuotteen julkaisu -Tuotteen arviointi vaatimusten -Eri tiedonkeruukanavista saatava palaute. 4.5 Projekti 5 käytettävyyden varmistuksen karsiminen nopeiden tulosten varmistamiseksi Taulukosta 5 havaitaan, että projektissa selvitettiin tuotetta koskevat määritelmät, mutta tämän jälkeen siirryttiin suoraan ohjelmoimaan tuotetta ja käytettävyystestejä suoritettiin vasta lopuksi, josta seurasi toiminnallisuuksien korjailua. Tuotekehityksestä vastannut ryhmä muodostui ohjelmoijista, testaajasta sekä vuorovaikutussuunnittelijasta, kenen vastuulla oli tuotteen käytettävyyden suunnittelu. Projektin aluksi määritettiin käyttäjät sekä heidän ominaisuuksien pohjalta määriteltiin tuotteen toiminnallisuudelle kriteerit. Toiminnallisuuden sekä vaatimusten varmistamiseksi suoritettiin myös loppukäyttäjän toiminnan havainnointia tuotteen tulevassa käyttöympäristössä. Tuotteen hahmottamiseksi muodostettiin myös käyttötapausskenaarioita ja käyttäjäprofiileita, joiden varaan luotiin tuotteen design. Seuraavaksi siirryttiin jo ohjelmoimaan, koska haluttiin saada tuotteen fyysistä kehitystä eteenpäin. Tästä syystä projektissa otettiin tietoinen riski, että osa toteutetuista toiminnallisuuksista ei välttämättä täyttäisi loppukäyttäjien vaatimuksia. Vasta tuotteen toiminnallisen version toteutuksen jälkeen sitä testautettiin loppukäyttäjillä. Havaittuja kehitystarpeita korjattiin ja tuotteen toiminnallisuutta optimoitiin kertomuksessa sen tarkemmin erittelemättömien iteraatioiden aikana. Kertomuksesta ei ilmene jatkettiinko kehitystä tuotteen julkaisun jälkeen. (Liite B: Tuotekehitysprojekti 5) 24

25 Taulukko 5: Projektikertomus 5:n suhteutuminen ihmiskeskeisen suunnitteluprosessin vaiheisiin Ihmiskeskeisen suunnitteluprosessin vaihe Projektin vaihe -2. käyttötilanteen ymmärtäminen ja määrittely. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Loppukäyttäjien rajaus. -Loppukäyttäjistä johdettiin tuotteen toiminnallisuuden määritelmät. -Vaatimuksia selvitettiin myös seuraamalla loppukäyttäjien toimintaa heidän toimintaympäristössä. -4. suunnitteluratkaisujen tuottaminen. -Kerätyn tiedon pohjalta rakennettiin käyttötapausskenaarioita ja käyttäjäprofiileita. -Tuotteen designin ja grafiikan luominen. -Tuotteen toiminnallisuuden tuottaminen. -Palvelun toiminnallisuuden toteuttaminen. -Tuotteen toiminnallisuuden arviointi vaatimusten -Käyttäjätestausta toiminnalliselle tuotteelle. -3. käyttäjävaatimusten ymmärtäminen ja määrittely. -Käyttäjätesteissä selvisi määrittelemättömiä tuotteelta vaadittuja ominaisuuksia. -Tuotteen toiminnallisuuden tuottaminen. -Käytettävyystesteistä saadut palautteet huomioiden, tuotetta kehitettiin. 4.6 Projekti 6 vahva pohjustus Projekti 6 oli jälleen asiakasprojekti. Taulukosta 6 nähdään, että tuotetta koskevia määritelmiä haettiin markkinoilla jo olleista tuotteista sekä tuotetta luonnosteltiin demoksi asti, jo ennen varsinaisen tilauksen saapumista. Toteutettu demo auttoi varmasti tilaajaa hahmottamaan toimitusratkaisua, jota hänelle oltiin tarjoamassa. Tässä vaiheessa tilaaja kykeni myös määrittelemään tarpeitaan ja käyttäjiä tarkemmin. Tilauksen varmistumisen jälkeen tuotteesta luotiin rautalankamalli, joka kuvasi tuotteen toiminnallisuudet. Rautalankamallille suoritettiin vielä asiantuntija-arviointia yrityksen sisällä, ennen kuin sen pohjalta toteutettiin prototyyppiä. Prototyypille järjestettiin vielä erittelemätön määrä käyttäjätestejä loppukäyttäjillä. Tämän jälkeen siirryttiin tuotteen ohjelmointiin, jonka aikana vuorovaikutussuunnittelijan näkemyksiä myös kysyttiin. Kun tuotteesta oli saatu toiminnallinen versio valmiiksi, järjestettiin sille käyttäjätestausta jälleen erittelemätön määrä. Käyttäjätesteistä saadut tulokset vaikuttivat siihen, milloin tuotteen nähtiin vastaavan tilaajan tarpeita ja näin ollen olevan valmis. Kertomuksessa ei mainita projektin 25