Kano Model

Overview

The Kano model answers a question a plain needs list leaves open: does a requirement really matter the same amount whether it is met or not? Usually not. Some features only cause frustration when missing, without adding extra delight when present; others do the exact opposite. The module classifies every collected requirement along that pattern, producing a prioritization that a simple importance scale cannot deliver on its own.

In the DMAIC flow, Kano comes into play once the VoC→CTx tree has worked out needs, drivers, and requirements, and before a binding decision is made on what to tackle first. Skip this step and every requirement carries equal weight; run it, and it becomes visible which features separate "it works" from "it delights".

Must-be (M): Also called basic quality. Taken for granted. Meeting it barely registers; missing it causes clear dissatisfaction. Investment here prevents anger, it does not create delight.

Performance (O): Satisfaction rises with the degree of fulfillment, dissatisfaction falls accordingly. The classic "more is better" — every improvement here shows up directly.

Attractive (A): Also called excitement quality. Not expected at all. Its absence barely bothers anyone; its presence is a pleasant surprise. Attractive features tend to migrate toward performance or even must-be status once the market gets used to them.

Indifferent (I): Neither fulfilling nor omitting the feature moves satisfaction in any noticeable way. Effort spent here rarely pays off.

Reverse (R): The reaction runs opposite to what was expected — respondents would actually be happier without the feature. Often a sign that the requirement was phrased wrong or asked from the wrong perspective.

Questionable (Q): The two answers to one item logically contradict each other. Not a substantive result but a signal of a data problem — see below.

Items come from the VoC→CTx tree, at the level of needs, drivers, or requirements — whichever is chosen. One Kano instance always works on exactly one of these three levels; anyone who needs to rate both needs and drivers creates two separate instances.

Reconciling with the tree never happens silently in the background. A status line reports how many nodes were added, renamed, or have disappeared from the tree — only clicking "adopt from tree" carries that over. Vanished nodes are never deleted, only flagged as orphaned; their already-captured answers are kept, in case the node was only temporarily restructured or the results are still needed. Data flow is strictly one-directional: the Kano module reads from the tree but never writes back to it.

Approach

Capture is organized by respondent: a tab bar switches between people without changing the item list. Each item carries two questions on the same five-step reaction scale — from "I would be delighted" to "I would be very unhappy": one asking how the respondent reacts if the requirement is met (the functional question), one asking how they react if it is not (the dysfunctional question).

Both questions are needed because only their combination yields the category. A single question cannot tell whether agreeing with "this matters to me" reflects a must-be, performance, or attractive feature — the same high importance looks identical for all three. Only the answer pair, looked up in the classic Kano evaluation table, separates the six categories.

An optional third question adds importance on a scale from 1 (not important at all) to 9 (extremely important). It does not change an item's category — that is decided solely by the two Kano questions — but feeds bubble size in the Better/Worse chart and helps rank items within the same category. Where the survey needs to stay short, or a within-category ranking is not needed anyway, it can be left out.

An item's category is the modal value across all respondents: whichever of the six categories occurs most often. On a tie, the order M > O > A > I > R > Q decides — the stronger, more decisive category wins — and the row is additionally flagged as a tie so it does not go unnoticed.

The same counts produce two metrics: CS = (A+O)/(A+O+M+I) describes the satisfaction potential if the requirement is fulfilled — the closer to 1, the more satisfaction is up for grabs. DS = −(O+M)/(A+O+M+I) describes the dissatisfaction risk if it is not — the closer to −1, the greater the damage from not delivering. R and Q are deliberately excluded from the denominator: they express no preference for or against the requirement, only a reversal of the expected reaction (R) or a contradiction between the answers (Q). Counting them in would dilute CS and DS rather than sharpen them. If an item's answers are entirely R and Q, the denominator becomes 0 — no metric applies, and the display shows "—".

The Better/Worse chart plots CS against DS: x = |DS|, y = CS, with reference lines at 0.5 on each axis. When the third question is active, bubble size grows with the item's mean importance. Below the chart, the four quadrants appear as a legend: top-left attractive, top-right performance, bottom-left indifferent, bottom-right must-be.

A high share of questionable (Q) answers is almost never a substantive finding — it is nearly always a sign that a question was misunderstood or answered with reversed polarity. The module warns once the Q share exceeds 10%, both overall and per item. When that happens, it is worth reviewing the wording in question and, when in doubt, asking the respondent again rather than accepting the category at face value.

Pitfalls

Trying to cover everything with one level: A Kano instance always rates a single tree level. Anyone who needs to classify needs and drivers separately needs two instances — not a level switch hoping the old answers still apply.

Ignoring the sync status: When the tree changes, the item list stays on the old state until "adopt from tree" is clicked. Skipping the status line means evaluating outdated or renamed items without noticing.

Deleting orphaned items right away: A node that vanished from the tree is flagged, not deleted — its answers are kept. Before deleting it manually, check whether the node was only renamed or moved and the answers are still valid.

Forcing the third question under time pressure: Importance does not change an item's category, only its ranking within a category. Where time is short, the evaluation still produces complete M/O/A/I/R/Q categories without it.

Accepting a high Q share as a result: An item with many contradictory answers is not a genuine "Kano Q feature" — it signals a confusingly worded question. Clarify the wording first, then take the category seriously.

Downgrading must-be features by their CS value: A low CS combined with a high DS does not mean "unimportant" — quite the opposite, missing this requirement is costly. Must-be features still need to be secured even though they never stand out with a high CS in the chart.

Examples

This module ships with the following example datasets — load any of them in the app with a single click.

Available in the following cycles

• DMAIC: Define
• DMADV: Define
• No fixed phase in cycle 8D (lives in the "More" tile).