Hay algo profundamente reconfortante en hacer que un botón sea más grande, mejorar el contraste de un texto o reducir el número de pasos en un formulario. El trabajo es visible, medible, entregable. Los tests A/B lo validan. El equipo lo celebra. Y sin embargo, el producto sigue sin despegar.
Esta es la trampa más común en UX hoy: confundir usabilidad con valor. Los equipos se vuelven extraordinariamente buenos en optimizar la experiencia de algo que el usuario no necesita, no entiende o no confía suficiente para usar. El producto es cada vez más pulido. Y cada vez más irrelevante.
La señal más clara de que estás en este bucle es cuando las métricas de UX mejoran pero las de negocio no se mueven. Completion rate del onboarding: arriba. Retención a 30 días: plana. NPS: estancado. Algo no cuadra, y casi nunca la solución está en otra ronda de tests de usabilidad.
- La mayoría de los equipos optimizan la capa visible del producto, no el problema de fondo que ese producto intenta resolver.
- Los productos inteligentes —con IA, con personalización, con lógica adaptativa— son más difíciles de entender por el usuario, no más fáciles, aunque la interfaz sea impecable.
- Saber qué mejorar requiere primero saber qué trabajo concreto está intentando hacer el usuario: y ahí es donde la mayoría de los procesos de UX se quedan cortos.
El problema: Optimización sin diagnóstico
Imagina que tienes una tubería con una fuga importante en el sótano. Alguien llega, lija y pinta las paredes del baño, cambia los grifos y pone baldosas nuevas. El trabajo es real, el resultado es bonito, pero el agua sigue corriendo por donde no debe. Esto es lo que ocurre en la mayoría de los ciclos de mejora de UX.
El problema de raíz casi siempre es el mismo: los equipos de diseño se alimentan de datos de comportamiento —dónde hace clic la gente, dónde abandona, cuánto tarda— sin preguntarse por qué. El análisis de comportamiento es necesario pero insuficiente. Te dice qué pasa. No te dice por qué pasa ni, sobre todo, qué debería pasar en su lugar.
El resultado es un proceso que va siempre de síntoma en síntoma. Se rediseña el flujo de onboarding porque los usuarios abandonan en el paso 3. Se rediseña el menú porque hay confusión en la navegación. Se simplifica el formulario de alta porque tiene mucho abandono. Cada intervención está localmente justificada. El problema es que ninguna ataca la causa: el producto no está haciendo el trabajo que el usuario necesita que haga.
No hay mejora de UX suficientemente buena para un producto que resuelve el problema equivocado.
Cuando la IA añade inteligencia pero resta claridad
Este problema se ha agudizado con la proliferación de funcionalidades de IA en productos digitales. Los equipos añaden recomendaciones personalizadas, autocompletados predictivos, resúmenes generados, sugerencias contextuales. La interfaz es más capaz. Y, paradójicamente, más difícil de entender.
El usuario ya no sabe qué esperar del sistema. No entiende por qué le recomienda lo que le recomienda. No sabe si puede confiar en la sugerencia o si debería revisarla. El diseño puede ser impecable —tipografía, espaciado, jerarquía visual— y aun así generar ansiedad de uso porque el modelo mental del usuario y el comportamiento real del producto no coinciden. Ya escribimos sobre este fenómeno con más detalle cuando analizamos cómo la IA amplifica la ambigüedad en lugar de reducirla.
En este contexto, añadir un tooltip mejor o un skeleton loader más suave no mueve la aguja. El problema no es de polish. Es de comprensión del sistema.
El diagnóstico correcto: empezar por el trabajo, no por la pantalla
Antes de diseñar cualquier mejora, hay una pregunta que casi nunca se hace con suficiente rigor: ¿qué trabajo concreto está intentando hacer el usuario cuando llega a esta parte del producto? No "qué tarea está ejecutando en la interfaz", sino qué progreso real busca en su vida o en su trabajo.
La diferencia no es semántica. Un usuario que llega a la pantalla de informes de una herramienta de análisis no está "consultando datos". Está intentando justificar una decisión ante su responsable, o identificar si hay que cambiar algo antes de que sea demasiado tarde. Eso cambia radicalmente qué información es prioritaria, cómo debe presentarse y qué fricción es aceptable.
Este enfoque —Jobs-to-be-Done aplicado al diagnóstico de UX— no es nuevo, pero se usa mal o se usa poco. Se invoca como marco teórico en la fase de discovery y luego desaparece cuando llega el momento de priorizar mejoras. El backlog de UX se llena de tickets que vienen de heatmaps, no de entender el trabajo del usuario.
Tres preguntas antes de priorizar cualquier mejora de UX
En los proyectos de auditoría de producto que hacemos en Room 714, aplicamos siempre un filtro de tres preguntas antes de validar cualquier propuesta de mejora de experiencia:
1. ¿Esta mejora reduce fricción en el trabajo principal del usuario o en un trabajo periférico? Optimizar la experiencia de configuración de notificaciones cuando los usuarios ni siquiera llegan a usar el core del producto es ruido. La fricción que importa es la que bloquea el trabajo principal.
2. ¿El usuario tiene el modelo mental correcto para beneficiarse de esta mejora? Una funcionalidad rediseñada que el usuario no entiende para qué sirve no mejora nada. El problema previo es de comprensión, no de usabilidad.
3. ¿Hay evidencia de que este punto de fricción es la razón por la que los usuarios no obtienen valor, o simplemente es lo que los datos de comportamiento hacen visible? Los datos de comportamiento tienen un sesgo enorme: muestran lo que pasa donde hay instrumentación. No muestran por qué los usuarios no vuelven.
Estas tres preguntas no sustituyen la investigación, pero actúan como un filtro que impide gastar capital de diseño en mejoras que no moverán nada relevante. De hecho, el problema de optimizar lo incorrecto es primo hermano del patrón que describe el error de diseñar herramientas en lugar de diseñar para objetivos.
La crítica como habilidad central: lo que los equipos de UX ya no practican
Hay una habilidad que se está perdiendo en los equipos de diseño a medida que las herramientas —y ahora la IA— hacen el trabajo de generación más rápido y más fácil: la crítica estructurada.
Diseñar bien nunca fue solo producir pantallas. Fue siempre evaluar, descartar, cuestionar. Preguntarse si lo que se está construyendo resuelve lo que hay que resolver. Pero en la cadencia actual de muchos equipos —sprints cortos, presión de entrega, demos semanales— la crítica se ha reducido a una revisión estética en Figma y a una sesión de tests de usabilidad que valida que la gente puede completar el flujo. Que puedan completarlo no significa que les importe completarlo.
Un test de usabilidad mide si el usuario puede hacer algo. No mide si ese algo merece hacerse.
La crítica real —la que pregunta si el producto está resolviendo el problema correcto para la persona correcta en el momento correcto— requiere tiempo, contexto y, sobre todo, voluntad de frenar cuando el equipo tiene inercia de entrega. Es incómoda. Y por eso casi nunca ocurre.
El rol de la IA en este problema: acelerador de lo equivocado
Las herramientas de generación de interfaces con IA —y los flujos de "vibe design" que están emergiendo— amplifican este problema en lugar de resolverlo. Generan variantes a una velocidad que hace imposible la reflexión. El equipo se vuelve increíblemente productivo produciendo cosas que nadie ha validado que valgan la pena.
La IA es un acelerador neutro: acelera lo que ya estás haciendo. Si lo que estás haciendo es optimizar sin diagnosticar, la IA lo hará más rápido. Si tienes criterios de evaluación claros —qué trabajo resuelves, qué modelo mental necesita el usuario, qué fricción es crítica— la IA puede ser un aliado para generar y contrastar opciones. Pero el criterio tiene que venir de antes.
Este es el argumento central del post de Nielsen Norman Group sobre la crítica como habilidad nuclear en la era de la IA: no se trata de producir más rápido, sino de evaluar mejor. Y evaluar requiere haber definido antes qué significa "mejor" para tu usuario específico. Algo que, sin el diagnóstico correcto del trabajo del usuario, es imposible.
Cómo salir del bucle: un cambio de jerarquía, no de herramientas
La solución no está en nuevas metodologías ni en sumar más investigación al proceso. Está en cambiar la jerarquía de lo que se optimiza primero.
La mayoría de los equipos operan con una jerarquía implícita que va de lo visible a lo invisible: primero lo que los datos muestran (flujos, pantallas, componentes), luego lo que los usuarios dicen en los tests, y casi nunca lo que los usuarios realmente necesitan lograr. La jerarquía correcta es la inversa: empieza por el trabajo, baja a la comprensión del modelo mental, y solo entonces entra en la optimización de la interfaz.
Esto tiene consecuencias prácticas inmediatas:
- Las métricas de UX que importan son las que miden progreso en el trabajo del usuario (¿llegó a la decisión que necesitaba tomar?, ¿resolvió el problema que trajo al producto?), no solo eficiencia de flujo.
- La investigación de usuarios tiene que incluir conversaciones sobre el contexto del trabajo, no solo tests de tareas sobre la interfaz actual.
- La priorización del backlog de diseño necesita un filtro explícito: ¿esto afecta al trabajo principal o es mejora de confort?
No es un cambio trivial, especialmente en organizaciones donde UX reporta a producto y producto reporta a métricas de uso. Pero es el único cambio que corta el ciclo de mejorar lo que no importa. Y es perfectamente compatible con aplicar economía del comportamiento al diseño: entender cómo toma decisiones el usuario antes de decidir qué optimizar para él.
Si tu equipo está en ese bucle —métricas de UX que suben mientras las de negocio se quedan planas— puede ser el momento de hacer un diagnóstico de producto desde el trabajo del usuario, no desde el backlog de mejoras. En Room 714 hacemos exactamente esa auditoría: identificar qué trabajo no se está resolviendo bien antes de proponer ninguna pantalla nueva. Porque a veces la mejor mejora de UX es darse cuenta de que el problema no está en la UX.
