S-72.501 Tietoliikennepalveluiden käyttäjäkeskeinen suunnittelu

OLO-ryhmä 22.3.2005

Sihteeri: Tiina Hellsten

YHTEENVETO

Oppimistavoite: Tekniikkalähtöisyys vs. käyttäjälähtöisyys

Tehtävänä ryhmällämme oli tutkia tekniikkalähtöistä ja käyttäjälähtöistä tuotekehitystä ja vertailla niitä. Tietoa kertyikin runsaasti ja siksi tämä yhteenveto onkin aika pitkä. Päällekkäisyyksiä raporteissa oli jopa yllättävän vähän. Päädyimme tulokseen, ettei kumpaakaan tapaa ole hyvä sivuuttaa kokonaan, vaan paras tulos saavutettaisiin paneutumalla molempiin vaihtoehtoihin. Toisinaan riskin otto kannattaa ja ilman niitä moni keksintö olisi jäänyt tekemättä. Oppimistavoite tavoitettiin ja tulokset olivat osittain jopa yllättäviä.

TEKNIIKKALÄHTÖINEN SUUNNITTELU

Tekniikkalähtöisen tuotekehityksen liikkeellepaneva voima on tuleva, uusi tai vanha tekniikka itsessään. Tuotetta aletaan kehittää tekniikan ehdoilla, jotta tekniikkaa saadaan mahdollisimman tehokkaasti hyödynnettyä. Kun tekniikka on olemassa, ruvetaan miettimään, minkälaisia tuotteita tekniikasta voisi kehittää. Usein kehitystyön taustana on käyttäjille tehty tutkimus, mutta sen avulla tehty vaatimusmäärittely kattaa vain kaikkein tärkeimmät ominaisuudet. Tämä jättää suunnittelijoille vapaat kädet kehitellä uusia ja innovatiivisia teknisiä ratkaisuja.

Tekniikkalähtöinen tuotekehitys pyrkii täyttämään tuotteella mahdollisimman monta asiakkaan toivetta sisällyttämällä tuotteeseen kaikki mahdolliset teknologiat ja ominaisuudet. Tärkeintä on, että asiakas tekee ostopäätöksensä tuotteen ulkoisten ominaisuuksien ja eri toimintojen pohjalta. Sillä ei ole merkitystä kokeeko käyttäjä tuotteen helposti käytettävänä tai osaako hän ylipäätänsä käyttää tuotetta oikein. Tärkeintä on saada asiakas ostamaan tuote.

Insinöörit ja markkinointiosaston henkilöt ovat keskeisessä roolissa tekniikkalähtöisessä tuotekehityksessä. Insinööreillä on käytettävänään uusi teknologia, jonka he haluavat tuotteessa toteuttaa. Markkinoijat sen sijaan ilmoittavat insinööreille markkinatutkimuksien tulokset ja kertovat mitä kaikkia ominaisuuksia asiakkaat toivovat tuotteeseen. Tässä yhteydessä puhutaan asiakkaasta, joka ostaa tuotteen, asiakas ei ole välttämättä tuotteen käyttäjä. Insinöörit tunkevat yhteen tuotteeseen kaikki mahdolliset teknologiat ja ominaisuudet, ja kun tuote on lopulta valmis, mietitään vasta sitten sen käyttämistä. Todellisuudessa tuote voisi olla käytettävyydeltään parempi jos siinä olisi vähemmän toimintoja. Vasta tässä vaiheessa tuote viedään käyttöliittymäsuunnittelun asiantuntijoille, ja heitä pyydetään tekemään tuotteesta hyvin käytettävä. Sehän on selvää, että tällainen menettely ei tee tuotteesta toimivaa. Käytettävyys ei ole ominaisuus, joka voidaan lisätä tuotteeseen suunnittelun lopuksi.

Tekniikkalähtöisen suunnittelun vahvuudet

