KÄYTTÄJÄKESKEINEN SUUNNITTELU STARTUP-YRITYKSISSÄ

Transkriptio

1 AALTO-YLIOPISTO Perustieteiden korkeakoulu Informaatioverkostojen koulutusohjelma Emil Virkki KÄYTTÄJÄKESKEINEN SUUNNITTELU STARTUP-YRITYKSISSÄ Kandidaatintyö Helsinki, Vastuuopettaja: Stina Immonen Työn ohjaaja: Petri Mannonen

2

3 Aalto-yliopisto Perustieteiden korkeakoulu Informaatioverkostojen koulutusohjelma KANDIDAATINTYÖN TIIVISTELMÄ Tekijä: Emil Virkki Työn nimi: KÄYTTÄJÄKESKEINEN SUUNNITTELU STARTUP-YRITYKSISSÄ Sivumäärä: 21 Päiväys: Julkaisukieli: suomi Pääaine: Ihminen ja vuorovaikutus Pääaineen koodi: IL3008 TIIVISTELMÄ Startup-yritykset ovat olleet esillä julkisuudessa viime vuosina. Startup-yritykset ovat nuoria yrityksiä, jotka etenevät nopeasti ja joustavasti etsiessään markkinoitaan ja tarjoamaansa. Yritysten pienistä resursseista huolimatta käyttäjäkeskeinen suunnittelu on niille vähintään yhtä tärkeää kuin vakiintuneille yrityksille. Startup-yritysten vaatimusten ja käyttäjäkeskeisen suunnittelun yhdistämisestä ei kuitenkaan löytynyt aiempaa tutkimusta. Tässä kandidaatintyössä pyrittiin selvittämään millaisia menetelmiä startup-yritykset käyttävät käyttäjäkeskeiseen suunnitteluun ja millaisia kokemuksia niillä on eri mentelmistä. Tutkimus toteutettiin kvalitatiivisena haastattelutukimuksena, johon osallistui 12 yritystä. Tutkimuksessa keskityttiin pääkaupunkiseudulla toimiviin ohjelmistoja ja ohjelmistopohjaisia palveluita suunnitteleviin startup-yrityksiin. Yleisimmiksi menetelmiksi osoittautuivat analytiikka, lainaaminen muista palveluista, haastattelut, vapaa käyttäjäpalaute, kyselyt sekä käyttäjätestit. Neljässä yrityksessä yhdistettiin kvantitatiivista ja kvalitatiivista tietoa Riesin The Lean Startupin hengessä. Tutkimuksessa selvisi, että startup-yritykset käyttävät vielä kevyempiä menetelmiä kuin perinteiset alennuskäytettävyysmenetelmät (discount usability), eikä menetelmiä usein sovelleta systemaattisesti. Yhdessäkään yrityksessä ei ollut formaalia, dokumentoitua, käyttäjäkeskeistä prosessia. Yritysten kokemuksiin eri menetelmistä ei saatu luotettavaa vastausta, sillä yritykset eivät vielä tässä liiketoiminnan vaiheessa kyenneet arvioimaan eri menetelmien toimivuutta. Työn ohjaaja(t): Petri Mannonen Vastuuopettaja: Stina Immonen Asiasanat: Käyttäjäkeskeinen suunnittelu, startup-yritykset

4 Sisällysluettelo TIIVISTELMÄ 1 Johdanto Teoreettinen tausta Käyttäjäkeskeinen suunnittelu Startup-yritysten toimintatavat Käyttäjäkeskeinen suunnittelu vähillä resursseilla Menetelmät ja aineisto Tulokset ja niiden tarkastelu Kokonaisprosessi A/B-testaus Analytiikka Asiantuntija-arvioinnit Haastattelut Kyselyt Käyttäjäpalautteen kerääminen Käyttäjätestaus Käyttäjäyhteisöt Lainaaminen muista palveluista Persoonat Skenaariot Kvantitatiivisen ja kvalitatiivisen tiedon yhdistäminen Tulosten arviointi Yhteenveto Johtopäätökset Lähdeluettelo Liitteet Liite 1: Haastattelurunko Liite 2: Haastattelujen yhteenvedot... 4

5 1 Johdanto Startup-yritykset ovat olleet esillä julkisuudessa viime vuosina. Ne ovat nuoria yrityksiä, joille on ominaista nopealiikkeisyys ja markkinoiden etsiminen. Hyvä käyttäjäkokemus on startup-yrityksille yhtä tärkeää kuin suurille vakiintuneille yrityksille, sillä kilpailu on kovaa. Pienen yrityksen resurssit eivät kuitenkaan riitä perinteisiin, raskaisiin käyttäjäkeskeisiin menetelmiin. Käyttäjäkeskeisten menetelmien ja startup-yritysten vaatimusten yhteensovittamisesta ei kuitenkaan löytynyt kirjallisuutta. Tästä syystä aihe oli tutkimuskohteena hyvin kiinnostava. Erilaiset kevyet käyttäjäkeskeisen suunnittelun menetelmät, kuten Jacob Nielsenin discount usability, alennuskäytettävyys, voisivat antaa startup-yrityksille mahdollisuuden tarjota hyviä käyttökokemuksia ilman kohtuuttomia taloudellisia uhrauksia. Raskaat, pitkäkestoiset ja vesiputousmaiset käyttäjäkeskeiset suunnitteluprosessit ja menetelmät eivät suoraan sovi startup-yrityksille paitsi kalleutensa vuoksi, myös siksi, että yritykset muuttavat jatkuvasti toimintaansa etsiessään kannattavia markkinoita ja tarjoamaansa. Startup-yrityksissä enemmän tai vähemmän formaalisti käytettyjen, ketterien ohjelmistokehitysmetodien ja käyttäjäkeskeisen suunnittelun yhdistäminen voi myös olla haasteellista. Tämä tutkimus pyrkii selvittämään millaisia menetelmiä ja käytäntöjä startup-yritykset käyttävät ja erittelemään yritysten kokemuksia niistä. Tutkimusmenetelmänä käytettiin teemahaastattelua, jonka tuloksia käsiteltiin kvalitatiivisesti. Tutkimusta varten haastateltiin 12 startup-yritystä. Tutkimuksessa keskityttiin pääkaupunkiseudulla sijaitseviin ohjelmistoja tai ohjelmistopohjaisia palveluita kehittäviin startup-yrityksiin tekijän koulutustaustan vuoksi sekä siksi että yritykset olisivat keskenään vertailukelpoisia. Lisäksi tällaisten yritysten runsas määrä helpotti haastateltavien löytämistä hyvin useat startup-yritykset kehittävät ohjelmistoja ja niihin perustuvia palveluita, koska alkuvaiheessa ohjelmistojen kehittäminen vaatii vain pieniä taloudellisia panostuksia. 2

