Isn't the attractiveness curve in the Kano model depicted wrong?

Question

tl;dr:

The description of "attractive" features talks about a "quick rise" in user satisfaction and "checking investment...beyond a point its overkill" yet the graph doesn't show a quick rise and trail off, it shows a slow rise and then exponential increase at the point that maximum effort. The graph must be wrong?

Longer:

I'm reading up about gathering user requirements and converting them to an engineering specification for a product. The Kano model has come up and its really interesting. However, I don't understand the depiction of one of the factors on the graph.

An "Attractive" feature is described as one the user isn't expecting, but is delighted to discover. Therefore, a feature that doesn't result in dissatisfaction when it is absent, but does result in lots of satisfaction when it is present.

From https://foldingburritos.com/kano-model/

Look how even some level of Functionality leads to increased Satisfaction, and how quickly it rises. This fact is key to keep a check on the investment we make on a given feature. Beyond a certain point, we’re just over-killing it.

And this makes sense to me. If a product contains a new innovation I wasn't expecting I will be very impressed. But, if the designers have invested a huge amount into this feature (and functionality and investment are interchangeable in the Kano model), then I am unlikely to continue to be further impressed at the same rate, let alone exponentially increase how satisfied I am.

"The Complete Guide" (as linked) seems to confirm this "Beyond a certain point, we’re just over-killing it." and refers to it being important to keep a check on investment. Again, I can see how an impressive new feature could become exciting for the designers and draw too much development effort, with diminishing returns in terms of customer satisfaction. The customer is very impressed with a little innovation ("wow thats cool"), giving them a lot of innovation might make them a bit more impressed, but clearly not at same rate, meaning investment on such features should be capped to avoid inefficiently consuming development resources at the expense of other key features or overall project cost.

BUT... then we come to the graph. Which implies the opposite.

Increasing investment in 'nice to have' results in exponential increase in satisfaction?

According to this graph, as investment into an unexpected/new/innovative feature's functionality is increased, user satisfaction goes up exponentially. In fact, according to the graph, at the higher end of investment, where we perhaps have a disproportionately large part of our budget and team assigned to this feature, which the user isn't even expecting to see, for every tiny increase in investment there is an infinite increase in user satisfaction.

It seems to me that the graph is inverted. That what should be shown, according to the description, which is a logical description of the points of concern, is a rapid rise in satisfaction as a new innovative feature is invested in, followed by a tailing off and eventual flatline of user satisfaction. For example, the first time I used a phone that could put someone on hold to receive a second incoming call I was impressed. This wasn't something I was expecting, but the feature was cool and useful, and my satisfaction went up. However, if the design team had thrown the kitchen sink at this new idea to the point that my phone could now accept 5, 10, or even 100 incoming calls, it is unlikely my satisfaction would have further increased at all, let alone exponentially.

Contrast this with battery life, which is not an "attractive" feature, its a "performance" feature, in that it is expected to be present, and better performance gives more user satisfaction in direct proportion. In this case if I'm offered a phone that can last 5, 10 or even 100 hours longer than my old one, I am likely to be a little, a lot, and then hugely more satisfied. Yet the Kano graph implies that a "nice to have" innovative feature will give vastly more user satisfaction than taking a critical feature and producing maximum performance, for the same level of investment.

Satisfaction as investment in key feature improves performance

What gives? Am I right, and this is being depicted wrong? Or is the description (and my experience in new product development teams) wrong?

EDIT: Alhough I'm asking about the apparent internal contradiction in the Kano graph vs the more logical description, there is another reason to reject this particular line on that graph from an external source, and that is the Pareto principle. The Pareto principle refutes what the graph is saying (that the majority of the benefit is only realised after maximum progress), but is consistent with the description Kano model gives, that a little effort goes a long way, but continued increase in effort has diminishing results.