Keskeisin syy tekniikkalähtöisen suunnittelun käyttöön on liiketoiminnan kannattavuuden parantaminen. Uusilla tuotteilla pyritään tuomaan lisäarvoa asiakkaille ja samalla parantamaan oman yrityksen kilpailukykyä. Saattaa myös olla, että valmiina on jo jokin tekniikka, jota käytetään turhan vähän. Tällöin tekniikkalähtöisen suunnittelun avulla on mahdollista tehostaa jo olemassa olevien resurssien käyttöä ja siten parantaa liiketoiminnan kannattavuutta.

Koska nykyisin tuotteet kehitetään kansainväliseen ja nopeasti muuttuvaan ympäristöön, on yritykselle erittäin tärkeää pysyä kehityksen mukana. Monille tuotteille nopea kehitys ja jakelu on elinehto, joten tekniikkalähtöisen suunnittelun mahdollistama nopea toteutus on suuri etu (Sommerville 2004).

Tekniikkalähtöinen suunnittelu sopii hyvin yrityksille, jotka eivät tavoittele voittoa, kuten esimerkiksi tutkimuslaboratoriot yliopistoissa. Näille on tärkeämpää keksiä uusia tekniikoita ja ideoita, joista vasta jälkeenpäin katsotaan, olisiko jollain potentiaalia myös yleisillä markkinoilla. Suurin osa keksinnöistä jää luultavasti sisäpiirin tutkimuksiksi, mutta nämä ovat tekniikan kehityksen kannalta todella tärkeitä. Tulevaisuudessa näitä tietoja hyväksikäyttäen voidaan keksiä tuleville sukupolville mitä tärkeimpiä laitteita ja vempaimia.

Tekniikkalähtöisessä tuotekehityksessä saattaa helposti syntyä tuotteita, jotka tuovat esille käyttäjien piilotarpeita eli tarpeita, joita käyttäjä ei itse tiedosta omaavansa, mutta joita hän haluaa tyydyttää.

Piilotarpeet usein huomataan luomalla aina vain innovatiivisempia tuotteita, jotka saattavat aluksi tuntua kaukaisille käyttäjien tämän hetkisessä elämässä. Esimerkiksi Sonyn 1980-luvulla kehittämä Walkman kasettisoitin, edusti onnistunutta tekniikkalähtöistä tuotekehitystä (Ainamo et al. 2003). Walkman kehitettiin ilman käyttäjien vaikutusta tuotekehitykseen ja lisäksi hyvin pienellä rahallisella investoinnilla, mutta tästä huolimatta tuote oli menestys (Ainamo et al. 2003). Toinen hyvä esimerkki on SMS eli tekstiviestit, joita ei alun perin suunniteltu vertaisviestintään vaan operaattorin yhdensuuntaisia asiakastiedotteita varten (esim. käyttökatkot). (FiCom) SMS-lähetysmahdollisuuden lisääminen ei kuitenkaan vaatinut GSM-puhelimeen suuriakaan muutoksia, jolloin se saatettiin lisätä ilman sen suurempia odotuksia. Loppu onkin siten historiaa.

