Tutoriales
Claude Opus 5.5 para errores de formulario con solución clara
Utiliza Claude Opus 5.5 para vincular cada fallo del formulario a una acción de recuperación antes de pulir el texto.
Utiliza Claude Opus 5.5 para vincular cada fallo del formulario a una acción de recuperación antes de pulir el texto. Quien solicita una muestra necesita saber qué corregir, qué datos se conservan y si la petición llegó. Un borde rojo y “Algo salió mal” no resuelven esas dudas.
Empieza por estados, no por una captura
Proporciona esquema de campos, reglas reales, categorías de respuesta del servidor y mensajes actuales. Usa datos ficticios. Una revisión comunitaria de formularios plantea cómo mejorar la validación, incluida la identificación del campo y la facilidad de corrección. Es evidencia de necesidad, no una certificación de accesibilidad.
El tutorial de notificaciones del W3C recomienda identificar el campo, explicar la corrección y enlazar al control. Tómalo como referencia y verifica la implementación con teclado y tecnología de asistencia.
| Estado | Respuesta útil | Evidencia necesaria |
|---|---|---|
| Campo obligatorio vacío | Nombrar campo y acción | Regla publicada |
| Formato rechazado | Explicar formato admitido | Comportamiento real del validador |
| Servicio no disponible | Conservar datos y ofrecer reintento | Respuesta de fallo confirmada |
| Resultado incierto | Explicar incertidumbre y consultar estado | ID de petición o API de estado |
| Petición aceptada | Confirmar recepción y siguiente paso | Respuesta exitosa del servidor |
No describas un tiempo de espera agotado como rechazo confirmado. Repetir un envío incierto puede duplicarlo si no existe un mecanismo seguro. El modelo debe señalar esa decisión pendiente, no inventar garantías del servidor.
Reescribe una solicitud ficticia
Supón un formulario con correo, cantidad y empresa opcional. Las reglas aprobadas exigen correo y una cantidad entera de 1 a 20. “Entrada no válida” no orienta. Para cantidad, “Introduce un número entero de 1 a 20” ofrece una acción. Si falta el correo, pide introducirlo; no acuses de formato incorrecto a una dirección aún no escrita.
Mantén opcional la empresa. No añadas teléfono, suscripción ni promesas de entrega para aparentar integridad. Conserva cantidad y empresa válidas tras un fallo. Tras el éxito, muestra solo el siguiente paso aprobado por el equipo, sin inventar plazos de respuesta.
Prompt para revisar estados
Revisa este formulario ficticio de muestras de producto.
Campos: correo obligatorio; cantidad obligatoria, entero 1–20; empresa opcional.
Recibes también etiquetas/mensajes, reglas, HTML y estados documentados del servidor.
Marca como desconocido cualquier detalle de implementación ausente.
Devuelve tabla: desencadenante, campo o formulario completo, mensaje, recuperación,
valores conservados, foco/anuncio y prueba de aceptación.
Mantén opcionales los campos opcionales y conserva entradas válidas tras el fallo.
No muestres éxito antes de una respuesta exitosa del servidor.
Distingue rechazo confirmado, servicio no disponible y resultado incierto.
No prometas reintentos sin duplicados sin respaldo de la implementación.
Propón textos concisos y asociaciones HTML necesarias, sin rediseñar la página.
Prueba envío vacío, cantidad 0/1/20/21/1.5, corrección, fallo de servidor,
tiempo de espera incierto, uso solo con teclado y envío correcto.
No envíes datos de clientes ni modifiques un formulario real.La referencia de Opus 5.5 aporta contexto del modelo. Es un método propuesto, no una mejora medida de conversión ni un ensayo ejecutado de Opus.
Revisa comportamiento y texto
Conserva etiquetas visibles, asocia errores y controles y permite llegar a cada problema desde el resumen. Decide si mover el foco al resumen o al campo y verifica la elección en la página real; varios anuncios simultáneos pueden confundir. Retira el error antiguo del campo corregido sin borrar las demás entradas.
Para la regla ficticia, 0, 21 y 1.5 fallan; 1 y 20 pasan. Estos límites se calcularon localmente, pero no prueban tu servidor. Valida cliente y servidor, incluido pegar datos y corregir tras el primer error. Una captura no demuestra orden del foco ni anuncios del lector de pantalla.
Conecta la solicitud con la campaña
El formulario debe continuar la promesa del anuncio. Cuando funcionen sus estados, prepara en Panelly Studio una imagen con la oferta aprobada de muestras. No se afirma integración nativa con Opus ni creación de formularios. Revisa coherencia entre anuncio y página y movimiento reducido si las animaciones distraen de corregir.
Preguntas de entrega
**¿Todos los errores deben usar el mismo mensaje?** Corregir un campo y esperar un servicio requieren acciones distintas. Reutiliza el tono, no un diagnóstico ambiguo.
**¿Una mejor frase demuestra accesibilidad o conversión?** No. Prueba la interacción y mide los resultados por separado. La entrega inmediata es un estado recuperable respaldado por evidencias.
