Leí esta semana un artículo de Nielsen Norman Group escrito por Tony Alicea que nombra algo que venía sintiendo pero no había logrado poner en palabras: cuando la IA genera cada vez más pantallas, código y prototipos, el trabajo de investigación y diseño deja de producir documentos para convencer humanos y empieza a producir contexto para guiar modelos. Alicea lo llama UX-context design, y después de ver cómo un product manager de mi equipo le pidió a una IA un mockup para una reunión y terminó tomando decisiones de diseño que ningún diseñador revisó, coincido en que esto ya está pasando, lo llamemos como lo llamemos.
El problema: un modelo diseña "el promedio"
La idea central del artículo es simple y un poco incómoda. Un modelo de IA fue entrenado con una cantidad enorme de pantallas de búsqueda, formularios y dashboards, así que cuando le pedís uno, te da la versión promedio de eso. Sabe cómo se ve el software en general; no sabe nada de tus usuarios, tu dominio ni lo que tu equipo aprendió en investigación, a menos que se lo des como contexto. Alicea usa una comparación que se me quedó grabada: es como un arquitecto excelente diseñando tu casa sin haber conocido nunca a tu familia. Te va a dar una casa de dos pisos porque la mayoría de las casas tienen dos pisos, aunque uses silla de ruedas o tengas un bebé que necesita dormir cerca tuyo. No es un error del arquitecto: es que nunca tuvo el contexto.
Ya no solo diseñan los diseñadores
Lo que hace que esto sea urgente y no solo teórico es un cambio silencioso: en muchas organizaciones, los diseñadores dejaron de ser los únicos que producen diseño. Un product manager pide un mockup rápido antes de una reunión. Un ingeniero le pide a un asistente de código que agregue una función de exportar, y el asistente decide dónde va el botón, cómo se redacta el error, qué pasa si falla. Son decisiones de diseño, las tome quien las tome. El artículo argumenta que la respuesta no es tratar de controlar quién puede "diseñar" —esa batalla ya está perdida—, sino asegurarse de que todo lo que la IA genera, sin importar quién lo pidió, esté informado por lo que la organización sabe de sus usuarios y sus estándares.
De personas y journey maps a un archivo que la IA sí lee
Acá está la parte que más me hizo repensar mi propio trabajo. Los entregables clásicos de UX —personas con foto de stock, journey maps, reportes de hallazgos— están diseñados para que un humano los interprete y se convenza de algo. Una IA no necesita persuasión, necesita el razonamiento de fondo. El artículo describe un ejemplo real: DESIGN.md, un formato que Google Labs abrió en abril de 2026 para describir la identidad visual de un producto a herramientas de IA de código. Vive junto al código, mezcla valores exactos (colores, tipografía, espaciados) con prosa explicando para qué sirve cada uno, y las herramientas de IA lo leen cada vez que generan algo. Sin entrega formal, sin reunión de traspaso: el contexto alimenta directamente la creación del producto.
A partir de ahí, Alicea plantea una hipótesis más amplia: un archivo UX.md que además de lo visual incluya:
- Síntesis de investigación como restricciones accionables, no solo insights de reporte ("los usuarios abandonan el registro cuando se les pide un dato que no tienen a mano").
- Estándares de interacción: cuándo confirmar y cuándo permitir deshacer, cómo redactar errores, si la interfaz es para expertos o novatos.
- Un glosario de los términos que usan los usuarios y el dominio, para que la IA no elija "ticket" cuando tus usuarios dicen "caso".
- Modelos de usuario y de mundo: qué saben, qué necesitan, en qué condiciones usan el producto (una enfermera interrumpida a media tarea, alguien completando un trámite bajo estrés).
Mi reflexión
Lo que más me convence de esta idea es lo que implica sobre el rol del entregable: no está para convencer, está para funcionar. Se mide por si mejora lo que la IA genera, no por si un stakeholder lo aprueba en una reunión. Y no se abandona en una carpeta compartida una vez entregado: vive junto al producto, cambia cuando el producto cambia, y se lee automáticamente cada vez que alguien —diseñador, PM o ingeniero— le pide algo a una IA. Eso cambia el trabajo de investigación de "producir un documento final" a "curar una fuente de verdad viva", algo mucho más parecido a mantener código que a escribir un informe.
Todavía quedan preguntas abiertas que ni el propio artículo resuelve del todo: cuánto contexto es demasiado, qué pasa cuando el modelo mejora y la curación de hoy queda obsoleta, cómo se mide de verdad si el contexto sirvió. Pero la dirección me parece clara, y ya la puedo ver en mi propio trabajo: si mis hallazgos de investigación solo viven en un Notion que nadie vuelve a abrir, esos hallazgos no van a influir en nada de lo que una IA genere para mi producto mañana.
"El futuro entregable de UX no es un documento que convence a un humano, sino un contexto que guía a una máquina."
¿Tu equipo ya está armando algo parecido a un UX.md, aunque no lo llame así? Me gustaría leer tu experiencia. Podés escribirme en LinkedIn.