El Modelo Kano es un framework para priorizar las features de un producto, desarrollado por Noriaki Kano en 1984 (Universidad de Ciencias de Tokio). Mapea cada feature en dos ejes —nivel de implementación en el eje X y satisfacción del cliente en el eje Y— y las clasifica en 5 categorías con curvas distintas. Es una de las pocas herramientas que logra distinguir qué features son básicas, cuáles aportan rendimiento y cuáles deleitan.
En este artículo veremos: qué son las 5 categorías, cómo realizar una encuesta Kano con usuarios reales, cómo aplicar los resultados al roadmap, ejemplos concretos y los errores más comunes al usarlo.
Las 5 categorías del Modelo Kano
1. Atributos Básicos (Must-be)
Son las funcionalidades que el usuario da por sentadas. Su presencia no aumenta la satisfacción (el usuario las considera obvias), pero su ausencia causa una gran insatisfacción. La curva es una L invertida: plana arriba a la derecha, con una caída drástica si faltan.
Ejemplos: en una app de banca como la de BBVA o Nubank, "ver el saldo de la cuenta"; en un portal inmobiliario como Idealista, "poder ver las fotos del inmueble"; en una app de chat como WhatsApp, "recibir notificaciones de mensajes nuevos".
2. Atributos de Rendimiento (Performance)
Funcionalidades donde "más es mejor". A mayor implementación, mayor satisfacción, y viceversa. La curva es una línea diagonal creciente. Son atributos "lineales".
Ejemplos: la velocidad de carga de una web (más rápido = más feliz); el número de restaurantes disponibles en Glovo o Rappi; la duración de la batería de un smartphone.
3. Atributos de Deleite (Delighters)
Son funcionalidades que el usuario no espera. Su ausencia no causa insatisfacción (nadie las pide), pero su presencia genera un entusiasmo desproporcionado. La curva es exponencial: empieza en cero y crece rápidamente.
Ejemplos: la primera vez que Slack introdujo las reacciones con emojis; cuando Spotify lanzó el "Wrapped" anual; el primer reconocimiento facial en el iPhone.
4. Atributos Indiferentes
Funcionalidades que no le importan a nadie. Su presencia o ausencia no afecta la satisfacción. Son features que NO se deben construir porque consumen recursos sin generar valor.
Ejemplos: opciones de personalización que los usuarios nunca descubren; integraciones con herramientas que no utilizan; ajustes avanzados que permanecen ocultos.
5. Atributos Inversos (Reverse)
Funcionalidades que, sorprendentemente, reducen la satisfacción si están presentes. Cuanto más se implementan, peor es el resultado. A menudo surgen en segmentos de usuarios específicos.
Ejemplos: notificaciones push demasiado frecuentes; pop-ups de registro obligatorio; menús complejos en un producto que debería ser simple.
Cómo hacer una encuesta Kano
La encuesta Kano es un cuestionario estandarizado donde por cada feature se plantean 2 preguntas al usuario:
- Pregunta funcional: "¿Cómo te sentirías si esta funcionalidad estuviera presente?"
- Pregunta disfuncional: "¿Cómo te sentirías si esta funcionalidad NO estuviera presente?"
El usuario responde a ambas con 5 opciones:
- Me gustaría
- Espero que esté
- Soy indiferente
- Puedo tolerarlo
- No me gustaría
El cruce entre las dos respuestas mapea la feature en una de las 5 categorías a través de una matriz estándar publicada por Kano.
¿Cuántos usuarios se necesitan?
Para que una encuesta Kano sea estadísticamente relevante, se necesitan al menos 30 respuestas por segmento de usuario, y más de 50 para obtener resultados robustos. Por debajo de 20, los resultados son solo indicativos y no accionables. Por encima de 100, la clasificación tiende a estabilizarse.
Herramientas recomendadas: SurveyMonkey, Typeform o Google Forms con una matriz de puntuación integrada.
Cómo aplicar el Modelo Kano al roadmap
Una vez clasificadas las features, la prioridad está clara:
- Construye primero todos los Atributos Básicos. Sin ellos, el producto es inaceptable.
- Invierte en los de Rendimiento: cuantos más, mejor. Optimízalos hasta agotar el presupuesto.
- Añade 1 o 2 Delighters por lanzamiento: demasiados no funcionan (el usuario se acostumbra y se convierten en atributos de rendimiento), y muy pocos te hacen perder diferenciación.
- Elimina los Indiferentes: cada recurso invertido aquí es un desperdicio.
- Quita los Inversos para los segmentos donde resultan problemáticos.
Ejemplo real: Kano aplicado a una app de fitness
Un equipo de producto está lanzando una app de fitness. Tienen 12 features candidatas. Tras una encuesta Kano con 80 usuarios, descubren:
- Básicos (Must-be): seguimiento por GPS, contador de calorías, registro de entrenamientos.
- Rendimiento (Performance): precisión del GPS, velocidad de sincronización, calidad de los gráficos.
- Deleite (Delighters): insignias sociales para compartir, integración con música.
- Indiferentes: opciones de personalización del avatar, modo competitivo.
- Inversos (para el segmento "casual"): gamificación excesiva que los usuarios ocasionales perciben como agobiante.
Resultado en el roadmap: prioridad 1 para los 3 atributos básicos (necesarios en el MVP); prioridad 2 para optimizar el GPS y la sincronización; 1 delighter (insignias sociales) en el lanzamiento; se eliminan la personalización del avatar y el modo competitivo (no son para el segmento objetivo inicial).
Los 4 errores más comunes
1. No segmentar a los usuarios. Una feature puede ser de Deleite para los power users e Indiferente para los usuarios ocasionales. Sin segmentación, el resultado es un promedio inútil.
2. No darse cuenta de que los Delighters evolucionan. Una feature de deleite (ej. reacciones con emojis en Slack) se convierte en un atributo básico cuando los competidores la copian. El análisis Kano debe repetirse periódicamente.
3. Crear encuestas demasiado largas. Más de 15 features en una sola encuesta Kano provocan que los usuarios abandonen. Divídela en varias encuestas más cortas.
4. Confundir "me gustaría" con "lo usaría". Los usuarios a menudo dicen que quieren features que luego no utilizan. Combina siempre el análisis Kano con datos de uso reales.
Kano vs. otros frameworks de priorización
- RICE (Reach × Impact × Confidence ÷ Effort): más cuantitativo, basado en el caso de negocio.
- MoSCoW (Must/Should/Could/Won't): más simple, menos granular.
- Matriz de Valor vs. Esfuerzo: la matriz 2×2 estándar, pero pierde la dimensión de "deleite".
- Kano: mejor para entender el tipo de feature, no solo la prioridad.
Buena práctica: combina Kano con otro framework. Kano te dice qué tipo de feature es; RICE o MoSCoW te dicen cuál construir primero.
Preguntas frecuentes
¿Cuánto tiempo se necesita para una encuesta Kano completa?
La preparación del cuestionario lleva 1-2 días, el reclutamiento de usuarios 3-7 días, y el análisis 1 día. En total, de 1 a 2 semanas. Para equipos que ya tienen una comunidad de usuarios por email o in-app, el proceso es más rápido (3-5 días en total).
¿Funciona para productos B2B o solo B2C?
Funciona excelentemente para B2B, quizás incluso mejor. Quienes toman las decisiones en B2B tienen expectativas más definidas (atributos básicos más claros) y segmentos más distintos. Considera reclutar 30 usuarios por rol (admin, usuario final, finanzas) en lugar de una única población.
¿Puedo aplicarlo como PM o diseñador junior?
Sí, es uno de los frameworks más democráticos. La matemática es simple (cruces en una matriz de 5×5). El verdadero valor está en la discusión de equipo que genera la encuesta, no en la ejecución técnica.
¿Cada cuánto tiempo hay que repetir el análisis Kano?
Cada 12-18 meses es un plazo razonable. Las expectativas de los usuarios evolucionan, los delighters se convierten en atributos de rendimiento, y los básicos cambian (por ejemplo, la integración con IA ha pasado de ser un delighter a un atributo de rendimiento en 18 meses).
¿Qué hago si no tengo usuarios reales (pre-lanzamiento)?
Usa proxies: usuarios de productos similares, beta testers reclutados en comunidades, o usuarios de la competencia. Los resultados serán menos robustos pero útiles para priorizar el MVP. Repite el análisis Kano 6 meses después del lanzamiento con usuarios reales.
Próximos pasos
Kano es uno de los frameworks de producto que todo diseñador UX debería conocer para dialogar con los product managers. Para aprender a hacer investigación de usuarios de forma sistemática —entrevistas, tests, análisis, síntesis—, el Curso de User Research de CorsoUX cubre 9 capítulos con 62 lecciones y mentoría 1:1. Para la ruta de aprendizaje completa (research + design + writing), tienes el Curso UX Design Completo.
Para otros frameworks relacionados, consulta nuestras guías sobre Jobs to be Done, las métricas UX y el customer journey map.
