ux-kano-model

Kano Model Sub-Skill

Version: 1.2.0 Framework: Jerry User-Experience -- Kano Model Constitutional Compliance: Jerry Constitution v1.0 Parent Skill: /user-experience (skills/user-experience/SKILL.md) Wave: 4 (Advanced Analytics) Project: PROJ-022 User Experience Skill | GitHub Issue #138

Document Sections

Section	Purpose
Document Audience	Triple-Lens audience guide
Purpose	Sub-skill overview and key capabilities
When to Use This Sub-Skill	Activation triggers and scope boundaries
Available Agents	Single agent with role, model, and output location
P-003 Compliance	Worker agent hierarchy position
Invoking the Agent	Invocation via ux-orchestrator
Methodology	Kano Model categories, evaluation table, CS coefficients, sample size considerations
Execution Procedure	5-phase workflow from scope definition through synthesis
Output Specification	Output location, L0/L1/L2 structure, required sections
Routing	Keywords and lifecycle-stage routing integration
Cross-Framework Integration	Upstream inputs and downstream handoffs
Synthesis Hypothesis Confidence	Confidence classifications with rationale
Quality Gate Integration	H-13/H-14 compliance for C2+ deliverables
Degraded Mode Behavior	Operation with insufficient respondents or without survey data
Wave Architecture	Wave 4 entry criteria and bypass conditions
Constitutional Compliance	Governing principles
Registration	Parent-routed registration model
Deployment Status	Current implementation status
Quick Reference	Common workflows and agent selection hints
References	Full repo-relative paths to all referenced files

Document Audience (Triple-Lens)

This SKILL.md serves multiple audiences:

Level	Audience	Sections to Focus On
L0 (Stakeholder)	Product managers, feature owners	Purpose, When to Use This Sub-Skill, Quick Reference
L1 (Developer)	Engineers invoking the agent	Invoking the Agent, Execution Procedure, Output Specification
L2 (Architect)	Workflow designers, skill maintainers	Methodology, Cross-Framework Integration, Synthesis Hypothesis Confidence

---

Purpose

The Kano Model sub-skill provides AI-augmented feature classification and prioritization using the Kano Model methodology (Kano et al., 1984). It assists tiny teams (1-5 people) in understanding which features satisfy, delight, or frustrate users by classifying features into five categories based on the functional/dysfunctional questionnaire pair.

The agent operates on user-provided survey data or assists with survey design when no data exists. It does NOT conduct surveys itself -- it designs questionnaires, analyzes response data, and produces classification reports with Customer Satisfaction (CS) coefficients for priority decision-making.

Key Capabilities

• Survey Design -- Generates functional/dysfunctional question pairs ready for team administration
• Response Classification -- Maps answer pairs to Kano categories using the 5x5 evaluation table (Kano et al., 1984)
• CS Coefficient Calculation -- Computes Better/Worse coefficients per feature (Berger et al., 1993)
• Priority Matrix -- Better vs. Worse scatter plot for feature prioritization
• Feature Lifecycle Analysis -- Attractive-to-Performance-to-Must-be migration patterns
• Conflict Detection -- Identifies split classifications and flags for domain expert resolution
• Sample Size Awareness -- Calibrates confidence by respondent count (5-8 = directional; 20+ = statistical)

---

When to Use This Sub-Skill

Activate when:

• Prioritizing a backlog of potential features by user satisfaction impact
• Deciding which features are "table stakes" (Must-be) versus differentiators (Attractive)
• Designing a Kano survey questionnaire for team administration
• Analyzing existing Kano survey response data
• Determining which features to invest in, maintain, or deprioritize
• Understanding how feature expectations shift as a product matures (lifecycle dynamics)
• Resolving disagreements about feature priority with a structured, evidence-based framework
• Receiving a job-derived feature list from /ux-jtbd that needs prioritization

Do NOT use for:

• General usability evaluation of existing interfaces (use /ux-heuristic-eval)
• Diagnosing why users fail to take a desired action (use /ux-behavior-design)
• Measuring ongoing UX health metrics (use /ux-heart-metrics)
• Accessibility compliance auditing (use /ux-inclusive-design)
• Building component libraries (use /ux-atomic-design)
• User motivation research without a defined feature list (use /ux-jtbd)
• Running rapid prototyping sprints (use /ux-design-sprint)
• General research without UX focus (use /problem-solving)

---

Available Agents

Agent	Role	Tier	Mode	Model	Wave	Output Location
ux-kano-analyst	Kano model feature classification and prioritization	T2	Convergent	Sonnet	4	projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-kano-analyst-{topic-slug}.md

Tool tier: T2 = Read-Write (Read, Write, Edit, Glob, Grep, Bash). This agent operates on user-provided data only -- it does NOT have WebSearch, WebFetch, or Context7 MCP tools. The T2 assignment follows the principle of least privilege (AR-006): the agent reads feature lists and survey data provided by the user, performs classification analysis, and writes output reports. No external research is required because the Kano methodology is self-contained within the agent's training knowledge.

Cognitive mode: Convergent -- narrows from feature list and response data to classified priorities. Each iteration refines rather than expands.

Output at three levels per AD-M-004:

• L0 (Executive Summary): Feature classification overview with top priorities for stakeholders and cross-framework synthesis input.
• L1 (Technical Detail): Full classification table, CS coefficients, evaluation methodology, conflict analysis, and priority matrix.
• L2 (Strategic Implications): Feature lifecycle dynamics, competitive positioning, product maturity trajectory, and roadmap recommendations.

---

P-003 Compliance

