El otro día me dio por curiosear las opiniones de los usuarios de una app lanzada recientemente por gente que conozco. «Buena idea, regular ejecución, mal soporte», «Necesita mejorar. La idea es buena y funciona casi bien», «Necesita mejorar muchísimo», «Buena idea, pero malísima app», «Esta demasiado verde como para haberla lanzado a nivel nacional»… son algunas de las opiniones que se leen de los primeros usuarios. Sí, también hay alguna valoración positiva, pero el tono general es de decepción.
Inviertes un montón de dinero y tiempo en desarrollar una aplicación, haces un lanzamiento multitudinario, consigues que miles de personas se la descarguen… solo para encontrarse con un producto que funciona de aquella manera. ¿Cuántas de estas personas van a dejar de usarla, y no te van a dar una segunda oportunidad? Da igual que, como dicen los desarrolladores, «gracias a vuestros comentarios vamos ajustando la App para mejorar la experiencia como usuarios». Muchos de ellos no van a perder más el tiempo contigo.
Desde luego, no soy ajeno a estos problemas. Yo también he caído en ese mismo error. Te pones a diseñar algo que crees que es fantástico. Haces el esfuerzo de desarrollarlo. Lo lanzas… y resulta que la acogida es muy floja. Porque no funciona bien del todo. Porque es complejo. Porque no responde a las necesidades reales del público objetivo. Porque te has venido arriba con tus ideas sin tener en cuenta a quienes en definitiva son quienes tienen que hacer uso de la herramienta. Porque has querido correr, porque no has hecho las suficientes pruebas. Luego sí, intentas recopilar el feedback, intentas reconducir la situación… pero ya es tarde, eres prisionero de lo que ya has hecho, y encima has perdido la confianza de tus potenciales usuarios.
¿Cómo deberían abordarse estos procesos para minimizar el riesgo de una mala acogida? Estoy seguro de que existe un montón de literatura y metodologías que ya dan respuesta a esta pregunta (y sin embargo se ve que no se aplican lo suficiente). Yo, de mi experiencia, extraigo estos puntos:
- Entiende bien la problemática: y con esto me refiero no a «lo que tú crees que es la problemática», sino «lo que el usuario cree que es la problemática». Es a ellos a los que hay que ofrecer soluciones. El despotismo ilustrado («yo sé lo que tú necesitas») no funciona. Hay que investigar, hablar con ellos, pasar tiempo a su lado, conocerles. Entender cuál es la china que les aprieta en el zapato. Primero porque así sabremos mejor qué es lo que tenemos que resolver. Y segundo porque en el propio proceso estaremos ganando aliados para el futuro, nos verán como alguien que «se ha molestado en entendernos» y no como alguien que «nos impone su solución».
- Resuelve un problema cada vez: es mejor resolver un problema de forma incuestionable, que intentar resolver a la vez quince problemas dejándolos a medias. Escoge un problema, y diseña una solución sencilla, robusta, fiable, que el usuario compre. Si consigues resolverle un problema de forma consistente, ya está de tu lado. A partir de ahí sigue identificando problemas, y resolviéndolos con el mismo nivel de exigencia. Pero uno detrás de otro.
- Busca el 20%: o «Keep It Simple, Stupid». Una solución simple va a tener mucha mejor aceptación que una compleja. Incluso si en el camino pierdes potencia. Ya sabemos que «si añadiésemos esto y aquello, los resultados serían aún mejores». Ya. Pero hay que centrarse en ese 20% de funcionalidades que resuelven el 80% del problema. Ya habrá tiempo de rizar el rizo, si realmente es necesario. Porque si de un problema resuelves el 80%, posiblemente deje de ser un problema y te puedas centrar en otra cosa.
- Prueba las soluciones exhaustivamente: probar, probar, y probar. Necesitas un colectivo pequeño con quienes trabajar en el «piloto». No vale cualquiera. Tiene que ser gente implicada, que te ayude a testear la herramienta en todas las circunstancias posibles, y que te dé feedback. Hasta que los usuarios de ese piloto no estén extremadamente satisfechos (y se hayan convertido en unos usuarios intensivos), no se puede dar el siguiente paso. Si los que han estado involucrados en el desarrollo no están satisfechos… ¿qué crees que va a pasar con aquellos a los que tu herramienta «les cae del cielo»?
En este sentido, me gustó mucho esta visión de «minimum viable product» que vi en una presentación de Spotify.
Tienes que resolver problemas desde el minuto 1. Ya irás refinando la forma de hacerlo, ya le añadirás complejidad si es necesario. Pero tu producto, por sencillo que sea, tiene que mejorar la vida del usuario, y tiene que funcionar de forma impecable desde el principio. Si no, es muy probable que el potencial usuario te cierre las puertas.
En mi experiencia, hay un enemigo importante en todo este planteamiento: el tiempo. O mejor dicho, la presión por parte de «los que mandan» para que las soluciones se implanten «antesdeayer». Todos los pasos que definía antes requieren tiempo. ¿Cuánto? Indefinido. No se puede calendarizar una fase de exploración, no se puede calendarizar una fase de desarrollo, no se puede calendarizar una fase de pruebas. Porque no conoces el problema hasta que te pones a analizarlo. Porque no puedes resolver incidencias hasta que no empiezas las pruebas, no sabes qué va a pasar, no sabes cuánto te va a costar resolverlo. Pero esto es algo que nadie quiere oír, como tampoco quieren oír que «la primera versión sólo va a centrarse en un problema muy concreto». Quieren la solución «tope de gama», y la quieren ya.
Y eso hace que nos saltemos pasos. No preguntamos a los usuarios, porque «el problema está claro». Diseñamos de espaldas a ellos. Nos metemos en caros y complejos desarrollos sin haber validado nuestras asunciones (o aceptamos como «validación» que alguien en un comité simplemente no se negase). Hacemos un par de pruebas en una semana, ignoramos el feedback que nos den, y nos ponemos con la expansión. Y sacamos pecho en una reunión de seguimiento. ¡Hemos cumplido! Ahí está nuestra herramienta, que mira qué bien funciona (en la demo… y de hecho a veces la demo la hacemos con pantallazos en powerpoint «por si acaso los problemas del directo»), ¡y en el plazo que prometimos!. Luego empiezan los problemas, el «runrun» de que aquello no va bien, que es complejo, que en determinadas circunstancias no funciona, que tampoco me resuelve nada, que yo lo que necesito no es esto. El impacto que se supone que debería de tener no aparece por ningún lado. Y entonces nos ponemos a pensar «qué podemos hacer para enderezar el rumbo», y empezamos a pensar en «la inversión que hemos hecho para nada». Ya. A buenas horas.
Las cosas, para que salgan bien, hay que hacerlas de determinada manera. No sirven los atajos. Y quienes toman las decisiones (y quienes les asesoran, que muchas veces son parte del problema porque son los primeros que no dicen las cosas como son) deben asumirlo.
