Tu diseño hizo que abandonaran

En pocas palabras: La indefensión aprendida aparece cuando los usuarios encuentran fallo tras fallo sin un camino claro para avanzar. Si el esfuerzo sigue sin llevar a ninguna parte, dejan de intentarlo, aunque todavía quieran el resultado.

Cuando los usuarios abandonan un producto, los diseñadores suelen recurrir a la misma explicación: simplemente no estaban suficientemente motivados. Encontraron un obstáculo y se rindieron. Si de verdad les hubiera importado el resultado, habrían insistido. El producto solo filtró a quienes no iban en serio.

Esa explicación exime al diseño de toda responsabilidad. Convierte un fallo de diseño en algo de lo que se culpa al usuario. Después los equipos siguen construyendo las mismas experiencias que no funcionan y culpando a quienes no pudieron completarlas. He oído versiones de eso en equipos de producto más de una vez.

El 1 de octubre de 2013, millones de estadounidenses intentaron usar HealthCare.gov para contratar un seguro médico. No eran visitantes que pasaban por allí por simple curiosidad. Muchos necesitaban cobertura. Algunos llevaban años sin seguro. La motivación era real.

Cuatro millones de personas visitaron el sitio ese primer día. Al llegar la noche, seis se habían inscrito. Todos los demás encontraron errores, tiempos de espera agotados, procesos de creación de cuentas rotos y mensajes que no explicaban nada. Después abandonaron por completo. Una cifra así debería poner nervioso a cualquier diseñador.

La pregunta real es por qué personas con una necesidad genuina se fueron. El sitio falló, pero eso por sí solo no explica por qué dejaron de intentarlo quienes lo necesitaban.

No era falta de motivación. Era lo que hacen los fallos repetidos cuando la gente no ve una salida.

La pasividad ante las descargas no se aprende. Es la respuesta predeterminada.

— Steven Maier & Martin Seligman · Traducción del inglés

Por qué la gente deja de intentarlo

En 1967, Martin Seligman y Steven Maier realizaban en la Universidad de Pensilvania experimentos destinados a estudiar el condicionamiento del miedo en perros. Los colocaban en arneses y les administraban descargas eléctricas leves. Después los trasladaban a una caja donde saltar una barrera baja detenía las descargas. La mayoría lo descubría rápido. Pero los perros que habían recibido descargas inevitables en el arnés, sin forma de detenerlas, en su mayoría se tumbaban y esperaban a que terminara el dolor. Podían escapar. No lo intentaban.

Seligman y Maier lo llamaron indefensión aprendida. Los perros habían aprendido, mediante exposición repetida a resultados que no controlaban, que nada de lo que hicieran cambiaba nada. Esa lección pasaba al entorno siguiente, aunque ahora escapar fuera posible.

Casi cincuenta años después, los mismos investigadores volvieron al trabajo con mejores herramientas y encontraron algo importante. Su artículo de 2016 en Psychological Review concluyó que la pasividad observada no era aprendida en absoluto. «La pasividad ante las descargas no se aprende. Es la respuesta predeterminada, no aprendida, ante acontecimientos aversivos prolongados» (traducción del inglés). En otras palabras, dejar de actuar resulta fácil. Lo que hay que aprender, mediante acciones exitosas, es que el esfuerzo todavía puede cambiar el resultado.

La rendición se extiende

Eso importa en el trabajo de producto. Cada vez que un usuario encuentra un error que no entiende, un flujo que muere sin siguiente paso o un formulario que rechaza datos sin decir por qué, dedica esfuerzo y no llega a ninguna parte. Un mal momento no basta por sí solo. Pero se acumulan. Donald Hiroto y Martin Seligman mostraron en 1975 que este hábito de rendirse puede pasar de una situación a otra.

El efecto no queda ligado al primer mal momento. He visto ese bloqueo extenderse por un flujo malo en minutos, sobre todo cuando los usuarios empiezan a asumir que el siguiente paso también fallará.

Para un producto, esto significa que un proceso de bienvenida roto no solo te cuesta esa sesión. Enseña a los usuarios a esperar problemas también la próxima vez.

Seis personas lo consiguieron

Las cifras de HealthCare.gov son difíciles de ignorar. Cuatro millones de personas ese día, seis procesos completados. El sitio devolvía errores durante la creación de cuentas, superaba los tiempos de espera por la carga de tráfico y ofrecía mensajes tan vagos que los usuarios no podían saber si el problema era suyo o del Gobierno.

Los errores no eran todo el problema. Los errores ocurren. El daño real venía del callejón sin salida después de cada uno. Un mensaje que dice que algo falló, sin pistas sobre qué ocurrió, sin indicar si esperar, reintentar o llamar a un número, y sin ningún camino para avanzar, no es neutro.

Deja al usuario atascado. Lo intentó. El resultado fue malo. Nada de lo que hizo lo cambió. Cada vuelta de ese patrón lo acercaba más al estado predeterminado: dejar de intentarlo. Al cabo de un tiempo, deja de esperar que el próximo intento salga mejor.

Comprueba el primer momento que falla

La mayoría de los diseñadores dedica más tiempo a pensar en lo que ocurre cuando todo funciona. Diseña con cuidado el camino sin errores y deja los estados de fallo para después. Debería ser al revés. En los estados de fallo la gente decide si sigue o empieza a rendirse. Un error de formulario sin salida en el tercer paso puede borrar todo el trabajo de los pasos uno y dos. Esos momentos parecen menores hasta que los usuarios los encuentran.

Antes de lanzar cualquier flujo para usuarios, haz la Prueba del Primer Fallo. Recorre el flujo y provoca todos los estados de fallo que encuentres. Para cada uno, haz una sola pregunta: ¿tiene el usuario una acción concreta que pueda realizar ahora mismo? No un reconocimiento vago del problema. No una disculpa. Un siguiente paso real que pueda dar. En la práctica, aquí se desmoronan muchos flujos.

Esto detecta más fallos de diseño de los que la mayoría de los equipos quiere admitir.

«Algo salió mal» no es una acción. «Inténtalo más tarde» no es una acción. «Contacta con soporte» sin enlace directo ni número no es una acción. He visto a productos esconderse durante años detrás de frases así. Esos mensajes colocan al usuario en la situación que produce indefensión: un mal resultado y ninguna acción que permita cambiarlo.

Lo que ayuda no es un flujo perfecto sin fallos. Lo que ayuda es el control. La investigación de Seligman mostró que incluso en situaciones donde no se podían evitar resultados negativos, las personas que conservaban una sensación de capacidad de acción sobre sus respuestas no desarrollaban indefensión del mismo modo. Un mensaje que dice «Tu sesión ha caducado. Haz clic aquí para continuar donde lo dejaste» no es solo mejor texto. Da al usuario un paso concreto que puede dar.

Haz esta prueba antes de lanzar. Hazla en cada estado al que pueda llegar tu producto. La pregunta sigue siendo sencilla: ¿tiene el usuario adónde ir desde aquí? Si no, estás construyendo un producto que enseña a rendirse.

Si la gente sigue abandonando, el diseño es parte del problema.