This sub-skill contains a single worker agent (ux-kano-analyst) that is invoked by the parent ux-orchestrator. The agent MUST NOT include Agent in its tool list per H-01/P-003.

MAIN CONTEXT (user request)
    |
    v
ux-orchestrator (T5, Opus, Integrative) -- routes, gates, synthesizes
    |
    +-- ux-kano-analyst (T2, Convergent, Sonnet) [Wave 4] -- THIS SUB-SKILL

Enforcement: The ux-kano-analyst agent declares disallowedTools: [Agent] in .md frontmatter. The .governance.yaml includes Agent prohibition in capabilities.forbidden_actions with P-003 consequence statement.

---

Invoking the Agent

Via Natural Language Request

Describe your feature prioritization need; the orchestrator routes to this sub-skill:

"Classify these backlog features using Kano analysis"
"Which of these features are must-haves versus delighters?"
"Design a Kano survey for our feature candidates"
"Analyze these Kano survey results and prioritize the features"
"Help me decide which features to build first using Kano model"

Via Explicit Agent Request

"Use ux-kano-analyst to classify our product backlog features"
"Have ux-kano-analyst analyze the survey results in the attached data"

Via Agent Tool (orchestrator internal)

The ux-orchestrator invokes the agent via the Agent tool:

Agent(
    description="ux-kano-analyst: Kano feature classification for dashboard features",
    subagent_type="jerry:ux-kano-analyst",
    prompt="""
## UX CONTEXT (REQUIRED)
- **Engagement ID:** UX-0001
- **Topic:** Dashboard Feature Prioritization
- **Product:** [product name and domain]
- **Target Users:** [user description]
- **Input:** [feature list file path or inline feature list]
- **Survey Data:** [survey response file path, or "none -- design survey"]

## TASK
Perform Kano model feature classification. Classify features using evaluation
table, compute CS coefficients, produce priority matrix, flag split classifications.

## MANDATORY PERSISTENCE (P-002)
Create file at: projects/${JERRY_PROJECT}/engagements/UX-0001/ux-kano-analyst-dashboard-features.md
"""
)

Governance codification (AD-M-007): The session_context contract (on_receive/on_send) is specified in ux-kano-analyst.governance.yaml per AD-M-007. Fields are enumerated below:

on_receive fields:

Field	Type	Required	Description
engagement_id	string	Yes	UX engagement identifier (format: UX-{NNNN})
product_context	string	Yes	Product name, domain, and target user description
feature_list	array	Yes	Features to classify; each entry includes feature name, brief description, and optional category tag
survey_responses	array	No	Raw survey response data; each entry includes respondent ID and functional/dysfunctional answer pairs per feature. If absent, agent enters survey design mode.
respondent_count	integer	No	Number of survey respondents. Used for sample size confidence calibration.
upstream_artifacts	array	No	File paths to upstream handoff artifacts (JTBD job-derived feature list, heuristic eval findings)

on_send fields:

Field	Type	Required	Description
feature_classifications	array	Yes	Per-feature: name, category (M/O/A/I/R/Q), response distribution, confidence
cs_coefficients	array	Yes	Per-feature Better/Worse coefficients
priority_matrix	object	Yes	Better vs. Worse scatter with quadrant assignments and rankings
split_classifications	array	Yes	Features with no majority category; distribution breakdown, resolution prompt
survey_design	object	No	Functional/dysfunctional question pairs (survey design mode only)
lifecycle_analysis	object	No	Feature lifecycle stage with migration trajectory
synthesis_judgments	array	Yes	AI judgment calls with confidence (HIGH/MEDIUM/LOW) and rationale
sample_size_disclosure	object	Yes	Respondent count, statistical adequacy, confidence calibration

Source: Invocation pattern from parent SKILL.md [Invoking an Agent].

---

Methodology

The Kano Model

The Kano Model (Kano, Seraku, Takahashi, & Tsuji, 1984) classifies customer preferences into categories based on the relationship between feature implementation and customer satisfaction. Unlike linear models, the Kano Model recognizes that different feature types have fundamentally different satisfaction curves.

Feature Categories

Category	Symbol	Satisfaction Curve	Description	Example
Must-be	M	Absent = high dissatisfaction; present = neutral	Basic requirements taken for granted	Login, data persistence, back button
Performance	O	Linear: more = more satisfaction	Features with linear satisfaction relationship	Load speed, storage capacity, export formats
Attractive	A	Absent = neutral; present = delight	Unexpected features that differentiate	Smart autocomplete, AI suggestions
Indifferent	I	No satisfaction impact either way	Features customers do not care about	Backend database choice, internal refactoring
Reverse	R	Presence causes dissatisfaction	Features a segment actively does not want	Forced social sharing, auto-playing audio
Questionable	Q	Contradictory response	Misunderstood question or careless response	Likes both presence AND absence

Functional/Dysfunctional Questionnaire Methodology

The Kano Model uses a paired-question approach for each feature (Kano et al., 1984):

1. Functional question (positive form): "How would you feel if this product had [feature X]?"
2. Dysfunctional question (negative form): "How would you feel if this product did NOT have [feature X]?"

Each question uses a standardized 5-point response scale:

Response	Code	Meaning
I like it	1	Positive reaction to the feature state
I expect it	2	Considers this a basic expectation
I am neutral	3	No strong feeling either way
I can tolerate it	4	Mild negative reaction, but acceptable
I dislike it	5	Strong negative reaction

Kano Evaluation Table (5x5 Grid)

The combination of functional and dysfunctional responses maps to a Kano category using this standard evaluation table (Kano et al., 1984; Berger et al., 1993):

	Dysfunctional: Like	Dysfunctional: Expect	Dysfunctional: Neutral	Dysfunctional: Tolerate	Dysfunctional: Dislike
