Plataforma inteligente de gestión de contenido digital

Utilizando el modelo KANO para priorizar funcionalidades de producto

Os contamos nuestra experiencia poniendo en práctica el modelo KANO para la priorización de funcionalidades de producto.
Athento's product team
Veronica Meza

Veronica Meza

Athento cuenta con varios mecanismos para que sus usuarios puedan contribuir al roadmap del producto. Por ejemplo, tenemos la página para solicitar funcionalidades feedback.athento.com y recibimos solicitudes directamente a través de nuestros Customer Success Managers que escuchan de forma activa a los usuarios. Una vez recibido este feedback, por supuesto, tienes que priorizar aquellas funcionalidades que efectivamente vas a llegar a implementar.

En mayo de este año, detectamos que habían algunas funcionalidades o mejoras que varios de nuestros clientes estaban pidiendo. Nos propusimos evaluarlas para saber si debíamos acometerlas y con qué prioridad. El método que escogimos para realizar esta valoración fue una versión simplificada del modelo KANO.

 

El Modelo Kano

El modelo Kano es una herramienta de priorización introducida por el profesor Noriaki Kano en los 80’s. Básicamente, se trata de categorizar y priorizar las funcionalidades de acuerdo con el grado de satisfacción que una funcionalidad puede darle a los usuarios.

Para poder categorizar y priorizar las funcionalidades, se hacen preguntas sobre ellas  en una determinada manera. Una vez realizadas estas preguntas, es posible catalogar las funcionalidades en alguna de las siguientes categorias de acuerdo con la respuesta emocional que los usuarios dan a dichas preguntas:

  • Acttractive (Atractivas):  los usuarios no esperan tenerlas pero les gustaría si las tuvieran.
  • Must-be (Imprescindibles): los usuarios esperan tener esta funcionalidad y no les gusta el no tenerla.
  • Performance (De rendimiento):  a los clientes les gustan estas funcionalidades y les disgusta no tenerlas.
  • Indifferent (Indiferentes): a los clientes les da igual tenerlas o no.
  • Questionable (Cuestionables):  las respuestas arrojan resultados contradictorios o poco claros.
  • Reverse (De reversa): los usuarios prefieren no tener esta funcionalidad. Tenerlas les causa insatisfacción.

El roadmap del producto debe evitar funcionalidades de reversa, indiferentes o aquellas cuestionables.

A continuación, os contamos nuestra experiencia con esta herramienta de priorización.

 

Implementando el modelo KANO

Lo primero que me gustaría comentar es que Athento no siguió una aproximación purista en la implementación de este framework. Por varios motivos y limitaciones, así como por simplicidad. Por ejemplo, no es posible hacer una traducción textual al castellano de algunas de las preguntas y opciones que el modelo Kano utiliza.

De cualquier manera, en este artículo os contamos cómo lo implementamos nosotros y vosotros en vuestro caso podéis decidir si seguís un enfoque mucho más purista.

Escogimos 5 funcionalidades para preguntarle a nuestros clientes. Queríamos tener un porcentaje alto de colaboración y sabemos que si hacemos encuestas muy largas, los usuarios podrían dejar de participar. Tened en cuenta que por cada funcionalidad en el modelo Kano, deben hacerse dos preguntas.

 

El cuestionario KANO

De acuerdo con el modelo KANO, por cada funcionalidad hay que hacer una pregunta funcional y una disfuncional:

Funcional

  • ¿Cómo te sentirías si el producto tuviera…X funcionalidad? (How would you feel if the product had…)

Disfuncional

  • ¿Cómo te sentirías si el producto no tuviera…X funcionalidad? (How would you feel if the product did not have…)

Para ambas preguntas, las opciones de respuestas son las mismas:

  • Me gusta (I like it)
  • Lo espero (I expect it)
  • Me da igual (I am neutral)
  • Puedo tolerarlo (I can tolerate it)
  • No me gusta (I dislike it)

Una vez tienes las respuestas, tienes que clasificar las funcionalidades en sus categorías siguiendo una matriz como la que se muestra a continuación.

Kano Matrix

Nuestro cuestionario KANO

Utilizamos Google Forms para hacer las encuestas.

