Suunnittelutiimi keksii listan käyttäjän tarpeista tuotteellesi. Suunnittelutiimi tulee pöydän ääreen erilaisten ominaisuuksien kanssa. Johtoryhmä haluaa vain ominaisuuksia, jotka tuovat yritykselle rahaa. Tukitiimi näkee aivan muita ominaisuuksia, jotka on korjattava. Mistä tuotetiimi tietää, mihin suuntaan mennä?
Suunnittelututkijoina luotamme siihen, mitä asiakkaat sanovat ja tekevät, jotta voimme lukea syvemmälle ja selvittää, mitä he haluavat. Monet meistä ovat kuitenkin usein kamppailleet uusien tapojen kanssa kvantifioida ja visualisoida näitä tarpeita tehokkaalla tavalla, jotta nämä tiimit pääsisivät yhteisymmärrykseen. Asiakkaat voivat toki äänestää ominaisuuksista ja asettaa ne paremmuusjärjestykseen, mikä antaa loistavan yleiskuvan, mutta ei aina anna syvempää ymmärrystä siitä, mitkä ominaisuudet ovat välttämättömiä sen lisäksi, mitä jo odotetaan.
Tulkaa mukaan Kano-malliin.
Kano-malli on professori Noriaki Kanon 1980-luvulla kehittämä teoria tuotekehitykseen ja asiakastyytyväisyyteen liittyen, jossa asiakkaiden mieltymykset jaetaan viiteen luokkaan. Se tarjoaa tekniikoita, joiden avulla voidaan ymmärtää asiakkaiden näkökulmia tuotteen ominaisuuksiin arvioimalla kunkin ominaisuuden osalta kahta mittaria: tyytyväisyyttä ja tunnetta. Näihin kahteen mittaukseen saadut vastaukset kuuluvat johonkin viidestä luokasta: Houkutteleva, Suorituskyky, Välinpitämätön, Pakko olla, Ei-toivottu.
How to use it
Suunnittele kyselylomake, jossa jokainen ominaisuus on lueteltu erikseen. Ihannetapauksessa esittelet jokaisen ominaisuuden osalta prototyypin tai vuorovaikutteisen rautalankamallin avulla, jos mahdollista, mitä ominaisuus voi tehdä. Älä käytä paljon aikaa prototyyppien luomiseen: se on vain prototyyppi, jolla saat idean perille. Jotkut ihmiset voivat todella takertua yksityiskohtiin jopa prototyypeissä, koska he saattavat pitää ideasta, mutta eivät siitä, miten se on toteutettu.
Jos ominaisuuksien demonstrointi ei ole mahdollista, myös selventävä tekstimuotoinen kuvaus toimii hyvin.
Pro-vinkki: Muiden IBM:n tutkijoiden kanssa käydyissä keskusteluissa on käynyt ilmi, että ne, jotka onnistuivat paremmin, testasivat 15-20 ominaisuutta. Ne, jotka menestyivät huonommin, testasivat 30-40 ominaisuutta. Yli 20 ominaisuuden testaaminen oli ylivoimainen määrä tietoa sekä asiakkaille että tutkijoille analysoitavaksi.
Kunkin ominaisuuden nähtyään käyttäjät valitsevat vastauksensa Kano-kyselylomakkeeseen:
- Jos sinulla oli (ominaisuus), miltä sinusta tuntuu?
- Jos sinulla ei ollut (ominaisuus), miltä sinusta tuntuu?
(Daniel Zacariasilla on erinomaisia vinkkejä siitä, miten nämä kysymykset kirjoitetaan selkeästi)
Kanon kyselylomakkeen vakiovastaukset molempiin edellä mainittuihin kysymyksiin ovat:
- Pidän siitä
- Odotan sitä
- Olen neutraali
- Voin sietää sitä
- En pidä siitä
Daniel Zacarias tarjoaa myös joitain muita vaihtoehtoja vastausjoukoksi näille vastauksille. Periaatteessa, jos aiot kokeilla Kanon mallia, lue koko hänen artikkelinsa. Se on hämmästyttävä.
Jan Moorman suosittelee myös kolmannen kysymyksen lisäämistä: Kuinka tärkeä tämä ominaisuus on? Hän suosittelee käyttämään yhdeksänportaista Likertin asteikkoa ”Ei lainkaan tärkeä” – ”Erittäin tärkeä”. Kuitenkin, kun yrittää kirjoittaa Likertin tärkeysasteikon yhdeksän pistettä, se on … hieman hankalaa. Näyttää siltä, että seitsemänpisteinen Likertin asteikko on helpompi.
Vastausten selvittyäsi on analyysiprosessi, jota Daniel Zacarias kuvaa hyvin yksityiskohtaisesti. Suosittelen lämpimästi lukemaan sen läpi.
Yksi IBM:n tutkijat havaitsivat, että numerot olivat loistavia, mutta numerot itsessään eivät kertoneet kenellekään miksi, eli väistämätöntä kysymystä, jonka me kaikki saamme johtoryhmiltämme. Eräs tiimi käytti Kanon mallia noin 15 laadullisen haastattelun tekemiseen. Toinen ryhmä suoritti 5 laadullista haastattelua saatuaan kyselylomakkeet 40 henkilöltä. Molemmat tiimit suosittelivat vahvasti laadullisten haastattelujen lisäämistä tähän prosessiin, koska se lisäsi kerrontaa, joka auttaa antamaan tiedolle sen puuttuvan asiayhteyden.
Miten sitä EI SAA käyttää
Yksi IBM:n tiimeistä, jotka käyttivät Kano-mallia, epäröi käyttää sitä uudelleen. Tämä tiimi laati kyselylomakkeen käyttämällä ominaisuuksien kuvaamiseen skenaarioita, joiden he uskoivat olevan nykyisiä toimintatapoja. Testauksen edetessä kävi kuitenkin hyvin nopeasti selväksi, että suunnittelutiimin skenaariot eivät vastanneet sitä, miten asiakkaat todella käyttivät tuotetta, ja testaus suistui nopeasti raiteiltaan.
Ajatus skenaarioiden käyttämisestä ominaisuuksien kuvaamiseen on hyvä, mutta keskustellessamme heidän lähestymistavastaan kävi selväksi, että skenaariot on validoitava etukäteen. Kano + skenaariot -yhdistelmä olisi tehokas sen jälkeen, kun on tehty generatiivinen tutkimus, jossa selvitetään nykytilanne.
Toinen neuvo oli vähentää testattavien ominaisuuksien määrää. Tiimi, joka otti käyttöön pitkän 30-40 ominaisuuden listan, sanoi, että se oli hieman liian intensiivistä ja että asiakkaat hukkuivat ja uupuivat testauksen loppuun mennessä.
Hyödyt
Kano-malli on erittäin hyvä ominaisuuksien priorisoinnissa. Kanon mallin taustalla on teoria, jota Daniel Zacarias kutsuu ”ilon luonnolliseksi rappeutumiseksi”. Innovatiiviset ideat ja tuotteet siirtyvät jännittävyydestä ja uutuudesta, joka on Kano-kaavion yläosassa (Houkutteleva), odotettuihin ominaisuuksiin, jotka ovat alaosassa (Parhaimmillaan pakko-ominaisuuksia, pahimmillaan haittaavia).
Ota esimerkkinä langaton internet*. On vuosi 2001, olet työmatkalla ja sinulla on huippuluokan kannettava tietokone, jossa on ethernet-portti ja WiFi. Olet hotellissa ja saat tietää, että hotellissa on ethernet-portit, joiden kautta voit muodostaa Internet-yhteyden. Hotellissa ei ole langatonta internetyhteyttä, joka sisältyisi huoneen hintaan, mutta saat WiFi-yhteyden bisneskeskeskuksessa. Olet innostunut! Se on mahtavaa! Mitkä mahtavat vaihtoehdot!
Eteenpäin vuoteen 2017. Olet työmatkalla ja sinulla on perusläppäri, jossa on WiFi. Olet hotellissa ja opit, että siellä on ethernet-portit, joiden kautta voit muodostaa yhteyden internetiin. Heillä ei ole langatonta internetyhteyttä, joka sisältyisi huoneesi hintaan, mutta voit saada WiFin heidän bisneskeskustassaan. Olet raivona! Miltä planeetalta tämä hotelli on kotoisin, että Internetistä pitää maksaa ylimääräistä?! Ja kuka enää käyttää ethernet-porttiaan Internet-yhteyden muodostamiseen?
Mikä alkoi houkuttelevana ominaisuutena (ethernet-portit huoneessa ja WiFi bisneskeskuksessa), muuttui 16 vuotta myöhemmin ei-toivotuksi ominaisuudeksi.
Jos tiimit eivät tiedä, mitä asiakkaat haluavat, ne saattavat keskittyä ominaisuuksiin, joita odotetaan houkuttelevuuden sijasta. Yksi Kanon mallia käyttäneistä IBM:n tutkijoista havaitsi tämän omassa tiimissään: ”Joistakin ominaisuuksista tiimi oli hyvin innoissaan, mutta sitten se tajusi, että ne olivat pelkkää pöytätavaraa.”
Lisäpotentiaalia
Keskustellessamme Kano-mallista esitimme teorian, että sillä on potentiaalia myös muutamiin muihin asioihin:
- Kipupisteiden syvyyden mittaaminen
- Ominaisuuksien perustaminen tuotteen elinkaaren aikana, jotta voidaan arvioida mielihyvän luonnollista rappeutumista ajan myötä
Kipupisteiden syvyys
Malli voisi auttaa paljastamaan, kuinka pahoja olemassa olevat kipupisteet ovat. Kano-kyselylomake soveltuu helposti siihen, että tutkimuksen avulla voidaan syventyä syvemmälle ja oppia lisää siitä, miksi kipupisteet ovat niin pahoja kuin ne ovat ja miksi nämä ominaisuudet ovat niin tärkeitä asiakkaille. Se voisi paljastaa joitakin aiemmin tunnistamattomia tarpeita ja johtaa uusiin innovaatioihin.
Ominaisuuksien perustaminen
Keskustelimme siitä, että käytämme Kano-mallia ominaisuuksien arvioimiseen säännöllisesti, jotta voisimme tarkkailla, mitkä ominaisuudet alenevat alempiin luokkiin. Tämäntyyppinen pitkittäistestaus, jossa on riittävän suuri asiakaskunta, voisi osoittaa markkinoiden suuntauksia ja odotuksia ja auttaa jatkamaan tutkimuksen arvon osoittamista ajan mittaan. Se voisi myös auttaa tiimejä tietämään, milloin heidän tuotteensa alkaa pysähtyä tasolleen ja tarvitsevat innovatiivisia ideoita palatakseen trendejä määrittävään asemaan.
avoin kysymys
Joskus IBM:n suunnittelutiimit toimivat konsultteina projekteissa. Joitakin IBM:n suunnittelutiimejä pyydetään mukaan projektiin ”siivoamaan käytettävyyttä” ja ripottelemaan maagista UX-pölyä tuotteeseen juuri ennen lanseerausta. Toiset suunnittelutiimit ovat tilapäisesti mukana laajemmassa tuotetiimissä.
Keskustelumme päätteeksi meille jäi yksi avoin kysymys: onko Kanon mallista hyötyä, jos tuotteeseen ei voi vaikuttaa? Et ehkä pysty vaikuttamaan tuotteeseen, koska se on jo kehitteillä, koska johto vastustaa sitä, koska suunnittelutiimi on vain väliaikaisesti osa tuotetiimiä jne. Kannattaako Kanon mallin käyttämiseen nähdä vaivaa?
Vai onko se ehkä hyödyllinen, vaikka et voisikaan vaikuttaa tuotteeseen?
Ajatuksia?