Cómo validar la demanda con la investigación de usuarios

¿Cómo puedes validar la demanda de tu nuevo producto o prestaciones? La respuesta es sencilla: elige una plataforma inteligente de pruebas de usuarios. ¿Alguna sugerencia? Sí, ¡válida!

El uso de wireframes y prototipos interactivos de alta fidelidad con pruebas de usabilidad es una forma eficaz de obtener feedback, pero hay que hacerlo bien. Justinmind y Validately iniciaron una nueva colaboración en febrero de 2016, y ahora todos los usuarios de Justinmind PRO también pueden probar Validately de forma gratuita. En este artículo invitado, el fundador y CEO de Validately, Steven Cohn, ofrece algunos consejos sobre cómo validar la demanda de tu nuevo producto o funciones mediante la investigación de usuarios. El artículo también incluye consejos sobre cómo evitar errores comunes al realizar pruebas de usabilidad.

Todos sabemos que crear una nueva función o producto que genere un profundo compromiso por parte del cliente es difícil de conseguir. Jared Spool (líder en UX e investigación de usuarios) explica por qué en el siguiente tweet:

Las pruebas de usabilidad son un proceso conocido y bien documentado. Pero, ¿hay formas de probar la demanda de un nuevo producto o función antes de construirlo?

Sí. Siempre que lo hagas correctamente. He aquí cómo hacerlo:

Preguntar «¿Lo harías?» NO es suficiente

Empecemos destacando un error común en las pruebas:

Por desgracia, preguntar a un encuestado si utilizaría un producto no produce una respuesta fiable. El tweet anterior de Jared explica parcialmente el motivo. Pero la razón subyacente por la que esta pregunta es un predictor poco fiable de la demanda es que al encuestado no le cuesta nada decir «sí».

Tienes que hacer que el «Sí» cueste algo

En la vida cotidiana, sin pruebas, decir «sí» es una decisión de compromiso. Para decir «sí» primero tenemos que determinar: «¿Vale realmente la pena para mí?». Como ésta es la misma pregunta que se harán tus usuarios cuando tu producto (o función) salga al mercado, tienes que forzar esa decisión también durante las pruebas. Hay tres formas de hacer que decir «sí» a una pregunta cualitativa cueste algo durante una prueba.

• Tiempo: ask al encuestado de prueba para que te dedique más tiempo. Si están realmente interesados en el producto (o función), dirán «¡sí!». He aquí un ejemplo de pregunta:

• Reputación: ¿Pedir al encuestado que comparta tu producto con sus amigos sin compensación? Si están realmente entusiasmados con tu producto (o función), lo compartirán encantados con los demás. He aquí un ejemplo:

• Dinero: Pide al encuestado que pague por adelantado el producto (o función). Incluso cobrar una cantidad nominal es revelador. He aquí un ejemplo de pregunta:#

¿Qué pueden decirnos las pruebas de validación de la demanda?

Para que quede claro, esto NO garantiza necesariamente la creación de un producto (o función) que los clientes quieran utilizar. Después de todo, estoy seguro de que te has descargado aplicaciones que no utilizas, o has cancelado una reserva de hotel pagada por adelantado. Sin embargo, estas pruebas son una forma estupenda de evitar una mala implementación del producto o función. En pocas palabras, si una persona que responde a una prueba no está dispuesta a darte su tiempo, su reputación o su dinero, es que realmente no quiere utilizar tu producto.

El comportamiento anterior es un buen indicador

Otra buena validación de la demanda futura es si el encuestado ha utilizado un producto/función comparable en el pasado. Jared sugiere hacer esta pregunta:

El objetivo de hacer esta pregunta es comprender mejor por qué un usuario «alquiló» un producto de la competencia. La parte «háblame de él» trata de profundizar en lo que les haría cambiar a tu producto. ¿Qué les gusta u odian del otro producto? Lo que Jared quiere decir es que es poco probable que convenzas a alguien que actualmente no realiza una actividad para que la elija. Sin embargo, puedes animarles a cambiar de otro producto si el tuyo satisface una necesidad actualmente insatisfecha. Y, por supuesto, querrás utilizar las Pruebas Minimalistas para estas pruebas con el fin de validar a qué características va a decir «¡sí!» un cliente. Las pruebas de Validación de la Demanda son el primer paso. Para impulsar el compromiso de los clientes, un producto o función debe aportar valor y ser fácil de usar. Una vez que hayas validado la demanda, tienes que realizar también pruebas de usabilidad. Al observar las pruebas de usabilidad, nos hemos dado cuenta de algunos errores comunes.

 

Errores comunes en las pruebas de usabilidad

