Hay una creencia que está actuando como acelerante en miles de roadmaps de producto ahora mismo: que los usuarios quieren más IA. Que si no la tienen, se sienten mal servidos. Que el competidor que la integre primero gana. El problema es que esa creencia, en la mayoría de los casos, no tiene ninguna base empírica.
Los usuarios no piden IA. Piden no perder tiempo buscando el archivo que ya han adjuntado tres veces. Piden no tener que repetirle su contexto al agente de soporte de turno. Piden que el formulario no les haga elegir entre 47 opciones en un dropdown cuando solo hay tres que tienen sentido para ellos. La IA puede resolver esas fricciones. O puede ser una capa más que las complique. La diferencia no la decide la tecnología: la decide la intención con la que se diseña.
Lo que vemos con frecuencia en equipos de producto no es mala fe, sino una confusión de orden: se elige la solución (IA) antes de haber definido el problema con precisión. Y cuando la solución llega antes que el diagnóstico, lo que se construye no es un producto más inteligente, sino uno más complicado con mejor marketing.
La IA integrada sin diagnóstico previo genera fricción nueva disfrazada de conveniencia.
La integración real no se nota: el usuario completa su tarea más rápido y no sabe por qué.
El modelo mental del usuario debe ser el punto de partida, no la capacidad técnica disponible.
El problema: Cuando la Feature Busca su Caso de Uso
En UX hay un principio que se enseña en primero pero se olvida en producción: diseñar para los modelos mentales existentes de los usuarios, no para los modelos que a nosotros nos gustaría que tuvieran. Cuando un equipo añade un asistente conversacional a un flujo que el usuario ya resuelve con tres clics, no está mejorando la experiencia. Está añadiendo una decisión más: ¿uso el chat o hago lo de siempre?
Esa fricción de decisión tiene coste. Un coste que no aparece en los dashboards de adoption rate durante las primeras semanas, cuando la novedad todavía actúa como motivación. Aparece a los dos meses, cuando el usuario ha decidido que el asistente no le ahorra tiempo y ha vuelto al flujo antiguo. O peor: cuando ha abandonado la plataforma porque siente que se complica en lugar de simplificarse.
El patrón que se repite es siempre el mismo: el equipo de producto recibe presión para "integrar IA", interpreta esa presión como una instrucción de añadir una interfaz conversacional (porque es lo más visible), y lanza una feature que tecnológicamente funciona pero que nadie usa de forma sostenida. La IA, en ese escenario, no ha fallado. Ha fallado el proceso de diseño que llegó a ella sin preguntarse antes qué trabajo concreto estaba resolviendo.
Una feature de IA que nadie usa no es un problema de adopción. Es un problema de definición. Nadie adoptó algo que no necesitaba.
Ya escribimos sobre esto cuando analizamos por qué el chat no es la respuesta universal a cualquier interfaz de IA: la modalidad importa tanto como la capacidad. Pero la modalidad es consecuencia de entender el contexto del usuario, no del catálogo de capacidades del modelo.
El Diagnóstico: JTBD como Antídoto al Feature Theater
Jobs-to-be-Done no es una metodología de investigación UX al uso. Es una forma de formular preguntas que evita el sesgo de solución. La pregunta "¿quieres una función de IA que resuma este documento?" tiene un sesgo implícito: ya asume que el problema es la longitud del documento y que la solución es el resumen. La pregunta JTBD correcta es anterior: "¿qué estás intentando hacer con este documento y qué te impide hacerlo ahora mismo?"
La respuesta puede ser "necesito extraer los tres puntos de acción que hay al final", en cuyo caso un resumen genérico no sirve. O puede ser "necesito compartirlo con mi equipo sin que tengan que leerlo entero", en cuyo caso el problema no es de comprensión sino de comunicación interna. O puede ser algo completamente distinto que no tiene que ver con IA en absoluto.
Tres preguntas de diagnóstico antes de cualquier feature de IA
En los procesos de auditoría de producto que hacemos en Room 714, antes de evaluar si una capacidad de IA tiene sentido en un flujo concreto, hacemos tres preguntas que actúan como filtro:
¿Cuál es la fricción observable, no la percibida? No lo que el usuario dice que le molesta en una encuesta, sino lo que vemos que hace (o deja de hacer) en datos de comportamiento. Las encuestas dicen "me gustaría una función de resumen". Los datos dicen que el 80% de los usuarios abandona el documento antes del tercer scroll.
¿Esa fricción tiene una causa que la IA puede eliminar, o solo enmascarar? Si el documento es difícil de consumir porque está mal estructurado, un resumen de IA no resuelve el problema: lo aplaza. La solución es rediseñar cómo se genera o presenta el contenido. La IA puede ser parte de eso, pero no el parche encima.
¿El usuario puede completar el trabajo sin saber que hay IA detrás? Si la respuesta es sí, probablemente la integración sea buena. Si el usuario tiene que aprender un nuevo paradigma de interacción para acceder al valor, el coste de adopción puede superar el beneficio.
El caso del formulario y el dropdown
Un ejemplo concreto que ilustra la tensión: los dropdowns. Son uno de los componentes más sobreutilizados en interfaces complejas. Nielsen Norman Group lleva años documentando que su misuse genera tasas de error altas y abandono en flujos de conversión. La reacción moderna de muchos equipos es sustituirlos por campos de lenguaje natural procesados por IA: "escribe tu sector y lo detectamos". Eso puede funcionar, o puede generar una capa de incertidumbre nueva para el usuario ("¿lo ha entendido bien? ¿debería ser más específico?").
La solución JTBD no empieza por el componente. Empieza por la pregunta: ¿por qué el usuario tiene que seleccionar su sector en este momento del flujo? ¿Es necesario para personalizar lo que viene a continuación, o es un dato que se recoge porque siempre se ha recogido? Si lo segundo, eliminar el campo es mejor que sustituirlo por IA. La tecnología más elegante a veces es la ausencia de tecnología.
La Integración Real: Invisible por Diseño
La marca de una buena integración de IA en un producto no es que el usuario diga "qué buena la IA de esta app". Es que el usuario diga "qué fácil es esto" sin identificar ninguna causa tecnológica. La invisibilidad no es un defecto de diseño, es el objetivo.
Hay ejemplos que llevan años funcionando así sin que nadie los llame "producto de IA": el autocomplete de Google Search, que predice consultas con modelos de lenguaje desde 2004. La detección de spam de Gmail, que filtra con modelos de clasificación millones de correos al día sin que el usuario tome ninguna decisión. El sistema de recomendación de Spotify que construye Discover Weekly cada lunes, y que los usuarios describen como "parece que me conoce", no como "tiene buena IA".
Ninguno de estos casos requería que el usuario aprendiera un nuevo paradigma de interacción. Se integraron en flujos existentes, en momentos donde el usuario ya estaba tomando una decisión, y la IA redujo el coste cognitivo de esa decisión. Eso es integración real.
La IA no debería pedirle nada al usuario. Debería quitarle cosas: pasos, decisiones, repeticiones, esperas.
El contraste con muchas features de IA actuales es llamativo. Un asistente que aparece en un modal sobre el flujo principal y pide al usuario que "describa lo que necesita" está invirtiendo la relación: en lugar de quitarle trabajo, le está añadiendo uno nuevo. La promesa de conveniencia se convierte en una tarea más en la lista.
Esto conecta directamente con algo que hemos desarrollado en el contexto de las mejoras de UX que no mejoran nada: optimizar una parte del flujo que no es el cuello de botella real no mueve el indicador. Añadir IA a un paso que no es el problema del usuario tampoco.
El Coste Real del "Más IA": Deuda de Experiencia
Hay un tipo de deuda que los equipos de producto no contabilizan en sus roadmaps: la deuda de experiencia. Es la acumulación de features que tecnológicamente funcionan pero que cognitivamente sobrecargan al usuario. Cada elemento de interfaz que requiere una decisión, cada asistente que hay que configurar, cada sugerencia automática que puede estar equivocada y hay que verificar: todo eso consume energía cognitiva del usuario.
Esa deuda no aparece en las métricas de rendimiento del modelo. Aparece en el churn. Aparece en el NPS. Aparece en las entrevistas de usuario cuando alguien dice "es que hay demasiadas cosas" sin poder señalar ninguna en concreto, porque el problema no es ninguna feature individual sino la suma de todas.
Los equipos que más están sufriendo este fenómeno ahora mismo son los que han añadido capacidades de IA de forma acumulativa: primero un resumen, luego un asistente de chat, luego sugerencias en línea, luego un panel de "insights". Cada uno por separado tenía su justificación de negocio. Juntos crean una interfaz donde el usuario no sabe qué es el producto y qué es el copiloto.
La pregunta de arquitectura de experiencia que debería hacerse antes de cada nueva feature de IA no es "¿podemos construirlo?" ni "¿tenemos los datos?". Es "¿a qué coste cognitivo para el usuario, y compensa ese coste el valor que entrega?"
Ese tipo de análisis requiere investigación cualitativa hecha con rigor, no encuestas de satisfacción post-lanzamiento. Requiere observar a usuarios reales completando tareas reales, identificar dónde aparece la confusión, dónde se detienen, dónde hacen clic en lo incorrecto. Y requiere la disposición organizacional de deshacer lo construido si el diagnóstico lo indica, que es la parte más difícil. Como señalamos en nuestro análisis sobre por qué la investigación de usuario muere cuando se convierte en entregable, el problema no es la investigación en sí, sino que sus conclusiones rara vez llegan a los momentos de decisión de producto con suficiente fuerza.
El Camino: Menos Features, Mejor Integradas
La dirección que funciona no es más IA, sino IA más precisa. Un solo punto de integración que elimina una fricción real vale más, en términos de experiencia y de retención, que cinco features que demuestran capacidad técnica sin resolver ningún trabajo concreto del usuario.
El proceso que recomendamos tiene tres fases que no se pueden saltarse en orden. Primero, mapa de fricciones real basado en comportamiento observado, no en supuestos de roadmap. Segundo, identificación de los dos o tres trabajos donde la IA puede reducir coste cognitivo de forma invisible. Tercero, implementación mínima, medición del impacto en el comportamiento (no en la adopción de la feature) y decisión informada sobre si escalar o descartar.
Ese proceso es más lento que "añadir IA al producto". También es el único que evita construir deuda de experiencia que después hay que pagar con rediseños costosos y usuarios que ya no dan una segunda oportunidad.
Si tu equipo está evaluando dónde y cómo integrar capacidades de IA en un producto existente, o si sientes que el roadmap actual está acumulando features sin una lógica de experiencia clara, en Room 714 trabajamos exactamente en esa intersección. No para decirte cuánta IA necesitas, sino para ayudarte a encontrar dónde tiene sentido —y dónde estás pagando un coste que nadie te está contando.