6 Tutkimuskysymyksiksi tiivistyivät seuraavat: Millaisia käyttäjäkeskeisen tuotekehityksen menetelmiä ohjelmistoalan startupyritykset käyttävät? (1) ja Millaiset käyttäjäkeskeisen tuotekehityksen menetelmät ja käytännöt ohjelmistoalan startup-yritykset kokevat hyödyllisiksi ja toimiviksi ja toisaalta millaiset menetelmät ja käytännöt ne ovat todenneet ongelmallisiksi? (2) Tutkimuksessa esitellään ensin taustatietoa käyttäjäkeskeisestä suunnittelusta, startupyritysten toimintatavoista sekä kevyistä käyttäjäkeskeisistä menetelmistä. Seuraavaksi kuvataan tutkimuksessa käytetty menetelmä ja tutkimusaineisto ja esitellään löydökset haastatteluista. Lopuksi vedetään yhteen startup-yritysten käyttämiä menetelmiä ja pohditaan tutkimuksen onnistumista. 2 Teoreettinen tausta Aiempi tutkimus käyttäjäkeskeisyyden ja startup-yrityksille ominaisten reunaehtojen ja vaatimusten yhdistämisestä vaikuttaa olevan vähäistä, joten aihetta pyrittiin lähestymään samanaikaisesti kummastakin suunnasta. Tässä luvussa esitellään käyttäjäkeskeisen suunnittelun määritelmä, kuvataan startup-yritysten ominaispiirteitä, jotka erottavat ne muista yrityksistä sekä eritellään muutamia kevyitä käyttäjäkeskeisiä menetelmiä. 2.1 Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu on tälle tutkimukselle keskeinen käsite. Löyhästi käyttäjäkeskeinen suunnittelu voitaisiin määritellä suunnitteluksi, jossa käyttäjä on keskiössä tuotetta siis suunnitellaan käyttäjiä varten ja näiden tarpeet huomioon ottaen sen sijaan, että keskityttäisiin vain teknisiin ratkaisuihin tai myynnin kannalta tärkeisiin ominaisuuksiin. On kuitenkin olemassa täsmällisempikin määritelmä. ISO-standardi ISO :en Human-centered design for interactive systems (2010) mukaan käyttäjäkeskeinen suunnittelu on lähestymistapa järjestelmien suunnitteluun ja toteutukseen, jonka tarkoituksena on tehdä vuorovaikutteisista järjestelmistä käytettävämpiä keskittymällä järjestelmän käyttöön ja soveltamalla ergonomiaa sekä käytettävyystietoa ja tekniikoita (käännös kirjoittajan). Standardissa puhutaan varsinaisesti ihmiskeskeisestä suunnittelusta (human-centered design). Tarkoituksena on korostaa, että huomioon otettava ihminen ei välttämättä ole 3

7 tuotteen käyttäjä, vaan voi olla myös sidosryhmään kuuluva henkilö, johon tuote välillisesti vaikuttaa. Sivuhuomiona standardissa kuitenkin mainitaan, että termejä käyttäjäkeskeinen ja ihmiskeskeinen käytetään käytännössä toistensa synonyymeina. Standardin aiemmassa versiossa käytettiinkin termiä user-centered design, käyttäjäkeskeinen suunnittelu. Koska ihmiskeskeinen suunnittelu ei ole suomen kielessä vakiintunut termi, käytetään tässä tutkimuksessa vielä nimitystä käyttäjäkeskeinen suunnittelu. (ISO , 2010) ISO :en (2010) mukaan käyttäjäkeskeiseen lähestymistapaan kuuluvat suunnitteluprosessista riippumatta aina seuraavat periaatteet: a) suunnittelu pohjautuu ymmärrykseen käyttäjistä, tehtävistä ja käyttöympäristöstä b) käyttäjät osallistuvat prosessiin koko suunnittelun ja kehityksen ajan c) suunnittelua ohjaa ja kehittää käyttäjäkeskeinen arviointi d) prosessi on iteratiivinen e) suunnittelu huomioi koko käyttäjäkokemuksen f) suunnittelutiimissä on monialaista osaamista ja monialaisia näkökulmia ISO kuvaa myös käyttäjäkeskeisen suunnitteluprosessin, joka on esitetty kuvassa 1. Prosessi alkaa käyttäjäkeskeisen suunnitteluprosessin suunnittelusta. Tämän jälkeen prosessi jatkuu iteratiivisesti käyttökontekstin ymmärtämisestä ja määrittelystä käyttäjävaatimusten määrittelyyn, suunnitteluratkaisujen toteutukseen ja arviointiin. Prosessi päättyy, kun suunnitteluratkaisut täyttävät käyttäjävaatimukset. (ISO , 2010) 4

8 Kuva 1: Käyttäjäkeskeisen tuotekehityksen vaiheiden väliset suhteet (ISO , 2010). Koska tutkimus käsittelee käyttäjäkeskeisyyttä yrityksissä, on tärkeää erottaa käsitteet käyttäjäkeskeisyys ja asiakaskeskeisyys. Asiakas ja käyttäjä voivat olla eri tahoja: usein esimerkiksi asiakas on yritys ja käyttäjä on yrityksen työntekijä. Yritys saattaa toimia hyvinkin asiakaskeskeisesti, mutta sen tuotteet saattavat silti olla hyvin vaikeita käyttää: tuotteet täyttävät asiakasyritysten tarpeet ominaisuuksien kannalta, mutta eivät huomioi loppukäyttäjän tarpeita tai työympäristöä. Käyttäjäkeskeisyyden ISO-määritelmälle keskeistä on järjestelmien tekeminen käytettävämmiksi soveltamalla käytettävyystietoa ja keskittymällä siihen miten järjestelmää käytetään. Käyttäjäkeskeisyyden ja asiakaskeskeisyyden ero voidaan nähdä siinä, että käyttäjäkeskeisyydessä oleellista on se miten tuotetta käytetään, asiakaskeskeisyydessä se miten asiakas saadaan ostamaan se. Käyttäjäkeskeisyyden saavuttamista edesauttaa suunnitteluprosessi, jossa selvitetään käyttäjän tarpeet ja käyttökonteksti, huomioidaan se suunnittelussa ja testataan järjestelmää iteratiivisesti. 2.2 Startup-yritysten toimintatavat Startup-yritysten ja vakiintuneiden yritysten haasteet ja lähtökohdat eroavat toisistaan. Pienten yritysten resurssit ovat hyvin rajalliset mutta samanaikaisesti niillä on kova kiire markkinoille. Ne eivät vielä tunne markkinoitaan eivätkä voi tietää ovatko asiakkaat edes kiinnostuneita tuotteesta. Seuraavassa kuvaillaan kaksi lähestymistapaa, 5

