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 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:
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.
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.
De acuerdo con el modelo KANO, por cada funcionalidad hay que hacer una pregunta funcional y una disfuncional:
Funcional
Disfuncional
Para ambas preguntas, las opciones de respuestas son las mismas:
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.
Utilizamos Google Forms para hacer las encuestas.
Las 5 funcionalidades que eligimos fueron:
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.
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.
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:
¿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:
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.
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.
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.
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.
Otra de las funcionalidades implementadas fue la vista de miniaturas a la izquierda de los formularios.
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.
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.
El éxito de la implementación de un sistema ECM depende en gran medida de una buena planificación. Por eso, en nuestro e-book te presentamos los
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
Empresas con grandes departamentos de comunicación o que se dedican al sector de la comunicación, el diseño o la televisión, requieren de una forma eficiente
