Kano Model — Ways to use it and NOT use it
The design team comes up with a list of user needs for your product. The engineering team comes to the table with a different set of features. The management team only wants the features that will make the company money. The support team sees entirely different features that need to be fixed. How is a product team to know in what direction to go?
As design researchers, we rely on what customers say and do to read deeper and discover what they want. However, many of us have often struggled with new ways to quantify and visualize those needs in an effective manner for these teams to come into alignment. Customers can certainly vote on and rank features, which gives a great overview, but doesn’t always give that deeper understanding of what are the must-haves over what is already expected.
Enter the Kano Model.
What is it?
The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories. It provides techniques to help us understand customers’ perspectives on product features by assessing two measures for each feature: the satisfaction and sentiment. The responses to these two measures will fall into one of the five categories: Attractive, Performance, Indifferent, Must-Be, Undesired.
How to use it
Craft a questionnaire with each feature listed separately. For each feature, ideally you demonstrate the what the feature can do through a prototype or interactive wireframe, when possible. Don’t spend much time prototyping for this: it’s just a prototype to get the idea across. Some people can get really tied up in the details even in prototypes, because they may like the idea, but not how it was implemented.
If it’s not possible to demo the features, an explanatory text description also works well.
Pro-tip: In discussion with other IBM researchers, those who were more successful tested 15–20 features. Those who were less successful tested 30–40. Testing more than 20 features was an overwhelming amount of data, both for the customers, and for the researchers to analyze.
After seeing each feature, users select their response to the Kano questionnaire:
- If you had (feature), how do you feel?
- If you didn’t have (feature), how do you feel?
(Daniel Zacarias has some excellent pointers on how to write these questions in a clear way)
The standard Kano questionnaire responses to both of the above questions are:
- I like it
- I expect it
- I’m neutral
- I can tolerate it
- I dislike it
Daniel Zacarias also offers some other options for the answer set for these answers. Basically, if you’re going to try the Kano model read his whole article. It’s amazing.
Jan Moorman also recommends adding a third question: How important is this feature? She recommends using a nine-point Likert scale of “Not at all important” to “Extremely important”. However, when trying to spell out the nine points on the Likert scale for importance, it’s … a bit tricky. It seems that the seven point Likert scale is easier.
Once you have the answers, there’s an analysis process that Daniel Zacarias describes in great detail. I strongly suggest you go read through that.
One issue researchers at IBM found was that having these numbers were great, but the numbers themselves didn’t tell anyone why, the inevitable question we will all get from our management teams. One team used the Kano model to conduct around 15 qualitative interviews. Another team conducted 5 qualitative interviews after getting questionnaires from 40 people. Both teams strongly recommended adding qualitative interviews to this process, as it added the narrative that helps to give the data its missing context.
How to NOT use it
One of the IBM teams who used the Kano model was hesitant about using it again. This team set up the questionnaire using scenarios they believed to be the current way things worked to describe the features. However, as the testing progressed, it became obvious very quickly that the design team’s scenarios did not reflect how customers actually used the product, and the testing derailed quickly.
The idea of using scenarios to describe the features is good, but as we discussed their approach, it became clear that scenarios must be validated beforehand. The Kano + scenarios combination would be powerful following generative research that establishes the as-is situation.
Another piece of advice was to scale down the number of features being tested. The team that took on a long list of 30–40 features said it was a bit too intensive, and that customers got overwhelmed and worn out by the end of the test.
Benefits
The Kano model is very good at prioritizing features. A theory that underlies the Kano model is what Daniel Zacarias calls “the natural decay of delight.” Innovative ideas and products move from being exciting and new, at the top of the Kano chart (Attractive) to expected features, at the bottom (Must-haves at best, detractors, at worst).
Take wireless Internet as an example*. It’s 2001, and you’re traveling for work, and have a top of the line laptop that has an ethernet port and WiFi. You’re at a hotel, and you learn that they have ethernet ports for you to connect to the Internet. They don’t have wireless Internet included in your room rate, but you can get WiFi in their business center. You’re stoked! It’s amazing! What great options!
Fast forward to 2017. You’re traveling for work and have a basic laptop that has WiFi. You’re at a hotel, and you learn that they have ethernet ports for you to connect to the Internet. They don’t have wireless Internet included in your room rate, but you can get WiFi in their business center. You’re furious! What planet is this hotel from that you have to pay extra for Internet?! And who still uses their ethernet port to connect to the Internet anymore?
What started out as an attractive feature (ethernet ports in the room, and WiFi in the business center), 16 years later turned into an undesired feature.
If teams aren’t clued in to what customers want, they could be focused on features that are expected instead of attractive. One of the IBM researchers who’d used the Kano model noted this on her own team: “There were some features that the team was very excited about, and then realized that those were table stakes.”
Additional Potential
As we discussed the Kano model, we theorized it has the potential for a few other things, too:
- Gauging the depth of pain points
- Baselining features over a product lifecycle to assess the natural decay of delight over time
Depth of pain points
This model could help to reveal just how bad existing pain points are. The Kano questionnaire easily lends itself to allow for research to dig deeper to learn more about why the pain points are as bad as they are, and why these features are so important to customers. It could unveil some previously unidentified needs and lead to further innovation.
Baselining features
We discussed using the Kano model to assess features on a regular basis to observe which features were downgrading to lower categories. This type of longitudinal testing, with a large enough base of customers, could indicate market trends and expectations and help continue to prove research value over time. It could also help teams to know when their product is starting to plateau and are in need of innovative ideas to return to a trend-setting status.
Open Question
Sometimes design teams at IBM act as consultants for projects. Some design teams at IBM are asked to come on to a project to “clean up the usability” and sprinkle the magical UX dust on a product shortly before launch. Other design teams are temporarily embedded on a broader product team.
We were left with one open question at the end of our discussion: is the Kano model useful if you can’t impact the product? You may not be able to impact the product because it’s already under development, because of management pushback, because the design team is only temporarily part of the product team, etc. Is going through the effort of using the Kano model worth it?
Or, maybe it’s still useful even if you can’t impact the product?
Thoughts?
At IBM in Austin, a group of design researchers meet for lunch a few times a month to discuss research topics of interest. Afterwards, the researchers in IBM Power Systems, the primary conversation facilitators, collect and note the highlights of the conversation. This is one of the series of posts about the lunches from IBM Power Systems researchers.
*inspired by Jared Spool’s example (see below)
Resources
- The brilliant Daniel Zacarias has a complete explanation of how to fully implement and use the Kano Model, where he gives not only a phenomenal overview, but tools to tabulate as well: https://foldingburritos.com/kano-model/
- Jan Moorman discusses her experience with the Kano model at projekt202: https://uxmag.com/articles/leveraging-the-kano-model-for-optimal-results
- Jared Spool discusses the Kano Model at length: https://www.youtube.com/watch?v=ewpz2gR_oJQ
cary-anne olsen-landis is the Experience Research Lead for Power Systems at IBM based in Austin. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
