feedback

¿Cómo conseguir feedback directo de tus usuarios en etapas tempranas de tu prototipo para iOS?

Ha llegado el gran día. Llevas meses trabajando en lanzar este proyecto para iOS y hoy has enviado tu app a un grupo cerrado de beta testers cuidadosamente elegidos. ¿Y ahora qué? ¿Cómo vas a conseguir feedback? ¿Están teniendo problemas? ¿Les todo ha ido bien? ¿Tienen dudas sobre cómo usar la app? ¿Tienen un canal directo de comunicación contigo?

Cuando estás lanzando tu prototipo por primera vez, ya sea a un grupo de beta testers cerrado o en el Apple Store, es imprescindible recoger la información sobre la prueba, saber qué ha ido bien y qué ha ido mal, para tomar decisiones a nivel técnico y de negocio.

Tienes varias formas de hacer esto, y he elaborado una lista con algunas de ellas:

1 – Enviar un email/encuesta tras la prueba y recoger los resultados

De toda la vida. nada nuevo, vamos. Consiste en enviar un mail al finalizar un periodo de prueba para preguntar a tus usuarios sobre los resultados obtenidos. Puedes usar un formulario de Google Forms, uno de typeform, o incluso enviar preguntas abiertas directamente en el mail. El coste de implementación es prácticamente cero. El problema es que para cuando el usuario quiera o pueda contestar el mail, puede que se haya perdido información relevante del contexto, ya que puede haber pasado mucho tiempo y la experiencia está casi olvidada. Además, la comunicación sólo la puedes iniciar tú como propietario del producto.

2 – Integrar un módulo para el envío de un mail

El coste de implementación es bajo, pero el canal de comunicación es el mismo que el anterior. Una mejora es que es el propio usuario el que inicia la conversación por su cuenta, por lo que el valor del feedback obtenido puede ser mayor.

3- Integrar un sistema de app analytics

Ligeramente más complicado de integrar, aunque herramientas como Firebase nos ofrecen módulos de analytics a coste cero para etapas tempranas de un prototipo. Consiste en medir los eventos que se disparan dentro de la aplicación, en vistas específicas de la misma (se ha abierto cierta vista, usuario a pulsado en determinado botón, etc.). La gran pega de esta técnica es que la comunicación es estrictamente unidireccional.

4 – Integrar un módulo de “rate us” (y dirigir las respuestas a tu servidor)

Es el típico mensaje en pantalla para que el usuario puntúe tu aplicación, bien el en Apple Store (más barato ya que recientemente Apple ha publicado un nuevo API para este tipo de casos), o bien mandando una respuesta a un servidor propio (un poco más caro de integrar). De nuevo, la comunicación es unidireccional.

5 – Integrar un sistema de tickets

Una solución algo más elaborada y un poco más costosa de implementar que las anteriores es integrar un sistema de tickets o “issues”. Zendesk en su opción gratuita nos permite esta posibilidad, y además ofrece un API para integrar pantallas de creación y seguimiento de tickets dentro la app. La comunicación es bidireccional y la inicia el usuario.  Si tienes documentación online (manuales de usuario, etc) sobre tu proyecto, quizá sea una buena idea migrarla a una plataforma como Zendesk e implementar un sistema de tickets.

6 – Integrar un módulo de chat para envío de mensajes de texto en tiempo real

Por último, una gran opción es la integración de un chat en tiempo real. Muchas apps lo están haciendo últimamente, en mi opinión debido al bajo coste (en relación con el valor obtenido para tu negocio) de implementar un chat gracias a backends con base de datos en tiempo real como Firebase u otros. Con esta técnica tenemos comunicación bidireccional, en tiempo real, y que puede iniciarse tanto desde el usuario como desde el propietario de la app. Además, la información está contextualizada porque el usuario que pregunta seguramente sea porque le ha surgido una duda o problema en ese mismo momento. Si tú, como propietario de producto, estás online en ese momento, puedes contestarle en un breve espacio de tiempo.

¿Has implementado alguna de estas técnicas de obtención de feedback en tu proyecto? ¿Cuál fue tu experiencia? ¡Déjame un comentario!

Todos son sistemas válidos, éstos no son los únicos, y seguramente no serán los mejores. Dependiendo de los recursos a tu alcance, deberás elegir el que más te encaje. Siempre puedes enviar un mail a los usuarios tras la prueba beta (si los tienes controlados), y preguntarles cómo ha ido. Pero quizá cuando contesten, la experiencia no la tengan tan reciente, y les cueste recordar bien los detalles. Las app analytics son sencillas de implementar, pero sólo consigues comunicación en una dirección. Los sistemas de tickets exigen mayor trabajo de integración en tu app, pero consigues una comunicación bidireccional, aunque ésta no sea en tiempo real ni la puedas iniciar tu. El envío de un mail desde dentro de la app es una buena alternativa, además, el usuario está acostumbrado a este tipo de interfaz, pero la comunicación es más lenta. La técnica de “rate us” es otra opción, pero normalmente la información que puedes enviar es limitada. Finalmente, un módulo de chat para el envío y recepción de texto en tiempo real, sin obviar su coste de integración, te ofrece comunicación bidireccional en tiempo real, permitiéndote a ti y a tus usuarios iniciar una conversación en cualquier momento durante la prueba, teniendo información de contexto reciente, y por tanto añadiendo más valor a ese feedback.

Fuente de la imagen que acompaña al artículo: pixabay

 

 

2 Comments
  • Jorge González
    Posted at 19:20h, 09 April Reply

    Una opción muy recomendable, aparte del betatest, es hacer una prueba de usabilidad en directo con varias personas. Dejarles con la app y pedirles que naveguen o hagan ciertas acciones para ver “cómo se las apañan”. Los espacios como coworkings etc, son ideales para este tipo de pruebas, ya que la gente se suele ofrecer sin problema, y se aprende muchísimo.

    • Roberto
      Posted at 07:06h, 10 April Reply

      Hola Jorge, ¡gracias por tu comentario!
      Efectivamente, en el artículo trato las técnicas que requieren implementación de un programador, perfectamente complementarias con las que tú planteas. Pero tienes toda la razón, las pruebas de usabilidad no deben faltar.
      Un abrazo!

Deja un comentario