Modelo Kano

Métodos

Etapa

Investigación

Definición

Generación

Evaluación

Tipo

Cuantitativo
Cualitativo
Con usuarios
Experto

Clasificación

DuraciónCorta

DificultadMedia

ExperienciaBásica

ParticipantesMedio

¿Qué es?

En 1984, Noriaki Kano, investigador y consultor japonés, publicó un artículo con un conjunto de ideas y técnicas para ayudar a determinar la satisfacción de los clientes con las características de un producto. Estas ideas son conocidas como modelo Kano y se basan en las premisas siguientes:

  • La satisfacción de los clientes con las funciones o características del producto depende del nivel de funcionalidad que se proporciona (cuántas funcionalidades son desarrolladas y cómo son desarrolladas).
  • La satisfacción de los clientes sobre las funcionalidades de un producto varía a lo largo del tiempo.
  • Se puede determinar cómo los clientes perciben una funcionalidad mediante un cuestionario.

Así, teniendo en cuenta que no todos los atributos de un producto son igualmente importantes para el cliente, el modelo o análisis Kano sirve para determinar qué atributos del producto tienen mayor impacto en la satisfacción del cliente. Este modelo se basa en el principio de que la incorporación constante de funciones nuevas es una estrategia ineficaz para intentar mejorar la satisfacción del cliente.

Tal como se ve en el gráfico inferior, la percepción sobre las funcionalidades de un producto o servicio no es estática en el tiempo. Por eso es importante hacer un seguimiento que permita conocer esta evolución y tener indicadores que ayuden a guiar el proceso de desarrollo. La satisfacción y el nivel de desarrollo de la funcionalidad son las dos dimensiones básicas del modelo Kano y determinarán cómo los usuarios perciben las características o funcionalidades de un producto o servicio.

De este modo, lo que permite el método Kano es asignar a cada característica de un producto una categoría para visualizar qué percepción tienen los usuarios de las funcionalidades. A pesar de que hay diferentes nombres para estas categorías, el principio siempre es el mismo. Los atributos ayudan a clasificar las funcionalidades entre necesarias, positivas y negativas. A continuación mostramos un ejemplo de nomenclatura, que corresponde también con los términos usados en el gráfico superior:

Básico: los atributos requeridos son las funciones de referencia para el producto y, una vez identificados, se tienen que incluir en el producto. Ejemplos de esta categoría son: la seguridad y los requisitos legales. Este tipo de características pueden no aumentar la satisfacción del cliente, pero si faltan, esto tendrá claramente un impacto negativo.

Performance: hay una relación lineal entre los atributos queridos y la satisfacción del cliente. Cuando se incluyen los atributos queridos, la percepción del valor del producto subirá. En cambio, si se excluyen, el valor percibido del producto disminuirá. Así, los atributos queridos son los más importantes que hay que incluir en el producto para  aumentar la satisfacción de los usuarios.

Delighter: estos atributos son una fuente de excitación y sorpresa para los usuarios y, por lo tanto, mejorarán también la satisfacción. Asimismo, a diferencia de los atributos requeridos o queridos, si los exciter/delighter no están representados, en general no crearán decepción o frustración para los usuarios.

Indiferente: los atributos neutros representan características por las cuales los usuarios no tienen sentimientos fuertes (ni positivos ni negativos). Así, su presencia o ausencia no tendrá impacto en las calificaciones de satisfacción.

Inverso: este tipo de atributos proporcionan información sobre qué se tendría que excluir de un producto. Incluirlos puede afectar negativamente a la satisfacción del cliente, e incluso a veces los clientes pagan más para no tenerlos, como, por ejemplo, una aplicación gratuita que incluye anuncios, pero la versión de pago no.

¿Cuándo?

El método Kano permite evaluar la satisfacción de los usuarios en relación con un producto o servicio. Por tanto, este método se puede usar tanto en etapas iniciales del diseño como en etapas intermedias o finales de un proyecto. De hecho, el modelo será útil en cualquier momento que haga falta un retorno de la satisfacción de un servicio o producto. Así, dependiendo de la etapa del desarrollo del producto, habrá que definir cómo se muestran sus funcionalidades:

  • Cuando el producto no existe: Si el producto todavía no existe y, por lo tanto, los usuarios no lo conocen, se pueden utilizar prototipos. Pueden ser de baja fidelidad o, más adelante, prototipos interactivos que permitirán que los usuarios puedan interactuar con ellos para probar las diferentes funcionalidades.
  • Cuando el producto ya existe y los usuarios ya lo conocen: Se pueden usar las preguntas tradicionales basadas en texto. Se ha de tener en cuenta que hay que crear una pregunta que sea clara y eficaz.

¿Cómo?