Tekniikkalähtöisessä kehityksessä tuotteelle kehitetään varsin kehittyneitä ja uusia funktionaalisia teknologioita, ja tuote lykätään markkinoille ilman sen suurempaa tutkimusta käyttäjistä. Moni voisi luulla, että tällaisella tuotteella ei olisi mitään mahdollisuutta myydä, mutta näillekin tuotteille on oma kohderyhmänsä, joka on ns. early-adopters eli aikaiset käyttäjät. Kohderyhmänä näiden käyttäjien tarve ei niinkään ole helppokäyttöisyys, vaan uuden tekniikan mahdollistamat toiminnat, vaikka käyttö vaatisi hieman uhrauksia. Tämä ryhmä on kuitenkin varsin pieni kooltaan, ja massamarkkinoiden saavuttaminen vaatii tuotteelta muutakin. Päästäkseen tuotteen elinkaaressa kuiluksi kutsutun vaiheen yli massamarkkinoille, on tuotteen oltava käyttäjälähtöinen. Hieman itselleni yllätyksenä, voitaisiin ajatella että tässä vaiheessa käyttäjälähtöinen ja tekniikkalähtöinen kehitys yhtyvät. Tuotteen oltua jo jonkin aikaa markkinoilla, aletaan sitä kehittää käyttäjän näkökulmasta, tutkien käyttäjien palautetta ja suorittaen muita tutkimuksia käyttäjälähtöisestä tuotteesta. Voitaisiin sanoa, että ilman tätä kahden lähestymisen yhdistymistä tekniikkalähtöinen tuote harvoin pääse kuilun yli, mutta yhteispelillä tulokset voivat olla varsin toimiviakin. Näin ollen tekniikkalähtöisyys kyllä voi johtaa menestykseen, mutta sisältää riskejä ja suuren mahdollisuuden epäonnistumiseen markkinoilla.

Tekniikkalähtöisen suunnittelun heikkoudet

Tekniikkalähtöisen tuotekehityksen heikkouksia ovat käyttäjien unohtaminen tuotekehityksessä, liiallinen riskinotto ja piilotarpeisiin luottaminen uusia tuotteita kehitettäessä sekä tekniikan pitäminen itsessään lisäarvon tuojana käyttäjille. Tuotekehityksessä voidaan helposti joutua hakoteille, jos kehitetään tuotetta vain tekniikan takia. Käyttäjä käyttää yleensä tuotetta, koska se tuo odotettua lisäarvoa hänelle ja hän osaa sitä käyttää. Tekniikkalähtöisessä tuotekehityksessä turhan usein jää huomioimatta käyttäjän oikeat ja olemassa olevat tarpeet. Tällöin saatetaan kehittää tuotteita, jotka ovat jopa liian innovatiivisia ja liian kaukana käyttäjän todellisuudesta tai yksinkertaisesti käyttäjälle aivan turhia ja vaikeita käyttää. Lisäksi joskus uudet ominaisuudet heikentävät vanhojen tuttujen ominaisuuksien käytettävyyttä. Jos käyttäjät eivät omaksu uusia tuotteita, myös tavoiteltu markkinamenestys jää saamatta. Hyvä esimerkki teknologialähtöisen suunnittelun epäonnistumisesta on OLO-ryhmässä käsitelty Nokian N- Gage, joka epäonnistui sekä puhelimena, että pelilaitteena. Joskus tuotekehityksessä luotetaan liikaa käyttäjien piilotarpeisiin ja tällöin riskin määrä tuotekehityksessä on todella suuri. Uusi tuote saattaa epäonnistua täysin, koska käyttäjien piilotarpeet on oletettu väärin. Tämä ovat myös tekniikkalähtöisen tuotekehityksen uhkakuvia.

Ohjelmoijat tekevät tuotteita usein ensisijaisesti itselleen, [vaikka eivät ole loppukäyttäjiä] ja pyrkivät tuotekehitysprosessin aika täyttämään omia tavoitteitaan. Ohjelmoijilla on taipumus priorisoida sellaisia toimintoja, jotka ovat määritelty selkeimmin tai ovat sisällöltään heille tutuimpia. Ohjelmistoprojektien on tapana olla myöhästyä sovitusta aikataulusta, joten usein tuotteen suunniteltuja ominaisuuksia voidaan joutua karsimaan kiireessä. Tämän vuoksi käyttäjän kannalta oleellisia toimintoja voi jäädä puuttumaan lopputuotteesta, vaikka käyttäjän vaatimuksia olisikin huomioitu tuotesuunnittelussa. Vastoin uskomuksia, käyttäjät eivät ole lumoutuneita tuotteen toiminnoista. Tuotteiden menestykset ja tappiot ovat yhä uudelleen osoittaneet, että käyttäjät eivät juuri välitä toiminnoista. Käyttäjät haluavat vain päästä tavoitteisiinsa. (Cooper 1999)