9 joita startup-yritykset voivat soveltaa kehittäessään liiketoimintaansa välttyäkseen kehittämästä tuotetta jota kukaan ei halua ostaa. Blankin (2007) mukaan startuppien ongelmana on usein se, että ne suhtautuvat liiketoimintamallinsa ja tuotekonseptinsa muodostamiseen kuin perinteiseen tuotekehitykseen. Siksi ne eivät vielä tunne markkinoitaan, kun ne sitoutuvat tiettyyn tuotekonseptiin, jolloin ne sijoittavat huomattavia resursseja sellaisen tuotteen kehittämiseen, jota kukaan ei välttämättä ole kiinnostunut ostamaan. Blankin kehittämä asiakaskehitysmalli (Customer Development Model) pyrkii vastaamaan tähän ongelmaan viemällä tuotteen aikaisin potentiaalisten asiakkaiden arvioitavaksi käytännössä. Blank jakaa mallinsa neljään vaiheeseen: asiakkaiden löytämiseen (customer discovery), asiakkaiden vahvistamiseen (customer validation), asiakkaiden luontiin (customer creation) ja yrityksen rakentamiseen (company building). Asiakkaiden löytämisvaiheessa yritys selvittää ratkaiseeko sen tuote asiakkaiden ongelman ja onko ongelma asiakkaille tärkeä. Asiakkaiden vahvistamisvaiheessa yritys myy tuotettaan kokeeksi selvittääkseen luotettavasti, ovatko asiakkaat valmiita maksamaan tuotteesta. Tähän ei riitä pari sattumalta onnistunutta kauppaa, vaan myyntiprosessin on oltava toistettava. Mikäli jommassakummassa vaiheessa osoittautuu, että alkuoletukset markkinoista olivat virheellisiä, liiketoimintasuunnitelmaa korjataan ja aloitetaan uudestaan ensimmäisestä vaiheesta. Asiakkaiden luontivaiheessa yritys alkaa luoda laajempaa kysyntää tuotteelleen esimerkiksi mainonnan avulla. Ajatuksena on, että yritys alkaa käyttää merkittäviä summia rahaa vasta tässä vaiheessa, kun on jotakuinkin varmaa, että tuote toimii. Lopuksi yritys muuntautuu oppimiseen keskittyvästä organisaatiosta suoritusorganisaatioksi yrityksen rakentamisvaiheessa. (Blank, 2007) Toinen monien startup-yritysten toimintaan vaikuttanut näkemys on Riesin (2009) Lean-ajattelua startup-yritysten innovaatiotyöhön yhdistävä Lean Startup lähestymistapa. Lean startup tähtää pohjimmiltaan samaan kuin Blankin asiakaskehitysmalli: tarkoituksena on välttää tilanne, jossa kalliilla kehitetylle tuotteelle ei olekaan kysyntää. Riesin ajatuksena on välttää turhaa työtä testaamalla oletuksia markkinoista ja asiakkaista kehittämällä tuotteestaan yksinkertaisin mahdollinen versio, minimum viable product (MVP), joita testataan asiakkailla. MVP voi olla heikkolaatuinen alfa-versio tuotteesta tai siinä saattaa olla vain muutamia ominaisuuksia. MVP voi olla jopa pelkkä verkkomainos, jota klikattuaan käyttäjä voi antaa sähköpostiosoitteensa saadakseen ilmoituksen kun tuote julkaistaan. Tarkoituksena on kvantitatiivisesti selvittää, onko tuotteelle todellisia markkinoita. Ries painottaa teoksessaan MVP:n kysynnän mittaamista objektiivisesti ja kysynnän 6

10 tai sen puuttumisen syiden selvittämistä kvalitatiivisesti haastatteluin ja käyttäjätestein. Näin liiketoimintamallia voidaan muokata nopeasti vastaamaan paremmin asiakkaiden tarpeita. Molemmat lähestymistavat ovat iteratiivisia: yritys selvittää jatkuvasti, ovatko sen liiketoimintasuunnitelma ja -oletukset järkeviä ja tekee korjausliikkeitä tarvittaessa. Tämä muistuttaa ISO :ssa kuvattua käyttäjäkeskeistä tuotekehitysprosessia, jossa joka iteraatiolla selvitetään suunnitelmien järkevyys käyttäjien kanssa. Blankin ja Riesin metodologiat soveltavat samaa ajatusta liiketoimintaan ja asiakkaisiin: liiketoimintaa testataan iteratiivisesti ja systemaattisesti asiakkaiden kanssa ja korjataan havaitut ongelmat. Käyttäjäkeskeisyys ja liiketoiminnan kehittäminen ovat siksi hyvin yhteen sovitettavissa. 2.3 Käyttäjäkeskeinen suunnittelu vähillä resursseilla Pienet organisaatiot eivät useinkaan voi käyttää huomattavia resursseja käytettävyystyöhön, vaan joutuvat tyytymään kevyempiin menetelmiin. Tällaisia menetelmiä ovat esimerkiksi etäkäytettävyystestit, heuristiset arviot sekä persoonat ja skenaariot. Seuraavaksi kuvataan erilaisia kevyitä menetelmiä ja niiden hyviä ja huonoja puolia. Menetelmät on tarkoitettu käyttäjätiedon keräämiseen, käyttäjän huomiointiin suunnittelussa tai suunnitteluratkaisujen arviointiin. Nielsen (1993 s ) käyttää kevyistä menetelmistä termiä alennuskäytettävyys, (discount usability). Nielsenin mukaan on parempi käyttää kevyempiä, epätarkempia menetelmiä kuin ei mitään jos suunnittelijat vaativat vain parhaiden menetelmien käyttöä, voi käyttäjäkeskeinen suunnittelu jäädä kokonaan tekemättä kun raskaisiin menetelmiin ei olekaan varaa. Nielsen pitää kevyinä menetelminä käyttäjien työn seurantaa (user and task observation), yhden polun prototyyppejä (scenarios), yksinkertaistettua ääneen ajattelua (simplified thinking aloud) sekä heuristista arviointia (heuristic evaluation). Käyttäjien seurannalla Nielsen tarkoittaa lähinnä käyttäjien työn hiljaista tarkkailua. Yhden polun prototyypit ovat prototyyppejä, joissa on toteutettu vain yksi toiminto ja sekin vain pinnallisesti. Käyttäjä ei siis voi poiketa tehtävän edellyttämältä reitiltä lainkaan. Yksinkertaistettu ääneen ajattelu taas on tavanomainen käytettävyystesti, jossa käyttäjä ajattelee testiä suorittaessaan ääneen. Yksinkertaistetussa ääneen ajattelussa testaaja ei kuitenkaan ole korkeasti koulutettu ammattilainen eikä testiä nauhoiteta syvällistä analyysiä varten, vaan testin analysointi perustuu testaajan tekemiin muistiinpanoihin. Heuristisessa arviossa muutama asiantuntija käy käyttöliittymän läpi periaatejoukon eli heuristiikan avulla. Nielsenin 7

