Normalmente los pedidos llegan a los equipos de Diseño como soluciones, que, además, suelen estar disfrazadas de “necesidad” o “requerimiento”. Muchas veces, incluso, vienen con una «justificación» los hace parecer inequívocos. Ejemplos típicos de pedidos:

• “Hay que simplificar el onboarding [porque tiene muchos pasos]. ”
• “En la página de resultados hay que agregar un filtro por categoría”
• “Hay que mostrar más planes para aumentar la conversión”
• “Necesitamos un dashboard”

En este contexto, lo que se espera de Diseño es, en el mejor de los casos, que desarrollen una solución a ese «problema». En el peor, que pinten las pantallas de la solución que alguien ya creó.

El problema con estos pedidos

El problema es que estos pedidos mezclan cosas distintas: la observación, la interpretación como problema, y la solución propuesta. Y además, no se define el resultado esperado, o se lo supone implícito en la implementación de la mejora.

Pero observación ≠ interpretación ≠ solución ≠ resultado esperado.

Por ejemplo, el equipo de Diseño de un banco recibe este pedido: “Hay mucho abandono en el flujo de alta de cuenta, así que necesitamos hacerlo más corto.”

Observación: hay abandono en el flujo de alta
Interpretación: los usuarios abandonan porque hay muchos pasos
Solución: hacer el flujo más corto.
Resultado esperado: no se menciona, pero está implícito en la observación: que el abandono disminuya.

Por qué distinguir los elementos es importante?

Distinguir entre observación, interpretación y solución es clave, porque una idea de producto o funcionalidad no es una solución hasta que demuestra que resuelve un problema real (y relevante) para los usuarios. Por eso, en el mundo de producto hay un mantra (muy citado pero pocas veces practicado) que es que toda idea debe ser tratada como hipótesis.

Tratar las ideas como hipótesis ayuda a:

• No confundir convicción con evidencia. Que una idea parezca lógica no significa que sea cierta. Que el flujo de alta sea largo no demuestra que esa sea la causa del abandono ni que reducir pasos sea la solución.
• Explicitar los supuestos implícitos. ¿Por qué creemos que la longitud del proceso es la causa de abandono? ¿Por qué creemos que reducir pasos podría resolverlo?
• Definir una dirección y qué observar. Entender qué problema vamos a solucionar, qué cambio buscamos producir y qué resultado esperamos lograr orienta la solución y permite identificar qué señales o métricas mostrarían si ocurrió.

Pero el valor real es que:

• Cuando tratamos una idea como requerimiento, la pregunta es “¿cómo la construimos?”. Estamos en terreno de la ejecución.

• Cuando la tratamos como hipótesis, primero preguntamos “¿por qué creemos que esta solución va a producir el cambio que esperamos?”. Estamos en terreno de la decisión.

• Cuando le agregamos métricas, definimos hacia dónde va la solución y qué resultado esperamos conseguir a nivel producto y negocio con el cambio en la experiencia. Estamos en terreno de impacto.

Por eso, transformar pedidos en hipótesis y métricas cambia el lugar desde el que participa Diseño: deja de discutir solamente la solución y empieza a participar en la calidad de la decisión y en el resultado que se espera producir.

La cadena de impacto

Pasar de requerimientos a hipótesis, y de hipótesis a métricas, es pasar de ejecutar soluciones a discutir decisiones y resultados. Pero entre una decisión de Diseño y un resultado de negocio no hay un salto directo. Hay una cadena.

Una decisión de Diseño modifica algo en la experiencia → Esperamos que ese cambio produzca un cambio en el comportamiento de las personas → Ese comportamiento impacta en algún resultado de producto y, eventualmente, → en un resultado de negocio.

Experiencia → comportamiento → producto → negocio

La cadena de impacto permite hacer explícita la relación entre una decisión de Diseño y los resultados que esperamos producir, haciendo explícito qué esperamos que cambie en cada nivel y cómo se conecta ese cambio con el siguiente.

Por ejemplo:

Simplificar el proceso de alta de cuentas
→ Experiencia: menos pasos / menor esfuerzo / menor fricción
→ Comportamiento: más personas dan de alta una cuenta
→ Producto: aumenta la tasa de finalización/activación
→ Negocio: aumentan la cantidad de clientes (activos) / ingresos esperados. (métrica de Negocio)

 

 

Pero cuidado con dos cosas:

• esta cadena no describe una causalidad garantizada, solamente hace explícitas las relaciones causales que estamos suponiendo. Cada flecha contiene una nueva hipótesis: mejorar la experiencia no garantiza que cambie el comportamiento; cambiar el comportamiento no garantiza que mejore una métrica de producto; y mejorar una métrica de producto no siempre produce un resultado de negocio. Por eso necesitamos medir.
• Cuando agregamos métricas, hacemos explícito qué resultado esperamos producir con esa solución y cómo vamos a observarlo, pero no estamos diciendo en cuánto creemos que vamos a mejorar ese resultado.

Entender la cadena de impacto cambia la conversación

Entendiendo la cadena de impacto, podemos pasar de hablar de los pedidos en términos de experiencia

“Creemos que, si hacemos esta funcionalidad, el usuario podrá cumplir su objetivo.”

Y expresarlos en términos de producto, métricas e impacto:

“Creemos que, si hacemos esta funcionalidad/mejora/cambio, cambiará determinado comportamiento, y ese cambio se verá reflejado en esta/s métrica/s.”

Entender la cadena de impacto cambia la conversación. Ya no hablamos solamente acerca de la solución y la experiencia (ejecución), sino del cambio que esperamos producir y cómo ese impacto se conecta con resultados de producto y negocio (resultados).

Cambiar la conversación de Diseño a resultados significa conectar la experiencia con el comportamiento que esperamos cambiar, los resultados de producto que buscamos mover y el impacto de negocio al que queremos contribuir. Y en ese camino, la cadena de impacto es una herramienta fundamental.