UX writing: cómo escribir botones, errores y mensajes que guían al usuario

Hace poco revisábamos el panel de reservas de un hotel boutique con el que trabajamos. El diseño estaba cuidado, las fotos eran preciosas y aun así el equipo de recepción recibía cada semana las mismas llamadas: «¿Me ha llegado la reserva o no?». El problema estaba en tres palabras. Al terminar el pago, la pantalla decía «Proceso completado» y nada más. Nadie sabía si eso significaba reserva confirmada, pago pendiente o solicitud enviada.

Cambiamos ese mensaje por «Reserva confirmada. Te hemos enviado los detalles a tu correo» y añadimos el número de reserva bien visible. Las llamadas bajaron de forma clara en pocas semanas. Ni un píxel de diseño cambió. Eso es UX writing: escribir las palabras de una interfaz con la misma intención con la que se diseñan sus botones y sus pantallas.

En esta guía te cuento cómo lo trabajamos en el estudio: los principios que usamos, cómo adaptar el tono a cada situación, patrones concretos para los componentes más habituales y un método para escribir, revisar y probar textos sin necesitar un gran equipo.

01Qué es el UX writing y en qué se diferencia del copy

El UX writing es la redacción de todos los textos que una persona lee mientras usa un producto digital: botones, etiquetas de formulario, menús, avisos, mensajes de confirmación, estados vacíos, notificaciones, textos de ayuda. Su objetivo es que la persona entienda dónde está, qué puede hacer y qué va a pasar después.

El copywriting, que contamos en qué es el copywriting, trabaja sobre todo la persuasión: el titular que engancha, el anuncio que despierta curiosidad, la página de servicio que convence. El UX writing trabaja la comprensión y la acción. Uno abre la puerta; el otro acompaña a la persona una vez dentro.

Hay una idea que lo resume bien. La interfaz es una conversación entre el producto y quien lo usa, solo que una de las partes no puede improvisar. Cada respuesta del producto tiene que estar escrita de antemano, para cada situación posible, incluidas las que salen mal. Por eso el UX writing es tanto una tarea de escritura como de diseño de sistemas.

Por qué el texto pesa tanto en la experiencia

Jakob Nielsen y su equipo midieron hace años que, en una página web media, la gente lee como mucho alrededor del 28 % de las palabras. Escanea, salta, busca anclas. En una interfaz esa lectura es todavía más rápida: nadie lee un botón, lo reconoce. Eso significa que cada palabra tiene que estar donde la mirada la encuentre y decir lo esencial al principio.

Y significa también que, cuando el texto está bien, nadie lo nota. Es la parte del diseño que mejor funciona cuanto más invisible resulta.

02Cuatro principios que usamos en cada pantalla

Hay muchos marcos para el UX writing. En el estudio trabajamos con cuatro principios sencillos que nos sirven de filtro antes de dar un texto por bueno.

1. 01Claro. Usa las palabras que usa tu cliente, no las de tu organigrama. Si en el restaurante la gente dice «reservar mesa», el botón no dice «Solicitar disponibilidad».
2. 02Conciso. Quita todo lo que no ayude a decidir o a actuar. Menos palabras no es el objetivo; el objetivo es que cada una trabaje.
3. 03Útil. Cada texto responde a una pregunta que la persona tiene en ese momento: ¿qué es esto?, ¿qué pasa si pulso?, ¿qué hago ahora?
4. 04Humano. Escribe como hablaría una persona amable y competente de tu equipo. Ni robótico ni excesivamente chistoso.

Lo esencial, delante

La mirada lee las primeras palabras de cada línea y decide si sigue. Por eso funciona poner primero lo que importa: «Pedido enviado: llegará el jueves» se entiende antes que «Te informamos de que tu pedido ya ha sido enviado y llegará previsiblemente el jueves». Lo mismo con las opciones de un menú o los elementos de una lista: empieza por la palabra que distingue cada opción de las demás.

Un concepto, una palabra

Si en una pantalla hablas de «pedido», en otra de «compra» y en el correo de «orden», la persona se pregunta si son tres cosas distintas. La consistencia terminológica es una de las mejoras más baratas y con más efecto. Se resuelve con un glosario compartido, del que hablaremos más abajo.

03Voz constante, tono que se adapta

