Say goodbye to gut-feel decisions! The KANO Model instance(Glimmer PM01)

First, the origin of the name “Kano”. It is a model named after its founder, Noriaki Kano, and is not an inherent English term. Therefore, it cannot be split into an acronym (e.g., K standing for something, A for another).

I. Model Fundamentals

Let’s start with the model’s purpose: it is used to evaluate the priority of a product or requirement. Whether a feature (or even a task) is worth doing, when to do it, and what to prioritize can all be analyzed and justified using this model — thereby optimizing resource allocation and even directing the flow of wealth.

In the Kano Model, user requirements for a product are categorized into five levels:

1. Must-be Requirements
2. One-dimensional Requirements
3. Attractive Requirements (also called Excitement Requirements)
4. Indifferent Requirements
5. Reverse Requirements

Take a short video app as an example to illustrate each:

• Must-be Requirements: The core functions of a product — without them, the product loses its reason for existence. For instance, video playback and pause features in a short video app.
• One-dimensional Requirements: Features users expect the product to have. Their satisfaction increases with the presence of these features and decreases without them. They are less critical than must-be requirements. Examples include speed control and download/cache functions.
• Attractive Requirements: Value-adding features that delight users — their presence encourages engagement and sharing, but their absence does not cause dissatisfaction. For example, intelligent subtitles (eliminating the need to watch unsubtitled content).
• Indifferent Requirements: Features that have no impact on user satisfaction, whether present or not. For example, whether an app has a splash screen.
• Reverse Requirements: Features that annoy users when present but are well-received when absent. A typical example is long, unskippable ads in a product.

II. Evaluation Methodology

How to conduct requirement evaluation? The core lies in user research. Below are key methods and considerations:

1. Selection of Sample UsersUser needs vary — what is a one-dimensional requirement for some may be an indifferent requirement for others. Thus, sample selection is critical. Research should target core users and high-frequency users, including both existing and new users.
2. Design of Research QuestionnairesTo determine if a requirement is must-be or reverse, two-way questions (positive and negative) are required. For example: “What level of requirement is adding a product showcase to a short video app?”Invite 100 core users to participate, with two sets of questions:

• Positive question: “How would you feel if the app added a product showcase feature?” (Satisfied / Neutral / Dissatisfied)
• Negative question: “How would you feel if the app did NOT add a product showcase feature?” (Satisfied / Neutral / Dissatisfied)

Analyze the results using the simplified classification matrix below:

Hypothetical Results:

• 60% of users: Positive = “Satisfied”, Negative = “Dissatisfied” → Corresponding to “One-dimensional Requirement”
• 30% of users: Positive = “Neutral”, Negative = “Dissatisfied” → Corresponding to “Must-be Requirement”
• 10% of users: Positive = “Satisfied”, Negative = “Neutral” → Corresponding to “Attractive Requirement”

Final Judgment: Adding a product showcase is primarily a “One-dimensional Requirement” (based on the highest proportion) and should be prioritized for optimization.

Avoid Ambiguous Descriptions. For example, instead of vague phrases like “optimize the product showcase feature” or “add a product showcase icon”, use specific descriptions: “Add a small product showcase icon (100100 pixels) at the bottom right corner of the video playback page; tapping it redirects to the corresponding product page.”

III. Conclusion

In essence, the Kano Model optimizes resource allocation through classification to maximize user satisfaction — not mere categorization. Its application extends beyond product development and requirements management; it can also assist in daily decision-making. For example, deciding whether to enroll a child in extracurricular classes can be based on two-way feedback from both the child and parents. A detailed case study will be provided in a separate article.