Simplicidad vs precisión

Tengo encima de mi mesa un caso paradigmático de “simplicidad vs precisión“. Estoy diseñando una herramienta de seguimiento financiero, y pocas cosas hay más susceptibles de “precisión” que las finanzas. De hecho, el seguimiento y el reporte financiero debería ir “al céntimo”. Y sin embargo…

Ocurre que en el diseño inicial había una serie de requerimientos: “quiero controlar esto y aquello, tener este nivel de detalle, etc.”. Fenomenal, me puse manos a la obra. Pero una vez puesto en marcha, el feedback fue “uf, esto es demasiado lioso… tengo que meter demasiados datos… la visualización es difícil… TENDRÍAMOS QUE SIMPLIFICAR“.

La relación entre complejidad y exactitud es directamente proporcional. Una solución simple normalmente no te va a dar la mayor de las exactitudes. Si quieres mayores grados de precisión, tienes que aumentar la complejidad. Ahora bien, ésta no es una relación 1 a 1. A veces una solución sencilla te da un nivel de exactitud bastante importante, y no merece la pena ir más allá. A veces esa relación es abrupta (necesitas un incremento sustancial en la complejidad para mejorar sensiblemente la exactitud), a veces es progresiva (a medida que introduces complejidad marginal obtienes mejoras marginales en el otro ámbito), a veces es exponencial, a veces escalonada… en definitiva, hay una curva que relaciona las dos variables, pero la forma de esa curva no es evidente.

Sucede además que “complejidad” es una variable subjetiva. Lo que para unos es complejo, para otros no lo es. Aquí toca hacer un esfuerzo de empatía, porque la primera reacción de un egocéntrico no es la más constructiva del mundo (“si no lo entiendes no es mi problema”… sí que lo es, en realidad). Cuando alguien te dice que algo (que has hecho tú) “es lioso”, es que a él le parece “lioso” e, independientemente de lo que tú puedas opinar, su realidad es esa. De nada vale lo que tú creas, porque al final quien lo tiene que usar es él. Lo que sí está en tu mano es explicar a qué renuncias con la simplificación.

Otro elemento que hay que tener en cuenta es que la “exactitud” también es una variable relativa. ¿Realmente necesitas “exactitud”, o te basta con una “aproximación razonable”?. Depende de las circunstancias, claro, pero (de nuevo aparece aquí nuestro amigo Pareto) posiblemente hay un punto de que “con el 20% de la complejidad puedes conseguir el 80% de la precisión”, y que con ese 80% de precisión te baste y te sobre. Entender dónde está ese punto de “aproximación razonable” es otro factor que hay que manejar, y de nuevo la empatía es una herramienta fundamental.

Finalmente está la cuestión del diseño. Es decir, sea cual sea la curva que relaciona complejidad y exactitud es posible “moverla hacia la izquierda” haciendo un trabajo más o menos intenso de diseño. Cuando digo “mover a la izquierda” quiero decir conseguir el mismo grado de precisión reduciendo la complejidad. A veces esa reducción es real (haciendo las cosas de otra manera), y a veces es solo aparente (tienes que montar unas “tripas” complejas que dan una apariencia de usabilidad simple). En todo caso se requiere un análisis profundo, tiempo, esfuerzo, conocimientos… Como dice Richard Branson, “es complicado hacer algo simple”. Aquí el problema que te puedes encontrar es de plazos, de dedicación (y por lo tanto coste)… a veces resulta difícil explicar que “algo simple” en realidad tiene mucho trabajo detrás.

En definitiva, un proceso muy interesante, no exento de frustraciones pero también muy enriquecedor.

Herramientas: no hay segunda oportunidad para una buena primera impresión

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.

spotify_mvp

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.