11 mukaan iteratiivinen kehitys käyttäjäpalautteen pohjalta on erityisen tärkeää myös kevyitä menetelmiä käytettäessä. (Nielsen, 1993 s ) Benyon (2010, s ) kuvailee kaksi kevyttä menetelmää suunnittelun tueksi: persoonat ja skenaariot. Persoonat ovat fiktiivisiä esimerkkikäyttäjiä, joista on kuvattu nimi, taustatietoja ja tärkeimpänä tavoitteet ja pyrkimykset. Persoonat auttavat suunnittelijaa muistamaan, millaisille henkilöille käyttöliittymää suunnitellaan. Erilaisia persoonia luodaan useita suunnittelun tueksi. Skenaariot taas ovat konkreettisia tarinoita, joissa käyttäjät käyttävät tuotetta jossakin kontekstissa tavoitteidensa saavuttamiseen skenaarioiden avulla voidaan hahmottaa käyttäjien tehtävät sekä kontekstit, joissa tehtäviä tehdään. (Benyon 2010, s ) Haastattelut ja kyselyt ovat käyttäjäkeskeisen suunnittelun perustyökaluja. Niiden avulla saadaan kerättyä käyttäjien omia tulkintoja ja tekemistensä taustoja (Hyysalo 2009, s. 125). Hyysalon mukaan haastatteluita ei sovelleta ainoastaan sellaisenaan, vaan useimmat muutkin menetelmät sisältävät haastattelua osana menetelmää. Haastattelut ja kyselyt eivät sinällään ole kevyitä menetelmiä, mutta niitä voidaan mielestäni soveltaa pienilläkin resursseilla noudattamalla vapaamuotoisempaa rakennetta ja dokumentointia sekä tinkimällä vastaajien määrästä. Tällä tavoin saadaan vähemmän luotettavia tuloksia, mutta päästään kuitenkin parempaan tulokseen kuin kokonaan ilman haastattelua. Käytännössä kevyisiin menetelmiin voitaisiin hyvin lukea myös kevyt ja vapaamuotoinen käyttäjien seuraaminen heidän käyttäessään tuotetta sekä etäkäytettävyystestit. Etätestejä voidaan suorittaa siten, että testaaja on eri paikassa kuin koehenkilö ja testaaja seuraa käyttäjän toimintaa kameran, mikrofonin ja ruutukaappausten avulla. Etätestissä testaaja ja käyttäjä voivat olla paitsi eri paikoissa, myös ajallisesti erotettuina: nauhoitteiden avulla testi voidaan analysoida jälkikäteen. Tällä tavoin voidaan välttää matkakuluja ja testata tuotetta aidommassa ympäristössä. Hartsonin ynnä muiden mukaan käyttäjät pystyivät itse hyvin tunnistamaan ja kuvailemaan ongelmakohtia. Etätestien ongelmaksi he toteavat käyttäjien taipumuksen unohtaa ajatella ääneen, mikä vaikeuttaa tulosten tulkintaa. Vaikka etätestit ovat edullisia, ne vaativat silti aikaa analysointiin ja valmisteluun. (Hartson ym. 1996, s. 29) Erilaiset verkkopalvelut, kuten usertesting.com, mahdollistavat etäkäyttäjätestien teettämisen kustannustehokkaasti. Testiä varten tarvitsee vain määritellä tehtävät ja pientä korvausta vastaan tilaaja saa nauhoitteen useamman kohderyhmään kuuluvan käyttäjän toiminnasta sekä näiden vastaukset haluamaansa kyselyyn. (How it works, 2012) 8

12 Hasan ym. (2009) ovat tutkineet web-analytiikkatyökalujen hyödyntämistä verkkokauppojen käytettävyyden parantamisessa verrattuna heuristisiin arvioihin. Tutkimuksessa todettiin, että analytiikkatyökalujen metriikat voivat osoittaa nopeasti, helposti ja edullisesti käytettävyyden ongelma-alueita. Analytiikkaohjelmat voivat jopa osoittaa tietyt sivut, joissa ongelmia on. Metriikoiden avulla voidaan tunnistaa esimerkiksi, että sivuston tuotehaku ei palvele käyttäjiä - ne eivät kuitenkaan itsessään kerro mikä haussa on vikana. Tässä suhteessa heuristinen arvio on tehokkaampi: se paljastaa suoraan ongelmia, eikä pelkkiä ongelma-alueita ja mahdollistaa täten suoraan ongelmien korjaamisen. Kirjoittajat suosittelevatkin analytiikan yhdistämistä muihin käytettävyysmetodeihin, kuten heuristisiin arvioihin. (Hasan ym., 2009) Backstromin ja Kleinbergin (2011) mukaan A/B-testaus on menetelmä, jonka avulla voidaan selvittää kumpi kahdesta suunnitteluvaihtoehdosta on käyttäjälle mieluisampi näyttämällä osalle käyttäjistä eri vaihtoehto kuin toisille. Heidän kuvaamassaan perustapauksessa pienelle osalle käyttäjistä esitetään muokattu versio käyttöliittymästä ja analytiikan avulla selvitetään, kumpi käyttöliittymistä johtaa useammin haluttuun tulokseen. Esimerkiksi verkkokauppa voisi testata tuotesivullaan uutta asettelua A/Btestauksen avulla: osalle käyttäjistä näytettäisiin vanha tuotesivu ja osalle uusi ja tämän jälkeen analytiikan avulla selvitettäisiin kuinka moni käyttäjä kummastakin ryhmästä keskimäärin päätyi ostamaan tuotteen. Vaikka A/B-testaus ei varsinaisesti ole käyttäjäkeskeisen suunnittelun menetelmä, sen avulla voidaan valita vaihtoehtoisista suunnitteluratkaisuista käyttäjille sopivimmat, helpoimmat tai mieluisimmat. Lewis ja Rieman (1993, s. 26) pitävät älykästä lainaamista (intelligent borrowing), eli suunnitteluratkaisujen perusteltua kopioimista olemassa olevista tuotteista, hyvänä käyttöliittymäsuunnittelun menetelmänä kolmesta syystä: 1. Hyvistä käyttöliittymistä kopioidut ratkaisut ovat todennäköisesti parempia, kuin mitä suunnittelija pystyisi itse keksimään. 2. Kun suunnitteluratkaisuja lainataan käyttäjille ennestään tutuista lähteistä, käyttäjät osaavat käyttää niitä ilman opettelua. 3. Lainaaminen säästää aikaa suunnittelussa ja usein myös toteutuksessa. Älykkäässä lainaamisessa oleellista on ymmärtää miksi jokin ominaisuus on toteutettu niin kuin se on (s. 28). Suunnitteluratkaisujen kopioiminen miettimättä perusteluja ei ole älykästä lainaamista. Tässä luvussa esiteltiin joitakin mahdollisia menetelmiä käyttäjäkeskeiseen suunnitteluun pienillä resursseilla, esimerkiksi kevyitä käyttäjätestejä, analytiikkaa, persoonia ja haastatteluja. Erilaiset menetelmät soveltuvat erilaisille palveluille ja erilaisten yritysten resursseihin. Lisäksi erilaiset menetelmät myös täydentävät 9