Vaikka tuotetta ei testattaisikaan suunnittelijan taholta, ostaja tulee testaamaan sen. Tällöin mahdollisesti löytyvät käytettävyysongelmat heikentävät suunnittelijan mainetta laadukkaista tuotteista, joka saattaa tulla monin kerroin kalliimmaksi, kuin jos virheet olisi keksitty jo tuotetta kehittäessä (Nielsen 1993). Näin ollen tällainen kehitys ei selvästi ole taloudellista ja harvoin kannattavaakaan.

KÄYTTÄJÄLÄHTÖINEN SUUNNITTELU

Käyttäjälähtöinen suunnittelu perustuu käyttäjien tarpeiden, kykyjen ja ajattelumallien perusteelliseen tutkimukseen ja yksityiskohtaiseen vaatimusmäärittelyyn. Esimerkiksi vesiputousmalli on klassinen käyttäjälähtöisen suunnittelun malli, johon liittyy paljon testausta ja iteratiivista suunnittelua. Tavoitteena on luoda tuote, jossa tekninen toiminnallisuus ja käyttäjien tarpeet kohtaavat. Tekniikalla on tärkeä osa tuotekehitystä, mutta tekniikkaa käytetään lähinnä toteuttamaan käyttäjien tarpeita.

Kun suunnitellaan kohderyhmälle tuotetta, on otettava huomioon se, mitä he itse haluavat eivätkä vain tarvitse. Suunnittelija olettaa usein käyttäjän haluavan jotain muuta, kuin mitä käyttäjän todelliset toiveet ovat. Suunnittelijan tulisi siksi pyrkiä avoimesti astumaan tutkittavaan aiheeseen ja eläytyä kohderyhmään siten, että hän pystyy löytämään sen keskeisimmät arvot ja niihin liittyvät tarpeet. Eläytymisen kannalta on tärkeää, että keskustellaan sekä käyttäjien, että muiden suunnittelijoiden kanssa. (Huotari et al. 2003)

Käyttäjälähtöisyys- ja yhteistyö nähdään keskeisenä kehityssuuntana innovaatiotoiminassa. Toisaalta tutkimukset osoittavat, että tämän yhteistyön tiellä on vakavia organisatorisia ja tiedollisia esteitä. Tuotekehityshenkilöstön ja käyttäjien välillä oleva raja on vaikea ylittää: taloudelliset paineet, kehittäjien organisatorinen asema sekä erityinen ammatillinen kieli ja maailmankuva pitävät kehittäjien ja käyttäjien maailmoja erillään toisistaan. (Hasu et al. 2003)

Jotta tuote kokonaisuudessaan olisi onnistunut, täytyy tekniikan, käytettävyyden ja markkinoiden olla tasapainossa keskenään. Asiaa voidaan järkevästi kuvata kolmijalkaisena tuolina, jossa jokainen jalka edustaa yhtä kehityksen aluetta. Kun aikaisemmin tekniikkalähtöinen toiminta nojasi vain yhteen näistä jaloista eli teknologiaan, on käyttäjälähtöinen toiminta kaikkien näiden jalkojen varassa. Tämä tuotteen kehitys siis ottaa tuotteen elinkaaressa yhtälailla huomioon nämä kolme tekijää, ja niiden yhteistoiminta antaa tulokseksi tuotteen, joka on toimiva kokonaisuus.

Tyytyväinen käyttäjä todennäköisemmin seuraavallakin kerralla valitsee saman valmistajan tuotteen. Keskeneräisiä tuotteita ei markkinoille kannata laskea. Yritysten kannattaa panostaa siis myös tuotteen laatuun eikä vain myyntilukuihin, koska uuden käyttäjän hankkiminen on usein vaikeampaa kuin vanhan säilyttäminen.