Functional: Like	Q	A	A	A	O
Functional: Expect	R	I	I	I	M
Functional: Neutral	R	I	I	I	M
Functional: Tolerate	R	I	I	I	M
Functional: Dislike	R	R	R	R	Q

Reading the table: Find the respondent's functional answer (row) and dysfunctional answer (column). The intersection cell gives the Kano category for that respondent-feature pair.

Example: A respondent answers "I like it" to the functional question and "I dislike it" to the dysfunctional question. The intersection is O (Performance/One-dimensional) -- the respondent values this feature linearly.

Customer Satisfaction (CS) Coefficient Calculation

CS coefficients quantify each feature's potential to increase satisfaction (Better) or risk dissatisfaction (Worse) (Berger et al., 1993; Matzler & Hinterhuber, 1998):

Better = (A + O) / (A + O + M + I)       Range: 0 to 1 (higher = more satisfaction potential)
Worse  = -(O + M) / (A + O + M + I)      Range: -1 to 0 (closer to -1 = more dissatisfaction risk)

Where A, O, M, I are the count of respondents classifying the feature in each category. R and Q responses are excluded from CS calculation (Berger et al., 1993).

Priority Matrix interpretation:

Quadrant (Better, Worse)	Feature Type	Strategy
High Better, Low Worse (top-left)	Attractive (delighters)	Invest for differentiation; not urgent
High Better, High Worse (top-right)	Performance (competitive)	Invest to stay competitive; high priority
Low Better, High Worse (bottom-right)	Must-be (basics)	Implement immediately; absence causes dissatisfaction
Low Better, Low Worse (bottom-left)	Indifferent	Deprioritize; no satisfaction impact

Axis direction note: "High Worse" means the absolute value of the Worse coefficient is close to 1.0 (i.e., closer to -1 on the 0-to-(-1) scale), indicating high dissatisfaction risk when the feature is absent. Higher absolute Worse values signal stronger dissatisfaction potential, making those features more urgent to implement.

Sample Size Considerations

Survey sample size directly affects classification confidence (Berger et al., 1993):

Respondent Count	Confidence	Classification Quality	Action
0	N/A	No classification possible	Survey design mode only
1-4	Very Low	Individual preferences, not patterns	Disclose as anecdotal
5-8	MEDIUM	Directional signal; majority may shift	Classify with confidence disclosure; recommend 20+
9-19	MEDIUM-HIGH	Increasingly stable	Classify; note statistical threshold not yet met
20+	HIGH	Statistically reliable (Berger et al., 1993)	Full confidence in classifications and CS coefficients
50+	Very High	Enables segment analysis (practitioner recommendation; extends Berger et al., 1993 minimum -- no specific academic citation for this threshold)	Full classification plus segment breakdowns

Source: Berger et al. (1993) recommend a minimum of 20 respondents for reliable Kano classification. The 5-8 respondent range produces directional signals that are useful for early-stage prioritization but MUST be disclosed as MEDIUM confidence per synthesis validation protocol (skills/user-experience/rules/synthesis-validation.md [Sub-Skill Synthesis Output Map]).

Feature Lifecycle Dynamics

Kano categories are not static -- features migrate across categories as products and markets mature (Kano et al., 1984; Matzler & Hinterhuber, 1998):

Attractive (A)  --->  Performance (O)  --->  Must-be (M)
  "Delighter"         "Competitive"          "Table stakes"
   (novel)            (expected)              (baseline)