La voz es la personalidad de la marca y no cambia: cercana, experta, tranquila, divertida. El tono es cómo esa voz se ajusta al momento, igual que tú hablas de una forma con un amigo que celebra algo y de otra con uno que tiene un problema. Si tu marca ya tiene definido su tono de voz, el UX writing es donde ese tono se pone a prueba cada día.

Esta tabla es la que solemos usar como punto de partida para decidir el tono según la situación:

04Patrones de UX writing por componente

Cada componente tiene sus propias reglas. Aquí van los patrones que más usamos, con ejemplos que puedes adaptar.

Botones y enlaces

Un botón es una promesa de lo que va a ocurrir. Funciona cuando empieza por un verbo y nombra el objeto: «Descargar presupuesto», «Añadir al carrito», «Crear cuenta». Los genéricos como «Aceptar», «Enviar» o «Continuar» obligan a leer el contexto para saber qué hacen. En los diálogos de confirmación esto se nota mucho: «Eliminar proyecto» y «Mantener proyecto» se entienden sin leer la pregunta; «Sí» y «No» no. La parte visual de los botones, con sus jerarquías y estados, la tratamos en botones en UI.

En los enlaces, el texto tiene que tener sentido por sí solo, porque los lectores de pantalla permiten navegar saltando de enlace en enlace. «Consulta las condiciones de envío» funciona; «haz clic aquí» no dice nada fuera de contexto.

Etiquetas y textos de ayuda en formularios

La etiqueta nombra el dato con la palabra más común: «Teléfono», «Código postal». El texto de ayuda, debajo, explica el formato o el porqué: «Solo lo usaremos para avisarte si hay un cambio en tu cita». El placeholder (el texto gris dentro del campo) desaparece al escribir, así que lo reservamos para ejemplos de formato y dejamos la información importante fuera.

Mensajes de error

Un buen error dice qué ha pasado y cómo se arregla, en ese orden y sin culpar a nadie. «Introduce un correo con el formato nombre@dominio.com» es más útil que «Correo inválido». Le dedicamos una guía entera a la validación, el tono y la recuperación, porque da para mucho.

Confirmaciones y estados de éxito

El momento después de actuar es donde más dudas aparecen, como en el caso del hotel. Una buena confirmación dice qué ha pasado, qué viene ahora y dónde encontrar la información: «Cita reservada para el martes 14 a las 10:00. Te enviaremos un recordatorio el día antes».

Estados vacíos

Una pantalla sin datos es una oportunidad de orientar. En lugar de «No hay resultados», funciona explicar por qué está vacía y qué hacer: «Todavía no tienes facturas. Cuando emitas la primera, aparecerá aquí» y un botón para crearla.

Notificaciones y avisos

Un aviso compite con lo que la persona estaba haciendo, así que tiene que justificar la interrupción. La primera frase lleva el dato; la segunda, si hace falta, la acción. «Tu suscripción se renueva el 3 de mayo. Revisa tu método de pago».

05Una guía de estilo mínima para no improvisar

En cuanto hay más de una persona escribiendo textos (diseño, desarrollo, atención al cliente, marketing), la interfaz empieza a hablar con varias voces. Una guía de estilo de UX writing lo evita. No necesita ser un manual de cien páginas: con dos o tres bien pensadas basta para empezar.

Lo que incluimos siempre:

• →Tratamiento: tú o usted, y cómo se dirige el producto a sí mismo (primera persona del plural, «hemos», o impersonal).
• →Glosario: las palabras clave del producto y los sinónimos que dejamos fuera. «Reserva», nunca «booking» ni «solicitud».
• →Mayúsculas: en español, solo la inicial en botones y títulos («Guardar cambios», no «Guardar Cambios»).
• →Formato de fechas, horas y precios: «martes 14 de abril», «10:00», «25 €» con espacio antes del símbolo, como recomienda la RAE.
• →Números: cifras siempre en interfaz, porque se escanean mejor que las palabras.
• →Lenguaje inclusivo: fórmulas que funcionan sin desdoblar, como «te damos la bienvenida» en lugar de «bienvenido».
• →Patrones de componentes: la estructura de un error, de una confirmación, de un estado vacío, con un ejemplo de cada.

Los textos también viven en el código

En productos digitales, los textos suelen guardarse en archivos de cadenas separados del diseño, sobre todo si hay varios idiomas. Ponerles nombres que describan su función ayuda a mantener la coherencia y facilita la revisión. Algo así:

{
  "booking.confirm.title": "Reserva confirmada",
  "booking.confirm.body": "Te hemos enviado los detalles a {email}.",
  "booking.cancel.dialog.title": "¿Cancelar la reserva del {date}?",
  "booking.cancel.dialog.primary": "Cancelar reserva",
  "booking.cancel.dialog.secondary": "Mantener reserva",
  "booking.empty.title": "Todavía no tienes reservas",
  "booking.empty.action": "Hacer mi primera reserva"
}

Cuando los textos están así de ordenados, revisar el tono de todo un flujo es cuestión de leer un archivo, y traducirlo o adaptarlo a otro mercado resulta mucho más sencillo.

06Cómo escribimos los textos de una interfaz, paso a paso

En los proyectos de diseño web y experiencia digital que hacemos en el estudio, los textos entran en el proceso desde el principio. Este es el método que seguimos:

1. 01Escuchar cómo habla tu cliente. Revisamos correos, reseñas, consultas por WhatsApp y, si es posible, hablamos con algunas personas. De ahí salen las palabras reales que usarán los textos.
2. 02Mapear el flujo y sus momentos. Para cada paso anotamos qué sabe la persona, qué necesita saber y qué puede salir mal.
3. 03Escribir con contenido real en los wireframes. Nada de texto de relleno: un botón con «Lorem ipsum» esconde problemas de espacio y de jerarquía que aparecen tarde.
4. 04Escribir también los caminos alternativos. Errores, esperas, estados vacíos, sesiones caducadas. Suelen ser la mitad de los textos de un producto.
5. 05Recortar. Primera versión larga, segunda versión con la mitad de palabras. Casi siempre la segunda es mejor.
6. 06Revisar en voz alta. Si suena raro dicho por una persona del equipo, suena raro escrito.
7. 07Probar con usuarios. En los test de usabilidad prestamos atención a las dudas que aparecen ante un texto: ese titubeo es la señal más clara.
8. 08Documentar en la guía de estilo los patrones nuevos que hayan surgido.

Dos pruebas rápidas para comprobar tus textos

La prueba del subrayador. Imprime una pantalla y pide a dos o tres personas que marquen en verde lo que les da confianza o les aclara algo, y en rojo lo que les confunde o les sobra. En media hora tienes un mapa muy fiel de qué funciona.

La prueba de completar huecos. Quita una de cada cinco o seis palabras de un texto de ayuda y pide a alguien que las rellene. Si acierta la mayoría, el texto es predecible y se entiende sin esfuerzo. Es una adaptación de la conocida prueba cloze que se usa para medir comprensión lectora.

Para la legibilidad general existen índices adaptados al español, como la escala INFLESZ basada en el índice de Szigriszt-Pazos, que muchas herramientas de redacción calculan automáticamente. Son una orientación útil; la última palabra la tiene siempre la reacción de personas reales.

07Errores frecuentes y lo que funciona en su lugar

Cuando auditamos interfaces, los mismos patrones se repiten. Te los dejo formulados en positivo, para que sirvan de lista de revisión:

• →Lo que funciona es hablar de beneficios para la persona, no de procesos internos: «Recibe tu pedido mañana» en lugar de «Envío procesado por el centro logístico».
• →Lo que funciona es un verbo concreto en cada botón, en lugar de «Aceptar» o «Enviar».
• →Lo que funciona es explicar la consecuencia antes de una acción importante, con el número exacto de elementos afectados.
• →Lo que funciona es nombrar las cosas igual en todas partes: interfaz, correos, facturas y atención telefónica.
• →Lo que funciona es escribir el texto antes de diseñar el componente, para que el diseño se adapte al mensaje y no al revés.
• →Lo que funciona es la voz activa: «Hemos recibido tu pago» se lee mejor que «Su pago ha sido recibido».

Todo esto ayuda además a reducir la carga cognitiva: cada palabra que la persona no tiene que interpretar es energía que puede dedicar a decidir.

08Las palabras también son diseño

El buen UX writing apenas se ve. Lo que se nota es que todo se entiende a la primera, que los botones hacen lo que prometen y que, cuando algo sale mal, la interfaz te echa una mano en lugar de dejarte solo. Detrás hay criterio, escucha y muchas versiones descartadas.

En SIMA tratamos los textos como parte del diseño desde el primer boceto, junto a la estructura y la forma, porque una interfaz bien escrita es una interfaz más amable. Si sientes que tu web o tu aplicación podría explicarse mejor, escríbenos y revisamos juntos sus palabras.