Käyttäjälähtöisen suunnittelun vahvuudet

Käyttäjälähtöisen tuotekehityksen merkittävin vahvuus on käyttäjän tarpeiden huomioiminen tuotekehityksessä. Käyttäjätutkimuksen avulla saadaan selville mm. millaiset ihmiset käyttävät tuotetta ja millaisissa tilanteissa käyttö tapahtuu. Iteratiivinen suunnittelu ja tuotteen testaus mahdollistavat mahdollisimman hyvän kohderyhmän huomioimisen ja siten myös tuotteen hyväksyttävyyden paranemisen. Tuotteesta saadaan sellainen, joka tuo käyttäjälle lisäarvoa ja jota käyttäjän on miellyttävää, tehokasta ja helppoa käyttää. Tällöin käyttäjät yleensä myös ottavat tuotteen hyvin vastaan.

Joskus käyttäjälähtöisessä suunnittelussa voi käydä ilmi, että jokin osa tuotteesta on täysin turha, jotain erittäin tärkeää puuttuu tai käyttäjäryhmä on suunniteltu väärin. Näiden huomaaminen on huomattavasti halvempaa etukäteen kuin vasta tuotteen valmistuttua. Riskien määrä käyttäjälähtöisessä tuotekehityksessä on pienempi kuin tekniikkalähtöisessä, koska tuote on tehty käyttäjien ehdoilla.

Testaamalla tuotetta käyttäjällä on paljon helpompi lähteä myös markkinoimaan tuotetta. Kun tuntee käyttäjän ja ostajan on paljon helpompi mainostaa tuotetta juuri niillä ominaisuuksilla, joita sen tulevat käyttäjät pitävät kaikista tärkeimpinä.

Käyttäjäkeskeinen prosessi antaa lisäksi monia muita etuja liiketoiminalle. Metodit tuottavat parempilaatuisia systeemejä, jotka saavuttavat kasvavaa asiakastyytyväisyyttä ja luottamusta. Suunnittelu on myös tehokkaampaa käyttäjäkeskeisten metodien avulla. Systeemi todennäköisesti ehtii markkinoille nopeammin ja pienemmillä kuluilla. Myös pitkäaikaisia säästöjä on odotettavissa, sillä käytettävyydeltään parempi tuote ei vaadi niin paljon asiakastukea ja kustannuksia säästyy. Lisäksi yritykset, joiden työntekijöillä on käyttäjäkeskeisesti suunniteltuja tuotteita, huomaavat harjoitusaikojen vähenevän ja tuottavuuden nousevan. Työntekijät ovat tyytyväisempiä, sillä työ helpottu eikä monimutkaistu. (Mauro)

Käyttäjälähtöisen suunnittelun heikkoudet

High-tech teollisuudessa käyttäjän tarpeita on usein vaikeaa löytää. Käyttäjät ovat usein niin hyvin orientoituneita päivittäisiin rutiineihin, että he eivät itse huomaa, miten he voisivat helpottaa näitä päivittäisiä rutiineja, esimerkiksi jonkin high-tech-tuotteen avulla (Ainamo et al. 2003). Tässä piilee käyttäjälähtöisen tuotekehityksen heikkous. Tarpeita on joskus vaikeaa määrittää ja löytää, koska käyttäjä ei itsekään aina osaa kuvata tai kertoa omista tarpeistaan. Osa tarpeista saattaa olla jopa tiedostamattomia. Jos tarpeita ei pystytä ennustamaan riittävästi, voi suuret menestystuotteet jäädä keksimättä. Esimerkiksi tietoliikenneteollisuuden markkinat ovat erittäin nopeasti muuttuvat ja tällöin käyttäjän tarpeiden ennustaminen saa merkittävän roolin (Ainamo et al. 2002).

