Deuda UX: Identificar las causas y una herramienta para resolverlo

En las entregas anteriores conocimos ¿qué es la deuda técnica?, desde el origen en el ecosistema de desarrollo y ¿qué es la deuda UX?, respecto al producto diseñado, no llega con la calidad esperada al salir al público; sin embargo, ahora tenemos que poner manos a la obra e identificar cuándo empezamos a deber durante un proyecto y que planes de acción tenemos que hacer para resolverlo.

Para comenzar, tengamos la reflexión y comprensión de las causas, que seguirán pasando, sin embargo, el tener el conocimiento, nos permitirá gestionar mejor los recursos y pagar la deuda.

Frases que permiten detectar la deuda

Cada sprint, que se desarrolla o en las pruebas de calidad del software como es el testing o en plena demo en el review, lo que se detecta de imperfecciones, se toman las siguientes decisiones:

“Lo mejoramos en la fase 2.”

“Lo resolveremos en la siguiente versión”.

“No tenemos tiempo”.

“No tenemos recursos suficientes”.

“Lo arreglamos después – olvidando definir ese “más tarde” en el backlog”.

¿Te suena familiar?, ahí es cuando aparece la deuda.

Las métricas que impactan en la deuda UX

Las siguientes métricas son algunas que impactan directamente en el cumplimiento de sus necesidades, reacción y percepción de nuestros usuarios, las cuales es importante monitorear lo mejor posible. La siguiente lista son las relevantes, pero puede existir más, solamente detecta que esas métricas las obtienes de tus usuarios (Heurísticas o métodos a nivel de experto no cuentan, más no se deben ignorar).

Causas de la deuda técnica

Existen muchos motivos por los que vamos subiendo nuestro contador de deuda técnica, muchos de ellos por temas de negocio, ya que vivimos en una sociedad que evoluciona con gran velocidad y básicamente todo se necesita para ayer. Vamos a conocer algunas causas principales que pueden aumentar la deuda técnica.

• Presiones del negocio: En general todo debe ser lanzado cuanto antes y muchas veces se sacan cosas a producción sin haber pasado un buen control de calidad y con cambios rápidos que no contemplan todas las posibilidades o no totalmente completos.
• Cambios en la especificación: Es común que las especificaciones también a mitad del desarrollo e incluso en el último momento. Este tipo de cambios generalmente se incluyen en el proyecto con soluciones pobres o como se dice comúnmente con calzador. En general, no hay tiempo o presupuesto para hacer las comprobaciones adecuadas para este tipo de cambios.
• Falta de buenas prácticas: Por ejemplo, se decide no emplear un sistema de integración continua, prescindir de una batería de tests, no invertir tiempo en re-factorizar, no diseñar una buena arquitectura con componentes muy aplicados que no se adapten a los cambios [incluya aquí una larga lista de malos hábitos que vea en su empresa].
• Falta de conocimiento: Vivimos en un país en el que muchas empresas prefieren sacar adelante un proyecto adelante, con becarios o gente con poca experiencia que quizás no escriban un código muy elegante. Es importante disponer de buenos recursos con experiencia en desarrollo software (senior) y que este tipo de roles colaboren para enseñar a developers con menos experiencia (junior). En mi humilde opinión, hay que dar oportunidades a la gente joven y apostar por el talento y gente con experiencia.
• Falta de colaboración: A veces se toman malas decisiones por no conocer el negocio en profundidad, sin considerar ciertas implicaciones y por qué la gente de negocio no se involucra lo suficiente en el desarrollo. Para ello aplicar DDD (Domain Driven Design) y seamos un solo equipo.
• En algunos casos se incluyen influyen aspectos como el outsourcing, en el que empresas ponen sus esfuerzos en legar resultado y no en el cuidado del software. Por mi experiencia y lo que he podido ver, estoy a favor de desarrollar el software in-house e intentar externalizar mínimamente, pero eso ya son decisiones de negocio.

Causas de la deuda UX

Si recordamos esta parte del artículo anterior de las causas, “Al igual que la deuda tecnológica, la deuda UX a menudo se incurre cuando los diseñadores e investigadores trabajan bajo plazos ajustados o limitaciones de proyectos poco prácticas”. Otros factores que contribuyen a la deuda UX incluyen:

• Omitir pruebas de usuario.
• Sin tener en cuenta los estándares de branding, las guías de estilo, design system.
• Diseño por comité.
• Malinterpretando la visión del producto.
• Adquirir o fusionarse con otros productos.
• Mala comunicación o documentación.
• Pruebas de control de calidad insuficientes.
• Código heredado o re-factorización retrasada.

La consecuencia de pagar el precio de acumular deudas

¿Por qué es más costoso solucionar un problema de UX más tarde que antes del lanzamiento? Por muchas razones. Primero, el rediseño y la recodificación consumen muchos recursos: el equipo tiene que volver a familiarizarse con los matices y detalles de las funciones ya lanzadas, dedicar tiempo a la depuración de las mismas y, posiblemente, actualizar otras partes del software.

Desde una perspectiva pura de ingeniería de software, codificar la IU correctamente la primera vez es mucho más fácil para los desarrolladores que tener que cambiar el código realizado.

Pero también hay razones de experiencia del usuario para el costo adicional de la deuda UX:

• El lanzamiento de un diseño “parche” o temporal afecta la participación de mercado a largo plazo, porque muchos clientes lo intentarán y luego se rendirán cuando el diseño sea demasiado difícil o no satisfaga sus necesidades. Incluso si soluciona su queja más tarde, los usuarios no lo sabrán, porque no volverán a probar su sitio o producto una vez que hayan tenido una mala experiencia.
• Los usuarios se acostumbrarán al mal diseño. Luego, después de cambiar el diseño, las personas se verán obligadas a cambiar sus hábitos y te odiarán por eso.
• Cambiar el diseño de un componente a otro de la UX general degradará los sentimientos de consistencia y coherencia.
• Tus fallas vivirán para siempre en internet. Como el aprendizaje es social, los usuarios continuarán siendo “informados” durante años de tus pasos en falso por blogs, tableros de mensajes, canales de video y otras fuentes que discuten la versión anterior. Esta información desactualizada no solo será perjudicial en lugar de útil para sus usuarios, sino que también asustará a los nuevos prospectos que se encuentran con descripciones del mal diseño y cualquier solución incómoda que la gente haya descubierto y publicado.

Identificar las clases de deuda UX

La clase de deuda que podemos identificar, puede ser consciente y accidental/ignorada:

• Deuda Consciente causada por las limitaciones del proyecto, falta de información para definición de la solución, por la naturaleza de un proceso ágil (confundir, ágil con rapidez).
• Deuda accidental/ignorada causada por supuestos incorrectos o carencia de información acerca de los usuarios, cuando ocurren cambios en las expectativas, cambio en el contexto, necesidades o hábitos de uso a través del tiempo. La deuda de UX accidental aumenta exponencialmente con el tiempo.

Preparar la herramienta

Antes de utilizar alguna herramienta de gestión Ágil, es bueno entenderlo de manera manual o como bien se dice, “la forma” para poder gestionar la Deuda. Este esquema es presentado en una simple hoja de cálculo que nos permite construir y aprender de ello. Al final de este artículo podrás descargar (Sacar una copia) de la plantilla para resolver la deuda UX.

Antes de comenzar, entendamos este escenario en la cual, ver las gráficas y el registro de incidencias, son al final de un periodo de sprints (mes, trimestre, seis meses, sprints del 1 al N), dependiendo de su organización.

Lo recomendable, es que a medida que se termina un sprint, en las pruebas que hayan faltado y/o se detectaron muy tarde, se registren y en el planning del siguiente sprint, se ataquen, para evitar la acumulación.

Sin embargo, puede darse el caso, que se acumula y no se resuelvan, de todas maneras hay que hacer la contabilidad y marcar todas las incidencias en sus categorías, como Deuda Técnica y UX, reflejando lo planeado vs realidad.

En la siguiente imagen, creamos una pestaña llamada, “Datos”, se realizaron las fórmulas necesarias para la contabilidad, la automatización de las gráficas y priorización de incidencias.

También, la creación de categorías que nos puede ayudar a etiquetar y clasificar las incidencias.

Nota: Existen otras categorías respecto a la gestión de quién la detecto y quién la resolverá, que no estamos incluyendo en este ejemplo para mantenerlo lo más fácil posible.

También la sección de “Dashboard” para poder visualizar mejor la contabilidad.

Una forma de ver esta herramienta, es en fases de gestión, agregamos etiquetas por la parte de arriba en la celda 1, para que puedas identificar, qué columnas están relacionadas con cada fase, que describiremos enseguida:

• Identificación y registro de Deuda.
• Planificación y priorización.
• Deuda pagada (Resueltos).

Registrar la Deuda

Recomendamos que se capture las incidencias detectadas al final de cada sprint, sin embargo, si se tienen registros pasados, por favor vaciarlos y registrarlos como Deuda técnica y UX.

