The Kano Model: How Needs Affect User Satisfaction¶
Glossary¶
Basic need (Must-be)
Something users normally assume will work. They may not ask for it, but they will be dissatisfied if it is missing.
Performance need
Something users notice, request, or compare. The better it is fulfilled, the more satisfied they become.
Delight need (Attractive)
Something users do not expect or ask for, but which can pleasantly surprise them when it is provided.
Not every need affects users in the same way. Some needs are silently expected, some become more valuable as their quality improves, and some create satisfaction precisely because users did not expect them.
The Kano model helps describe these different relationships between a need and user satisfaction.
Software Development Examples¶
The same software feature can belong to different Kano categories depending on the product and its users. The examples below show how the categories might appear in typical software development projects. They are examples, not fixed classifications.
Basic Needs¶
These are things users often assume will simply work.
- Login works correctly: valid credentials let the user in, while invalid credentials do not.
- Data is not accidentally lost: information saved by the user is still there when they return.
- Basic operations behave correctly: creating, editing, and deleting an item produces the expected result.
- The application does not regularly crash during normal use.
- Access control is respected: ordinary users cannot access administrator-only functionality.
Users may never explicitly request these features. If they fail, however, the software can quickly feel broken or untrustworthy.
Performance Needs¶
These are qualities where users can notice and value improvement.
- Faster search: returning results in one second is better than returning them in five.
- Better search results: relevant results appearing first makes the feature more useful.
- More convenient filtering: supporting several useful filters helps users find what they need.
- Faster data processing: processing a large input in 20 seconds may be more satisfying than requiring two minutes.
- Better mobile usability: fewer awkward interactions and easier navigation improve the experience.
Here, "more" or "better" usually matters. Improving the feature can directly improve user satisfaction.
Delight Needs¶
These solve additional problems that users may not have thought to request.
- Undo after an accidental deletion: instead of only asking for confirmation, the application lets the user restore the deleted item.
- Helpful automatic suggestions: the system notices repeated input and offers to reuse or complete it.
- Remembering useful context: when the user returns, the application restores the filters or working state they were previously using.
- A useful shortcut discovered from behaviour: a frequently repeated multi-step operation can suddenly be performed with one action.
- Helpful error recovery: instead of merely reporting that an import failed, the application identifies the problematic rows and allows the valid ones to be imported.
The important part is not that these features are sophisticated. A small feature can be a delight if users did not expect it and it solves a real problem surprisingly well.
Tip
Do not classify a feature only by looking at what it does. Ask what the users of this particular product expect. Automatic saving, for example, might be a delight in one application and an unquestioned basic need in another.
Basic Needs¶
Info
Users usually do not ask for basic needs because they assume these needs will be fulfilled.
When a basic need is missing, users may consider the product broken, unreliable, or unacceptable. Fulfilling it does not usually create excitement; it merely prevents dissatisfaction.
Example
In a navigation application, users may never explicitly request that the calculated route lead to the correct destination. If it does not, however, they will strongly dislike the application.
A useful recognition question is:
Would users be dissatisfied and consider the product unacceptable without this?
Performance Needs¶
Info
Performance needs create more satisfaction when they are fulfilled better, faster, more accurately, or in greater quantity.
Users are more likely to mention, request, compare, or complain about these needs. A weak result causes lower satisfaction, while an improved result creates higher satisfaction.
Example
In a navigation application, users may compare route calculation speed, traffic accuracy, or the number of useful route alternatives. Better performance makes the application more valuable.
A useful recognition question is:
Does improving this need directly make the product more useful or satisfying?
Delight Needs¶
Info
Users usually do not request delight needs because they do not expect them or may not know that they are possible.
Their absence normally causes little dissatisfaction. Their presence, however, can create a pleasant surprise and make the product feel unusually thoughtful or helpful.
Example
A navigation application may warn that the destination entrance is on another street and guide the user directly to it. Users may not have requested this, but they can be very happy when the application solves the hidden problem for them.
A useful recognition question is:
Would users be pleasantly surprised if the product provided this?
Comparing the Categories¶
| Category | Will users usually ask for it? | If it is missing | If it is fulfilled |
|---|---|---|---|
| Basic | Often not | Strong dissatisfaction | The product feels acceptable |
| Performance | Often yes | Lower satisfaction | More or better creates more satisfaction |
| Delight | Usually not | Little or no dissatisfaction | Pleasant surprise and extra satisfaction |
Tip
Listen not only to what users request, but also to what they silently assume and what could solve a problem they have not learned to express.
Categories Depend on Context¶
A need does not have one permanent Kano category. Different users may have different expectations, and the same need may belong to different categories in different products or situations.
For example, offline access may be a delight for an occasional user, a performance need for a frequent traveller, and a basic need for someone who must work where network access is unreliable.
Categories Change Over Time¶
User expectations evolve. A feature that once created delight can become common, then eventually become a basic expectation.
Example
Automatic saving was once an impressive feature in many applications. Today, users may simply expect not to lose their work.
Kano Category Is Not Priority¶
Danger
A Kano category does not automatically tell the team what to implement first.
A basic need may be essential, but expensive. A delight need may be cheap and valuable. Legal obligations, project goals, risks, dependencies, effort, and available resources still matter when deciding priorities.
The Kano model describes how a need may affect satisfaction. It does not replace validation, prioritisation, or engineering judgement.