Käyttäjien tarpeet saattavat myös usein olla ristiriitaisia, joten joudutaan tekemään kompromisseja. Saattaa myös olla, että käyttäjän ja suunnittelijan välillä on liian suuri kuilu, joten käyttäjälähtöiseksi ajatellut ominaisuudet eivät vastaakaan käyttäjän odotuksia. Käyttäjälähtöisen tuoteen toteuttaminen saattaa asettaa myös huomattavia haasteita tekniikalle. Voi yksinkertaisesti olla, että tuotetta ei voida kehittää tämän hetkisellä tekniikalla tai, että tuottaminen tulisi aivan liian kalliiksi. Käyttäjäkeskeisen suunnittelun vaatima tutkimustyö vie paljon aikaa ja rahaa. Valitettavasti rahasäästöt käyttäjäystävällisestä suunnittelusta näkyvät vasta tuotteen julkaisemisen jälkeen, ja silloinkaan niitä ei ole helppo erottaa muista tuotoista. Myöskään nousseista tuloista käytettävyyden vuoksi ei ole paljoa dokumentoitu, vaan tieto kulkee usein vain kertomuksiin perustuen, jolloin tulkinnalle jää paljon varaa. (Nielsen 1993)

KÄYTTÄJÄLÄHTÖISEN JA TEKNIIKKALÄHTÖISEN EROJA

Tekniikkalähtöinen ja käyttäjälähtöinen suunnittelu eroavat paljon toisistaan. Ensimmäisessä lähdetään liikkeelle listasta teknisiä toimintoja ja katsotaan mitä niillä voisi tehdä, kun taas jälkimmäisessä ensin selvitetään, mitä halutaan tuottaa ja luodaan tekniikka sitä varten. Myös käsitteellinen suunnittelu tehdään eri näkökulmista, sillä käyttäjäkeskeisessä prosessissa tehdään kattava tehtäväanalyysi, mutta tekniikkakeskeisessä prosessissa suunnittelu pohjautuu löyhästi määriteltyihin toiminnallisiin spekseihin. Suunnittelutiimi pysyy samana koko käyttäjäkeskeisen prosessin kaikkien vaiheiden ajan, kun taas tekniikkalähtöisessä prosessissa yksi tiimi tekee yhden osan tuotteesta ja antaa eteenpäin seuraavalle tiimille. (Mauro)

Myös käyttäjien antaman palautteen kerääminen ja huomioon ottaminen tapahtuu eri tavalla. Tekniikkalähtöisessä prosessissa suunnittelijoiden päätökset perustuvat oletuksiin asiakkaista, kun taas käyttäjälähtöisessä prosessissa päätökset tehdään oikeiden käyttäjien oikeiden tarpeiden mukaan. Tekniikkakeskeisessä prosessissa toiminnalliset speksit jäädytetään hyvin aikaisessa vaiheessa suunnitteluprosessia ja tuloksena on kirjallinen määrittelyraportti. Käyttäjäkeskeisessä prosessissa jäädytys tapahtuu vasta, kun käyttäjätutkimus on täysin valmis ja testattu. Tuloksena on kaikki piirteet sisältävä simulaatio. Tekniikkalähtöisessä prosessissa iterointi on vaikea toteuttaa, koska se vaatii usein koodin uudelleen kirjoittamista. Siksi joka vaiheessa yritetään välttää muutosten tekemistä. Vastakohtana on käyttäjäkeskeinen prosessi, joka vaatii iteratiivista suunnittelua. Koodi kirjoitetaan vasta lukuisien suunnittelu kierrosten jälkeen, kun lopullinen versio on saavutettu. (Mauro)

Yksinkertaistetusti voidaan sanoa, että tekniikkalähtöisessä tuotekehityksessä tuote luodaan asiakkaalle, joka ostaa tuotteen kun taas käyttäjälähtöisessä tuotekehityksessä tuote on luotu käyttäjälle, joka tuotetta käyttää.

ASIAKAS VS. KÄYTTÄJÄ