13 toisiaan: vaikka menetelmät on tarkoitettu joko käyttäjätiedon keräämiseen, suunnitteluratkaisujen tuottamiseen tai ratkaisujen arviointiin, ei näitä aktiviteetteja voi aina erottaa toisistaan. 3 Menetelmät ja aineisto Tutkimuskysymykseen vastaamiseksi kerättiin tietoa haastattelemalla 12 startupyritystä. Tämän lisäksi kirjallisuudesta kerättiin taustatietoa haastattelurungon valmistelua ja tulosten käsittelyä varten. Kirjallisuudesta etsittiin taustatietoa startup-yrityksistä sekä pienen budjetin käytettävyystyöstä. Kirjallisuudesta pyrittiin selvittämään, millaisia erityisiä tarpeita ja toimintatapoja startupeilla on muihin yrityksiin verrattuna. Koska startup-yrityksillä ei useinkaan ole alkuvaiheessa käytettävissään suuria budjetteja, myös alennuskäytettävyys (discount usability) tarjoaa pohjaa sille, miten ne saattaisivat huomioida käytettävyyttä tuotekehityksessään. Empiirisen tiedonkeruun menetelmäksi valittiin teemahaastattelu, koska muut vastaavat menetelmät, kysely ja strukturoitu haastattelu, eivät olisi soveltuneet tällaiseen tutkimukseen. Teemahaastattelussa voidaan kysyä avoimia kysymyksiä ja jatkokysymyksiä vastausten perusteella (Hyysalo, 2009) ja näin saavuttaa tarkempi kuva yrityksen toimintatavoista. Strukturoitu kysely tai haastattelu rajoittaa vastauksen ennalta määriteltyihin kysymyksiin, joten se ei voi antaa vastausta kysymyksiin joita ei alun perin tiedetty edes kysyä (Hyysalo, 2009). Teemahaastattelulla oli mahdollista kerätä tietoa menetelmistä ja käytännöistä, joiden olemassaolosta ei haastatteluja aloitettaessa ollut edes tietoa. Lisäksi kyselyihin olisi ollut vaikea saada riittävää vastausastetta (Hyysalo, 2009). Haastattelut tehtiin maalis-huhtikuussa Ne olivat kvalitatiivisia, avoimia haastatteluja, joissa käytettiin apuna löyhää kysymys- ja teemarunkoa (Liite 1). Tarkoituksena oli saada yleiskuva yrityksen toimintatavoista käyttäjäkeskeisessä suunnittelussa ja tämän perusteella esittää tarkempia kysymyksiä menetelmistä ja käytännöistä. Haastatteluissa haettiin, paitsi objektiivista tietoa käytetyistä käytännöistä ja menetelmistä, myös yrityksen edustajan subjektiivisia näkemyksiä niiden hyödyllisyydestä ja toimivuudesta kyseisessä yrityksessä, sekä siitä millaisia ongelmia ja hyviä puolia niissä on. Kysymysrungossa on myös erikseen mainittu muutamia menetelmiä, joita käytettiin avustavina esimerkkeinä jos haastateltava ei suoraan osannut mainita kaikkia käyttämiään menetelmiä tai ymmärtänyt kysymystä. Tarkoituksena ei ollut selvittää tarkkoja prosesseja tai menetelmien soveltamisen 10

14 yksityiskohtia, vaan saavuttaa yleiskuva siitä, millaisia menetelmiä ja käytäntöjä yritys käyttää, miten niitä käytetään ja kuinka hyvin ne toimivat. Haastattelun alkulämmittelyksi ja aineiston käsittelyn tueksi kysyttiin myös taustatietoa yrityksen tuotteesta tai palvelusta, asiakkaista, loppukäyttäjistä, organisaatiosta sekä historiasta. Tämän jälkeen yritettiin muodostaa yleiskäsitys yrityksen tuotekehitysprosessista ja käytännöistä käyttäjäkeskeisyyden näkökulmasta. Yleiskäsitystä täsmennettiin selvittämällä menetelmiä ja käytäntöjä, joita yritys hyödyntää käyttäjätiedon keräämiseen, suunnitteluun sekä tuotteen validointiin. Sekä aiempien kohtien aikana, että myös erikseen lopuksi, kysyttiin yrityksen subjektiivisia kokemuksia eri menetelmistä. Täsmentävillä kysymyksillä selvitettiin menetelmien yksityiskohtia sen verran, että saatiin selville, mitä tai millaista menetelmää haastateltava tarkoittaa. Esimerkiksi haastateltava saattaisi tarkoittaa sanalla käyttäjätesti joko käytettävyystestiä tai beta-vaiheen testikäyttöä. Haastattelut toteutettiin yritysten ehdottamissa tiloissa ja ne nauhoitettiin käsittelyä varten. Haastattelut olivat yksilöhaastatteluja, lukuun ottamatta yhtä haastattelua, johon osallistui haastattelijan lisäksi kaksi henkilöä. Tämä ei kuitenkaan merkittävästi vaikuttanut saatuihin tuloksiin. Muistiinpanoja ei tehty itse haastatteluiden aikana, mutta mieleen jääneitä seikkoja pyrittiin kirjoittamaan ylös pian haastattelun jälkeen. Haastattelut käytiin läpi nauhoilta ja kirjattiin oleellisimmat esiin tulleet seikat ylös niitä ei litteroitu sellaisenaan tekstiksi. Syksyllä haastateltavilta pyydettiin vielä korjauksia haastatteluiden yhteenvetoihin, ja osasta yrityksiä niitä saatiinkin. Haastattelu on menetelmänä kohtuullisen luotettava. Ongelmaksi saattavat kuitenkin muodostua johdattelevat kysymykset ja muut vääristymät (Hyysalo, 2009 s ). Haastattelurungossa mainitut esimerkit tuntuivat ajoittain ohjailevan haastateltavia. Lisäksi kahdessa yrityksessä haastateltava ei ollut paras henkilö yrityksessä vastaamaan käyttäjäkeskeistä tuotekehitystä koskeviin kysymyksiin. Tarkentavien kysymysten perusteella tämä on kuitenkin johtanut enemmänkin vajavaisen kuin väärän kuvan muodostumiseen yrityksen toiminnasta joitakin menetelmiä tai niiden yksityiskohtia on voinut jäädä puuttumaan, mutta olemattomia menetelmiä haastateltavat eivät ole kuvanneet. Haastattelun tulosten tulkinta ja menetelmien luokittelu ei myöskään aina ollut yksiselitteistä. Tuloksia voidaan pitää haastattelumenetelmän haasteet huomioiden melko luotettavina. Joitakin menetelmiä on kuitenkin saattanut jäädä havaitsematta, eikä tietoa eri menetelmien yleisyydestä voida pitää täydellisen tarkkana. Otoksen koko (12 yritystä) on melko pieni, joten kvantitatiivista tietoa ei tuloksista voi johtaa esimerkiksi eri menetelmien suhteellista yleisyyttä ei ole järkevää yrittää 11