El objetivo de los equipos de desarrollo de un producto o servicio es determinar qué características hacen que los clientes estén más satisfechos y cómo usar esta información para ayudarnos a priorizar lo que se tiene que construir. Hay detalles importantes que hay que tener en cuenta a la hora de implementar el modelo Kano. Así, a continuación se detallan las fases necesarias para implementar este modelo:

  1. Preparación
  2. Ejecución
  3. Análisis
  1. Preparación

En general, cuando se empieza este tipo de análisis, los equipos trabajan en nuevas funciones e ideas para el lanzamiento o próximo lanzamiento de un producto. También se utiliza el método Kano para tener una «fotografía» de la satisfacción de los usuarios con un producto en un momento determinado. De las funciones/ideas en las cuales se trabaja, el equipo necesita responder preguntas como:

  • ¿Cuáles son las que hay que priorizar? O ¿en cuáles hay discrepancias dentro del equipo de desarrollo en su priorización?
  • ¿Cuáles tienen un impacto directo para los usuarios?
  • Se recomienda elegir tres, como máximo (siempre se podrán hacer estudios más extensos más adelante, una vez se conozca mejor el modelo).

¿A qué perfiles de usuario (o «personas») se dirigen estas funciones? Se puede elegir a quince usuarios (o más) por cada sector demográfico.

Creación del cuestionario:

 Para descubrir las percepciones de los usuarios en referencia a las funcionalidades del producto, el cuestionario Kano consiste en un par de preguntas para cada funcionalidad que queremos evaluar:

  • Cómo se sienten los usuarios si la funcionalidad está presente
  • Cómo se sentirían si no estuviera

La primera pregunta se denomina «funcional» y la segunda «disfuncional» (también se pueden denominar «positivas» y «negativas»). Se trata de preguntas cerradas con opciones de respuesta muy específicas. Las respuestas posibles para las preguntas «cómo se siente si está / no está esta funcionalidad» son:

  • Me gusta
  • Lo espero
  • Soy neutral
  • Puedo tolerarlo
  • No me gusta

En referencia al cuestionario, hay algunos aspectos que hay que tener en cuenta:

  • Hay que añadir una explicación muy breve del objetivo del cuestionario, el formato de respuesta, lo que los participantes tienen que hacer y el tiempo que se tarda en rellenarlo.
  • Si se utiliza un wireframe interactivo, se tendría que describir brevemente el objetivo de la funcionalidad, proporcionar un enlace a los wireframes y pedir al usuario que vuelva al cuestionario.
  1. Ejecución

Las herramientas habituales de creación de cuestionarios se adaptan perfectamente a las necesidades del modelo Kano. Así, una vez los cuestionarios han sido creados, se puede pasar a su distribución de cara a los usuarios. Actualmente, hay herramientas (de pago) que hacen que la selección y acceso a un subconjunto de usuarios sea muy fácil.

Siempre es recomendable probar el cuestionario con uno o más usuarios para detectar posibles confusiones o aspectos no claros. Una vez hecho este pequeño test, ya se puede enviar la encuesta a los usuarios que formen parte del grupo objetivo.

  1. Análisis

Después de haber recogido suficientes respuestas, hay que analizarlas. La tabla siguiente es un ejemplo de cómo se puede hacer el análisis a partir de las respuestas de los usuarios. Hay otros ejemplos de tablas, pero todas tienen un significado casi igual y lo único que cambia son las nomenclaturas.

Respuestas del cuestionario al usuario Respuesta a una pregunta disfuncional
1. Me gusta 2. Lo espero 3. Soy neutral 4. Puedo tolerarlo 5. No me gusta
 

 

 

Respuesta a una pregunta funcional

1. Me gusta Cuestionable Delighter Delighter Delighter Performance
2. Lo espero Inverso Indiferente Indiferente Indiferente Básico
3. Soy neutral Inverso Indiferente Indiferente Indiferente Básico
4. Puedo tolerarlo Inverso Indiferente Indiferente Indiferente Básico
5. No me gusta Inverso Inverso Inverso Inverso Cuestionable

Tal como muestra la tabla, las respuestas a las preguntas están divididas entre funcionales (cómo se sentirían los usuarios si una funcionalidad específica estuviera presente) y disfuncionales (cómo se sentirían si no estuviera presente). Según la opción de respuesta que escoge el usuario de las cinco opciones posibles: 1) Me gusta, 2) Lo espero, 3) Soy neutral, 4) Puedo tolerarlo, 5) No me gusta, sabremos en cuál de las categorías podemos poner cada una de las funcionalidades sobre las cuales hemos hecho preguntas (una pregunta funcional y una disfuncional por cada funcionalidad).

Así, según la tabla, vemos que hay las categorías siguientes:

  • Cuestionable: esta sexta categoría añadida, que no se ha definido en la introducción, no es una categoría real del modelo Kano, sino que quiere decir que se han obtenido respuestas conflictivas («Me gusta» y «No me gusta») a las dos preguntas (funcional y disfuncional). Es normal obtener algunas respuestas así, pero si hay muchas, hay algo que no ha funcionado bien.
  • Inverso: esta categoría nos dice que el usuario ha respondido «no me gusta» a la versión funcional y «me gusta» a la versión disfuncional; por lo tanto, este usuario no está interesado en esta funcionalidad y quizás quiere lo contrario («inverso»).
  • Performance: las funcionalidades de performance son las más fáciles de situar. Son las que a los usuarios les gusta tener y no les gusta cuando no están. Esta reacción extrema traduce la relación lineal «más es mejor» entre estas dos dimensiones.
  • Básico: las funcionalidades básicas son los casos restantes, cuando a un usuario no le gusta que no estén. Los usuarios pasan de tolerar a esperar tener la funcionalidad.
  • Delighter: se muestran funcionalidades delighter cuando a un usuario le gusta tener una funcionalidad que no se espera. Es otra manera de decir que lo que se propone es nuevo y atractivo.
  • Indiferente: se producen para cualquier respuesta «soy neutral» o «puedo tolerarlo», tanto para las preguntas funcionales como disfuncionales. Es decir, ocupan las casillas del medio de la tabla (descontando cualquiera de las categorías descritas más arriba).

Ventajas

  • En la economía digital, las preferencias de los clientes cambian tan deprisa que usar metodologías robustas y flexibles como el modelo Kano, para examinar los productos y servicios de manera continua, es fundamental para conocer las características que aportarán realmente un valor añadido a los usuarios o todo lo contrario.
  • El modelo Kano, además de ser fácil de utilizar y potente, clasifica las funciones o características de un servicio o producto. Así, se convierte en una herramienta muy útil para enseñar al público de interés y defender o no una nueva funcionalidad.
  • Los principios del modelo Kano son intemporales. Las empresas tienen que estar al día con los usuarios y comprender los cambios en sus intereses, deseos y limitaciones. Idealmente, todo esto a tiempo real.

Inconvenientes

  • A pesar de que los principios del modelo Kano son intemporales y estándar, siempre es importante hacer una prueba piloto antes de un lanzamiento masivo o continuo.
  • El formato de cuestionario Kano puede llegar a ser pesado para un usuario, puesto que consiste en pedir un retorno sobre una funcionalidad desde cinco atributos. Es decir, con una misma pregunta, se cambiará solo la funcionalidad y por cada una de estas últimas, se tendrá que hacer una pregunta funcional y disfuncional. Esto puede hacer que el usuario se canse más deprisa y deje de leer el detalle de las preguntas.

Notas

  • No hay soluciones mágicas cuando se trata de priorizar las características de un producto. Aunque se tienen que considerar muchas dimensiones diferentes, la satisfacción del usuario es probablemente la más importante. Esto lleva a preguntas que no tienen respuestas definitivas, sino que hay que trabajarlas de manera iterativa:
    1. ¿Cómo se mide la satisfacción?
    2. ¿Cómo se escoge lo que se tiene que construir para conseguir esta satisfacción?
    3. ¿Cómo se puede ir más allá de la satisfacción y hacia el placer?
  • Los nombres de las categorías utilizados en este documento son un ejemplo de un tipo de nomenclatura, pero hay otros. A continuación, se muestra una tabla comparativa con ejemplos de otras nomenclaturas de las categorías y las equivalencias entre ellas:
  Categoría 1 Categoría 2 Categoría 3 Categoría 4 Categoría 5
Nomenclatura 1 Básico Performance Delighter Indiferente Inverso
Nomenclatura 2 Requerido Querido Delighter / Exciter Neutro Anticaracterística
Nomenclatura 3 Must-Be Unidimensional Atractivo No importante No querido

Referencias

Hanington, B.; Martin, B. (2012). Universal Methods of Design: 100 ways to research complex problems, develop innovative ideas & Design effective solutions. Rockport.

Leveraging the Kano Model for Optimal Results: <https://uxmag.com/articles/leveraging-the-kano-model-for-optimal-results>. [Fecha de consulta: 25 de enero de 2021].

The Complete Guide to the Kano Model: <https://foldingburritos.com/kano-model/>. [Fecha de consulta: 25 de enero de 2021].

The Kano Model – A tool to prioritize the users’ wants and desires: <https://www.interaction-design.org/literature/article/the-kano-model-a-tool-to-prioritize-the-users-wants-and-desires>. [Fecha de consulta: 25 de enero de 2021].

Imagen: <https://commons.wikimedia.org/wiki/File:Kano_Model.png>. [Fecha de consulta: 25 de enero de 2021].