Stats
Actions
Tags
From jerry
Classifies product features using Kano model into Must-be, Performance, Attractive, Indifferent, Reverse categories via functional/dysfunctional questionnaires. Computes CS coefficients, generates priority matrices, reports, and survey templates for prioritization.
How this skill is triggered — by the user, by Claude, or both
Slash command
/jerry:ux-kano-modelsonnetThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- VERSION: 1.2.0 | DATE: 2026-03-04 | SOURCE: skills/user-experience/SKILL.md | PARENT: /user-experience skill | REVISION: iter4 quality gate revision -- add framework-inference qualifier to bypass rationale (Evidence Quality 0.91->target), add Phase 5 inline template fallback for symmetric treatment with Phase 2 (Actionability 0.93->target), use consistent [PLANNED: Wave 4 Phase 2] token in...
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
| 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 |
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 |
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.
Activate when:
/ux-jtbd that needs prioritizationDo NOT use for:
/ux-heuristic-eval)/ux-behavior-design)/ux-heart-metrics)/ux-inclusive-design)/ux-atomic-design)/ux-jtbd)/ux-design-sprint)/problem-solving)| 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:
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.
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"
"Use ux-kano-analyst to classify our product backlog features"
"Have ux-kano-analyst analyze the survey results in the attached data"
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.yamlper 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].
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.
| 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 |
The Kano Model uses a paired-question approach for each feature (Kano et al., 1984):
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 |
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.
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.
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]).
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.
The agent executes a 5-phase procedure. Phase flow depends on whether survey data is provided.
Goal: Establish the feature set, respondent context, and engagement parameters.
Activities:
survey_responses provided, proceed to Phase 3; otherwise Phase 2Outputs: Validated feature list, engagement context, data availability determination.
Goal: Generate a ready-to-administer Kano questionnaire.
Activities:
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.
Goal: Classify each respondent-feature pair using the Kano evaluation table.
Activities:
sample_size_disclosure with respondent count and statistical adequacyOutputs: Per-feature classification table with response distribution and split/Q flags.
Goal: Compute CS coefficients and produce the priority matrix.
Activities:
[DOMAIN EXPERT REQUIRED] markersOutputs: CS coefficient table, priority matrix, priority ranking, conflict report.
Goal: Produce the final output report and prepare handoff data for cross-framework synthesis.
Activities:
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)feature_classifications, cs_coefficients, priority_matrix, split_classifications, sample_size_disclosure, synthesis_judgmentsOutputs: Complete Kano analysis report at projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-kano-analyst-{topic-slug}.md.
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)| 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.
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.
| 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 |
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 |
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).
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 |
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.
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").
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:
[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-modelDirectional classification (5-8 respondents) MEDIUM", "/ux-kano-modelFeature 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").
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.mdfile [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.
The agent adapts its behavior based on data availability and quality:
When invoked without survey_responses:
kano-survey-template.mdWhen 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).
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."
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.
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]).
This sub-skill is deployed in Wave 4 (Advanced Analytics) of the /user-experience skill's criteria-gated wave model.
| 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) |
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].
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.yamlcapabilities.forbidden_actions: 3 entries in NPT-009 format referencing the constitutional tripletdisallowedTools: [Agent] in skills/ux-kano-model/agents/ux-kano-analyst.md frontmatterThe following limitations MUST be disclosed per P-022 (no deception):
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.mdfor discoverability but routing flows through the parent.
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.
| 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" |
| 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) |
| 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 |
| 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 |
| 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
npx claudepluginhub geekatron/jerry --plugin jerryIdentify features that delight, satisfy, or dissatisfy customers to guide prioritization.
Provides MoSCoW, Kano Model, WSJF, and Wiegers' matrix for prioritizing requirements by business value, customer impact, effort, and risk. Includes scoring templates and trade-off analysis.
Ranks requirements, features, backlog items, and initiatives using MoSCoW, Kano model, weighted scoring, and value-effort matrices.