Las 5 funcionalidades que eligimos fueron:

  • Poder customizar a nivel de formulario qué botones se muestran en la barra de acciones rápidas del documento.
  • Generar QRs con URLs para compartir documentos de forma pública con usuarios externos. La idea es que la funcionalidad actual de generación de QR permita añadir una URL única y que un usuario externo pueda usar esa URL para consultar información sobre el documento. Cuando el usuario use esa URL, verá una pantalla pública (sin login requerido) donde verá los campos que hayan sido marcados como públicos para ese tipo de documento.
  • Selector desde la configuración del ciclo de vida para asociar un color a un estado. Cuando esta opción esté habilitada, el color se mostrará en el listado de documentos y en la etiqueta del estado del ciclo de vida dentro de un documento.
  • Permitir enviar a varios usuarios externos al mismo tiempo un documento para su aprobación/revisión. Al momento de la encuesta, solo se podía añadir un email por envío.
  • Pestaña nueva junto a la pestaña HTML en la que se verían los documentos relacionados. La pestaña indicaría en su título el número de adjuntos. Cuando el usuario abra/active la pestaña, vería como miniaturas los adjuntos.

El primer punto importante para nosotros era que los usuarios entendieran lo mejor posible de qué se trataban las funcionalidades propuestas. Por suerte, con Google Forms podíamos incluir imágenes y explicaciones para ilustrar a los usuarios.

Kano sample question

Otro punto importante para nosotros era el planteamiento de las preguntas y las respuestas. Tuvimos que hacer una traducción y ajuste de las mismas para que fueran más naturales y entendibles para nuestros usuarios.

Para facilitar el rellenado de la encuesta la dividimos en una página por funcionalidad. En cada página, hacíamos la pregunta funcional y la disfuncional.

Análisis de los resultados

Una vez conseguimos una muestra significativa, llegó el momento de analizar las respuestas. La primera alegría que nos llevamos fue ver que ninguna de las funcionalidades propuestas eran de tipo Reverse, por lo que al menos de comienzo, podíamos aventurar que no estábamos muy desencaminados al pensar en su implementación.

Como podéis ver, para cada funcionalidad, las opiniones de los usuarios estaban divididas. Para algunos una caracterísitica podía ser atractiva, mientras que para otros, esta podía ser indiferente.

Llegados a este punto, tienes que averiguar cuál es la categoría dominante, es decir, tratar de averiguar lo que la mayoría de los usuarios quieren. Para ello, se usan coeficientes:

  • Coeficiente de satisfacción CS+: suma de % atractivas + % performance / suma de todos los porcentajes a excepción de reversa y cuestionable.
  • Coeficiente de insatisfacción CS-: suma de % performance + % imprescindibles / suma de todos los porcentajes a excepción de reversa y cuestionable.

¿Qué significan estos coeficientes y qué valores podemos tener como referencia? El coeficiente CS+ de satisfacción del cliente se sitúa entre 0 y 1. Cuanto más se acerque el resultado a uno, mayor será el efecto sobre la satisfacción del cliente. Por el contrario, un coeficiente CS+ cercano a 0, sugiere que esa característica concreta tiene muy poca influencia en la satisfacción del cliente.

El coeficiente de insatisfacción (CS-), si se aproxima a -1, la no inclusión de esta característica tiene un fuerte impacto en la insatisfacción de los clientes. Por el contrario, un valor cercano a 0 significa que la ausencia de esta característica no hace que los clientes estén insatisfechos.

Si os fijáis en los datos de la tabla de abajo, vemos que la inclusión de la mayoría de las funcionalidades parecen mostrar un impacto positivo sobre la satisfacción del cliente de acuerdo con su CS+ (>0.5). El coeficiente de insatisfacción también nos muestra que la no inclusión de la funcionalidad de envío de aprobación a varios correos tiene un impacto negativo importante en los clientes (CS- de -0.89). 

Además de estos coeficientes, es interesante calcular también la fuerza total y la fuerza de la categoría. Estos datos nos ayudarán con la distribución de frecuencias. La fuerza total muestra hasta qué punto los usuarios consideran una característica  importante. Por regla general, el valor debe ser superior al 50%.  Podemos calcular la fuerza total de la siguiente manera:

  • Fuerza total = % Atractivas + % Imprescindibles + %Performance

