Henry Fordin uskotaan aikanaan tokaisseen, että mikäli hän olisi kysynyt asiakkailtaan heidän tarpeistaan, olisi vastaus ollut “nopeampi hevonen”.
Vaikkakin hieman tyly, sisältää lausahdus yksinkertaisen totuuden: tuotteen käyttäjät eivät useimmiten osaa visioida tarvitsemaansa ratkaisua, mutta he ovat mestareita kertomaan omista tarpeistaan. Ja juuri nämä tarpeet ovat nitä tekijöitä, joita ymmärtämällä on mahdollista suunnitella aidosti hyödyllinen ratkaisu.
Olettamukset ongelmana
Miltei jokainen IT-alalla toiminut on joskus istunut palaverissa, jossa asiakkailta on kysytty suoraan, mitkä ominaisuudet tekisivät heidän sovelluksestaan hyödyllisen. Vastaus on miltei poikkeuksetta luokkaa “nopeus ja helppokäyttöisyys”.
Kun myyjä sitten välittää nämä terveiset toteutustiimille, on lopputulos juuri sellainen 4,58 % nopeampi hevonen – ja toisinaan yhden satulan sijaan mullistavasti kahdella satulalla.
Missään vaiheessa ei tarkennettu listattujen adjektiivien merkitystä käyttäjille, saati sitten selvitetty millaiseen työhön sovellusta ollaan rakentamassa. Vaikka briiffi olisi kuinka perusteellinen, on ymmärrys jäänyt pintapuoliselle tasolle, jossa jokainen peilaa viestiä vain oman näkökulmansa kautta ja ymmärryksen aukot paikataan olettamuksilla.
Kohti käyttäjäkeskeistä projektityötä
Entäs jos palaverissa olisi sovittu, että sovelluksen suunnittelijat tulevat tutustumaan tulevien käyttäjien työhön, ilman IT-managerien ja talousjohtajien läsnäoloa?
Muutaman hengen tiimi olisi tullut käyttäjien työympäristöön paikan päälle, huomaten välittömästi useita ympäristön asettamia haasteita, joista heillä ei ollut aikaisemmin aavistustakaan. Käyttäjille monet näistä merkityksellisistä asioista ovat niin arkipäiväisiä, etteivät he edes ajatelleet niitä. Ne eivät nouse esille palaverismoothieta siemaillessa, vaan vaativat esiintyäkseen todellisuutta vastaavan ympäristön.
Havainnoinnin edetessä toteutustiimi toteaa ettei heidän mielikuvansa sovelluksen tarpeista vastannutkaan todellisuutta, ja he huomaavat useita työvaiheita, joita voitaisiin helpottaa teknologian keinoin. Suunnittelijat siis alkavat todella ymmärtää käyttäjien tarpeita, sen sijaan että he vain pyrkisivät toteuttamaan käyttäjien toiveet sellaisenaan. Tällöin käytättäjien toimialaosaaminen ja suunnittelijoiden asiantuntemus saadaan yhdistettyä kokonaisuutta hyödyttävällä tavalla, jonka lopputulos on jotain enemmän kuin “nopeampi hevonen”.
Tällaista lähestymistapaa kutsutaan käyttäjäkeskeiseksi suunnitteluksi, ja sen ensimmäinen vaihe on juuri yllä kuvattu – käyttäjätutkimus. Näin suhteellisen pienellä panostuksella saatiin selvitettyä käyttäjien todelliset tarpeet, varmistettiin koko toteutustiimille mielekäs suunta ja vältyttiin loppuvaiheen hätäkorjausputkelta.
Käyttäjätutkimus on kannattava sijoitus
Yksinkertaistettuna käyttäjätutkimuksen tarkoitus on säästää rahaa. Kun heti alussa rakennetaan kattava ymmärrys käyttäjien tarpeista, säästytään hintavilta korjausliikkeltä ja ylipäänsä aloitetaan tekemään oikeita asioita. Käyttäjätutkimus on projektityöskentelyn sijoitus, jolla varmistetaan, että projektissa todella tehdään sitä mitä halutaankin tehdä.
Voin taata, että kun yhdessä projektissa toteuttaa käyttäjätutkimuksen vaiheen, ei voi kuin ihmetellä mikä peijakas on koskaan ajanutkaan toimimaan millään muulla tavalla.
Lue lisää käyttäjäkeskeisestä suunnittelusta:
