Un modal de confirmación aparece en pantalla. El usuario hace clic en "Eliminar cuenta" sin querer. Catorce veces lo hacen antes de que alguien se dé cuenta. El código funciona exactamente como fue escrito. Los tests pasan. El diseñador aprobó el componente. El ticket se cerró como "Done".
Este es el tipo de fallo que más daño hace y que menos aparece en los informes de calidad: la experiencia rota que ningún sistema de revisión estaba diseñado para detectar. No es un bug. Es algo peor: es una decisión que nadie cuestionó porque era técnicamente correcta.
La pregunta que debería perseguir a cualquier equipo de producto no es "¿funciona?" sino "¿qué siente el usuario cuando lo usa?". Y esa pregunta, incómoda y difícil de operacionalizar, es la que más se evita.
El código puede ser impecable y la experiencia puede ser destructiva para el usuario.
Los tickets describen comportamientos, no emociones ni consecuencias.
La calidad de experiencia no se valida en el sprint review: se valida en el mundo real.
El Ticket: Una Herramienta que Mide lo que Puede, no lo que Importa
Los sistemas de gestión de tareas —Jira, Linear, GitHub Issues, lo que uses— son herramientas extraordinarias para rastrear comportamientos esperados. "El botón debe enviar el formulario cuando el campo está relleno". "La animación debe durar 200ms". "El estado de error debe mostrar el mensaje correcto". Todo eso es verificable, automatizable, cerrable.
Pero hay una categoría entera de problemas que estos sistemas no pueden formular. No porque sean malos sistemas, sino porque su modelo mental es el de la ingeniería: correcto vs. incorrecto, pasa vs. falla. La experiencia de usuario opera en una dimensión diferente: confianza, ansiedad, fricción percibida, sensación de control. Nada de eso entra en un campo de descripción de ticket.
El resultado es una asimetría peligrosa. Los equipos se vuelven muy buenos resolviendo los problemas que pueden articular y sistemáticamente ciegos a los que no. Un flujo de onboarding puede pasar todas las revisiones de QA, cumplir con las guías de diseño, no tener ningún error de consola y aun así generar una tasa de abandono del 60% porque en algún punto el usuario siente que algo no encaja, que no está seguro de qué va a pasar si continúa, que la promesa del producto no cuadra con lo que tiene delante.
Un ticket describe lo que hace el producto. La experiencia es lo que el usuario siente mientras lo hace. Confundir ambas cosas es el origen de productos que "funcionan" pero que nadie quiere usar.
Esto conecta directamente con algo que mencionamos cuando hablamos de UX improvements that optimize the wrong thing: el equipo puede estar midiendo y mejorando las métricas equivocadas mientras la experiencia real se deteriora sin que nadie lo vea.
Fricción Invisible: Los Tres Lugares donde la Experiencia se Rompe sin Romperse
Si tuviéramos que señalar dónde aparecen más frecuentemente estos fallos silenciosos, hay tres patrones que se repiten con suficiente consistencia como para merecer atención específica.
Acciones destructivas sin peso emocional
El modal de confirmación del que hablábamos al principio es un ejemplo perfecto. Diseñar un diálogo de confirmación para eliminar una cuenta, borrar datos importantes o cancelar una suscripción no es solo un problema de componentes: es un problema de diseño de consecuencias. ¿Cuánta fricción es la apropiada? ¿Qué lenguaje transmite la gravedad de la acción sin ser paternalista? ¿Dónde va el botón destructivo para reducir clics accidentales sin esconderlo tanto que frustre al usuario que sí quiere eliminar?
Estas preguntas no tienen respuesta en una guía de estilo. Tienen respuesta en el comportamiento real de usuarios reales. Y sin ese dato, el equipo tiende a resolver el problema técnico (el modal aparece, el botón funciona) e ignorar el problema experiencial (la acción no tiene el peso que debería tener).
Estados intermedios que no comunican nada
Carga. Procesando. Guardando. La pantalla en blanco que dura dos segundos entre una acción y su resultado. Estos estados intermedios son donde más se pierde la confianza del usuario, y son también los que menos atención reciben en el diseño. El ticket dice "mostrar spinner durante la carga". El spinner aparece. Ticket cerrado.
Pero hay preguntas que el ticket no hace: ¿el usuario sabe qué está pasando exactamente? ¿Sabe cuánto va a tardar? ¿Sabe que su acción fue registrada y que el sistema está respondiendo, no colgado? Los estados de carga mal diseñados generan una cantidad desproporcionada de ansiedad y soporte innecesario. No porque fallen: porque no comunican.
Flujos que asumen contexto que el usuario no tiene
Este es quizás el más difícil de detectar desde dentro. El equipo conoce el producto tan bien que asume que ciertas cosas son obvias. El usuario llega sin ese contexto y en algún punto del flujo se encuentra ante una decisión que no sabe cómo tomar. No porque la interfaz sea incorrecta: porque no tiene la información necesaria para avanzar con confianza.
Los flujos de configuración inicial, los procesos de integración con otros servicios, las pantallas de permisos: todos son lugares donde este problema aparece de forma recurrente. El código es correcto. El diseño es limpio. El usuario está paralizado.
QA Experiencial: Qué Significa Probar lo que no se puede Automatizar
El problema está identificado. La pregunta práctica es: ¿cómo lo atrapas antes de que llegue a producción?
No hay una respuesta única, pero sí hay prácticas concretas que los equipos que hacen esto bien tienen en común. La primera es la más contraintuitiva: aceptar que parte de la calidad experiencial solo se valida con personas reales, y construir el proceso en consecuencia. Eso no significa pruebas de usabilidad elaboradas para cada feature —eso sería paralizar el ritmo de entrega—. Significa tener mecanismos ligeros y regulares de observación real.
Cinco usuarios viendo un flujo nuevo antes de lanzarlo no es investigación rigurosa. Es suficiente para detectar los problemas gordos. Los problemas que hacen que catorce personas eliminen su cuenta sin querer.
El protocolo de las tres preguntas antes de cerrar un ticket
Una práctica que recomendamos en las auditorías de producto es añadir tres preguntas al criterio de aceptación de cualquier feature que afecte a un flujo crítico del usuario:
¿Qué está sintiendo el usuario en cada paso de este flujo? No qué está haciendo: qué está sintiendo. Confianza, duda, urgencia, confusión. Si el equipo no puede responder esto, es una señal de que el flujo no se ha diseñado con suficiente resolución emocional.
¿Qué pasa si el usuario comete el error más probable? Identificar cuál es el error más probable en ese flujo y diseñar explícitamente qué ocurre. No como caso de error técnico, sino como experiencia de recuperación: ¿el usuario sabe qué salió mal? ¿Sabe cómo volver al buen camino?
¿Qué información necesita el usuario que no le estamos dando? Revisar el flujo desde el punto de vista de alguien que llega sin contexto. ¿Hay decisiones que se le piden sin que tenga los elementos para tomarlas? ¿Hay pasos donde el estado del sistema es opaco?
Estas tres preguntas no reemplazan la investigación de usuario —algo sobre lo que ya hemos escrito con detalle—, pero sí elevan el listón de lo que un equipo considera "terminado".
El Problema de Raíz: Cuando el Producto se Optimiza para el Sprint, no para el Usuario
Hay un mecanismo sistémico detrás de todo esto que vale la pena nombrar. Los equipos de producto trabajan bajo presión de entrega. El sprint tiene fecha. Los tickets tienen criterios de aceptación. El éxito se mide en features desplegadas, en velocidad, en cobertura de test. Toda la maquinaria de gestión apunta hacia una definición de calidad que es técnica y cuantificable.
La experiencia del usuario, en cambio, es cualitativa, acumulativa y difícil de atribuir a una tarea concreta. Nadie cierra un ticket que diga "el usuario siente que el producto es fiable". Pero esa sensación de fiabilidad —o su ausencia— es exactamente lo que determina si alguien sigue usando el producto o no.
Lo que ocurre es una optimización inadvertida hacia lo medible. Y lo medible, en la mayoría de los equipos, no incluye "cómo se sintió el usuario al usar esto". El resultado, con el tiempo, es un producto que acumula deuda experiencial de la misma forma que acumula deuda técnica: silenciosamente, hasta que el coste de devolverla es mayor de lo que el equipo puede permitirse.
La deuda técnica aparece en los logs. La deuda experiencial aparece en el churn. Y cuando aparece en el churn, ya es tarde para tratarla como un problema de diseño.
Este problema es especialmente agudo cuando hay herramientas de generación de código o diseño en el flujo —IA o no—, porque estas herramientas son muy buenas resolviendo lo que se les pide y completamente ciegas a lo que no se les pregunta. El código generado puede ser técnicamente impecable y experiencialmente vacío, porque nadie le preguntó "¿qué debe sentir el usuario aquí?". Como ya exploramos en el post sobre features de IA que nadie pidió, el problema no está en la herramienta: está en quién define qué se construye y con qué criterios de calidad.
La solución no es ralentizar ni añadir capas de proceso. Es ampliar la definición de "terminado". Un flujo está terminado cuando funciona técnicamente y cuando hemos verificado, aunque sea de forma ligera, que no destruye confianza, que no genera confusión en los puntos críticos y que las acciones con consecuencias tienen el peso que merecen.
Eso no requiere un equipo más grande. Requiere una forma de pensar diferente sobre qué significa que algo esté bien hecho.
Si en tu equipo los tickets se cierran como "Done" y el churn sigue siendo un misterio, probablemente estás midiendo la mitad de lo que importa. En Room 714 hacemos auditorías de producto que empiezan exactamente aquí: no en si el código funciona, sino en si la experiencia está construida para generar confianza o para erosionarla. La conversación, si te interesa, es corta.