Asiakas on määritelmältään vahvasti markkinoinnin termi (Kotler), jolla tarkoitetaan tuotteen ostajaa. Termissä otetaan huomioon tekijöitä kuten osto käyttäytyminen, osto motiivit. Painotus on siis juuri osto tilanteessa ja siihen liittyvässä toiminnassa. Termi ei kuitenkaan käsitä millään tavalla sitä kuka, miksi ja miten käyttää. Käyttäjä termin määrittely on taas hyvin päinvastainen. Tuotteilla voi olla monia käyttäjiä, ja niiden kaikkien identifioiminen on varsin vaikeaa. Käyttäjä ei aina ole sama ihminen kuin asiakas. Käyttäjä terminä liittyy vahvasti käyttäjäkokemus jalkaan käyttäjälähtöisessä toiminnassa. Esimerkiksi televiestinnässä käyttäjä ei siis välttämättä ole matkaviestintilaaja, vaikka lähes kaikki tilaajat ovatkin käyttäjiä. Molemmat termit ovat kuitenkin tärkeitä asiakaslähtöisessä toiminnassa, koska markkinointi on myös yksi osa, ja siinä on katsottava asioita asiakkaan kantilta, eikä pelkästään käyttäjän.

TARPEET VS. PIILOTARPEET

Käytöstä ja käyttäjästä puhumiseen on perinteisesti liitetty tarpeen käsite. Abraham Maslow (1954) esitti edelleen laajimmin tunnetun tarvehierarkian, joka alkaa fysiologisista tarpeista ja päätyy itsensä toteuttamisen tarpeeseen. Uudet teknologiat ja tuotteet avaavat uusia toimintamahdollisuuksia ja synnyttävät uusia tarpeita. Norman ja Ramírez (1994) toteavatkin, että on parempi keskittyä tarpeiden sijasta tarkastelemaan käyttäjien toiminnan ongelmia ja suoristustapoja tai sitä, miten tuote täydentää asiakkaan nykyistä osaamista ja toimintaa. (Hasu et al. 2003)

Keeley on luonut käsitteellisen mallin kolmesta korkeateknologiatoiminnan pääluonteenpiirteestä. Ne ovat ”kyvykkyys”, ”elinkelpoisuus” ja ”haluttavuus”. Kyvykkyys tässä edustaa teknologiaosaamista, elinkelpoisuus tuotteen taloudellista potentiaalia ja haluttavuus liittyy käyttäjien tarpeisiin. Ensin on mietittävä mikä on haluttavaa ja vasta sen jälkeen on kysyttävä onko se mahdollista ja taloudellisesti kannattavaa. Usein teknologiayritykset kilpailevat keskenään teknologiaosaamisesta ja uusista innovaatioista eivätkä keskity asiakkaan vielä tyydyttämättömiin tarpeisiin. (Cooper 1999)

Käyttäjä ymmärretään yhteisöllisenä: Yhä useammin teknologioiden käyttöönottoon liittyy yhteistyötä usean henkilön ja yhteisön välillä. Toiseksi tarpeen perustana ovat yhteisessä toiminnassa esiin tulevat asioiden toimimattomuus, häiriöt ja jännitteet ja epämääräinen tyytymättömyys nykyiseen toimintatapaan. Kolmanneksi teknologian tarve ei ole valmiina olemassa. Se rakentuu ja artikuloidaan teknologian käyttöönoton kuluessa. Neljänneksi tarve on monitasoinen ja -ulotteinen ilmiö: Vaikka sen ydin on teknologian panos työn ongelmien ratkaisuun ja tuloksen laadun parantamiseen, teknologian käyttöarvo on riippuvainen käytön organisatorisista järjestelyistä ja käyttöä tukevista välineistä. (Hasu et al. 2002)

LÄHTEET:

Ainamo, Korhonen (2003). Handbook of Product and Service Development in Communication and Information Technology. Kluwer Academic Publishers.

