Diseñar interfaces para que las use un agente de IA
Un agente usa tu producto por la pantalla, por el HTML o por una API. Cómo diseñar cada capa: nombres accesibles, acciones estables y errores que se entienden.
Este artículo se centra en la interfaz y el HTML. Para el marco general (qué es la experiencia de agente y cómo evaluarla), mira agentes como usuarios.
¿Por qué un agente puede fallar donde una persona no?
Una persona deduce mucho de la pantalla: sabe que un botón “Continuar” abajo a la derecha avanza el flujo. Un agente tiene que obtener esa información de otra parte, y de qué parte depende de la herramienta que use. La investigación sobre agentes que usan computadoras muestra que el problema rara vez es el clic en sí. El benchmark OSWorld 2.0 (junio de 2026), con tareas largas y cambios a mitad de tarea, concluye que el control básico de la interfaz no es el cuello de botella: los agentes fallan al mantener restricciones, al actualizarse cuando llega información nueva y al verificar su resultado. Tu diseño no arregla el razonamiento del modelo, pero sí puede facilitarle la verificación y la recuperación.
¿Por qué vía llega un agente a tu producto?
| Vía | Qué ve el agente | Qué diseñar |
|---|---|---|
| Pantalla (computer use) | Capturas de pantalla; hace clic en coordenadas | Objetivos grandes, estado visible, sin cambios de layout inesperados |
| HTML y árbol de accesibilidad | Roles y nombres de los elementos | HTML semántico y nombres accesibles |
| API o servidor MCP | Acciones con parámetros y resultados | Nombres estables, errores con código, resultados verificables |
Un mismo producto puede recibir las tres. Revisa cada una por separado.
¿Qué cambia si el agente mira la pantalla?
Con computer use, Claude controla un escritorio mediante capturas de pantalla y acciones de ratón y teclado, y las coordenadas son píxeles de la captura. La documentación de Anthropic enumera límites que se traducen en decisiones de diseño: los desplegables y las barras de desplazamiento pueden ser difíciles de manipular con el ratón, el agente puede dar por buena una acción sin comprobarla y cada acción es un viaje de ida y vuelta con latencia. Para tu interfaz eso significa:
- Objetivos grandes y bien separados, no iconos pequeños pegados entre sí.
- Estado visible tras cada acción: un mensaje de confirmación o un cambio claro en la página, para que la captura siguiente permita verificar.
- Layout estable: OSWorld 2.0 documenta casos en que, en interfaces que cambian en tiempo real, las acciones apuntan a posiciones de pantalla que ya no son válidas.
- Alternativa de teclado para los componentes difíciles de usar con el ratón.
¿Qué cambia si el agente lee el HTML?
Herramientas como Playwright MCP dan al modelo instantáneas estructuradas del árbol de accesibilidad en lugar de imágenes, de modo que no necesitan modelos de visión y evitan la ambigüedad de las capturas. Para ese agente, lo que existe es lo que el árbol expone: el rol y el nombre de cada elemento. Ahí tu trabajo de accesibilidad se convierte en trabajo para agentes:
- Usa HTML nativo: un
<button>y un<label>ya exponen rol y nombre. La guía WAI-ARIA de nombres y descripciones pide apoyarse en las técnicas de nombrado de HTML siempre que sea posible. - Que el nombre diga qué hace el control. Dos botones “Editar” sin más contexto son indistinguibles; “Editar dirección de envío” no.
- No repitas el rol en el nombre: la guía WAI-ARIA lo prohíbe expresamente (“botón” en el nombre de un botón).
- Cuidado con
aria-labelen botones y enlaces: reemplaza el texto visible que, por defecto, daba el nombre, y puede dejar al agente (y a un lector de pantalla) con una etiqueta distinta de la que ve la persona.
Una consecuencia práctica: si un lector de pantalla no puede usar tu flujo, un agente que lee el árbol de accesibilidad probablemente tampoco. Es una buena prueba barata.
¿Qué cambia si el agente llama a una API?
Cuando hay una capa de acciones (una API o un servidor MCP), el agente no depende de botones. Cuatro decisiones:
- Nombres estables. “cancelar_suscripcion” conserva su nombre aunque cambie el texto del botón.
- Parámetros claros. Qué datos necesita, cuáles son obligatorios y qué formato esperan.
- Resultado verificable. La acción devuelve si se completó, qué cambió y cómo comprobarlo.
- Permiso explícito. Qué puede hacer el agente, con qué alcance y cuándo debe pedir confirmación.
Un error pensado para una persona dice “Algo salió mal”. Un agente necesita un código estable, la causa en una frase y el siguiente paso posible: “PAGO_RECHAZADO: el método de pago venció; el usuario debe actualizarlo”. Sin código, el agente puede reintentar a ciegas, y eso puede repetir un cobro o un envío. Si una acción puede fallar de cinco formas, las cinco deben tener un código y una salida.
Documenta cada acción en pocas líneas: qué hace, qué parámetros recibe, qué devuelve, qué errores devuelve y si requiere confirmación. Si no puedes describir su resultado en una frase, probablemente hace demasiado. Para el servidor MCP en sí, revisa MCP explicado para diseñadores.
¿Qué debe confirmar una persona?
No todo: pedir confirmación en cada paso hace inútil al agente, y no pedirla nunca lo hace peligroso. La documentación de computer use de Anthropic recomienda exigir confirmación humana para las acciones con consecuencias, como transacciones financieras o aceptar condiciones. Un criterio práctico:
- Acciones difíciles de revertir: borrar, enviar, publicar.
- Dinero o datos personales: cobros, cambios de datos.
- Fuera del alcance autorizado: cualquier paso que el usuario no aprobó de antemano.
El resto puede ejecutarse con un registro de lo que hizo. Para el diseño de esas pantallas, mira aprobación de acciones de un agente.
Pasos para probar tu interfaz con un agente
- Elige una tarea real de tu producto, con inicio y fin claros.
- Haz que un agente la intente por cada vía que ofreces: solo con capturas, solo con el árbol de accesibilidad y, si existe, solo con la API.
- Registra en qué paso se atasca, qué confirmación pide y qué información le falta.
- Corrige el nombre, el permiso o el estado que causó el atasco.
- Repite hasta que la tarea termine con el resultado correcto y un registro claro.
Ejemplo
Ejemplo ilustrativo: una aplicación de reservas tiene un flujo de cambio de cita con cuatro pantallas. Un agente que usa el árbol de accesibilidad se detiene en la tercera: hay tres botones llamados “Elegir” sin contexto y no sabe cuál corresponde al horario deseado. El equipo renombra los botones (“Elegir martes 14, 10:00”), muestra un mensaje de confirmación tras reservar y añade una acción “reprogramar_cita” con fecha y hora como parámetros. La persona confirma solo cuando el cambio implica un cobro.
Errores comunes
- Diseñar acciones solo como botones, sin nombre ni parámetros.
- Usar varios controles con el mismo nombre accesible.
- Cubrir el texto visible con un
aria-labelque dice otra cosa. - Pedir confirmación en cada paso, hasta volver inútil al agente.
- Devolver resultados vagos como “listo” sin decir qué cambió.
- Probar solo el caso feliz y no los errores ni los cambios a mitad de tarea.
Cuándo no conviene exponer la interfaz a agentes
Cuando una acción tiene consecuencias graves y no se puede revertir, o cuando el producto no tiene registros para auditar lo que hizo un agente. En esos casos, diseña primero la auditoría y la confirmación humana. Consulta también computer use para los riesgos de dejar que un agente controle una pantalla.