Obviously the attractive line should be of the shape of the must-be line, only 100% above the satisfaction zero point, rather than 100% below it. You might even argue that it need not be 100% above the zero, because although the customer isn't expecting your new feature, and so its a 'bonus', once they are aware of it and try to use it, it must meet a minimal functionality or the disappointment/failed delivery will reduce satisfaction and your reputation in their eyes. In other words, a good idea badly implemented is worse than not implementing it at all. There is a minimum standard to be met, as seen in the 'performance' line.

I really don't understand how the graph can be so clearly at odds with the description without challenge. What am I missing?

Answer 1

Fascinating question and more subtle than I originally thought.

According to this graph, as investment into an unexpected/new/innovative feature's functionality is increased, user satisfaction goes up exponentially. In fact, according to the graph, at the higher end of investment, where we perhaps have a disproportionately large part of our budget and team assigned to this feature, which the user isn't even expecting to see, for every tiny increase in investment there is an infinite increase in user satisfaction. It seems to me that the graph is inverted. That what should be shown, according to the description, which is a logical description of the points of concern, is a rapid rise in satisfaction as a new innovative feature is invested in, followed by a tailing off and eventual flatline of user satisfaction. For example, the first time I used a phone that could put someone on hold to receive a second incoming call I was impressed. This wasn't something I was expecting, but the feature was cool and useful, and my satisfaction went up. However, if the design team had thrown the kitchen sink at this new idea to the point that my phone could now accept 5, 10, or even 100 incoming calls, it is unlikely my satisfaction would have further increased at all, let alone exponentially.

I like your example - but I think that example is a single point on the line, not the entire line. Compare your example with the examples given in the paper, "The first time we used an iPhone, we were not expecting such a fluid touchscreen interface" "Think of the first time you used Google Maps or Google Docs. You know, that feeling you get when experiencing something beyond what you know and expect from similar products."

• If the line represented the touchscreen interface, you'd be correct - a fluid high performance touchscreen interface is delightful, but there are rapid diminishing marginal returns from a more fluid/more high performance touchscreen interface. (In my case, the performance exceeds what I'm biologically capable of; most touchscreens are hypersensitive in my case, and I have to detune them to get functionality).
• the first time you use google maps - the first time you can replace a paper map with something that is constantly up to date, doesn't need to be folded and presents geographically context relevant information that is delightful. Once again, there are diminishing marginal returns as the amount of context relevant information rises. I've turned off some context information in google maps because it keeps sending me information about fast food joints, when I'm looking for five star restaurants.

I think that the line is the set of these features - delight comes not from the sophistication of individual features, but rather from the accumulated set of useful features that were not part of the customer's expectation set.

(of course the real challenge is predicting whether a given feature will be perceived by the consumer as "delight" or "indifferent")

No authoritative answer, but that is my interpretation of the text. Hope that helps.

Answer 2

I would look carefully at the term, "attractive," and not necessarily presume that it is referring to aesthetics. When someone has a job to do with a piece of software, the adjective "attractive" doesn't necessarily refer at all to how it looks. ("Paint the hammer any color that you want to ...")

I would not place too much credence, frankly, on "XY graphs" that have no scale and which, in the end, are really trying to express an idea. Well, here's my expression of that idea:

1. It must(!) do the job. It must be able to enable the user to reliably and correctly accomplish the task, having never read any manual. "Forgive me all of my trespasses, and do the job regardless ... or, whatever you do, don't let me shoot off my foot."

2. It should help me do the job. The experience of using the software should be significantly better than "doing it by hand" – if such a thing is possible. (This is where "aesthetics" might fit in.) The software should meaningfully assist me in getting the job done, if possible. Especially when it leverages the digital computer's awesome power.

3. "Performance is nice, of course." (But these days, in a pinch, we can always "throw silicon at it.")

Occasionally, people interact with a computer "for the fun of it." But usually, your software is a tool for the job. As a designer, you should strive to put yourself in direct contact with people who actually have to do that job, and listen very carefully to them. If they're willing, brainstorm with them. Try to give them, if you can, not only "everything they expect" but – from their point-of-view, not yours(!) – "something more."