Qué debe decir tu app cuando falla: cómo escribir mensajes de error que la gente realmente entiende

Toda app falla alguna vez. Se cae el internet, un servidor tiene un hipo, alguien escribe un número de teléfono con letras. Esa parte no puedes evitarla del todo. Lo que sí puedes controlar es el mensaje de error —el texto que muestra tu app cuando algo sale mal— y ese único mensaje suele marcar la diferencia entre un usuario que se encoge de hombros e intenta de nuevo, y un usuario que en silencio decide que tu app está rota y no vuelve jamás.

La mayoría de las apps construidas con IA fallan justo en este momento. No porque el builder haya sido descuidado, sino porque los mensajes de error son la parte en la que nadie piensa hasta que algo sale mal frente a una persona real. Por defecto, las apps tienden a mostrar una de dos peores cosas posibles: nada en absoluto, o un bloque aterrador de texto técnico. Arreglemos ambas.

¿Por qué las apps fallan en silencio o muestran mensajes de error aterradores?

Las apps fallan mal de dos formas: no dicen nada cuando algo falla, o muestran un error técnico que una persona normal no puede leer. Ambas dejan al usuario adivinando, y adivinar es lo que hace que la gente se rinda.

El fallo silencioso. Una freelancer a quien llamaré Maya construyó un formulario de reservas para su negocio de fotografía. Una clienta tocó “Confirmar reserva”, el botón parpadeó y… nada. Sin confirmación, sin error, sin ícono de carga. ¿Funcionó? La clienta no estaba segura, así que reservó otra vez. Ahora Maya tenía dos reservas para el mismo horario y una clienta confundida. La app no se había caído: el guardado simplemente falló, y la app no dijo nada, así que la persona frente a ella no tenía idea de cuál era la realidad.

El error técnico aterrador. El otro fallo es más ruidoso y, de algún modo, peor. Una voluntaria que organizaba una recaudación de fondos comunitaria intentó subir una hoja de cálculo y recibió un cuadro rojo que decía Error 500: Internal Server Error. Lo leyó como “rompí algo”. No volvió a intentarlo, no escribió pidiendo ayuda, simplemente cerró la pestaña, porque el mensaje hacía que el problema sonara como su culpa y como si tal vez no fuera seguro tocarlo de nuevo.

Ambas usuarias se toparon con un problema normal y recuperable. Ambas se fueron, porque los mensajes de error de la app o no decían nada, o decían algo aterrador.

¿Qué hace bueno a un mensaje de error?

Un buen mensaje de error hace cuatro cosas pequeñas, en palabras simples: dice qué pasó, dice de quién es el problema, dice qué hacer a continuación, y no pierde el trabajo del usuario.

Dice qué pasó — “No pudimos guardar tu reserva”, no el silencio y no 500.
Dice de quién es el problema — normalmente la respuesta honesta es “nuestro”, y decirlo tranquiliza a la gente.
Dice qué hacer a continuación — “Intenta de nuevo en un momento” o “Revisa tu conexión a internet e intenta otra vez”.
No pierde su trabajo — lo que sea que hayan escrito sigue ahí en el formulario cuando aparece el mensaje.

Eso es todo. Sin ensayo de disculpas, sin código de error como titular, sin culpar a nadie. Aquí están los mismos tres fallos, reescritos:

❌ (no pasa nada) → ✅ “No pudimos guardar eso justo ahora. Tus datos siguen aquí: toca Confirmar para intentar de nuevo.”
❌ Error 500: Internal Server Error → ✅ “Algo salió mal de nuestro lado al subir ese archivo. No es culpa tuya. Inténtalo de nuevo en un minuto.”
❌ Invalid input → ✅ “Ese número de teléfono no se ve bien; debería tener 10 dígitos, como 555-123-4567.”

Nota que el último señala el campo específico y muestra cómo debería verse. “Entrada inválida” hace que la persona tenga que adivinar; “ese teléfono debería tener 10 dígitos” le dice exactamente qué cambiar.

¿Qué errores de la app deberías arreglar primero?

No necesitas un mensaje personalizado para cada fallo posible: tres cubren casi todo lo que puede salir mal en una app típica: el guardado o envío que falla, la entrada que la app no puede usar, y lo que se rompe de tu lado.

El guardado o envío que falla. El que más destruye la confianza, porque el usuario hizo todo bien y no está seguro de si funcionó. Confirma siempre el éxito y explica el fallo. Nunca lo dejes adivinando, y nunca botes lo que escribió.

El “no podemos usar lo que escribiste” (validación). Esto en realidad no es un error, es un malentendido. Captúralo en el momento en que la persona sale del campo, señala el campo exacto, y muestra un ejemplo del formato correcto. No esperes a que toque Enviar para revelar una pared de rojo.

El “algo de nuestro lado se rompió”. Problemas genuinos de servidor o de red. Di que es de tu lado, mantén la calma, y dales la opción de reintentar. El usuario no puede arreglar tu servidor, así que no lo hagas sentir que tiene que hacerlo.

Tres hábitos que ayudan en silencio

Hay unas cuantas cosas que separan a las apps que manejan bien los fallos de las que no:

Nunca muestres un código de error crudo como todo el mensaje. Un código puede ir en letra pequeña abajo para soporte, pero el titular que lee un humano debe ser una oración, no ERR_CONN_RESET.
Nunca culpes al usuario. “Ingresaste algo mal” duele; “esa fecha parece estar en el pasado, ¿quisiste decir el próximo mes?” ayuda. La misma información, un sentimiento completamente distinto.
Conserva siempre su entrada. Si la app se recarga o el guardado falla y el formulario se vacía, convertiste un pequeño tropiezo en diez minutos de volver a escribir todo. La gente perdona un guardado fallido. No perdona tener que hacer el trabajo dos veces.

¿Cómo logras que tu AI builder escriba mejores mensajes de error?

Puedes conseguir la mayor parte de esto en una sola petición: pega algo como el siguiente prompt y tu AI builder aplicará las reglas de lenguaje simple de arriba en toda tu app.

“Cuando un guardado o una subida de archivo falle, no falles en silencio y no muestres un código de error técnico. Muestra un mensaje corto y amigable en lenguaje simple que diga qué pasó, diga que está bien intentar de nuevo, y conserve lo que el usuario ya escribió. Para los campos de un formulario, valida cuando el usuario sale de cada campo y muestra un mensaje específico con un ejemplo del formato correcto.”

Luego pídele que te explique qué pasa en tres casos: cuando no hay internet, cuando un campo obligatorio está vacío, y cuando el servidor va lento. Si la respuesta a cualquiera de ellos es “no muestra nada” o “muestra el error crudo”, ese es tu próximo arreglo.

¿Cómo pruebas los mensajes de error de tu app?

Apaga tu wifi, abre tu app, e intenta hacer lo principal: esa es toda la prueba, y toma dos minutos.

Reserva el horario, guarda la nota, sube el archivo. Observa qué dice. ¿Le dijo algo que una persona normal entendería? ¿Perdió lo que escribiste? Ahora vuelve a encender el wifi y escribe deliberadamente algo incorrecto en un campo. Las mismas preguntas.

La mayoría de las apps fallan esta prueba la primera vez, y está bien: solo te muestra exactamente por dónde empezar. No tienes que hacer perfecto cada mensaje de error. Encuentra la cosa que más se rompe en tu app, y haz que ese mensaje sea amable, claro y honesto primero. La próxima vez que una persona real lo encuentre, intentará de nuevo en lugar de irse, y volver a intentar es todo el juego.