Kotitehtäväpalautus 4: Petri Naukkarinen

Tehtävä: Tuotesuunnittelun ongelma eli tekniikka vastaan käyttäjä...

Valitettavasti tärkein asia tuotesuunnittelussa pyrkii unohtumaan nykyisen huipputekniikan aikana: tuotteita tulisi tehdä käyttäjien tarpeisiin, eikä tuotteiden itsensä vuoksi. Teollisuus keksii uusia innovaatioita, jotka poikivat myöhemmässä vaiheessa tuotteita. Kun tuotekehitystä tehdään teknisen näkökannan puitteista, tekniikan ammattilaisten tuottamana, pertti peruskäyttäjän tarpeet uhkaavat hukkua taka-alalle.

Toki tuotekehitystä tehdään myös käyttäjien tarpeista lähtien. Tämä lähestymistapa antaa paremman vastineen niille ihmisille, jotka tuotetta sitten hyödyntävät. Yksi ensimmäisistä asioista, jotka täytyy ottaa huomioon teknistä keksintöä muutettaessa käyttäjäsovellukseksi on käyttäjäryhmien analysointi ja tarpeitten kartoitus. Vaikka tekniikka olisi miten hienoa, käytettävyyden ollessa huono tuotteella ei ole arvoa loppukäyttäjälle. Tärkeää on siis kartoittaa tuotteen käyttäjien - asiakkaitten - tarpeet ja taitotaso.

Paras mahdollinen tilanne olisi, että loppukäyttäjä voisi osallistua tuotteen suunnitteluprosessiin aivan alkuvaiheesta asti. Itse tuotteen tekninen toteutus voidaan huoletta jättää teknisen henkilöstön hoidettavaksi, koska tunnetusti teknisen suunnitteluhenkilöstön on välillä todella vaikeaa ajatella tuotekehitystä loppukäyttäjän kannalta. Asiakasta ei kiinnosta, miten tietokanta on viilattu nopeammaksi, vaan se että kanta ylipäätänsä on nopeampi.

Jos ajatellaan tuotekehitysprosessin eri vaiheita, ja loppukäyttäjän asemaa eräs mahdollinen lähestymistapa on mielestäni seuraavanlainen.

Loppukäyttäjien mielipide ja tarpeet on huomioitava erityisen tarkasti alussa markkinatutkimuksilla. Niitten perusteellahan itse tuotetta lähdetään määrittelemään ja rakentamaan.

Loppukäyttäjien mielipide on myös hyvin tärkeää tuotteen vaatimusmäärittelyjä (Requirement Specifications) ja toiminnallisuusmäärittelyjä (Functional Specifications) työstettäessä. Näissä vaiheissahan kartoitetaan ne ominaisuudet, joita tuotteella on ja ne raamit jotka tuotteen tulee lopulta toteuttaa. Tämä tarvittava informaatio saadaan esimerkiksi haastattelemalla asiakkaita ja siten kartoittamalla toiveita. Yleensä myös aikaisemmista ohjelmaversioista saatu palaute käytetään hyväksi uutta ohjelmistoa tai uutta ohjelmaversiota työstettäessä. Näin saadaan nivotuksi tekniset vaatimukset ja toisaalta myös rajoitteet loppukäyttäjien vaatimuksiin.

Kun sitten päästään siihen vaiheeseen, että on aika työstää järjestelmän teknistä kuvausta (Technical Specifications), tämä työvaihe on syytä tehdä erillään käyttäjistä. Käyttäjän ei ole tarpeen tietää, miten itse järjestelmä on toteutettu eikä varmasti suurta osaa käyttäjistä se edes kiinnosta.

Suunnittelun edetessä implementointi ja erilaiset testausvaiheet voidaan jättää puhtaasti teknisen henkilökunnan hoidettavaksi. Kun suunnittelu ja toteutus on niin pitkällä, että erilaiset testivaiheet on tehty ja ensimmäinen jollakin lailla toimiva versio (alfa- tai betaversio) on käsillä on loppukäyttäjän palaute hyvä ottaa uudestaan mukaan. Vaikkakin vaatimusmäärittelyjen tulisi olla niin tiukat, että käyttöliittymää myöten kaikki on viimeistä piirtoa myöten lukkoonlyöty, tämä ei käytännössä ole mahdollista. Siksi varhaisiin versioihin on vielä mahdollista tehdä muutoksia tietyin rajoituksin käytettävyystestien perusteella.

Tässä esitetty malli ei aivan ole yksi yhteen kurssilla esitetyn mallin kanssa. Suurin ero on se, että määrittelyt pyritään saamaan mahdollisimman tarkaksi jo heti alussa, ja prosessin edetessä muutokset pyritään minimoimaan. Syynä tähän ovat nopeat läpimenoajat ja se, että yhteen paikkaan tehty muutos vaikuttaa moneen muuhun paikkaan. Tämä vaikeuttaa toteutusta ja erityisesti tuotteen toimivuuden testaamista.

Kun tuote on sitten valmis ja markkinoilla esimerkiksi jonkun rajoitetun myyntimäärän puitteissa, sen toimivuus ja tehokkuus pyritään tietysti varmistamaan keräämällä kokemuksia vielä tässäkin vaiheessa ennen kuin tuote lasketaan laajemmin markkinoille.

Tässä vaiheessa käyttäjän tarjoaman informaation perusteella tehdään yleensä enää mahdollisten virheiden korjauksia, eikä varsinaisia toiminnallisuuden muutoksia. Huomattavaa on, että jos julkaisuvalmista tuotetta kähdetään muuttamaan, se tulee kalliiksi yritykselle. Parempi vaihtoehto on tehdä uusi versio (Release) ja julkaista se myöhemmin. Näin myös maksavalle kansalle saadaan kuva, että jatkuvaa tuotekehitystä tehdään.

Ongelmana tehokkaan, toimivan, luotettavan ja kaikki_loputkin_korusanat_tähän tuotteen tekemisessä käyttäjäystävälliseksi on kova kilpailu. Läpimenoajat ovat pieniä prosessin eri vaiheitten ollessa vahvasti rinnakkaisia. Näin myöskään käyttäjien kokemuksia, vaatimuksia ja palautetta on erittäin vaikeaa hyödyntää muuta kuin prosessin alkuvaiheessa tai sitten seuraavassa ohjelmaversiossa. On siis löydettävä kompromissi tehokkuuden, ja tuotteen käyttäjäystävällisyyden välillä. Jos monta versiota tuotteesta on vaikeakäyttöisiä, on tuotteen kilpailuetu menetetty oli se teknisesti miten huippua tahansa.