Cuando un cliente nos contacta y nos cuenta qué problema necesita solucionar, ponemos todos nuestros esfuerzos en averiguar qué está fallando y por qué.

En este caso, se trataba de una aplicación móvil pensada para ofrecer un servicio de seguridad a aquellas personas que consideraban necesario su autocuidado, porque se sentían inseguras y vulnerables en ciertas circunstancias vitales.

El mayor problema de esta app era la adquisición, el engagement, y como consecuencia, la falta de monetización.

Todos los esfuerzos del equipo habían generado una app con una serie de funcionalidades muy avanzadas técnicamente pero sin una propuesta de valor clara y sin un usuario target identificado.

El proceso que seguimos en elmeunebot para dar solución a estos problemas fue detectar cuál era realmente su “early adopter”, teniendo en cuenta la capacidad técnica de la app y su necesidad de monetización.

Para ello, recurrimos a la metodología de Jobs-to-be-done, utilizada para procesos de innovación, que trata de identificar cuál es la tarea principal del usuario, sin tener en cuenta ninguna solución concreta, simplemente descubrir cuál es su “job” y qué necesidades tiene en el camino para conseguirlo.

¿Cómo fue el proceso para intentar dar con una solución?

Los equipos de research y diseño de elmeunebot nos implicamos, junto con profesionales de marketing y producto de esta app de seguridad, en la realización de múltiples actividades:

1. Workshop de alineación: definición del “scope” para la investigación de usuario‍

Preparamos una sesión de trabajo en la que se redefinió cuál era la tarea principal que el usuario quería cumplir, quién era dicho usuario como “early adopter” y qué necesidades tenía.

Después de esta sesión, se acordó que el usuario principal, que hasta entonces había sido múltiple y variado, se acotaba a personas que quieren cuidar de sus seres queridos. Partiendo de ello, empezamos la etapa de investigación que nos permitiría validar las hipótesis lanzadas.‍

2. Reclutamiento de “early adopters” con Screening

Diseñamos un cuestionario para recoger los datos de personas que cumplían con las condiciones de ese “early adopter”, de forma que pudiéramos recopilar datos de personas que luego serían entrevistadas para hablar sobre el cuidado de sus seres queridos.

3. Entrevistas con usuarios y validación de soluciones

Realizamos 6 entrevistas con usuarios que constaban de dos partes:

• 1º parte: conocer cuál era esa tarea a cumplir (cuidado de seres queridos), por qué y cómo lo hacían.
• 2ª parte: validación de las posibles soluciones. Se les invitaba a descargar dos apps: una de la competencia y la propia app de seguridad con la que estábamos trabajando. De esta forma los entrevistados podían ver: qué ofrecían, cuál era la experiencia del onboarding, si satisfacía su necesidad y si pagarían por ello.

Tras las entrevistas, validamos que la propuesta de la app para la que trabajábamos no era clara, incluía muchas funcionalidades que no se entendían y tampoco acababan de satisfacer directamente la tarea de cuidar a seres queridos.

4. Workshop de ideación

Con las conclusiones de las entrevistas, preparamos una sesión de trabajo que consistía en idear una funcionalidad que permitiera integrarse con las funcionalidades existentes en la app pero satisfaciendo la necesidad concreta de ese “early adopter” detectado: personas que necesitan cuidar a sus seres queridos.

Teniendo en cuenta todos los insights obtenidos de las entrevistas y creando el perfil de esa “persona”, se definió un flujo que permitiría mejorar la experiencia de este “early adopter”.

5. Diseño de wireframes y UI

Desde el equipo de diseño preparamos, a partir de las conclusiones de los workshops y las entrevistas, los wireframes de la funcionalidad “core”: localización de seres queridos con tareas asignadas a cada miembro, para el cuidado de los integrantes de un círculo de confianza (familiar, amistades, etc).

¿Cuáles fueron los beneficios obtenidos con esta fase de investigación y redefinición del target?

• Validamos que el cambio en el “early adopter”, que habíamos planteado en el primer workshop con el cliente, era acertado. Los que se mostraban dispuestos a pagar por el servicio de cuidados eran los cuidadores, no las personas cuidadas.
• Comprobamos que los cuidadores tenían necesidades de control de geolocalización pero también de tareas relacionadas con sus rutinas.
• Detectamos que la app, como solución, parecía interesante, pero resultaba confusa para los usuarios, que no entendían bien cuál era la funcionalidad principal.
• Descubrimos que los cuidadores se mostraban más interesados en crear un círculo de cuidado con sus seres queridos, en lugar de ejercer un control individual.

A pesar de todo, estos hallazgos nos generaron un gran reto: integrar la nueva solución diseñada con el resto de la app. Al estar enfocada a las personas que se auto-cuidaban y no tener como objetivo el rediseño de toda la plataforma, tuvimos que reorganizar y simplificar el planteamiento para que estuviera en armonía con las funcionalidades ya existentes en la aplicación.

Tras superar este gran obstáculo, los principales resultados con nuestro trabajo fueron:

• Un cambio de dirección en el enfoque del producto. La app pasa de estar centrada en sus funcionalidades a ser una app que responde a las necesidades del nuevo target identificado: los cuidadores de seres queridos.
• Una variación en la funcionalidad core de “botón de alerta”. Quedará en un segundo plano, ya que se trata de una funcionalidad que no va a asegurar recurrencia y “engagement”, debido a su propia naturaleza: las personas (por suerte) no tenemos situaciones de alerta todos los días, ni todas las semanas.
• Una simplificación en la propuesta de la app: Nuevo diseño para la pantalla de inicio con la funcionalidad de geolocalización de seres queridos y seguimiento de sus tareas diarias con posibilidad de actualización automática.

¿Cuáles fueron los resultados trabajando como un equipo “in-house”?

Tras el trabajo realizado, el cliente nos cuenta que su experiencia ha sido positiva, ya que les hemos ayudado a centrarse en una funcionalidad, teniendo en cuenta que satisface a un usuario identificado y validado, además de orientarles en cuanto a cómo organizar y priorizar las funcionalidades que antes ofrecían. Para nosotros ha resultado ser una experiencia muy satisfactoria poder identificar, validar y rediseñar la experiencia para que esta app de seguridad encuentre su market-fit.

A partir de ahora, nuestro cliente podrá medir, trackear los resultados de estos cambios y seguir planteando iteraciones en beneficio del producto, adaptado a su usuario objetivo.

En elmeunebot trabajar como un equipo “in-house” nos permite siempre establecer una relación de confianza con el cliente y colaborar con todos los departamentos como equipo para alcanzar unos objetivos comunes.

Si crees que te gustaría validar o comprobar si estás centrándote en el usuario adecuado, puedes leer este artículo para saber todos los detalles de cómo preparar tu Research Plan.

Sin embargo, si prefieres ver cómo lo hacemos nosotros y qué podemos ofrecerte para que conozcas y definas mejor a tu usuario, no dudes en escribirnos a hola@elmeunebot.es.