15 päätellä haastattelujen tuloksista. Lisäksi joitakin menetelmiä saatetaan käyttää joissakin yrityksissä, vaikka tässä tutkimuksessa menetelmää ei olisikaan tullut vastaan. Haastatteluiden perusteella voidaan kuitenkin tunnistaa joitakin menetelmiä, joita selvästi yleisesti käytetään. Kaikki haastatellut yritykset ovat suomalaisia, pääkaupunkiseudulla toimivia yrityksiä. Tuloksia ei voida yleistää maailmanlaajuisesti, sillä kulttuurisista, poliittisista ja taloudellisista syistä johtuen toimintatavat voivat olla erilaisia ulkomaisissa yrityksissä. Toistettaessa tutkimus joukolle suomalaisia startup-yrityksiä voidaan odottaa saatavan kvalitatiivisesti vastaavia tuloksia. Kuitenkin, pienehköstä otoksesta johtuen, joitakin menetelmiä ei välttämättä löydy ja vastaavasti uusia menetelmiä voi löytyä. Määrällisesti tulokset eivät todennäköisesti ole samankaltaisia kuin tässä tutkimuksessa. Koska haastattelu on avoin, haastattelijan toiminta ja ratkaisut haastattelun aikana vaikuttavat myös paljon tuloksiin. Liian pinnallisessa haastattelussa voi myös jäädä havaitsematta asioita, joita tässä tutkimuksessa on löydetty. 4 Tulokset ja niiden tarkastelu Tutkimusta varten haastateltiin 12 yritystä. Kuvaukset yrityksistä, niiden käyttämistä menetelmistä ja kokemuksista on esitetty liitteessä 2. Yhteenveto haastatelluista yrityksistä on kuvattu taulukossa 1. Taulukossa eritellään yritysten asiakkaat, loppukäyttäjät sekä tuotekehityksen vaihe. Yrityksen ikää tai työntekijämäärää ei ole esitetty, sillä startup-yritysten kohdalla ne saattavat olla harhaanjohtavia: liikeideaa ja tuotetta on saatettu kehittää jo vuosia ennen yrityksen perustamista ja riskirahalla voidaan ostaa paljon alihankintaa ja konsultointia, joka ei näy työntekijämäärässä. 12

16 Taulukko 1: Haastatellut yritykset Nimi Asiakkaat Loppukäyttäjät Vaihe Mindo (*) Yritykset Kuluttajat Julkinen testikäyttö Holvi Kuluttajat ja yhteisöt Kuluttajat ja yhteisöt Julkinen testikäyttö Movenote Yritykset Yritykset Julkaistu Yritys 4 Ei vielä tiedossa Kuluttajat Suljettu testikäyttö Yritys 5 Yritykset Yritykset Julkaistu Etuma Yritykset Yritykset Julkaistu Yritys 7 Yritykset Yritykset ja kuluttajat Julkaistu FinderBase Kuluttajat ja yhteisöt Kuluttajat ja yhteisöt Julkaistu Kiosked Yritykset Kuluttajat ja yritykset Julkaistu Playmysong Yritykset ja kuluttajat Kuluttajat ja yritykset Julkaistu Tellyo Yritykset Kuluttajat Ei julkaistu Yritys 12 Yritykset Kuluttajat ja yritykset Julkaistu *) Mindo toimii varsinaisesti toisen perustajan yrityksen alaisuudessa, mutta itsenäisenä organisaationa Yritysten markkinat ja tuotteet olivat keskenään melko erilaisia. Kolme yritystä suunnitteli tuotteita tai palveluita yrityksille ja kolme yritystä kuluttajakäyttäjille. Kuusi yritystä suunnitteli tuotteita molemmille sektoreille. Suurin osa yrityksistä perusti kuitenkin liiketoimintamallinsa yritysmyyntiin. Osa tuotteista oli kaikille avoimia www-pohjaisia palveluita, osa mobiilisovelluksia ja osa yleisöltä suljettuja yrityssovelluksia. Kaksi palveluista oli lisäosia, joita voidaan liittää olemassa olevien sovellusten tai www-sivujen osiksi. Muiden käyttöliittymien lisäksi yhdessä palvelussa käytettiin merkittävästi sähköpostia ja yhdessä tekstiviestejä. Myös käyttäjäkeskeisyyden tärkeys koettiin eri yrityksissä hyvin eri tavalla toiset tekivät runsaasti haastatteluja ja käyttäjätestejä, toiset perustivat suunnittelunsa myyjien kertomuksiin asiakkaan tarpeista. Tutkimuksen kannalta ongelmallista oli, että yritysten liiketoiminta oli kaiken kaikkiaan alkuvaiheessa. Osa yrityksistä ei ollut vielä edes julkaissut tuotettaan. Tästä syystä yritysten oli hyvin vaikeaa luotettavasti arvioida eri menetelmien hyödyllisyyttä: ennen tuotteen julkaisua ja toiminnan vakiintumista on vaikea arvioida kuinka hyvin suunnittelussa ollaan onnistuttu. Lisäksi voi olla vaikea erottaa liiketoimintamallin tai toteutuksen puutteista ja itse menetelmien puutteista johtuvia epäonnistumisia. 4.1 Kokonaisprosessi Yhdessäkään yrityksessä ei käytetty formaalia ISO :ssa kuvattua käyttäjäkeskeistä tuotekehitysprosessia. Missään yrityksessä ei esimerkiksi kattavasti selvitetty kaikkia käyttötilanteita ja ympäristöjä ennen suunnittelun aloittamista. 13

