El concepto de “Deuda de UX” es un derivado de la “Deuda técnica” acuñada por Ward Cunningham y sigue los mismos principios que una deuda financiera: por cada peso que pedimos prestado, hay un cierto interés que corre, y cuanto más tiempo tardamos en devolverlo, mayor será el monto a devolver.
Pero tomar deuda no siempre es malo. De hecho pedir prestado, o incluso comprar en cuotas, nos permite acelerar tiempos y hacer cosas que sin los recursos que aporta el préstamo no hubiéramos podido hacer.
El problema está cuando vamos tomando deuda periódicamente y sin control, porque cuando finalmente llega el momento de pagar la deuda, ésta se volvió tan costosa que los recursos necesarios para pagarla (tiempo, presupuesto, recursos) es muy alto, o incluso a veces, es necesario rehacer el producto (refactorear todo el código, rediseñar la aplicación), con todo lo que esto significa para el producto, para la empresa y para el usuario.
Dicho de otra forma, la deuda de UX es la brecha que hay entre la experiencia que estamos diseñando y la experiencia que deseamos generar. Cuanto más dejamos para mañana lo que podemos hacer hoy, más deuda estamos generando.
- Tratemos de pedir un monto que sabemos que vamos a poder devolver
- Que el tiempo del préstamo sea lo más corto posible
- Que finalmente paguemos la deuda
¿Cómo se gesta la deuda de UX?
Siguiendo la explicación de Ward Cunningham: “aquéllos problemas internos que decidimos no solucionar ahora, son los mismos que en un futuro nos van a impedir seguir con el desarrollo”. Tanto la deuda técnica como la deuda de UX crean un círculo vicioso que es difícil de cortar:
- Los equipos de desarrollo usan atajos inintencionalmente o involuntariamente. Por ejemplo, no comentar el código (deuda técnica) o no definir un manual de estilo (deuda de UX).
- Cuando se deja sin tratar, estos atajos (deuda) se acumulan y se hace cada vez más difícil y poco práctico arreglarlo (pagar la deuda).
- Finalmente, la deuda engendra más deuda y el producto se degrada en una experiencia de usuario poco amigable, incoherente, e inutilizable (código difícil de modificar, interfaz difícil de volver consistente).
El problema con la deuda de UX es que es invisible, porque a diferencia de la deuda técnica, que se hace inmediatamente visible cuando el código se rompe, la deuda de UX se hace evidente con el tiempo, cuando la navegación empieza a hacerse difícil y el contenido clave empieza a quedar oculto. También puede salir a la luz cuando no podemos agregar nuevos componentes, o cuando la interfaz empieza a quedar tan inconsistente que los usuarios empiezan a confundirse y la conversión se ve afectada.
¿Cómo sabemos que estamos generando deuda de UX?
Cuando pasan o nos decimos algunas de estas cosas estamos empezando a generar una deuda de UX:
- “Lo arreglo después” – sin definir ese “después” en el backlog
- “Lo mejoramos en la versión 2”
- “No tenemos tiempo”
- “No tenemos recursos”
Tipos de Deuda de UX
La deuda de UX puede ser intencional o accidental.
- La deuda de UX intencional es el resultado de las decisiones tomadas en base a restricciones del proyecto: no hay tiempo, no hay suficientes diseñadores, no hay presupuesto para testear.
- La deuda de UX accidental se crea a partir de asunciones incorrectas acerca de los usuarios, o cuando ocurren cambios en las expectativas, necesidades o hábitos de uso a través del tiempo. La deuda de UX accidental aumenta exponencialmente con el tiempo.
Esta presentación de Andrew Right tiene un excelente ejemplo de cómo se contraen ambos tipos de deuda. En este artículo está el texto que forma la base de esa presentación.
Métodos para gestionar la deuda de UX
La utilización de metodologías ágiles es una buena forma de gestionar la deuda de UX por el trabajo en sprints que plantea, tanto para la deuda intencional como para la deuda accidental.
Así, la deuda intencional de UX que tomamos en un sprint, podemos repagarla en el sprint siguiente o ponerla en el backlog para que no se pierda en la nebulosa de las ideas.
Y dado que el proceso “Build – Measure – Learn” que plantea esta metodología propone un contacto continuo con el usuario, la deuda accidental se va mitigando. Cambios en los hábitos de uso o expectativas de los clientes respecto del producto, se van chequeando permanentemente y se incorporan al proceso de diseño y desarrollo.
