La brecha lingüística como falla estructural
Nielsen Norman Group lo formula sin rodeos: los equipos de UX rara vez pierden conversaciones de presupuesto porque su trabajo carezca de valor, sino porque reportan de forma inadecuada [3]. La falla es precisa: UX comunica en términos de actividad y métricas de usabilidad; los ejecutivos senior operan en términos de ingresos, costes, riesgo, velocidad y retención. Reportar tests de usabilidad y citas de usuarios sin traducir ese trabajo a impacto de negocio es el error estructural central que convierte a UX en un centro de coste recortable.
El mismo patrón se replica en la relación con producto. Los hallazgos de investigación son reconocidos superficialmente por los gestores de producto y luego archivados sin traducirse en decisiones de roadmap [8]. La causa: los investigadores presentan hallazgos cuando las decisiones ya están parcialmente tomadas, en un lenguaje de comportamiento de usuario que no mapea a las métricas con las que el PM justifica prioridades. No es que la investigación sea irrelevante; es que llega tarde y mal empaquetada.
Medir demasiado tarde es no medir
La lectura que hacemos del problema de baselines es directa: cuando no existen benchmarks previos al inicio de un proyecto, es imposible demostrar mejora [3]. Sin una medición inicial del estado del producto, cualquier afirmación sobre el valor del rediseño es anecdótica. NNg propone institucionalizar el establecimiento de baselines como hábito sistemático previo a cualquier trabajo de diseño o rediseño. No es una recomendación opcional; es la infraestructura mínima para que UX pueda hablar el idioma del negocio con datos, no con esperanzas.
Explicabilidad por rol: una capa de UX que no puede ser genérica
La explicabilidad de IA no es un toggle de encendido y apagado. Distintos roles empresariales aportan objetivos, conocimientos y contextos diferentes, y por tanto la explicabilidad no puede ser de talla única [1]. Un desarrollador necesita trazabilidad del modelo; un administrador de sistemas necesita atribución de fuentes; un experto de dominio necesita explicación de razonamiento y pasos. Diseñar una sola capa de explicabilidad para los tres es diseñar para ninguno.
Trazabilidad para roles técnicos de construcción: capacidad de rastrear decisiones del modelo, verificar inputs y outputs, depurar fallos. El valor de negocio es reducir tiempo de resolución de incidencias y costes de mantenimiento [Fuente 1].
Explicación de razonamiento para expertos de dominio: descripción comprensible del proceso por el que el sistema llegó a una conclusión. El valor de negocio es la confianza operativa — si el experto no entiende por qué la IA recomienda algo, no actuará sobre esa recomendación [1].
El RAS como cierre del circuito
El Recommendation-Adoption Score resuelve un punto ciego crítico: la mayoría de líderes de investigación toman decisiones de inversión basándose en la intuición, en respuesta a demandas urgentes o asignando recursos a quienes los solicitan, sin maximizar el impacto real del equipo [10]. El RAS cuantifica la proporción de valor de recomendaciones que efectivamente llega a los usuarios finales, exponiendo lo que NNg denomina research breakage: la brecha entre el valor que la investigación genera y el que se concreta en el producto.
3 categorías — Clasificación de recomendaciones en el RAS: adoptadas (valor completo), comprometidas (progreso parcial), comunicadas pero no implementadas (valor potencial no realizado) ([10])
El diseñador de IA como crítico, no como especificador
En sistemas probabilísticos, el diseñador ya no puede especificar cada caso posible [7]. El modelo toma decisiones de diseño —qué incluir, cómo formularlo— y la competencia clave pasa a ser la crítica: articular criterios de evaluación que codifiquen el entendimiento de las necesidades del usuario y los estándares de calidad de la respuesta [7]. Este cambio refuerza la necesidad de que el reporte UX no se centre en lo que el diseñador hizo (escribir prompts, crear flujos), sino en los criterios de evaluación que definió y en el grado en que el sistema los cumple frente a baselines previos.
La posición que defendemos es concreta: un equipo de UX que trabaja en productos con IA necesita, como mínimo, tres prácticas integradas para dejar de ser tratado como centro de coste. Primera, establecer baselines antes de cualquier intervención de diseño [3]. Segunda, diferenciar la explicabilidad del sistema por rol del usuario, porque la confianza operativa se construye rol por rol, no con una explicación genérica [1]. Tercera, medir retroactivamente la adopción de recomendaciones con algo como el RAS, para diagnosticar dónde se pierde valor entre lo investigado y lo implementado [10]. Sin estas tres piezas, el equipo de UX produce conocimiento que se evapora entre la presentación de hallazgos y la siguiente reunión de roadmap.
Fuentes consultadas
- Explicabilidad de IA en entornos empresariales: diferenciación por rol. ver
- Diseño de agentes IA para usuarios: lecciones de estudios de usabilidad. ver
- Reporte de UX orientado a resultados de negocio: métricas y baselines. ver
- Vibe architects: usuarios no técnicos como constructores de sistemas IA agénticos. ver
- Arquitectura de contexto: principios de arquitectura de información aplicados a sistemas IA. ver
- Economía conductual aplicada al diseño UX: fricción, motivación y brecha intención-acción. ver
- Crítica de diseño como competencia central en sistemas IA: de especificaciones deterministas a criterios de evaluación. ver
- Integración de recomendaciones de investigación en el roadmap de producto. ver
- Taxonomía de los cuatro tipos de trabajo de diseño con IA. ver
- Recommendation-Adoption Score (RAS): medición de impacto y asignación de recursos en investigación UX. ver