Muestra exactamente dónde empieza el cambio
Una petición útil empieza por la ubicación y por una diferencia observable entre lo que ocurre y lo que debería ocurrir. Indica la dirección de la página, la acción del usuario y el resultado encontrado. Si hay una imagen de apoyo, acompáñala con una explicación escrita que permita reproducir la situación.
Imagina un sitio de formación en el que quieres mejorar la presentación de los cursos. Decir que la página debe ser más sencilla deja abiertas varias interpretaciones. La IA puede reducir texto, cambiar la navegación o retirar una opción de compra que consideró redundante, aunque esa opción fuera importante.
Puedes concretar la petición: en la página de un curso, después de elegir una edición, la persona debe ver claramente la fecha, el precio y las opciones de inscripción. Si existe la posibilidad de comprar un conjunto de cursos, esa elección debe seguir disponible en el mismo recorrido y con las reglas actuales.
Observa que ya estás separando presentación de funcionamiento. Querer una página menos cargada no significa querer menos modalidades de compra. La descripción debe hacer explícita esa intención para evaluar la simplificación visual sin presumir un cambio en la forma en que el negocio vende sus productos.
Guarda una referencia del estado anterior cuando ayude a comparar. Puede ser una captura de la página y una descripción del recorrido con datos de demostración. La referencia permite mostrar lo que existía sin tener que reconstruir de memoria todos los elementos después del cambio.
Para preparar el siguiente paso, consulta Desarrollar aplicaciones con IA.
Explica qué debe seguir funcionando
Un cambio tiene requisitos nuevos y compromisos heredados del estado anterior. Identifica los comportamientos que no pueden desaparecer, especialmente los que solo aparecen en determinadas condiciones. No basta con pedir que se mantenga todo lo demás: explica los recorridos relevantes y las reglas cuya conservación formará parte de la verificación.
En el ejemplo de los cursos, la opción de comprar un conjunto puede aparecer solo cuando existen ediciones compatibles. Una prueba con un curso aislado no la muestra. Si esa condición no está descrita, una revisión rápida puede dar la impresión de que todo sigue correcto, aunque haya desaparecido un recorrido comercial.
El mismo cuidado se aplica a la información guardada. Si quieres cambiar el orden de los campos de un formulario, aclara que los registros existentes deben seguir siendo legibles y utilizables. Una petición visual no concede por sí sola libertad para cambiar la interpretación de los datos que el equipo ya recogió y utiliza.
Esta preparación amplía la idea de planificar una aplicación antes de construirla, aplicada a una parte que ya existe. Empiezas por lo que hace hoy la aplicación y añades la diferencia deseada. Así puedes evaluar la propuesta de cambio sin volver a discutir todas las decisiones del producto.
Si no sabes cuáles son las dependencias, pide primero un análisis de impacto. La respuesta debe identificar los recorridos potencialmente afectados y las dudas que necesitan decisión. Ese análisis puede revelar que un cambio aparentemente pequeño toca reglas de acceso, disponibilidad o cálculo que merecen tratarse por separado.
Separa corrección, mejora y nueva funcionalidad
Una corrección restablece un comportamiento esperado; una mejora cambia cómo se presenta o ejecuta; una funcionalidad nueva añade una posibilidad. Distinguir estas peticiones ayuda a controlar el alcance. Cuando las mezclas en una instrucción genérica, resulta difícil saber qué cambio resolvió el problema y cuál introdujo trabajo adicional.
Si las fotografías de los cursos no aparecen, empieza por describir ese fallo. Pedir al mismo tiempo una galería nueva, una reformulación de la página y otra forma de cargar imágenes reúne decisiones diferentes. La primera pregunta es si la imagen correcta vuelve a aparecer en las condiciones en que debería estar disponible.
Después puedes decidir si merece mejorarse la galería. Esa segunda tarea tendrá su propio objetivo, como permitir comparar imágenes sin perder la elección de edición. Separarlas permite discutir la utilidad de la mejora después de confirmar que el contenido original volvió a funcionar, en lugar de aceptar un rediseño por necesidad.
El tamaño de la petición también debe corresponder a tu capacidad de revisarla. Si no puedes verificar varios cambios independientes en una entrega, reduce el lote. Una secuencia de cambios comprensibles puede ser más fácil de seguir que una transformación extensa cuya explicación se limita a que quedó mejor.
Verifica la novedad y los recorridos anteriores
La validación debe confirmar lo que cambió y lo que debía permanecer. Elige ejemplos que ejerciten las condiciones relevantes, incluida una excepción cercana al cambio. Compara el resultado con la petición escrita. Una página que abre y parece correcta todavía puede haber perdido una acción importante para el usuario.
Para la página de formación, puedes verificar una inscripción individual, la elección de un conjunto y una edición sin plazas. Cada situación responde a una regla distinta. Si el cambio solo se observó en el primer caso, el informe debe decirlo, sin presentar los demás recorridos como igualmente verificados.
Pide evidencia del comportamiento, no solo una lista de archivos modificados. Interesa saber si la elección se mantiene al avanzar, si el precio mostrado corresponde a la modalidad seleccionada y si regresar a la página conserva la información esperada. Los detalles técnicos ayudan cuando explican el impacto de una decisión.
Es la lógica que desarrollo al probar una automatización antes de entregarla. La prueba sigue la tarea real de la persona, incluidos los caminos menos frecuentes que pueden haberse visto afectados. No necesitas repetir indiscriminadamente todas las pruebas del proyecto, sino justificar las que cubren el cambio.
Cierra el cambio con una explicación verificable
Un cambio queda listo para decidir cuando sabes qué cambió, qué se comprobó y qué sigue pendiente de confirmar. Pide un resumen relacionado con el comportamiento del usuario y las reglas preservadas. Si existe una limitación, debe indicar el recorrido afectado para que puedas decidir el siguiente paso.
Una entrega útil explicaría que se reorganizó la presentación de opciones, que la inscripción individual y el conjunto siguen disponibles en las condiciones previstas y que se comprobó la edición sin plazas. Si no se observó la confirmación por email, esa ausencia debe quedar claramente registrada al cerrar el trabajo.
Guarda también el motivo del cambio. Igual que interesa explicar por qué una automatización modificó una campaña, interesa relacionar un cambio en la aplicación con la necesidad que lo motivó. Ese registro ayuda a evitar que una revisión futura elimine una decisión sin conocer su propósito.
Si las pruebas revelan una regresión, vuelve al requisito concreto e identifica qué dejó de funcionar. Conserva la posibilidad de recuperar una versión conocida mientras se prepara la corrección. La siguiente petición debe resolver el fallo observado con el alcance necesario, manteniendo visibles las elecciones ya aceptadas.