Publicas algo, la gente empieza a usarlo y, en una semana, empiezan a llegar los mensajes. Una reseña de una estrella que dice "confuso". Un mensaje directo que dice "¿también puede hacer X?". Un ticket de soporte que en realidad es solo alguien desahogándose por un botón que no encontró. Este es el buen problema: significa que a la gente le importa lo suficiente como para decirte que algo está mal. Pero también es el momento en que la mayoría de los creadores de aplicaciones, sin darse cuenta, empiezan a empeorar las cosas, porque convertir un comentario en un prompt parece que debería ser sencillo, y casi nunca lo es.
He visto empeorar muchas aplicaciones después del lanzamiento, no mejorar, y rara vez es porque los comentarios fueran malos. Es por lo que ocurre entre leer el mensaje y escribir el siguiente prompt. Tres patrones aparecen una y otra vez.
Error uno: construir exactamente lo que escribieron
Un usuario dice "me gustaría que hubiera un interruptor de modo oscuro en el encabezado". Así que abres el chat de creación y escribes: "añade un interruptor de modo oscuro en el encabezado". El creador de aplicaciones lo hace. Ticket cerrado, ¿verdad?
Excepto que ese usuario en realidad no quería un interruptor en el encabezado: quería que la aplicación dejara de dañarle los ojos por la noche. Tal vez quería que siguiera automáticamente la preferencia del sistema y no tener que pensarlo nunca más. Tal vez el problema real era que tu fondo es blanco y deslumbrante, y el interruptor es una solución alternativa que inventó porque no sabe qué más pedir. Los usuarios son excelentes describiendo síntomas y poco fiables prescribiendo soluciones, porque no saben qué es barato o caro de construir, y no están pensando en los otros doce lugares de la aplicación donde habría que respetar ese interruptor.
El destrozo aquí se acumula. Recibes cinco solicitudes de funciones en una semana, implementas las cinco de forma literal, y ahora tienes un panel de configuración con un interruptor de modo oscuro, un interruptor de "vista compacta", un interruptor de "ocultar barra lateral" y una casilla de "modo simple" que contradice a medias a las otras tres. Nadie pidió un panel de configuración. Tú construiste uno igualmente, una solicitud literal a la vez, y ahora cada función nueva hay que probarla contra un lío combinatorio de estados de interruptores que nadie recuerda haber activado.
La solicitud es información. No es la especificación. Tu trabajo es el paso de traducción intermedio, y saltárselo es la forma más común de que los comentarios se conviertan en sobrecarga de funciones.
Error dos: quedarse en silencio y luego soltarlo todo de golpe
El fallo opuesto parece disciplinado desde fuera. No reaccionas a cada mensaje a medida que llega —buen instinto, en general—. Pero luego dejas que se acumulen dos semanas de tickets en una hoja de cálculo, y un sábado te sientas y escribes un único prompt enorme: "corrige el error del pago, añade la función de exportación, rediseña el flujo de incorporación, corrige la navegación móvil y actualiza el texto de la página de precios".
El creador de aplicaciones hará todo lo posible con eso, pero acabas de pedir cinco cambios no relacionados en una sola pasada, en una base de código donde esas cinco cosas probablemente afectan archivos superpuestos. Cuando algo se rompe —y con un cambio de ese tamaño, algo suele romperse— no puedes saber cuál de las cinco solicitudes lo causó. Tu historial de versiones muestra un diff gigantesco en lugar de cinco revisables por separado. Si necesitas revertir la corrección del pago porque introdujo una regresión, también revertirás el rediseño de incorporación que funcionaba bien. El registro de verificación de esa ejecución es un muro de cambios que nadie, ni siquiera tú, va a leer línea por línea.
Agrupar parece eficiente. En realidad es todo lo contrario en el momento en que algo del lote falla, porque ahora depurar significa desenredar cinco hilos en lugar de seguir uno.
Error tres: dejar que el mensaje más ruidoso marque la hoja de ruta
Este es el más difícil de notar mientras lo estás haciendo. Un usuario envía un correo enfadado, detallado y bien argumentado sobre una función que quiere. Está bien escrito, es específico, claramente le tomó diez minutos redactarlo —y diez minutos de la atención real de alguien parecen merecer diez minutos de la tuya—. Así que dejas lo que estabas haciendo y la construyes.
Mientras tanto, cuarenta usuarios más silenciosos se topan cada semana con el mismo paso confuso de registro y simplemente se van. Ninguno de ellos te escribe un párrafo al respecto. No envían nada en absoluto: simplemente no vuelven, y ese silencio nunca aparece en tu bandeja de entrada exigiendo una respuesta. La cantidad de palabras y la actualidad de un mensaje no son lo mismo que la importancia, pero lo parecen, especialmente a las 11 de la noche cuando un mensaje está frente a ti y cuarenta no conversiones están en un panel de análisis que no has abierto.
| Error | Cómo se ve | El destrozo |
|---|---|---|
| Implementación literal | Usar en el prompt las palabras exactas del usuario, sin examinarlas | Sobrecarga de funciones, interruptores contradictorios, proliferación de configuraciones |
| Agrupar y volcar | Silencio, seguido de un prompt gigante con múltiples solicitudes | Diffs no revisables, reversiones difíciles, regresiones misteriosas |
| Hoja de ruta guiada por la voz más ruidosa | Reaccionar a quien haya escrito más recientemente o con más insistencia | Perseguir casos extremos mientras el verdadero punto de abandono queda sin resolver |
Cómo es en realidad el prompt correcto
La solución no es un diagrama de proceso, es un hábito: lee el mensaje y luego pregúntate qué hay detrás antes de tocar siquiera el chat de construcción. Cuando aparece ese usuario que pide modo oscuro, la necesidad real suele ser "reducir la fatiga visual de noche", y la respuesta más barata y mejor suele ser "respetar la preferencia de esquema de color del sistema operativo" — una línea, sin nueva interfaz, sin interruptor que mantener. Cuando llegan cinco tickets en una semana, busca el patrón antes de escribir nada: si tres son en realidad la misma confusión descrita de tres formas distintas, eso es un solo prompt, no tres.
Mantén los cambios enfocados en un solo propósito incluso cuando la motivación sea avanzar rápido. "Corregir el error de checkout donde los usuarios invitados pierden su carrito al recargar" es un prompt que puedes verificar de una sola vez y revertir limpiamente si no funciona. También te deja una tarjeta de versión que significa algo seis semanas después, en lugar de una entrada de changelog que solo dice "varias correcciones".
Y pondera los comentarios por patrón, no por volumen de sentimiento. Una queja breve y directa que también sufrieron otros tres usuarios merece el próximo prompt más que una petición elocuente de alguien que describe un flujo de trabajo que nadie más usa. Aquí es donde observar realmente el uso —dónde abandonan las personas, en qué hacen clic antes de irse— demuestra su valor, porque te dice qué está haciendo la mayoría silenciosa mientras la minoría ruidosa te escribe correos.
Nada de esto significa ignorar a los usuarios que se toman el tiempo de escribirte. Significa no dejar que "quién me escribió más recientemente y de forma más persuasiva" sea el algoritmo que decide qué se construye a continuación. El mensaje es el inicio de la conversación, no el ticket. La traducción de lo que alguien dijo a lo que realmente le pides al builder sigue siendo tuya, cada vez.