17 Tämä ei ole mitenkään yllättävää, sillä startup-yritysten toimintatavat voivat olla hyvin kevyitä, joustavia ja epäformaaleja. 4.2 A/B-testaus 3/12 yritystä käytti aktiivisesti A/B-testausta. Näistä kaksi yritystä aikoi lisätä A/Btestauksen käyttöä tulevaisuudessa. Lisäksi yksi yritys oli aikeissa ottaa menetelmän käyttöön. Yksi yritys teki A/B-testausta sovelluksensa iphone- ja Android-versioiden välillä. Näiden kolmen yrityksen lisäksi kaksi yritystä oli kokeillut A/B-testausta, mutta luopunut siitä. Toisessa yrityksistä palvelun pieni käyttäjämassa esti luotettavien tulosten saamisen. Toisessa yrityksessä A/B-testaus oli osoittautunut teknisesti hankalaksi eikä siihen ollut resurssien vähäisyyden takia aikaa paneutua. 4.3 Analytiikka 11/12 yritystä, eli lähes kaikki haastatellut, hyödynsivät analytiikkaa. Erityisesti analytiikan avulla seurattiin mitä ominaisuuksia käyttäjät käyttävät. Kaksi yritystä käytti analytiikkaa käytettävyysongelmien etsimiseen analytiikan avulla saatettiin esimerkiksi etsiä käyttötilanteista kohtia, joihin käyttäjät jäävät jumiin. Kaksi yritystä karsi analytiikan perusteella tarpeettomia ominaisuuksia pois käyttöliittymästä. Yksi yritys hyödynsi laajasti analytiikkaa ja arvioi sen perustella muun muassa suositusalgoritminsa toimivuutta seuraamalla esimerkiksi sitä, kuinka kauan käyttäjät katselivat suositeltua sisältöä. Yksi yritys käytti analytiikkaa lähinnä liikenteen lähteiden ja sivustolla vietetyn ajan seuraamiseen. Yksi yritys seurasi vain järjestelmän käytön määrää. Analytiikka koettiin laajalti hyödylliseksi. Sen koettiin kuitenkin tarvitsevan tuekseen muita menetelmiä, kuten haastatteluita. Yksi yritys totesi, ettei ominaisuuden käytön määrä kerro suoraan mitään: vähäinen käyttö voi kertoa joko ominaisuuden tarpeettomuudesta tai käytettävyysongelmasta. Se kummasta on kyse täytyy selvittää muita menetelmiä käyttäen. Samaa mieltä olivat tutkimuksessaan myös Hasan ym. (2009). Yhdessä yrityksessä analytiikan käyttöä hankaloitti palvelussa käsiteltävän tiedon luottamuksellisuus, joka esti keräämästä kattavaa analytiikkaa. 4.4 Asiantuntija-arvioinnit Asiantuntija-arvioinnilla tarkoitetaan tässä heuristisen arvion lisäksi myös muita käytettävyystarkastuksia, joissa yksi tai useampi asiantuntija käy käyttöliittymän läpi. Vain 1/12 yrityksessä oli teetetty formaali asiantuntija-arviointi, mikä oli yllättävän vähän. Lisäksi neljässä yrityksessä oli hyödynnetty yrittäjien verkostoja ja pyydetty 14

18 tutuilta käytettävyysasiantuntijoilta kommentteja käyttöliittymästä tai epäformaaleja arviointeja. 4.5 Haastattelut 8/12 yritystä oli tehnyt jonkinasteisia haastatteluja käyttäjien kanssa. Haastattelut olivat pääosin varsin vapaamuotoisia, lähes keskustelunomaisia. Haastatteluja niistä tekee kuitenkin toiminnan tavoitteellisuus (Hyysalo 2009, s. 125). Viidessä yrityksessä haastattelussa hyödynnettiin prototyyppiä tai haastattelu yhdistettiin käyttäjätestiin. Yhdessä yrityksessä käytetään vapaamuotoisia käyttäjähaastatteluja käyttödatan selittämiseen: mikäli jotakin ominaisuutta ei analytiikan mukaan käytetä, syy selvitetään käyttäjiä haastattelemalla. Formaaleja haastatteluja oli käytetty vain kolmessa yrityksessä. Kahdessa yrityksessä teetettiin formaali haastattelumuotoinen markkinatutkimus ennen palvelun kehittämistä. Toinen näistä sisälsi myös käyttäjien tarpeiden kartoitusta. Yksi yritys käytti aiemmin formaaleja haastatteluja myös käyttäjien tarpeiden selvittämiseksi, mutta luopui niistä epäluotettavuuden ja työläyden vuoksi. Vapaamuotoisiin haastatteluihin oltiin yrityksissä pääosin tyytyväisiä. Yhdessä yrityksessä korostettiin haastattelun avoimuuden tärkeyttä, sillä strukturoidussa haastattelussa saadaan vastaus vain kysymyksiin, jotka tiedetään kysyä. Yksi yritys piti formaaleja haastatteluja liian raskaina suhteessa kerätyn tiedon hyödyllisyyteen ja luotettavuuteen. Käyttäjät eivät kyenneet ilmaisemaan tarpeitaan eivätkä objektiivisesti arvioimaan omaa toimintaansa. Myös Hyysalo (2009) varoittaa näistä vaaroista. Lisäksi yrityksessä oltiin sitä mieltä, että yhden asiakkaan liika kuunteleminen voi haitata kokonaisuutta. Käyttäjien päivittäisten toimien seuraaminen tai kontekstisidonnainen haastattelu voisi auttaa saamaan luotettavamman kuvan käyttäjien toiminnasta, mutta ne ovat hyvin raskaita pienille yrityksille. 4.6 Kyselyt 6/12 yritystä käytti erilaisia kyselyitä. Neljässä yrityksessä oli tehty käyttäjäkyselyitä palvelun julkaisun jälkeen. Näistä kolmessa yrityksessä kysymykset olivat avoimia, yhdessä monivalintoja. Yksi yritys kokeili avoimien kyselyiden lisäksi lyhyitä, yhden kysymyksen monivalintoja. Avoimissa kyselyissä kysyttiin sekä taustatietoja että konkreettisia kehitysehdotuksia. Yksi yrityksistä teki kyselyn palvelun kohderyhmälle ennen toteutuksen aloittamista. Yksi yritys käytti aiemmin kyselyitä, mutta luopui niistä. Syynä oli yrityksen pieni asiakaskunta ja kyselyiden alhainen vastaustaajuus, mikä johti siihen, että kyselyiden luotettavuus oli kyseenalainen. Lisäksi yrityksessä 15