Features that once delighted users (Attractive) become expected differentiators (Performance) as competitors adopt them, and eventually become baseline expectations (Must-be). This migration is driven by competitive pressure, customer learning, and market maturation. Features classified as Attractive today may become Must-be within typically 1-3 product cycles (practitioner estimate based on Kano's original lifecycle observation; no single empirical citation establishes a universal timeframe, as migration speed varies by industry and competitive intensity). Teams should continuously re-evaluate classifications, especially for features approaching transition boundaries. The agent documents lifecycle stage assessment for each feature when sufficient product history is available.

---

Execution Procedure

The agent executes a 5-phase procedure. Phase flow depends on whether survey data is provided.

Phase 1: Scope Definition

Goal: Establish the feature set, respondent context, and engagement parameters.

Activities:

1. Receive and validate engagement context (engagement ID, product context, target users)
2. Verify Wave 4 entry criteria (or bypass documentation)
3. Parse the feature list; validate each feature has a name and description
4. Determine survey data availability: if survey_responses provided, proceed to Phase 3; otherwise Phase 2
5. If upstream JTBD artifacts available, map job statements to features

Outputs: Validated feature list, engagement context, data availability determination.

Phase 2: Survey Design

Goal: Generate a ready-to-administer Kano questionnaire.

Activities:

1. For each feature, craft a functional/dysfunctional question pair using user-understandable language (concrete, no developer jargon, balanced tone)
2. Include the standardized 5-point response scale with each question
3. Generate administration guidance: minimum sample size (20+ statistical; 5-8 directional), respondent selection criteria, administration tips (randomize feature order, avoid priming)
4. Produce the survey questionnaire using skills/ux-kano-model/templates/kano-survey-template.md (if the template is not yet available -- marked [PLANNED] -- produce the questionnaire using the functional/dysfunctional pair format described in the Methodology section with the standardized 5-point response scale; see Template Fallback note in the Output Specification section)

Outputs: Kano survey questionnaire file ready for team administration.

Note: The agent terminates after Phase 2 when no survey data is provided. The team administers the survey independently. A subsequent invocation with survey response data resumes at Phase 3.

Phase 3: Response Analysis

Goal: Classify each respondent-feature pair using the Kano evaluation table.

Activities:

1. Parse survey response data (respondent ID, functional/dysfunctional answers per feature)
2. Apply the 5x5 evaluation table to each respondent-feature pair
3. Aggregate per feature: count M/O/A/I/R/Q, determine majority category, calculate percentages
4. Detect split classifications (no single category > 50%) and high Q rates (> 10%)
5. Record sample_size_disclosure with respondent count and statistical adequacy

Outputs: Per-feature classification table with response distribution and split/Q flags.

Phase 4: Priority Synthesis

Goal: Compute CS coefficients and produce the priority matrix.

Activities:

1. Calculate Better and Worse coefficients for each feature (excluding R and Q responses)
2. Construct the priority matrix (Better x-axis, Worse y-axis) and assign quadrant positions
3. Detect priority conflicts: features with similar CS values, majority category vs. CS-derived quadrant mismatches, high R count (> 20%) indicating user segment disagreement
4. Produce priority ranking: Must-be (implement immediately), Performance (high priority), Attractive (medium priority), Indifferent (deprioritize)
5. Document feature lifecycle stage assessment where product history is available
6. Flag priority conflicts for domain expert resolution with [DOMAIN EXPERT REQUIRED] markers

Outputs: CS coefficient table, priority matrix, priority ranking, conflict report.

Phase 5: Synthesis and Handoff Preparation

Goal: Produce the final output report and prepare handoff data for cross-framework synthesis.

Activities:

1. Assemble complete output using skills/ux-kano-model/templates/feature-priority-template.md (if the template is not yet available -- marked [PLANNED] -- use the Required Output Sections table in the Output Specification section as the authoritative fallback)
2. Populate L0/L1/L2 sections
3. Compile Synthesis Judgments Summary with confidence classifications
4. Prepare handoff data: feature_classifications, cs_coefficients, priority_matrix, split_classifications, sample_size_disclosure, synthesis_judgments
5. Persist output to designated path per P-002

Outputs: Complete Kano analysis report at projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-kano-analyst-{topic-slug}.md.

---

Output Specification

Output Location

projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-kano-analyst-{topic-slug}.md

Where:

• {engagement-id} follows the pattern UX-{NNNN} (e.g., UX-0001)
• {topic-slug} is a kebab-case descriptor of the feature set evaluated (e.g., dashboard-features, onboarding-backlog, mobile-priorities)

Required Output Sections

Section	Level	Content
Executive Summary	L0	Feature count by Kano category; top 3 Must-be features; top 3 Attractive features; sample size and confidence disclosure; overall prioritization recommendation for stakeholders
Engagement Context	L1	Product description, target users, feature list source, survey administration details, respondent count, MCP status
Feature Classification Table	L1	Per-feature: name, majority Kano category, response distribution (M/O/A/I/R/Q counts and percentages), classification confidence
CS Coefficient Analysis	L1	Per-feature: Better coefficient, Worse coefficient, quadrant assignment; summary statistics
Priority Matrix	L1	Text-based scatter plot representation with features plotted by Better (x) vs. Worse (y); quadrant boundaries and labels
Split Classification Analysis	L1	Features with no majority category; distribution breakdown; domain expert resolution prompts
Feature Lifecycle Assessment	L2	Per-feature lifecycle stage (if product history available); migration trajectory predictions; competitive context
Strategic Implications	L2	Product maturity assessment, competitive positioning recommendations, roadmap implications, investment priority rationale
Synthesis Judgments Summary	L1	Each AI judgment call listed with confidence classification (HIGH/MEDIUM/LOW) and rationale
Handoff Data	L1	Structured data for downstream sub-skills and cross-framework synthesis: feature classifications, CS coefficients, priority matrix, split classifications, sample size disclosure

Synthesis Judgments Summary requirements: This section MUST list every AI-generated judgment (category assignment interpretation, CS coefficient analysis, priority ranking, lifecycle stage assessment, conflict resolution framing) with a confidence classification (HIGH/MEDIUM/LOW) and a one-line rationale. This enables downstream consumers (including the ux-orchestrator synthesis gate) to assess which findings are strongly supported versus which require additional validation.

Templates

Two templates support the agent's output production:

Template	Path	Purpose
Kano Survey Template	skills/ux-kano-model/templates/kano-survey-template.md [PLANNED: Wave 4 Phase 2]	Functional/dysfunctional questionnaire pair template with standardized response scale and administration guidance
Feature Priority Template	skills/ux-kano-model/templates/feature-priority-template.md [PLANNED: Wave 4 Phase 2]	Feature classification report and priority matrix output template with L0/L1/L2 sections

Template fallback: Until templates are created during Wave 4 Phase 2 implementation, agents SHOULD use the Required Output Sections table above as the authoritative output specification and produce equivalent content inline.

Source: Output location from [skills/user-experience/SKILL.md -- Available Agents] and ORCHESTRATION.yaml pipeline-wave4 artifacts.

---

Routing

Trigger Keywords

Keyword	Routing Context
Kano	Direct match -- primary trigger
Kano model	Direct match
must-be	In combination with feature/prioritization context
attractive quality	Direct match
one-dimensional	In combination with feature/quality context
performance feature	In combination with Kano/classification context
feature classification	Direct match
feature prioritization	In combination with Kano/satisfaction context
delighter	In combination with feature/UX context
CS coefficient	Direct match
satisfaction coefficient	Direct match

Lifecycle-Stage Routing Integration

This sub-skill is routed to by the ux-orchestrator in the following lifecycle-stage scenarios:

Stage	User Intent	Route Condition
Before design	"Need to prioritize features"	Direct route to /ux-kano-model per [skills/user-experience/SKILL.md -- Lifecycle-Stage Routing]
Before design	"Decide what to build" (with known feature list)	Qualification question: "Are you defining the problem or prioritizing features?" If prioritizing: route here. Source: [skills/user-experience/SKILL.md -- Common Intent-to-Route Resolution]
Any stage	After /ux-jtbd completion	Canonical "Discover to Prioritize" sequence continuation: JTBD job-derived feature list available as upstream handoff artifact

Wave Gating

This sub-skill is in Wave 4 (Advanced Analytics). It requires Wave 3 completion before deployment:

Entry criteria: Wave 3: Storybook with 5+ Atom stories AND 1 Persona Spectrum review completed.

Bypass condition: Existing user base with analytics (skip Persona Spectrum prerequisite). Note: this bypass condition allows teams with an established product and analytics infrastructure to proceed to Wave 4 without completing the Persona Spectrum review, recognizing that such teams already have user understanding from behavioral data (framework inference based on Wave 4 entry criteria requiring launched product with analytics).

Source: Routing integration from [skills/user-experience/rules/ux-routing-rules.md -- Stage Routing Table] and [skills/user-experience/SKILL.md -- Lifecycle-Stage Routing]. Wave assignment from [skills/user-experience/SKILL.md -- Wave Architecture]. Bypass condition from [skills/user-experience/SKILL.md -- Wave Definitions] (Wave 4 "Bypass Condition" column: "Existing user base with analytics (skip Persona Spectrum prerequisite)") and [skills/user-experience/SKILL.md -- Wave Transition Quality Gates] (bypass documentation requirements: 3-field format).

---

Cross-Framework Integration

Upstream Inputs

This sub-skill receives context from other sub-skills when invoked as part of a multi-sub-skill workflow:

From Sub-Skill	Handoff Artifact	Key Fields	Usage
/ux-jtbd	Job-derived feature list	Job statements, switch forces (push/pull), outcome expectations, feature candidates	JTBD job statements provide the feature list; switch forces inform expected category (push = Must-be; pull = Attractive). Source: [skills/user-experience/SKILL.md -- Cross-Sub-Skill Handoff Data]
/ux-heuristic-eval	Severity-rated findings	Finding ID, heuristic violated, severity (0-4), affected screen/flow	Heuristic findings reframed as features for Kano classification; severity provides initial Must-be vs. Performance signal

Downstream Handoffs

This sub-skill produces artifacts that feed into cross-framework synthesis via the Jerry handoff protocol (docs/schemas/handoff-v2.schema.json).

To Sub-Skill/Consumer	Handoff Artifact	Key Fields	Trigger
ux-orchestrator (synthesis)	Feature classifications + CS coefficients + priority matrix	feature_classifications, cs_coefficients, priority_matrix, split_classifications, sample_size_disclosure	After classification; feeds cross-framework synthesis convergence detection
/ux-lean-ux (cross-sub-skill)	Priority-ranked feature list	Features ranked by CS quadrant; Attractive features as experiment candidates	Attractive features become Lean UX experiment candidates; Must-be features bypass experimentation
/ux-heart-metrics (cross-sub-skill)	Feature priority baseline	CS coefficients per feature, expected satisfaction impact	CS coefficients provide predicted baseline for post-implementation UX measurement

Handoff data format: Uses handoff-v2 schema (docs/schemas/handoff-v2.schema.json) with ux_ext extension fields: feature_count, respondent_count, statistical_adequacy ("directional" or "statistical"), split_count, conflict_count. Default confidence for 5-8 respondent directional classification: 0.65. Criticality: C2.

Canonical Multi-Skill Workflow Sequences

This sub-skill participates in the following canonical sequences:

Sequence	Skills Involved	This Sub-Skill's Role
Discover to Prioritize	/ux-jtbd then /ux-kano-model	Receives job-derived feature list from JTBD; classifies features by user satisfaction impact to determine build priority
Prioritize to Experiment	/ux-kano-model then /ux-lean-ux	Attractive features become Lean UX experiment candidates; Must-be features bypass experimentation (implement directly)
Prioritize to Measure	/ux-kano-model then /ux-heart-metrics	CS coefficients provide predicted satisfaction baseline; HEART metrics measure actual post-implementation UX impact

Source: Handoff data contracts from [skills/user-experience/rules/ux-routing-rules.md -- Handoff Data Contracts] and [skills/user-experience/SKILL.md -- Cross-Sub-Skill Handoff Data] ("/ux-jtbd -> /ux-kano-model: Job-derived feature list"). Canonical sequences from [skills/user-experience/SKILL.md -- Canonical Multi-Skill Workflow Sequences] ("Discover to Prioritize: /ux-jtbd then /ux-kano-model").

---

Synthesis Hypothesis Confidence

Kano Model outputs include synthesis hypotheses that carry confidence classifications per the synthesis validation protocol (skills/user-experience/rules/synthesis-validation.md [Sub-Skill Synthesis Output Map]).

Synthesis Step	Typical Confidence	Rationale
Directional classification (5-8 respondents)	MEDIUM	Small sample provides directional signal only; Kano survey requires >= 20 respondents for statistical classification (Berger et al., 1993), so 5-8 yields MEDIUM. Source: skills/user-experience/rules/synthesis-validation.md [Sub-Skill Synthesis Output Map]
Feature priority conflict interpretation	LOW	Resolving conflicting priorities requires domain context AI lacks. When multiple features have split classifications or similar CS coefficients, the resolution depends on business strategy, competitive landscape, and user segment knowledge that exceeds training data. Source: skills/user-experience/rules/synthesis-validation.md [Sub-Skill Synthesis Output Map]
Statistical classification (20+ respondents)	HIGH	Sufficient sample size for reliable Kano classification per Berger et al. (1993) recommendation; CS coefficients are statistically meaningful with 20+ respondents
Feature lifecycle stage assessment	MEDIUM	Lifecycle migration (Attractive -> Performance -> Must-be) assessment is based on general product maturity patterns (Kano et al., 1984; Matzler & Hinterhuber, 1998); application to a specific product requires domain knowledge about competitive dynamics and market maturation rate
CS coefficient interpretation	MEDIUM	CS coefficient calculation is deterministic (arithmetic formula), but interpretation of "High Better" vs. "Low Better" boundaries and quadrant assignment thresholds involve judgment about the specific product context

Gate enforcement:

• HIGH (20+ respondents): Synthesis Judgments Summary with acknowledgment prompt. Classifications advance directly to design decisions.
• MEDIUM (5-8 respondents, lifecycle, CS interpretation): "Validation Required" section. Design recommendations withheld until validation against real user data, domain expert review, or expanded survey results.
• LOW (conflict interpretation): Design recommendation section structurally omitted. Tagged [DOMAIN EXPERT REQUIRED].

Confidence upgrade path: Directional classification (MEDIUM) upgrades to HIGH through: (a) expanding the survey to 20+ respondents, or (b) convergence with a second framework in cross-framework synthesis (per skills/user-experience/rules/synthesis-validation.md [Convergence Thresholds]: moderate convergence = 2 frameworks with supporting evidence = HIGH). Example: Kano classifies "search autocomplete" as Attractive AND JTBD independently identifies "quick information retrieval" as a high-pull switch force -- convergent finding receives HIGH confidence.

Source: Confidence classifications from [skills/user-experience/rules/synthesis-validation.md [Sub-Skill Synthesis Output Map]] ("/ux-kano-model Directional classification (5-8 respondents) MEDIUM", "/ux-kano-model Feature priority conflict interpretation LOW"). Gate enforcement from [skills/user-experience/SKILL.md [Synthesis Hypothesis Validation]]. Convergence upgrade thresholds from [skills/user-experience/rules/synthesis-validation.md [Convergence Thresholds]] ("Moderate convergence: 2 frameworks identify the same UX problem with supporting evidence = HIGH").

---

Quality Gate Integration

Kano Model deliverables are subject to the Jerry quality gate per H-13 and H-14:

Aspect	Requirement	Source
Quality threshold	>= 0.92 weighted composite score for C2+ deliverables	H-13 (quality-enforcement.md)
Creator-critic-revision cycle	Minimum 3 iterations for C2+ deliverables	H-14 (quality-enforcement.md)
Self-review	Required before presenting any deliverable	H-15 (S-010)
Scoring dimensions	Completeness (0.20), Internal Consistency (0.20), Methodological Rigor (0.20), Evidence Quality (0.15), Actionability (0.15), Traceability (0.10)	S-014 (quality-enforcement.md)

Kano-specific quality considerations: Completeness -- all features classified, none dropped. Internal Consistency -- CS coefficients mathematically consistent with classification table. Methodological Rigor -- canonical 5x5 grid applied (Kano et al., 1984). Evidence Quality -- sample size disclosure mandatory. Actionability -- recommendations per quadrant, domain expert prompts for splits. Traceability -- every classification traces to respondent data.

Note: The kano-methodology-rules.md file [PLANNED: Wave 4 Phase 2] will codify the evaluation table rules and CS calculation rules that support methodological compliance scoring when created. Until then, the Methodology section of this SKILL.md serves as the authoritative reference for Kano-specific quality evaluation criteria.

---

Degraded Mode Behavior

The agent adapts its behavior based on data availability and quality:

No Survey Data Available

When invoked without survey_responses:

• Agent enters survey design mode (Phase 2 only)
• Produces functional/dysfunctional questionnaire using kano-survey-template.md
• Provides administration guidance with sample size recommendations
• Does NOT produce feature classifications, CS coefficients, or priority matrix
• Output carries a disclosure: "Survey design mode -- no classification data available. Administer the survey and re-invoke with response data for feature classification."

Fewer Than 5 Respondents

When respondent_count < 5: classifications labeled [ANECDOTAL -- NOT FOR DESIGN DECISIONS], CS coefficients labeled "unreliable", priority matrix placed in "Insufficient Data" zone. All synthesis outputs classified as LOW. Recommendation to expand to 5+ (directional) or 20+ (statistical).

5-8 Respondents (Directional Mode)

When respondent_count is 5-8: full classifications at MEDIUM confidence with caveat "Directional only -- coefficients may shift with additional respondents." Priority matrix produced with widened quadrant boundaries. P-022 disclosure: "Classification based on {N} respondents. Berger et al. (1993) recommend >= 20 for statistical reliability."

High Questionable (Q) Response Rate

When Q responses exceed 10% for any feature: affected features flagged [QUESTION CLARITY ISSUE], excluded from priority matrix ranking, with rephrasing guidance for the functional/dysfunctional question pair.

MCP Unavailability

The ux-kano-analyst is a T2 agent with no MCP dependencies. All inputs are user-provided data (feature lists and survey responses). No degraded mode for MCP is necessary. The parent MCP dependency matrix confirms Miro ENH as the only MCP connection for /ux-kano-model; ENH status means cosmetic limitation only (skills/user-experience/SKILL.md [MCP Integration Architecture]).

---

Wave Architecture

This sub-skill is deployed in Wave 4 (Advanced Analytics) of the /user-experience skill's criteria-gated wave model.

Wave 4 Position

Property	Value
Wave	4 -- Advanced Analytics
Companion sub-skill	/ux-behavior-design (Fogg B=MAP)
Entry criteria	Wave 3: Storybook with 5+ Atom stories AND 1 Persona Spectrum review
Bypass condition	Existing user base with analytics (skip Persona Spectrum prerequisite)
Quality gate	S-014 composite >= 0.85 on Wave 4 deliverables (wave transition readiness -- operational output quality; H-13 >= 0.92 applies separately to governance artifacts; see skills/user-experience/SKILL.md [Wave Transition Quality Gates] for derivation)

Wave 4 Rationale

1. Prerequisite knowledge: Effective feature classification benefits from prior JTBD research (Wave 1) and component understanding (Wave 3)
2. User base requirement: Kano surveys require respondents; Wave 4 entry criteria ensure the team has users to survey
3. Complementary pairing: Wave 4 pairs Kano analysis (feature-level prioritization) with Behavior Design (action-level diagnosis) -- together answering "which features matter most" and "why users are not completing desired actions"

Wave Bypass

Teams with an existing user base and analytics data may bypass the Wave 3 Persona Spectrum prerequisite. Bypass requires 3-field documentation: (1) unmet criterion, (2) impact assessment (e.g., "Kano analysis proceeds without inclusive design context"), (3) remediation plan with target date.

Source: Wave architecture from [skills/user-experience/SKILL.md -- Wave Architecture] [Wave Definitions] and [Wave Transition Quality Gates].

---

Constitutional Compliance

All agents in this sub-skill adhere to the Jerry Constitution v1.0:

Principle	Requirement	Consequence of Violation
P-003	NEVER spawn recursive subagents -- worker agent, no Agent tool access	Agent hierarchy violation; uncontrolled token consumption
P-020	NEVER override user decisions on feature priority or classification interpretation	Unauthorized action; trust erosion
P-022	NEVER present classification confidence without sample size disclosure; NEVER inflate statistical claims with insufficient respondent data	Governance undermined; false precision in prioritization decisions
P-001	NEVER present Kano classifications without response distribution evidence or CS coefficient derivation	Unreliable outputs; unfounded prioritization claims propagate downstream
P-002	NEVER leave Kano classification results or priority matrices in transient context only -- persist to files	Context rot vulnerability; artifacts lost on session compaction

Per-agent enforcement: The ux-kano-analyst agent declares:

• constitution.principles_applied: P-003, P-020, P-022, P-001, P-002 in skills/ux-kano-model/agents/ux-kano-analyst.governance.yaml
• capabilities.forbidden_actions: 3 entries in NPT-009 format referencing the constitutional triplet
• disallowedTools: [Agent] in skills/ux-kano-model/agents/ux-kano-analyst.md frontmatter

AI-Augmented Analysis Limitations

The following limitations MUST be disclosed per P-022 (no deception):

• Survey design is guidance, not validated questionnaire research. Question wording should be pre-tested with 2-3 respondents before full administration (Kano et al., 1984).
• Classification is mechanical, interpretation is contextual. The 5x5 evaluation table is deterministic, but interpreting which Must-be features are truly urgent or which Attractive features are feasible requires domain knowledge the agent lacks.
• CS coefficients are descriptive, not prescriptive. They describe satisfaction potential in the survey data but do not account for implementation cost, technical feasibility, or strategic alignment.
• Feature lifecycle predictions are pattern-based. The migration trajectory is well-documented (Matzler & Hinterhuber, 1998), but timing depends on competitive dynamics the agent cannot observe.
• Always validate with domain experts. Classification reports should be reviewed by product managers with knowledge of competitive context, business strategy, and user segment priorities before roadmap commitments.

---

Registration

This sub-skill follows a parent-routed registration model. Sub-skills are not independently registered in CLAUDE.md or mandatory-skill-usage.md because they are routed through the parent /user-experience orchestrator (ux-orchestrator). This is an explicit exception to the H-26 registration requirement (parent-routed model): parent skills own the CLAUDE.md and mandatory-skill-usage.md registration; sub-skills are discovered and dispatched by the parent orchestrator's internal routing logic.

Registration Point	Status	Detail
CLAUDE.md skill table	Registered via parent	/user-experience is registered in CLAUDE.md; sub-skills are not independently listed
mandatory-skill-usage.md trigger map	Routed via parent	The /user-experience trigger map row includes "Kano model" and "feature prioritization" as positive keywords (H-22); requests matching these keywords route to the parent skill, which dispatches to this sub-skill
AGENTS.md agent registry	Registered	ux-kano-analyst is listed in AGENTS.md under the User-Experience Skill Agents section
Parent SKILL.md agent table	Registered	ux-kano-analyst is listed in skills/user-experience/SKILL.md [Available Agents]

H-26 parent-routed model rationale: Independent registration of sub-skills would create duplicate trigger map entries and ambiguous routing (AP-02 Bag of Triggers). The parent orchestrator owns lifecycle-stage routing logic and dispatches to the correct sub-skill based on triage qualification, not keyword matching alone. Sub-skill agents are registered in AGENTS.md for discoverability but routing flows through the parent.

---

Deployment Status

Wave 4 Sub-Skill -- Planned. This sub-skill is part of Wave 4 (Advanced Analytics) of PROJ-022. The companion agent file (skills/ux-kano-model/agents/ux-kano-analyst.md) and governance file (skills/ux-kano-model/agents/ux-kano-analyst.governance.yaml) are planned for creation during Wave 4 implementation of PROJ-022 EPIC-005. The SKILL.md itself is complete and specifies the methodology, output format, and routing integration that the agent will implement.

---

Quick Reference

Common Workflows

Need	Command Example
Feature prioritization	"Classify these backlog features using Kano analysis"
Survey design	"Design a Kano survey for our dashboard feature candidates"
Survey analysis	"Analyze these Kano survey results and produce a priority matrix"
JTBD-to-Kano pipeline	"We completed JTBD analysis -- now prioritize the job-derived features with Kano"
Competitive feature assessment	"Which of our features are must-haves versus delighters compared to competitors?"
Feature lifecycle review	"Assess which Attractive features are becoming expected Performance features"
Split resolution guidance	"Help interpret these split Kano classifications"
Priority conflict analysis	"Several features have similar CS coefficients -- help us differentiate priority"

Agent Selection Hints

Keywords	Routes To
Kano, must-be, attractive, one-dimensional, satisfaction, feature classification, delighter, CS coefficient, functional dysfunctional	ux-kano-analyst
heuristic, usability, Nielsen, severity, inspection	/ux-heuristic-eval (not this sub-skill)
JTBD, jobs to be done, switch interview, outcome, motivation	/ux-jtbd (not this sub-skill)
behavior, Fogg, B=MAP, motivation, ability, prompt, nudge	/ux-behavior-design (not this sub-skill)
HEART, metrics, measurement, GSM, happiness, engagement	/ux-heart-metrics (not this sub-skill)
lean UX, hypothesis, experiment, build-measure-learn	/ux-lean-ux (not this sub-skill)
accessibility, WCAG, ARIA, inclusive design	/ux-inclusive-design (not this sub-skill)

---

References

Source	Content	Path
Parent SKILL.md	Sub-skill scope, wave architecture, routing, MCP dependencies, synthesis protocol	skills/user-experience/SKILL.md
Agent definition	Agent frontmatter, identity, expertise, guardrails	skills/ux-kano-model/agents/ux-kano-analyst.md [PLANNED: Wave 4]
Agent governance	Tool tier, forbidden actions, output validation, constitutional compliance	skills/ux-kano-model/agents/ux-kano-analyst.governance.yaml [PLANNED: Wave 4]
UX routing rules	Lifecycle-stage routing, handoff data contracts, common intent resolution	skills/user-experience/rules/ux-routing-rules.md
MCP coordination	MCP dependency matrix, degraded mode behavior	skills/user-experience/rules/mcp-coordination.md
Synthesis validation	Confidence gate protocol, per-sub-skill confidence map	skills/user-experience/rules/synthesis-validation.md
Wave progression	Wave 4 entry criteria, signoff requirements	skills/user-experience/rules/wave-progression.md
CI checks	P-003 enforcement, sub-skill validation gates	skills/user-experience/rules/ci-checks.md [STUB: EPIC-001]
Kano methodology rules	Evaluation table rules, CS calculation rules	skills/ux-kano-model/rules/kano-methodology-rules.md [PLANNED: Wave 4 Phase 2]
Kano survey template	Functional/dysfunctional questionnaire pair template	skills/ux-kano-model/templates/kano-survey-template.md [PLANNED: Wave 4 Phase 2]
Feature priority template	Feature classification and priority matrix output template	skills/ux-kano-model/templates/feature-priority-template.md [PLANNED: Wave 4 Phase 2]
Skill standards	H-25/H-26 skill structure requirements	.context/rules/skill-standards.md
Agent development standards	H-34 dual-file architecture, tool tiers, handoff protocol	.context/rules/agent-development-standards.md
Quality enforcement	Quality gate thresholds, criticality levels, strategy catalog	.context/rules/quality-enforcement.md
Handoff schema	Canonical handoff schema v2	docs/schemas/handoff-v2.schema.json
Agent governance schema	Governance YAML validation schema	docs/schemas/agent-governance-v1.schema.json

Requirements Traceability

Source	Content	Path
PROJ-022 PLAN.md	Project plan: sub-skill scope, wave assignment, acceptance criteria, implementation phases	projects/PROJ-022-user-experience-skill/PLAN.md
EPIC-005 (Wave 4 Deployment)	Parent work item for Wave 4 sub-skill implementation including this sub-skill	PROJ-022 EPIC-005 in projects/PROJ-022-user-experience-skill/WORKTRACKER.md
ORCHESTRATION.yaml	Orchestration plan governing the build sequence for this sub-skill	projects/PROJ-022-user-experience-skill/orchestration/ux-skill-build-20260303-001/ORCHESTRATION.yaml

External References

Source	Citation
Kano et al., 1984	Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). "Attractive Quality and Must-Be Quality." Journal of the Japanese Society for Quality Control, 14(2), 39-48.
Berger et al., 1993	Berger, C., Blauth, R., Boger, D., et al. (1993). "Kano's Methods for Understanding Customer-Defined Quality." Center for Quality Management Journal, 2(4), 3-36. Recommends >= 20 respondents for statistical Kano classification.
Matzler & Hinterhuber, 1998	Matzler, K., & Hinterhuber, H. H. (1998). "How to make product development projects more successful by integrating Kano's model of customer satisfaction into quality function deployment." Technovation, 18(1), 25-38.

---

Sub-Skill Version: 1.2.0 Parent Skill: /user-experience v1.0.0 Constitutional Compliance: Jerry Constitution v1.0 Wave: 4 (Advanced Analytics) SSOT: skills/user-experience/SKILL.md Project: PROJ-022 User Experience Skill Created: 2026-03-04