Cuando tenemos este paso listo, podemos revisar en la pestaña “Dashboard” el número de incidencias detectadas, en el caso que son viejos los registros, depositarlos en el sprint detectado (por aquello que no recuerden cuándo se apareció).

En este caso, es de un periodo actual al terminar.

Planeación y priorización

Para poder realizar esta planificación y priorización, es importante que las personas que tienen conocimiento del las necesidades del cliente, desarrollo del producto y negocio, sean los responsables de esta actividad, ellos deben encontrar el balance entre la viabilidad, deseable y factible de cada incidencia, tomando su tiempo de investigación para dar la mejor certidumbre posible.

Dentro del proceso de planeación, hay que priorizar primero por el impacto/al usuario y facilidad de arreglo. Al inicio del siguiente sprint, debe contemplarse para resolverse inmediatamente.

Caso, contrario al final de cada periodo, realicen esta actividad con las incidencias detectadas del periodo y los viejos.

Por lo tanto, podemos visualizar cuantas incidencias planificadas, se resolverán durante el sprint, en este caso los representamos en el área azul y naranja punteada.

La idea es poder, detectar en cada planning, resolver de 2 a 3 incidencias por sprint, pero dado a la capacidad del equipo y recursos, negocien si es posible resolver más, ya que las incidencias reales deban estar por debajo de las planeadas y en menos sprint atacado (zona verde es la realidad).

Realizar el pago

No hay más que decir, solo pagar la deuda y recuperar los clientes perdidos.

Seguimiento en las resueltas

En este punto, podremos ver la comparativa de incidencias planeadas y resueltas, en cuanto a la fecha de reparación de momento lo tenemos como parte del registro. (Solo ocultas las columnas si deseas verlo de esta manera, aunque en la gráfica se ve mejor).

Conclusiones de esta serie de la Deuda UX

• El pago de intereses es muy alto y dejando un historial pésimo para nuestro producto (perder clientes nuevos/retenidos y malas reseñas de nuestro producto, traducido en negocio, pocos beneficios ingresarán) al acumular.
• Las métricas te permitirán tener un semáforo de cómo va mejorando, la deuda es una de tantas variables por las que se mueven, logra tener el mejor monitoreo posible.
• Tener una estrategia clara de UX al desarrollar un producto, aun así, habrá áreas de oportunidad que saldrán, sin embargo, el punto es amortiguar por completo la generación de deuda.
• Cuidar y mantener las incidencias de cada sprint (hablando de entornos de desarrollo ágiles) registro y planear atender inmediatamente.
• No es posible quedarnos sin deuda al desarrollar un producto digital/nueva funcionalidad, sin embargo, es responsable pagarla inmediatamente.
• Todo el equipo tiene la responsabilidad de identificar deudas consientes y accidentales, hablarlo y registrarlo para su pronta resolución. (Eviten culpas y solo dediquen su tiempo en cómo atacarlas).
• No dejes acumular deuda al final de cada periodo de desarrollo (núm. de sprints).

Para la realización de este último artículo parafrasearé y tomé referencias de dos artículos para la comprensión de las causas de la deuda técnica y UX, por su claridad y franqueza sobre el tema:

• “Qué es y como no caer en la deuda técnica” escrito por Adrian Alonso Vega.
• “UX Debt: How to Identify, Prioritize, and Resolve” escrito por Anna Kaley de Norman Nielsen Group.

Finalicemos con una charla

Muy bien, si eres de quienes aprenden de manera audiovisual, entonces aprovecha esta charla que tenemos para cerrar bien este tema. También contamos con la participación de Alice Vielmas – UX Designer & User Researcher – Twiter @alicevielmas

Para los que son más de Podcast

Platica de Deuda UX en UXcamp Europe 2021

Platica de la Deuda UX, con una actualización respecto a la experiencia de cliente que se llega a descartar.

Descargar la plantilla

Te ofrezco la plantilla para tus necesidades y pongas en práctica la gestión de la deuda UX.

Deja tus comentarios y si deseas colaborar en robustecer o mejorarlo, adelante, será un gusto, solo manda un correo solicitando la petición para cuadrar.

Actualizaciones:

2/08/2020 – v1.0

• Creación de la plantilla.
• Gráficas de Incidencias Creadas en los sprints y Incidencias planeadas vs Resueltas.
• Gestión de Datos.

1/06/2021 – Descargar v1.1

• Se crean las gráficas para la deuda técnica y deuda UX
• Se crean los datos para la deuda UX, respecto a los niveles de interacción, viaje del cliente y relación con la empresa.

Recuerda que cada día aprendamos y compartamos conocimiento, con el fin de:

Ser la mejor versión de uno mismo