El UX writing es el texto que guía al usuario dentro de una interfaz: botones, mensajes de error, formularios, notificaciones. Cuando funciona, casi no se nota. Cuando falla, el usuario se queda parado sin saber qué hacer o abandona directamente. Estos son los fallos que más vemos en proyectos reales y cómo solucionarlos.
1. Lenguaje técnico que nadie entiende
Un usuario medio no sabe qué es un “token de sesión” ni un “error 403”, y no debería hacer falta que lo sepa. Cambia el término técnico por lo que le pasa de verdad, como “tu sesión ha caducado, vuelve a iniciar sesión” en lugar de mostrar un código de error pelado. Si en algún caso el término técnico es inevitable, añade una explicación breve al lado.
2. Tono inconsistente entre pantallas
Si un botón tutea y el mensaje de error de al lado usa “usted”, el usuario nota el cambio aunque no sepa explicar por qué. Define una guía de estilo corta desde el principio del proyecto, con el tono, el tratamiento (tú o usted) y un par de ejemplos de cómo suena bien y cómo suena mal, para que cualquiera que escriba textos de producto la pueda seguir sin dudar.
3. Textos pensados desde la empresa, no desde el usuario
Es fácil escribir lo que la empresa quiere contar en lugar de lo que el usuario necesita saber en ese momento exacto de la pantalla. La forma de evitarlo pasa por hacer pruebas de usuario con cierta regularidad y preguntarte, en cada texto, qué está pensando la persona justo antes de leerlo.
4. Textos demasiado largos para una pantalla pequeña
La mayoría de tus usuarios leen desde el móvil, y un bloque de texto largo en una pantalla pequeña se salta o se lee por encima. Recorta cada frase a lo esencial, corta los párrafos largos en trozos más cortos y revisa cada palabra: si no aporta nada, fuera.
5. Microcopys genéricos que no dicen nada
Los microcopys son los textos más pequeños de la interfaz (botones, avisos, mensajes de error) y también los que más se descuidan. Un “haz clic aquí” no dice nada, mientras que “añadir al carrito” o “continuar con la compra” dejan claro qué va a pasar al pulsar. Lo mismo con los errores: en vez de “algo ha fallado”, explica qué ha pasado y qué puede hacer el usuario para solucionarlo. Si quieres ver ejemplos aplicados a conversión real, tenemos un artículo sobre UX writing en webs corporativas y microcopy que convierte.
6. Textos que no encajan con la cultura del usuario
Una expresión coloquial que funciona perfectamente en España puede sonar rara o directamente no entenderse en otro país hispanohablante. Si el producto se dirige a público internacional, prueba los textos con usuarios de distintos países y evita referencias muy locales o chistes que dependan del contexto cultural.
7. No revisar ni corregir los textos con el tiempo
Un mensaje de error mal redactado que nadie ha tocado en dos años sigue generando la misma confusión el primer día que el último. Programa revisiones periódicas de los textos de la interfaz, apoyadas en pruebas de usabilidad, para detectar frases confusas antes de que acumulen quejas de soporte.
Ninguno de estos errores se corrige de un día para otro, pero sí se nota rápido cuando se empieza a trabajar con una guía de estilo clara y revisiones periódicas. Si además quieres entender cómo casan estos textos con el resto de decisiones de interfaz, en cómo equilibrar creatividad y funcionalidad en el diseño UI/UX lo desarrollamos con más detalle.
Preguntas frecuentes sobre errores de UX writing
¿Quién debe escribir los textos de la interfaz, diseño o marketing?
Lo ideal es que sea alguien especializado en UX writing que trabaje codo con codo con diseño de producto, no marketing por su cuenta. Los textos de interfaz responden a lógicas distintas a las de una campaña publicitaria.
¿Cuánto debe medir un microcopy?
No hay una cifra fija, pero la regla general es usar la mínima cantidad de palabras que transmita la acción sin ambigüedad. En botones, dos o tres palabras suelen bastar.
¿Cómo se detectan los errores de UX writing en una web ya publicada?
Con pruebas de usabilidad, grabaciones de sesión y revisando los tickets de soporte, ya que los mensajes que generan más consultas suelen ser los que hay que reescribir primero.