A continuación te presentamos dos estructuras de prueba diferentes, con el mismo objetivo. Intenta determinar las dos diferencias antes de que te las contemos.

Las diferencias clave:

¿Adivinaste las principales diferencias entre las pruebas? ¡Sigue leyendo para averiguarlo! Enunciado de la «tarea»
La primera gran diferencia entre las dos pruebas es el enunciado de la tarea. Es una diferencia sutil, pero el impacto es significativo.

• En la Prueba 1, el enunciado de la tarea es muy prescriptivo. Incluso utilizamos los nombres exactos que aparecen en el producto.
• En la Prueba 2, el enunciado de la tarea depende del caso de uso, es decir, «Comparte tus ideas sobre un proyecto».

¿Por qué es importante? El enunciado de una tarea es importante porque los nuevos usuarios acuden a tu producto para resolver un problema que tienen. La solución que ofreces y cómo etiquetas el camino hacia esa solución es lo que estás probando con una prueba de usabilidad. Sin embargo, si durante tu prueba eres demasiado prescriptivo con tu tarea, haciendo esencialmente una «pregunta cargada», los resultados se verán empañados. La prueba 1 indica al usuario dónde debe hacer clic. Así, no estaría claro si una persona es capaz de completar la tarea porque la UX es intuitiva, o porque simplemente buscó los botones con la etiqueta «bloc de notas» y «añadir nota», ya que hemos utilizado esas palabras. Por el contrario, la Prueba 2 es más propicia a cómo pensaría normalmente un usuario, es decir, con un problema a resolver en mente. En este caso, el problema a resolver es «añadir mis pensamientos sobre un proyecto». Por lo tanto, la navegación satisfactoria por el flujo y la finalización de la tarea por parte del encuestado de la prueba puede darnos la seguridad de que la función UX es intuitiva.

Esencialmente, el enunciado de la tarea para una prueba de usabilidad debe basarse en el caso de uso. Evita ser demasiado prescriptivo al formular una tarea, o acabarás recibiendo respuestas retóricas.

 

La página de entrada

En esta app «de juguete» que hemos construido, la función «añadir nota» está en la página «bloc de notas». Pero como la mayoría de los usuarios que utilizan la aplicación pasan tiempo en el «proyecto actual», realmente tenemos que probar si navegar desde la página del «proyecto actual» a la página del «bloc de notas» para añadir notas es intuitivo para nuestros clientes.

Esto es especialmente importante porque la tarea del usuario es «compartir sus pensamientos sobre un proyecto», como hemos señalado antes. Empezando en la página principal, podemos averiguar si el usuario piensa intuitivamente en navegar hasta el «bloc de notas» cuando quiere completar el caso de uso de «compartir pensamientos». Si el punto de entrada de una prueba de usabilidad inicia al usuario en la página con la actividad (como hicimos en la Prueba 1), entonces no estás probando la capacidad del usuario para navegar hasta la función correctamente. Simplemente estás probando si el usuario puede realizar una actividad en esa página concreta. Básicamente, una buena prueba de usabilidad no sólo mide la capacidad de un usuario para completar una tarea, sino que también prueba la capacidad de un usuario para completar los flujos de navegación habituales hacia esa tarea. He aquí cómo estructuraríamos una prueba de usabilidad para esta función:

• Quién: Como se trata de una nueva función dentro de un producto ya establecido, pruébala con clientes reales.
• Cuántos: 5 clientes por página de inicio (ver más abajo)
• En qué momento: En la fase de prototipo
• Dónde: A distancia para ver si nuestros clientes pueden hacerlo de forma natural antes de programar una prueba de usabilidad en persona.
• Introducción de la prueba: «Estamos planeando añadir una función a la aplicación ToDo que te permita compartir tus pensamientos sobre un proyecto. Aquí tienes un prototipo de esa función. Por favor, utiliza este prototipo para darnos tu opinión sobre este proyecto con tus compañeros de equipo.»
• Prueba de la página de inicio: Realiza una prueba de usabilidad que comience en la página Proyectos actuales, en la página Proyectos archivados y en la página Línea de tiempo, ya que esos son los tres flujos de navegación principales que tendrán nuestros clientes. No sugerimos realizar una prueba que comience en la página Bloc de notas.

 

Eso es todo por ahora, amigos. Nos complace anunciar que Justinmind y Validately unirán sus fuerzas a finales de este mes. Así queestad atentos para más detalles sobre la integración y para más actualizaciones de UX. Mientras tanto, ¿por qué no inscríbete en una demostración de Validately y si aún no lo has hecho descarga Justinmind ¡para empezar a mejorar tu flujo de trabajo!