Hay una frase que empieza a circular con fuerza: la interfaz de usuario va hacia la muerte.
El argumento parece evidente. Si puedo decirle al ordenador “revisa estos correos, cruza los reclamos con el CRM, prepara una respuesta para cada cliente y avísame antes de enviar”, ¿para qué necesito abrir cuatro aplicaciones, aprender sus menús y ejecutar cada paso con el ratón?
La conclusión, sin embargo, confunde dos cosas distintas: que disminuya la interacción manual y que desaparezca la experiencia de usuario.
No estamos dejando de diseñar interfaces. Estamos cambiando qué gobierna la interfaz.
Durante décadas, el producto digital asumió que una persona debía traducir su intención en una secuencia de acciones: abrir, buscar, seleccionar, completar, comparar, confirmar. Los agentes alteran esa relación porque permiten expresar un resultado y delegar parte del recorrido. Pero cuanto más trabajo ejecuta el sistema, más necesitamos comprender su alcance, sus decisiones operativas, sus permisos, su evidencia y su capacidad de recuperación.
La interfaz deja de ser únicamente el lugar donde hacemos el trabajo. Se convierte en el lugar donde definimos, autorizamos, supervisamos, verificamos y, cuando sea necesario, deshacemos el trabajo que realiza un agente.
En resumen
UX/UI no muere. Pierde su monopolio sobre la ejecución directa.
La voz será una entrada excelente para expresar intención, interrumpir y coordinar. La pantalla seguirá siendo superior para comparar opciones, revisar grandes cantidades de evidencia, editar detalles, detectar anomalías y comprender consecuencias.
El futuro más probable no es una experiencia voice-only, sino una arquitectura híbrida:
- Voice-first cuando hablar sea la forma más rápida de declarar un objetivo, añadir contexto o cambiar de dirección.
- Visual-first cuando verificar, comparar o autorizar requiera precisión.
- API-first para el agente cuando exista una herramienta estructurada y fiable.
- GUI o intervención humana cuando la capacidad no esté disponible, el contexto sea ambiguo o el riesgo exija control directo.
Y sí: vamos a diseñar UX para agentes. Pero no significa dibujar pantallas que “le gusten” a una IA. Significa diseñar una superficie semántica que el agente pueda descubrir y utilizar con fiabilidad: herramientas con nombres inequívocos, parámetros tipados, resultados estructurados, permisos mínimos, errores accionables, estados consultables y operaciones reversibles.
El entregable estratégico ya no será solo un wireframe o un flujo. Será un contrato de delegación.
La voz cambia el punto de entrada, no elimina la interfaz
A 5 de agosto de 2026, la documentación oficial de OpenAI describe una experiencia en la que ChatGPT Voice puede utilizarse con Work y Codex para iniciar tareas, comprobar progreso, priorizar, interrumpir, redirigir y coordinar varios agentes desde una conversación. GPT-Live añade una arquitectura full-duplex: puede escuchar y hablar al mismo tiempo y mantener la conversación mientras delega trabajo más complejo.
Esto reduce de manera drástica el coste de expresar intención. Ya no es necesario aprender de antemano dónde vive cada función. Podemos decir lo que queremos conseguir en lenguaje natural.
Pero hablar no equivale a conceder control ilimitado.
Voz utiliza las herramientas y permisos disponibles en la experiencia seleccionada. El contexto del ordenador puede requerir acceso al micrófono, grabación de pantalla y audio, accesibilidad, archivos locales o aplicaciones concretas. Un workspace puede habilitar o restringir funciones. Una herramienta puede leer datos sin poder modificarlos, crear borradores sin poder enviarlos o preparar un cambio sin poder desplegarlo.
La voz hace que la interacción parezca continua. Los permisos, los límites y los estados siguen siendo discretos.
Por eso una buena experiencia debe separar, verbal y visualmente, al menos tres mensajes:
“Te escuché.”
“Acepté la nueva instrucción.”
“La instrucción ya fue aplicada a las tareas activas.”
No son equivalentes. En un sistema con varias tareas paralelas, una corrección puede afectar solo a una rama, llegar demasiado tarde para una acción ya ejecutada o quedar pendiente de una aprobación. La fluidez conversacional no puede ocultar esa realidad operativa.
El agente es un androide sin cuerpo
La metáfora más útil no es “un chatbot más inteligente”. Es un androide sin cuerpo.
Puede hablar con nosotros, escuchar mientras pensamos, observar partes del entorno digital y utilizar las “manos” que le prestan las herramientas, APIs, conectores, terminales y permisos del sistema. También puede mantener contexto, coordinar subtareas y reaccionar a eventos.
| Capacidad metafórica | Implementación digital |
|---|---|
| Voz | Conversación speech-to-speech, transcripción y síntesis |
| Oídos | Micrófono, detección de actividad y audio compartido |
| Ojos | Capturas, navegador, archivos y datos estructurados |
| Manos | APIs, herramientas MCP, terminal, conectores y automatizaciones |
| Memoria | Contexto de conversación, archivos e instrucciones autorizadas |
| Sistema nervioso | Orquestación, eventos, estados y llamadas a herramientas |
| Conciencia de límites | Policies, sandbox, permisos, schemas y checkpoints humanos |
El punto decisivo es que no tiene manos universales. Le prestamos manos específicas.
Puede leer correo si existe una herramienta autorizada para leer correo. Puede redactar si la herramienta permite crear borradores. Puede enviar únicamente si existe una acción de envío y la autoridad concedida incluye ese verbo, ese destinatario y ese volumen. Puede analizar transacciones sin tener permiso para cancelar una suscripción. Puede preparar un rollback sin poder ejecutarlo en producción.
Cada verbo adicional —leer, modificar, publicar, enviar, borrar, pagar— aumenta el radio de impacto.
Esto explica por qué la interfaz no desaparece. Cuando el sistema solo sugiere, el coste de un error puede ser una mala respuesta. Cuando actúa, el error puede propagarse fuera del chat. El diseño debe hacer visible la diferencia entre capacidad y autoridad.
Del diseño de pantallas al diseño de colaboración
La UX tradicional organiza posibilidades: menús, botones, jerarquías y recorridos. La UX agéntica debe organizar responsabilidades.
Antes diseñábamos una acción: “Enviar”. Ahora debemos diseñar una delegación completa:
“Identifica a los clientes afectados, redacta una respuesta usando esta política, no prometas compensaciones superiores a 100 euros, crea borradores pero no envíes nada y avísame cuando encuentres un caso ambiguo.”
El producto tiene que convertir esa frase en un estado operativo verificable. Debe distinguir:
- El resultado buscado.
- Las fuentes autorizadas y las excluidas.
- Las acciones permitidas y prohibidas.
- Los límites de dinero, volumen, tiempo y alcance.
- Los criterios de éxito.
- Los puntos que requieren intervención humana.
- La evidencia que demostrará que el trabajo está bien hecho.
- La forma de corregir o revertir el resultado.
Esto cambia la unidad mínima del diseño. Ya no es únicamente el clic. Es la relación de trabajo entre una persona, uno o varios agentes y los sistemas sobre los que actúan.
Magentic-UI explora esta relación mediante coplanificación, cotrabajo, multitarea, guardas de acción y memoria. La idea importante no es una interfaz concreta, sino que la colaboración admite grados: supervisión distante, control cercano, resolución conjunta o toma de control completa. El usuario debe poder cambiar de nivel sin reiniciar toda la tarea.
Un plan, por ejemplo, no debería ser una lista decorativa generada por el modelo. Debe ser un objeto manipulable: reordenar pasos, cancelar una rama, cambiar una fuente, reducir el alcance o añadir un checkpoint obligatorio.
¿Vamos a diseñar UX/UI para agentes?
Sí, pero conviene separar dos disciplinas que compartirán el mismo producto.
| UX para personas que colaboran con agentes | Experiencia para agentes que usan sistemas |
|---|---|
| Lenguaje comprensible | Nombres de herramientas inequívocos |
| Resumen antes del detalle | Schemas estrictos de entrada y salida |
| Comparación visual | Datos estructurados y tipados |
| Explicación contextual | Descripciones operativas precisas |
| Confirmación proporcional al riesgo | Señales de impacto y reversibilidad |
| Pausa, redirección y toma de control | Estados de tarea consultables |
| Evidencia y procedencia | Identificadores estables y referencias |
| Undo y recuperación | Operaciones idempotentes o compensatorias |
| Accesibilidad multimodal | Errores legibles por máquina |
| Responsabilidad organizativa | Logs y trazas auditables |
Para una persona, una capacidad puede representarse con texto, una tarjeta, un botón, una comparación o una conversación. Para un agente, esa misma capacidad necesita una representación estructurada.
El Model Context Protocol formaliza parte de esta segunda superficie. Una herramienta puede declarar un nombre, una descripción, un inputSchema, un outputSchema y resultados estructurados. Esto permite que un agente descubra qué existe, valide parámetros y reciba una salida que no dependa de interpretar una pantalla.
Pero un protocolo no sustituye al diseño. Una función llamada processItem sigue siendo ambigua. Una herramienta llamada create_refund_draft, que exige order_id, reason, maximum_amount y requires_human_approval, comunica mucho mejor su intención, sus límites y su riesgo.
La nueva responsabilidad de producto es diseñar la superficie semántica de las herramientas.
La investigación AXIS ofrece una señal útil: las largas secuencias de clics visuales pueden introducir latencia y menor fiabilidad, mientras que un enfoque API-first puede completar tareas con menos pasos. Sus resultados se obtuvieron en Microsoft Word y no deben generalizarse sin cuidado, pero ilustran una dirección clara: las aplicaciones preparadas para agentes necesitarán capacidades estructuradas además de pantallas para humanos.
El nuevo entregable: un contrato de delegación
Un contrato de delegación no es necesariamente un documento legal ni una única pantalla. Es el conjunto observable de condiciones que determina qué resultado se persigue, qué puede hacer el agente y cómo se comprobará su trabajo.
Puede organizarse en ocho capas.
| Capa | Pregunta de diseño | Affordance necesaria |
|---|---|---|
| Intención | ¿Qué resultado entendió el sistema? | Resumen editable: “Entendí que…” |
| Contexto | ¿Qué fuentes, períodos y exclusiones utilizará? | Panel de fuentes y actualidad |
| Capacidad | ¿Qué herramientas existen y están conectadas? | Inventario de capacidades y estado |
| Autoridad | ¿Qué puede leer, modificar, enviar o borrar? | Permisos por verbo, objeto e impacto |
| Plan | ¿Cómo se descompone la tarea y dónde se decide? | Timeline editable y checkpoints |
| Ejecución | ¿Qué está haciendo, qué está bloqueado y qué cambió? | Estado observable, pausa y takeover |
| Evidencia | ¿Qué demuestra que el resultado es correcto? | Diffs, fuentes, tests y procedencia |
| Recuperación | ¿Cómo se corrige, revierte o escala? | Undo, rollback y acciones compensatorias |
Intención
“Limpia mi bandeja” es ambiguo. “Archiva newsletters anteriores a 90 días, etiqueta facturas y no borres mensajes” define un resultado y límites. Antes de una tarea amplia, la interpretación debe poder editarse.
Contexto
El usuario necesita saber qué datos entran y cuáles quedan fuera. Un análisis de cuentas debe indicar bancos, períodos, monedas y fecha de actualización. “No encontré el dato” no es lo mismo que “no tengo permiso”, “la fuente no está conectada” o “la herramienta falló”.
Capacidad y autoridad
Tener una herramienta no implica permiso para usar todas sus acciones. Leer no es modificar. Modificar no es publicar. Publicar no es borrar. La autoridad debería concederse por verbo, objeto, período, volumen y nivel de impacto.
Plan y ejecución
El plan debe admitir cambios sin reiniciar el trabajo. La ejecución tiene que mostrar qué ramas siguen activas, qué instrucción utiliza cada una y qué acciones ya no pueden deshacerse.
Evidencia
Una respuesta convincente no es suficiente. El agente debe vincular afirmaciones y cambios con fuentes, operaciones, diffs, tests o capturas. Codex ya muestra parte de este patrón al devolver cambios revisables, resultados de terminal y evidencia de validación.
Recuperación
Cada acción con efectos debería declarar si es reversible, parcialmente reversible o irreversible. Cuando no existe undo técnico, el producto necesita una acción compensatoria: restaurar una versión, enviar una corrección, crear un ticket o escalar a un responsable.
Patrones concretos para una interfaz agéntica
La teoría se vuelve útil cuando se traduce en componentes de producto.
Cabecera de misión
Debe mostrar el objetivo actual, el agente responsable, el entorno de ejecución, el tiempo transcurrido, el estado y el nivel de autoridad. Estados como preparando, esperando aprobación, ejecutando, bloqueado, verificando, completado, fallido y revertido son más informativos que una animación genérica de “pensando”.
Resumen de resultado
Un cierre útil debería responder seis preguntas:
| Campo | Contenido |
|---|---|
| Resultado | Qué se consiguió |
| Alcance | Qué fuentes, cuentas o archivos se procesaron |
| Cambios | Qué se modificó fuera del chat |
| Excepciones | Qué quedó incompleto y por qué |
| Riesgos | Qué supuestos o incertidumbres permanecen |
| Próxima acción | Qué conviene hacer ahora |
Timeline de actividad
No necesita exponer razonamientos privados ni una transcripción interminable. Debe registrar acciones observables: herramienta utilizada, objeto afectado, hora, resultado, evidencia generada y reversibilidad.
Tarjeta de aprobación
“Necesito permiso” es insuficiente. La aprobación debería mostrar una acción concreta:
Acción: enviar 14 respuestas
Destinatarios: lista revisable
Fuente del contenido: política de soporte v3.2
Datos incluidos: nombre, pedido y propuesta de compensación
Impacto: comunicación externa
Reversibilidad: no reversible después del envío
Alternativas: guardar borradores / enviar 2 casos de prueba
Aprobación válida durante: 10 minutosProcedencia e incertidumbre
Cada afirmación o gráfico importante debería enlazar con su fuente, fecha, herramienta y transformación. Un “92 % de confianza” aislado dice poco. Es mejor explicar la causa: “faltan dos estados de cuenta”, “tres documentos contradicen la política” o “la clasificación utiliza una coincidencia aproximada”.
Centro de recuperación
El botón no debería decir simplemente “Deshacer”. Debería explicar qué restaurará y cuál será el radio de impacto: “Restaurar 18 etiquetas de correo al estado de las 10:42”.
La seguridad también es una decisión de UX
Un agente que lee páginas, correos o documentos puede encontrar instrucciones maliciosas incrustadas en esos materiales. Si además tiene herramientas con permisos amplios, una entrada no confiable puede convertirse en una acción real.
OWASP utiliza el correo como ejemplo de agencia excesiva: un asistente que solo necesita leer mensajes recibe también capacidad de envío, y una inyección indirecta intenta hacerle reenviar información sensible. La mitigación no consiste únicamente en escribir un prompt mejor. Consiste en eliminar funciones innecesarias, usar credenciales de solo lectura, exigir revisión para el envío y limitar volumen.
La respuesta de UX tampoco puede ser pedir confirmación para cada microacción. Eso produce fatiga y enseña a aprobar sin leer. El diseño debe combinar:
- Mínimo privilegio por defecto.
- Aprobaciones en momentos de impacto significativo.
- Separación entre lectura, escritura, publicación y borrado.
- Límites de volumen, dinero, tiempo y destinatarios.
- Estado visible y capacidad de parada.
- Evidencia posterior y registro auditable.
- Recuperación técnica o compensatoria.
La gobernanza atraviesa todo el producto. El NIST AI RMF organiza la gestión del riesgo en torno a gobernar, mapear, medir y gestionar. Para diseño, esto implica definir roles, responsables, criterios de evaluación y procedimientos de incidente antes de que una demo se convierta en infraestructura crítica.
Qué trabajo disminuirá y qué trabajo crecerá
La parte incómoda es que no todas las tareas actuales conservarán el mismo valor.
Es razonable esperar menos demanda para trabajo centrado exclusivamente en producir muchas variaciones de pantallas, documentar recorridos deterministas o convertir requisitos estables en componentes previsibles. Los agentes ya pueden acelerar parte de esa producción y el lenguaje natural reducirá algunos pasos intermedios.
Pero crecerán otras responsabilidades:
- Modelar cómo una intención abierta se convierte en un objetivo verificable.
- Diseñar transiciones entre autonomía, colaboración y toma de control humana.
- Definir permisos y aprobaciones proporcionales al riesgo.
- Diseñar estados para tareas paralelas y de larga duración.
- Crear herramientas y APIs legibles por agentes.
- Representar procedencia, incertidumbre y cobertura de evidencia.
- Diseñar undo, rollback y acciones compensatorias.
- Evaluar comportamiento, no solo pantallas.
- Trabajar con seguridad, legal, operaciones y negocio en gobernanza.
- Mantener accesibilidad entre voz, texto, imagen, teclado y control directo.
El diseñador deja de ser solamente quien ordena controles en una superficie. Pasa a participar en la definición de quién puede hacer qué, en nombre de quién, con qué información, bajo qué límites y con qué responsabilidad.
Qué debería hacer hoy un equipo de diseño
No hace falta esperar a que toda la organización tenga agentes autónomos. Se puede empezar con seis preguntas aplicadas a cualquier flujo existente:
- ¿Qué resultado intenta conseguir la persona? No qué botón pulsa, sino qué cambio desea en el mundo.
- ¿Qué partes pueden delegarse de forma segura? Separar investigación, preparación, modificación y publicación.
- ¿Qué evidencia permitiría verificar el resultado? Fuentes, diffs, tests, muestras o métricas.
- ¿Dónde debe intervenir una persona? Ambigüedad, impacto externo, dinero, datos sensibles o irreversibilidad.
- ¿Cómo se recupera el sistema de un error? Undo, snapshot, rollback o acción compensatoria.
- ¿Cómo se expone la misma capacidad a humanos y agentes? Una representación comprensible y otra estructurada.
También conviene cambiar los entregables. Junto al journey map o al prototipo, un equipo debería documentar:
- Matriz de autoridad por acción.
- Modelo de estados y eventos.
- Inventario de herramientas.
- Schemas y errores esperados.
- Checkpoints humanos.
- Plan de evidencia y procedencia.
- Estrategia de recuperación.
- Métricas de calidad de colaboración.
La próxima gran interfaz no será una pantalla
La interfaz gráfica no desaparece. Deja de ser el centro exclusivo de la experiencia.
Seguiremos necesitando botones, formularios, tablas, gráficos y editores. Pero su función cambia. Muchas veces ya no serán el instrumento con el que ejecutamos cada paso, sino la superficie donde comprendemos la misión, delimitamos autoridad, observamos progreso, revisamos evidencia y decidimos si aceptar, corregir o revertir.
La voz hace visible este cambio porque nos permite expresar intención sin recorrer el software manualmente. Codex y otros agentes lo convierten en una realidad operativa porque pueden utilizar herramientas, actuar en paralelo y producir cambios revisables. Esa combinación no mata UX/UI. La obliga a madurar.
Pasamos de diseñar instrumentos que una persona opera directamente a diseñar relaciones de trabajo con un androide sin cuerpo: uno que escucha, observa, ejecuta, se equivoca y necesita límites comprensibles.
La próxima gran interfaz no será solo una pantalla.
Será un contrato.
Preguntas frecuentes
- ¿La voz reemplazará a las interfaces gráficas?
- No. La voz reduce el coste de expresar intención, iniciar trabajo e interrumpir una tarea. Las interfaces visuales siguen siendo mejores para comparar alternativas, revisar evidencia, editar con precisión, comprender estados complejos y confirmar acciones de riesgo.
- ¿Habrá menos trabajo para diseñadores UX/UI?
- Probablemente habrá menos trabajo centrado exclusivamente en producir variaciones de pantallas y recorridos deterministas. Crecerá el trabajo sobre modelos de interacción, permisos, observabilidad, comportamiento, evaluación, accesibilidad multimodal, recuperación y gobernanza.
- ¿Qué significa diseñar UX para agentes?
- Significa crear capacidades que un agente pueda descubrir e invocar de forma fiable: nombres de herramientas claros, schemas estrictos, resultados estructurados, permisos mínimos, errores accionables, estados consultables y operaciones reversibles.
- ¿Qué es un contrato de delegación?
- Es la especificación observable que conecta el resultado pedido con el contexto autorizado, las herramientas disponibles, los límites de autoridad, el plan, los checkpoints, la evidencia, la responsabilidad y las opciones de recuperación.
- ¿Cuándo debe un agente pedir aprobación?
- Cuando una acción produce un efecto externo significativo, expone datos sensibles, aumenta privilegios, implica dinero, afecta a terceros, supera el alcance concedido o es difícil de revertir. La aprobación debe ser proporcional al riesgo, no una interrupción para cada microacción.
- ¿Cómo se mide una buena experiencia humano-agente?
- Además de éxito y velocidad, conviene medir correcciones necesarias, intervenciones evitables, tiempo para detectar errores, cobertura de evidencia, cumplimiento del alcance, calidad de recuperación, confianza calibrada y porcentaje de acciones reversibles.