Hay un patrón que se repite en casi todos los proyectos de producto que llegan a nosotros con problemas. No es un fallo de ejecución. No es que el equipo sea malo. Es que llevan meses construyendo la respuesta correcta a la pregunta equivocada.
El ciclo tiene una lógica perversa: hay un síntoma visible (la tasa de conversión cae, los usuarios abandonan el onboarding, las quejas sobre una pantalla se acumulan), alguien lo convierte en un brief ("rediseña este flujo"), y el equipo empieza a diseñar. Rápido, con buena voluntad, con metodología incluso. El resultado final es una solución técnicamente impecable para un problema que no era el problema.
La tensión que queremos explorar en este post no es nueva, pero la IA la ha vuelto urgente de una manera específica: cuando tienes herramientas que generan soluciones en segundos, el cuello de botella ya no es la velocidad de diseño. Es la calidad del diagnóstico. Y ahí es exactamente donde la industria está fallando en silencio.
Resolver rápido un problema mal definido no es eficiencia: es deuda de producto acumulada a velocidad de sprint.
El diagnóstico no es una fase previa al diseño; es diseño. La forma en que encuadras el problema determina el espacio de soluciones posibles.
Las señales de que estás resolviendo el problema equivocado suelen estar en los datos que nadie ha mirado, no en los que todo el mundo monitoriza.
Síntoma vs. Causa: La Confusión que Todo Brief Perpetúa
Cuando un médico de urgencias ve a un paciente con fiebre de 40 grados, no le da paracetamol y lo manda a casa. La fiebre es información, no el diagnóstico. En diseño de producto hacemos exactamente eso con una frecuencia alarmante: tratamos el síntoma porque es lo que el brief describe, porque es lo que el cliente puede ver, porque es lo que tiene un wireframe asociado.
Un ejemplo clásico: una empresa de SaaS B2B detecta que el 60% de los usuarios nuevos no completa el onboarding. El brief dice "mejora el onboarding". El equipo rediseña la progresión de pasos, simplifica los formularios, añade tooltips contextuales. El resultado: la tasa sube al 68%. Todos contentos. Excepto que la retención a 90 días no se mueve un milímetro, porque el problema real no era que el onboarding fuera confuso; era que los usuarios que llegaban no tenían el job-to-be-done que el producto resuelve. Estaban captando a la persona equivocada, no diseñando mal para la persona correcta.
Esto no es un caso hipotético. Es la estructura subyacente de la mayoría de los "rediseños que no mueven métricas" que hemos visto. Y la señal de que estás en este territorio es precisamente esa: la métrica que mides mejora, pero el negocio no se mueve. Estás optimizando la capa equivocada.
Un rediseño que mejora la métrica local sin mover el negocio no es un éxito de UX. Es un diagnóstico fallido con buena presentación.
La raíz del problema es estructural. Los proyectos llegan con un brief que ya contiene implícita la solución ("rediseña X", "añade Y", "simplifica Z"). El brief no es neutral: es una hipótesis sobre cuál es el problema, formulada por alguien que probablemente no ha hecho investigación de usuario sistemática. Cuando el equipo de diseño acepta ese brief sin cuestionarlo, está aceptando también esa hipótesis, y toda su inteligencia de diseño se aplica dentro de un espacio de soluciones que puede estar completamente desenfocado.
La Trampa del Problema Observable
Hay una razón por la que los equipos caen en esto constantemente: los síntomas son observables y los problemas raíz no. Puedes ver en Analytics que los usuarios abandonan en el paso 3. No puedes ver —sin investigación— por qué. La explicación más parsimoniosa (el paso 3 es confuso) se convierte en la hipótesis de trabajo por defecto, no porque sea la más probable, sino porque es la más cómoda de convertir en tarea.
La investigación que revelaría la causa real —entrevistas de usuario con guión semiestructurado, análisis de comportamiento cualitativo, revisión de tickets de soporte con granularidad temática— lleva tiempo y no cabe fácilmente en un sprint. Así que se omite. Y el equipo diseña con confianza hacia la pared equivocada.
Diagnóstico: El Trabajo que No Entra en el Sprint
El problema de tratar el diagnóstico como una fase dispensable tiene una causa raíz organizativa: los sprints están diseñados para producir entregables, y el diagnóstico no produce entregables, produce comprensión. La comprensión no se puede mostrar en una demo. No tiene un ticket de Jira obvio. No genera el momentum de progreso visible que los stakeholders demandan.
Pero la comprensión es la materia prima de la que depende todo lo demás. Sin ella, el diseño es una apuesta bien ejecutada.
¿Cómo se hace diagnóstico de verdad? No hay una respuesta única, pero hay principios que se repiten en los proyectos donde el diseño posterior funciona. El primero es separar con rigor la pregunta "¿qué pasa?" de la pregunta "¿por qué pasa?". La primera se responde con datos cuantitativos: funnels, heatmaps, tasas de abandono por segmento, cohortes. La segunda requiere datos cualitativos: qué dicen los usuarios cuando se les pregunta, qué hacen cuando nadie los observa directamente, qué alternativas usan cuando tu producto no resuelve su problema.
El segundo principio es que el diagnóstico debe generar hipótesis falsables, no narrativas. Una narrativa es "los usuarios encuentran el onboarding confuso". Una hipótesis falsable es "los usuarios con perfil X abandonan en el paso 3 porque el campo Y requiere información que no tienen disponible en ese momento". La segunda se puede validar con un cambio quirúrgico y una métrica clara. La primera genera un rediseño general que puede o no resolver algo.
El tercer principio, que es el más incómodo de articular en un entorno de producto: a veces el diagnóstico correcto produce la respuesta "no diseñes nada". O "diseña en otro sitio del producto". O "el problema no es de diseño sino de posicionamiento". Estas respuestas son intelectualmente honradas y estratégicamente valiosas, pero son muy difíciles de vender en una reunión donde el cliente ya tiene un presupuesto asignado a "mejora de UX". Tiene que haber alguien en el equipo, o en la consultora, con autoridad para decirlo.
Herramientas de Diagnóstico que Funcionan en la Práctica
No hace falta un proceso de investigación de seis meses para hacer un diagnóstico decente. Hay una capa de trabajo que se puede hacer en una o dos semanas y que transforma radicalmente la calidad del brief resultante. En proyectos con los que hemos trabajado, la combinación que más retorno produce por tiempo invertido es: cinco entrevistas de usuario con el perfil que más abandona o más se queja, revisión temática de los últimos 100 tickets de soporte relacionados con el área en cuestión, y un análisis de comportamiento por cohortes centrado en los usuarios que sí retienen para entender qué hacen diferente.
Esta combinación tarda menos de lo que parece y casi siempre revela que el problema real no es el que describe el brief inicial. No porque el brief mienta, sino porque el brief describe el primer nivel de síntoma, y hay al menos otro nivel por debajo que es donde está la solución útil.
Lo que el error de convertir la investigación en un entregable puntual produce es precisamente esto: un artefacto que describe síntomas con precisión académica pero que nadie vuelve a consultar cuando hay que tomar decisiones de diseño. El diagnóstico tiene que estar vivo y presente en cada decisión de diseño, no archivado en una carpeta de Notion.
JTBD como Marco de Diagnóstico: Más que una Herramienta de Ideación
Jobs-to-be-Done se usa habitualmente como marco de ideación: ¿qué trabajo está intentando hacer el usuario? ¿qué podríamos diseñar para ese trabajo? Pero su uso más valioso —y menos practicado— es como herramienta de diagnóstico: ¿el trabajo que el usuario está intentando hacer es el trabajo que nosotros creemos que está intentando hacer?
Esta distinción importa porque los productos tienden a calcificarse alrededor de la hipótesis de uso que se tenía en el momento del lanzamiento. Las interfaces, los flujos, las métricas de éxito, todo se diseñó para el job-to-be-done que el equipo fundador identificó. Pero los usuarios, con el tiempo, pueden estar usando el producto para un job diferente. O el job original puede haberse fragmentado: lo que antes era una tarea unitaria ahora son tres tareas distintas que usuarios distintos resuelven de forma distinta.
Un caso que ilustra bien esto: una plataforma de analítica de supply chain (categoría que aparece constantemente en conversaciones de IA aplicada) construida para que los responsables de operaciones tomen decisiones de inventario. Después de dos años, las entrevistas revelaron que los usuarios principales eran en realidad los analistas que preparaban los informes para esos responsables, no los responsables mismos. El job real era "construir un argumento convincente para justificar una decisión que ya habías tomado intuitivamente", no "descubrir qué decisión tomar". Toda la arquitectura de información estaba diseñada para el job equivocado. No porque alguien lo hubiera hecho mal, sino porque nadie había vuelto a preguntar.
Esto conecta con algo que vemos repetidamente: los productos que llevan años en el mercado tienen una deuda de diagnóstico acumulada. Cada feature añadida sin pasar por el filtro del job real es una capa más de complejidad que sirve a un usuario imaginario. El problema de los dashboards que no sirven para nada es en su mayoría un problema de diagnóstico: se construyeron para mostrar datos porque los datos estaban disponibles, no porque alguien hubiera identificado con precisión qué decisión necesitaba tomar el usuario con esos datos.
JTBD no es un ejercicio de creatividad para el roadmap. Es una auditoria de si sigues resolviendo el problema que creías estar resolviendo.
Diagnóstico en la Era de la IA: Velocidad sin Comprensión es el Riesgo Real
Hay una razón por la que este tema es más urgente ahora que hace cinco años. Las herramientas de IA generativa permiten producir wireframes, prototipos navegables y especificaciones completas en una fracción del tiempo que costaban antes. Esto es genuinamente valioso. Pero tiene un efecto secundario que pocas organizaciones están nombrando: cuando el coste de producir una solución se desploma, la tentación de saltarse el diagnóstico se dispara.
Si generar un prototipo completo cuesta dos horas, ¿para qué invertir dos semanas en entender el problema? La respuesta —que debería ser obvia pero no lo es en la presión de un equipo de producto— es que la rapidez con la que llegas a la pared equivocada no te hace más eficiente. Solo te hace más rápido en acumular trabajo que habrá que tirar.
Hay además un segundo efecto: las herramientas de IA aplicadas al diseño son extraordinariamente buenas generando soluciones plausibles. Un prompt bien construido produce interfaces que parecen razonables, flujos que tienen sentido superficial, copy que suena correcto. El problema es que "plausible" no es lo mismo que "correcto para este problema específico con este usuario específico en este contexto específico". La IA no sabe cuál es el job real. Tú tampoco, si no has hecho el diagnóstico.
Lo que esto implica para los equipos de producto no es ralentizar el uso de IA en diseño, sino invertir explícitamente más en la fase anterior. Si antes el diagnóstico competía en tiempo con la producción de mockups y los mockups ganaban por coste, ahora que los mockups son casi gratuitos, el diagnóstico debería ganar ese tiempo. En la práctica, muchos equipos están usando la velocidad de producción de la IA para hacer más iteraciones de la misma solución incorrecta en lugar de hacer una iteración de la solución correcta.
Este es también el contexto en el que cobra sentido la proliferación de interfaces generativas y sin fricción aparente: cuando la interfaz desaparece y la interacción se vuelve conversacional o intencional, el riesgo de haber resuelto el problema equivocado se multiplica, porque no tienes los puntos de abandono visibles del funnel tradicional para detectarlo. El diagnóstico tiene que ser anterior y más robusto, precisamente porque el feedback loop de la interfaz se vuelve más opaco.
Hacer del Diagnóstico un Hábito, No una Fase
La conclusión práctica no es "añade una fase de diagnóstico antes de cada proyecto". Eso funciona para proyectos nuevos, pero los productos en producción no tienen fases: tienen ciclos continuos de decisión. Lo que hace falta es convertir el diagnóstico en un hábito permanente del equipo, no en un ritual de inicio de proyecto.
Esto implica cosas concretas. Primero: cada iniciativa del roadmap debería responder a una pregunta de diagnóstico explícita antes de que se diseñe nada. No "vamos a mejorar el onboarding" sino "hemos identificado que el 40% de los usuarios con perfil X abandona porque el paso 3 requiere información de su ERP que no tienen a mano; vamos a diseñar para ese gap específico". La segunda formulación fuerza el diagnóstico porque lo hace visible.
Segundo: las métricas de éxito deben definirse antes del diseño, no después. Si no puedes decir qué número se va a mover y por qué antes de diseñar, es una señal de que el diagnóstico no está completo. El diseño que no tiene hipótesis medible es artesanía, no ingeniería de producto.
Tercero: el diagnóstico tiene que tener un dueño con autoridad para cambiar el brief. Si las conclusiones del diagnóstico llevan a "el brief está mal encuadrado", tiene que haber alguien que pueda decírselo al stakeholder y reencuadrarlo. En organizaciones donde el equipo de diseño es ejecutor sin autoridad de diagnóstico, este paso nunca ocurre. Y es el más importante.
En Room 714, cuando trabajamos con equipos en auditorías de producto, el primer entregable no es un rediseño ni un roadmap: es un mapa del problema real. A veces ese mapa confirma el brief inicial. Más a menudo, lo transforma por completo. La diferencia entre ambos escenarios puede ser la diferencia entre seis meses de trabajo que mueve métricas y seis meses de trabajo que genera una presentación bonita. Si llevas tiempo sospechando que tu equipo está resolviendo el problema equivocado con mucha eficiencia, es una buena señal de que toca parar y diagnosticar antes de seguir diseñando.