Ainamo, Chakrabarti, Korhonen (2002). Role of Universities in Product Development Process: Strategic Considerations for the Telecommunication Industry. http://ipc-lis.mit.edu/LIS02-003.pdf

Beyer, Holtzblatt (1998). Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann.

Cooper (1999). Nörttien Valtakunta. Miksi korkeateknologiatuotteet saavat meidät sekaisin ja kuinka palauttaa järki. Suomen Atk-kustannus Oy, Helsinki.

Edvardsson, Matthing, Sandén (2004). New service development: learning from and with customers. International Journal of Service Industry Management Volume 15 Number 5 pp. 479-498.

Faulkner (2000). Usability Engineering. Palgrave.

Hasu, Hyysalo, Lehenkari, Miettinen (2003). Tuotteesta työvälineeksi? Uudet teknologiat terveydenhuollossa. Sosiaali- ja terveysalan tutkimus- ja kehittämiskeskus STAKES.

Hasu, Miettinen (2002). ”Articulating User-needs in Collaborative Design. Towards Activity-Theoretical Approach.” Computer Supported Collaborative Work 11: 129-151.

Hiltunen (2001). Pilottihankkeesta palveluprosessien kehittämiseen.

http://www.lshp.fi/tellappi3/joiku_1_2001.htm

Huotari, Koskinen, Laakko, Laitakari-Svärd (2003). Käyttäjäkeskeinen tuotesuunnittelu. Käyttäjätiedon keruu, mallittaminen ja arviointi. Gummerus Kirjapaino Oy.

Kankkunen, Lagerroos, Lehtinen, Välimaa (1994). Tuotekehitys: Asiakastarpeesta tuotteeksi. Opetushallitus, Painatuskeskus Oy

Kotler (2003). Marketing management, Prentice Hall.

Köykkä (2004). S-72.501-kurssin luentokalvot. Luento 2, kalvot 2-4.

Lang (2002). The High-Tech Entrepreneuräs Handbook. Pearson Education Limited.

Mayhew (1999). The Usability Engineering Lifecycle. Morgan Kaufmann Publishers, inc. San Francisco, California.

Mauro. UCD and the next generation of interactive technology http://www.taskz.com/ucd_indepth.php

Nielsen (1993). Usability Engineering. Academic Press Limited, London.

Norman. Growing Up: Moving from Technology-Centered to Human-Centered Products, Chapter 2 from MIT press website. Luettavissa sähköisenä: http://mitpress.mit.edu/books/NORVH/chapter2.html

Norman (1998). Chapter 10 from "The Invisible Computer," MIT Press : Want Human-Centered Development? Reorganize the Company.Luettavissa http://www.nngroup.com/reports/want_hcd_reorg.html

Norman (1998). The Invisible Computer: Why Good Products Can Fail, the Personal Computer Is So Complex, and Information Appliances Are the Solution, The MIT Press. http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=3484&xid=4&xcid=0

Rubin (1994). Handbook of Usability Testing: how to plan, design and conduct effective test. John Wiley & Sons, New York.

Sommerville (2004). Software Engineering. Addison Wesley, New York

Uusitupa, Voipio (2001). Tietoliikenneaapinen. Otatieto.

Nettilähteitä:

FiCom. http://www.ficom.fi/fi/t_tekniikka_r.html?ld=1034946797.html

Liikenne- ja viestintäministeriö (2003). Henkilökohtainen navigointi NAVI-ohjelma, loppuraportti. http://www.mintc.fi/www/sivut/dokumentit/julkaisu/julkaisusarja/2003/a112003.pdf

TaskZ.com, User Centered design methology. http://www.taskz.com/ucd_indepth.php

Tepa - Tekniikan sanastokeskuksen termipankki. http://www.otalib.fi/tkk/tepa/index.html

Usernomics (1.4.2005). http://www.usernomics.com/user-interfacedesign.html