Designteamet tar fram en lista över användarbehov för din produkt. Teknikteamet kommer till bordet med en annan uppsättning funktioner. Ledningsgruppen vill bara ha de funktioner som kommer att ge företaget pengar. Supportteamet ser helt andra funktioner som måste åtgärdas. Hur ska ett produktteam veta i vilken riktning det ska gå?
Som designforskare förlitar vi oss på vad kunderna säger och gör för att läsa djupare och upptäcka vad de vill ha. Många av oss har dock ofta kämpat med nya sätt att kvantifiera och visualisera dessa behov på ett effektivt sätt så att dessa team kan komma överens. Kunderna kan säkert rösta på och rangordna funktioner, vilket ger en bra överblick, men ger inte alltid den djupare förståelsen för vad som är ett måste utöver det som redan förväntas.
Inför Kano-modellen.
Kano-modellen är en teori om produktutveckling och kundtillfredsställelse som utvecklades på 1980-talet av professor Noriaki Kano, och som delar in kundpreferenser i fem kategorier. Den tillhandahåller tekniker som hjälper oss att förstå kundernas perspektiv på produktegenskaper genom att bedöma två mått för varje egenskap: tillfredsställelse och känsla. Svaren på dessa två mått kommer att falla in i en av de fem kategorierna: Attraktiv, Prestanda, Indifferent, Måste vara, Oönskad.
Hur man använder det
Förbered ett frågeformulär där varje funktion listas separat. För varje funktion bör du helst visa vad funktionen kan göra med hjälp av en prototyp eller en interaktiv wireframe, om det är möjligt. Spendera inte mycket tid på att skapa prototyper för detta: det är bara en prototyp för att få fram idén. En del människor kan fastna väldigt mycket i detaljerna även i prototyper, eftersom de kanske gillar idén, men inte hur den implementerades.
Om det inte är möjligt att demonstrera funktionerna fungerar en förklarande textbeskrivning också bra.
Pro-tips: I diskussioner med andra IBM-forskare har de som varit mer framgångsrika testat 15-20 funktioner. De som var mindre framgångsrika testade 30-40. Att testa mer än 20 funktioner var en överväldigande mängd data, både för kunderna och för forskarna att analysera.
Efter att ha sett varje funktion väljer användarna sitt svar på Kano frågeformuläret:
- Om du hade (funktion), hur känner du dig?
- Om du inte hade (funktion), hur känner du dig?
(Daniel Zacarias har några utmärkta tips om hur man skriver dessa frågor på ett tydligt sätt)
Standardiserade Kanofrågeformulärssvar på båda ovanstående frågor är:
- Jag gillar det
- Jag förväntar mig det
- Jag är neutral
- Jag kan tolerera det
- Jag ogillar det
Daniel Zacarias erbjuder också några andra svarsalternativ för svarsalternativen för dessa svar. Om du ska prova Kano-modellen bör du läsa hela artikeln. Den är fantastisk.
Jan Moorman rekommenderar också att man lägger till en tredje fråga: Hur viktig är den här funktionen? Hon rekommenderar att man använder en niogradig Likertskala från ”Inte alls viktigt” till ”Extremt viktigt”. Men när man försöker stava ut de nio punkterna på Likert-skalan för betydelse är det … lite knepigt. Det verkar som om den sju punkter långa Likertskalan är lättare.
När man väl har svaren finns det en analysprocess som Daniel Zacarias beskriver mycket detaljerat. Jag rekommenderar starkt att du läser igenom den.
Ett problem som forskarna på IBM fann var att det var bra att ha dessa siffror, men siffrorna i sig berättade inte varför, den oundvikliga frågan som vi alla kommer att få från våra ledningsgrupper. Ett team använde Kano-modellen för att genomföra cirka 15 kvalitativa intervjuer. Ett annat team genomförde 5 kvalitativa intervjuer efter att ha fått frågeformulär från 40 personer. Båda teamen rekommenderade starkt att lägga till kvalitativa intervjuer till denna process, eftersom det tillförde den berättelse som hjälper till att ge data det sammanhang som saknas.
Hur man INTE använder den
Ett av IBM-teamen som använde Kano-modellen var tveksam till att använda den igen. Detta team ställde upp frågeformuläret med hjälp av scenarier som de trodde var det nuvarande sättet som saker och ting fungerade på för att beskriva funktionerna. När testningen fortskred blev det dock mycket snabbt uppenbart att designteamets scenarier inte återspeglade hur kunderna faktiskt använde produkten, och testningen spårade snabbt ur.
Tanken att använda scenarier för att beskriva funktionerna är bra, men när vi diskuterade deras tillvägagångssätt blev det tydligt att scenarierna måste valideras i förväg. Kombinationen Kano + scenarier skulle vara kraftfull efter generativ forskning som fastställer situationen som den är.
Ett annat råd var att skala ner antalet funktioner som testas. Teamet som tog sig an en lång lista med 30-40 funktioner sa att det var lite för intensivt och att kunderna blev överväldigade och utmattade i slutet av testet.
Fördelar
Kano-modellen är mycket bra på att prioritera funktioner. En teori som ligger till grund för Kano-modellen är vad Daniel Zacarias kallar ”the natural decay of delight”. Innovativa idéer och produkter rör sig från att vara spännande och nya, högst upp i Kano-diagrammet (attraktiva) till förväntade funktioner, längst ner (i bästa fall måste man ha dem, i sämsta fall är de avskräckande).
Tag trådlöst internet som exempel*. Det är 2001 och du reser i jobbet och har en toppmodern bärbar dator som har en Ethernet-port och WiFi. Du är på ett hotell och får reda på att de har ethernetportar så att du kan ansluta till Internet. De har inte trådlöst internet som ingår i rumspriset, men du kan få WiFi i deras företagscenter. Du är glad! Det är fantastiskt! Vilka fantastiska alternativ!
Fast forward till 2017. Du reser i jobbet och har en enkel bärbar dator med WiFi. Du är på ett hotell och får reda på att de har ethernetportar så att du kan ansluta till internet. De har inte trådlöst internet som ingår i rumspriset, men du kan få WiFi i deras företagscenter. Du är rasande! Vilken planet är det här hotellet från för att du måste betala extra för internet?! Och vem använder fortfarande sin ethernet-port för att ansluta till Internet längre?
Det som började som en attraktiv funktion (ethernet-portar på rummet och WiFi i affärscentret) förvandlades 16 år senare till en oönskad funktion.
Om teamet inte har koll på vad kunderna vill ha, kan de komma att fokusera på funktioner som är förväntade i stället för attraktiva. En av IBM-forskarna som hade använt Kano-modellen noterade detta i sitt eget team: ”Det fanns vissa funktioner som teamet var mycket entusiastiska över, och sedan insåg de att de var bordspengar.”
Övrig potential
När vi diskuterade Kano-modellen teoretiserade vi att den har potential för några andra saker också:
- Mätning av djupet av smärtpunkter
- Baserade funktioner under en produktlivscykel för att bedöma det naturliga förfallet av glädje över tiden
Djupet av smärtpunkter
Den här modellen skulle kunna hjälpa till att avslöja hur allvarliga befintliga smärtpunkter är. Kano frågeformuläret lämpar sig lätt för att möjliggöra forskning för att gräva djupare för att lära sig mer om varför smärtpunkterna är så svåra som de är, och varför dessa funktioner är så viktiga för kunderna. Det skulle kunna avslöja vissa tidigare oidentifierade behov och leda till ytterligare innovation.
Baselining features
Vi diskuterade att använda Kano-modellen för att regelbundet utvärdera funktioner för att observera vilka funktioner som nedgraderas till lägre kategorier. Denna typ av longitudinell testning, med en tillräckligt stor kundbas, skulle kunna indikera marknadstrender och förväntningar och bidra till att fortsätta att bevisa forskningens värde över tid. Det skulle också kunna hjälpa grupper att veta när deras produkt börjar bli en platå och är i behov av innovativa idéer för att återgå till en trendsättande status.
Öppen fråga
Ibland agerar designgrupper på IBM som konsulter för projekt. Vissa designteam på IBM ombeds att delta i ett projekt för att ”städa upp användbarheten” och strö det magiska UX-dammet på en produkt strax före lanseringen. Andra designteam är tillfälligt inbäddade i ett bredare produktteam.
Vi hade en öppen fråga kvar i slutet av vår diskussion: Är Kano-modellen användbar om man inte kan påverka produkten? Du kanske inte kan påverka produkten eftersom den redan är under utveckling, på grund av ledningens motstånd, eftersom designteamet bara tillfälligt ingår i produktteamet osv. Är det värt besväret att använda Kano-modellen?
Och kanske är den fortfarande användbar även om du inte kan påverka produkten?
Tankar?