19 oltiin sitä mieltä, että kyselyihin vastaavat aina tietynlaiset käyttäjät, ja tulokset ovat siksi vääristyneitä. Yksi yritys koki kyselyt erityisen hyödyllisiksi mainostajien kanssa keskustellessa. Yhdessä yrityksessä oli havaittu, että käyttäjäkyselyistä saadut kehitysehdotukset ovat usein samankaltaisia kuin mitä yrityksen sisälläkin on mietitty. Tämän koettiin toisaalta kyseenalaistavan kyselyjen hyödyllisyyttä, toisaalta vahvistavan, että yritys on oikealla tiellä. Samassa yrityksessä koettiin, että kyselyt eivät tarjoa kovin laajaa kuvaa käyttäjistä: niillä saa vastauksia vain kysymyksiin, joita on ymmärtänyt kysyä. Samaa mieltä oltiin myös eräässä yrityksessä, joka ei käyttänyt kyselyitä. Myös Hyysalo (2009 s. 129) huomauttaa, että kyselyillä ei saada tietoa kysymyksen vierestä. Hyysalon mukaan se, mistä tiedetään tarvittavan tietoa on usein paljon pienempi ongelma kuin asiat, joita ei edes ole tunnistettu tärkeiksi. Yksi yritys oli valmistellut käyttäjäkyselyä, mutta jättänyt sen toteuttamatta, koska kysely koettiin liian pinnalliseksi välineeksi käytettäväksi aikaisessa vaiheessa tuotekehitystä. Haastattelujen ja kyselyiden yleisyyttä voi selittää se, että menetelmät ovat tuttuja kaikille. Haastatteluja ja kyselyjä sovelletaan laajasti myös esimerkiksi markkinatutkimuksissa ja ne ovat siksi liiketoimintasuuntautuneille yrittäjillekin helppoja ymmärtää ja käyttää. Vaikka käyttäjätiedon keräämiseen olisi parempia tai täydentäviä keinoja on syytä muistaa, ettei startup-yrityksissä välttämättä ole koulutettua käytettävyysasiantuntijaa, joka niitä osaisi soveltaa. 4.7 Käyttäjäpalautteen kerääminen 8/12 yritystä keräsi vapaamuotoista tekstipalautetta käyttäjiltä. Palautetta kerättiin sähköpostista, asiakaspalvelun yhteydenotoista tai lomakkeilla palvelun käyttöliittymässä. Kokemukset palautteista olivat pääosin positiivisia. Yksi yritys piti palautetta hyvänä lähinnä selkeiden teknisten ongelmien löytämiseen. Yrityksessä koettiin ongelmaksi palautteen sirpaleisuus: palautteesta on vaikeaa löytää trendejä. Eräs yritys piti käyttäjäpalautetta epäluotettavana verrattuna kvantitatiiviseen käyttödataan kun taas toinen piti palautetta vinoutuneena sillä suurin osa palvelun käyttäjistä oli aikaisia omaksujia (early adopter). Yksi yritys harmitteli palautteen vähäistä määrää. 4.8 Käyttäjätestaus 6/12 yritystä teki käyttäjätestejä. Näistä viisi yritystä käytti vapaamuotoisia testejä. Yksi yritys oli lisäksi ostanut asiantuntijayritykseltä formaaleja käyttäjätestejä. Yhdessä yrityksessä oli teetetty etäkäyttäjätestejä. Kaikissa yrityksissä käyttäjätestien 16

20 yhteydessä pidettiin myös epäformaali palautekeskustelu. Lisäksi kahdessa yrityksessä hyödynnettiin koulutuksia käyttäjätestien kaltaisesti. Toinen yrityksistä oli sitä mieltä, ettei koulutuksia oikeasti tarvittu tuotteen käyttöönottoon niitä teetettiin vain käytettävyysongelmien löytämiseksi. Vapaamuotoiset testit olivat pitkälti toistensa kaltaisia. Niissä ei yleensä ollut etukäteen valmisteltuja tehtäviä eikä ääneen ajattelua juuri käytetty. Vain yhdessä yrityksessä käytettiin ääneen ajattelua. Yhdessä yrityksessä annettiin käyttäjille aina valmiit tehtävät ja yhdessä yrityksessä valmiita tehtäviä käytettiin silloin tällöin. Kaksi yritystä piti tärkeänä, että käyttäjät saivat kokeilla tuotetta vapaasti. Toisessa yrityksistä koettiin, että valmiit tehtävät ohjaavat käyttäjää liikaa, eikä niiden avulla saada aitoa palautetta. Yhdessä yrityksessä annettiin käyttäjien tehdä oikeita tehtäviään järjestelmän avulla. Tällä tavoin koettiin saatavan realistisempaa palautetta. Samassa yhteydessä annettiin käyttäjille myös yleisluontoisia tehtäviä myöhemmin tehtäväksi, joista pyydettiin antamaan palautetta sähköpostitse. Yritykset teettivät käyttäjätestejä vaihtelevissa paikoissa. Yksi yritys teetti testit aina käyttäjän luona. Yksi yritys oli joutunut teknisistä syistä teettämään käyttäjätestit laboratorio-olosuhteissa. Tämän koettiin tuottavan jossain määrin epärealistisia tuloksia. Etäkäytettävyystesteistä saadut kokemukset olivat hyviä: niillä saatiin paljon laadukasta palautetta ja selkeitä korjausehdotuksia. Etäkäytettävyystestejäkin pidettiin niin kalliina, että niitä voitiin teettää vain isoimmille ominaisuuksille ja laajuudeltaan pieninä. Kokemukset käyttäjätesteistä olivat pääosin positiivisia. Yksi yritys pyrki välttämään kaikkia raskaita menetelmiä. Yhdessä yrityksessä koettiin vaikeaksi teettää käyttäjätestejä kun samaan aikaan oli toteutettava nopeasti paljon uusia ominaisuuksia. Lisäksi yrityksessä oltiin sitä mieltä, että täysin kelvottomat käyttöliittymäratkaisut havaittaisiin joka tapauksessa tuotannossa. 4.9 Käyttäjäyhteisöt Käyttäjäyhteisöllä tarkoitetaan tässä käyttäjien ryhmää, jota voidaan osallistaa suunnitteluun eri tavoin. Yhteisö voi olla sähköpostilista, sosiaalisen median ryhmä mutta myös joukko käyttäjiä, jotka ovat tarjoavat yritykselle apuaan. 5/12 yrityksellä oli jonkinlainen käyttäjäyhteisö, joista ne keräsivät palautetta. Yhdessä yrityksessä tämä oli joukko testikäyttäjiä ja neljässä virtuaaliyhteisö, esimerkiksi Facebook-ryhmä tai sähköpostilista. Testikäyttäjäryhmää hyödynnettiin palautteen keräämisessä ja käyttäjätestien kohderyhmänä. Kaksi yritystä hyödynsi käyttäjäyhteisöä koekäyttäjien etsimiseen ja kokeiluversioiden julkaisuun. Yksi yritys oli teettänyt Facebook-ryhmänsä 17