Vemos que en el caso de las funcionalidades postuladas, todas ellas superan la prueba de la fuerza total. Podemos entender que son funcionalidades consideradas positivas por los clientes. Ahora bien, ¿cuál es la categoría en la que más claramente podemos posicionar cada funcionalidad?

La fuerza de la categoría muestra lo distinta que es una categoría en comparación con las demás. La fuerza de la categoría debe ser superior al 5% para mostrar que una característica pertenece inequívocamente a una categoría.

  • Fuerza de la categoría = porcentaje de la respuesta más frecuente – porcentaje de la segunda respuesta más frecuente

Como podemos ver en nuestra tabla, la funcionalidad número 3 se encuentra por debajo del 5%. Por tanto, no hay una categoría clara para la característica 3 que necesitará un análisis más profundo.

¿Qué hicimos con los resultados?

En sprints posteriores al estudio, planificamos algunas de las funcionalidades catalogadas como atractivas y que no le resultasen indiferentes a un gran porcentaje de los usuarios. En la siguiente gráfica se puede ver la distribución de respuestas para cada funcionalidad.

Una de las funcionalidades que priorizamos fue la de poder enviar un email de aprobación a más de un usuario. Este era uno de los casos en los que no tener esta posibilidad generaba más insatisfacción en los clientes. A continuación podéis ver la IU de la funcionalidad antes y después del estudio Kano. 

send-approval-email

Ahora los usuarios, haciendo clic en el botón “Add receiver” pueden añadir destinatarios sin limite para que reciban un documento para su aprobación vía email.

A continuación se puede ver otra de las funcionalidades priorizadas: Generar QRs con URLs para compartir documentos de forma pública con usuarios externos.

generar qr codes con enlaces publicos

Otra de las funcionalidades implementadas fue la vista de miniaturas a la izquierda de los formularios.

vista-miniaturas

Reflexiones sobre la experiencia

Aunque en apariencia sencillo, el modelo Kano ofrece resultados que a veces son difíciles de interpretar. Por ejemplo, casos en los que para un alto porcentaje de la muestra, la funcionalidad es atractiva, pero para un porcentaje también significativo la funcionalidad es indiferente. Considero personalmente que es complicado hilar fino con un modelo como este o, al menos, de la manera artesanal en la que nosotros lo hemos probado. 

El modelo presenta una serie de dificultades de implementación en una industria como la nuestra, por ejemplo, debes asegurarte de que el cliente entienda qué funcionalidad le estás proponiendo. Debes ayudarle a visualizar algo que no existe y aunque utilices mockups, wireframes o prototipos, estás utilizando una encuesta en la que la interacción con el usuario no existe. Quizás, lo ideal sería utilizar entrevistas en lugar de encuestas, aunque esto sería mucho más costoso.

Sin embargo, a alto nivel, el modelo Kano sí que nos ha permitido saber que a rasgos generales, la implementación de estas funcionalidades ocasionaría una respuesta positiva de los usuarios. Creo que esta es una de sus ventajas.

Además, considero que otro aspecto positivo de hacer este tipo de ejercicios es que te obligas a preguntarle a tus usuarios qué es lo que quieren y a escuchar su feedback directo. Escuchar a los usuarios es fundamental para que el producto crezca en la dirección adecuada.

 

Próximos pasos

Creo que para cerrar este ejercicio, nos queda escuchar el feedback post-implementación de estas funcionalidades. ¿Era lo que los usuarios entendieron cuándo les preguntamos? ¿Seguirían catalogando las funcionalidades de la misma manera si les preguntamos ahora que ya las tienen?

Al final, considero que la parte positiva de este tipo de iniciativas es darle a los usuarios más mecanismos para que expresen sus opiniones sobre el producto. En en futuro seguiremos probando nuevas formas de obtener feedback.

Recursos de Gestión Documental

Recogida de Requisitos de Proyecto

En esta entrada quiero hacer una reflexión sobre el proceso de recogida de requisitos para proyectos software. Sobra señalar la importancia de esta fase, que

Read More »