El texto de un botón es una decisión de producto, no un detalle de último momento
Hay una prueba rápida para saber si un equipo trata al microcopy como decisión de producto o como relleno final: fijate quién escribe los mensajes de error. Si la respuesta es "el que estaba programando esa pantalla, cinco minutos antes de subir a producción", ya sabés el resultado: "Algo salió mal. Intentá de nuevo."
Ese mensaje no dice qué salió mal, no dice qué hacer, y no asume ninguna responsabilidad. Es la versión textual de encogerse de hombros.
Por qué el microcopy es diseño de producto y no redacción
El texto de una interfaz no describe la interfaz. Es la interfaz, en el momento exacto en que alguien necesita decidir algo. Un botón que dice "Enviar" y uno que dice "Confirmar pedido" activan la misma función en el código y producen experiencias distintas. Uno suena reversible, el otro suena a que ya no hay vuelta atrás. En un checkout, esa diferencia cambia si alguien duda un segundo antes de tocarlo. Las pautas de escritura para interfaces de Nielsen Norman llevan años insistiendo con eso.
Y a diferencia de un color o una animación, el texto no se puede "aproximar". Un botón dice exactamente una cosa. Si esa cosa está mal elegida, no hay margen de interpretación que lo salve.
Los tres lugares donde más se nota
Estados vacíos. "No hay resultados" es información. "Todavía no armaste ningún proyecto — creá el primero para empezar" es una invitación. Un estado vacío bien escrito convierte el momento más deprimente de una interfaz —la pantalla en blanco— en el primer empujón hacia usar el producto.
Mensajes de error. Un buen mensaje de error contesta dos preguntas: qué pasó y qué hago ahora. "El email ya está registrado" contesta la primera y deja a la persona sola con la segunda. "Ese email ya tiene una cuenta — ¿querés iniciar sesión en vez de crear una nueva?" contesta las dos y además ofrece la salida.
Confirmaciones de acción irreversible. "¿Estás seguro?" no le da a nadie información nueva para decidir. "Esto va a eliminar los 34 socios cargados y no se puede deshacer" sí. La diferencia entre las dos frases es la diferencia entre una confirmación que se aprieta sin leer y una que realmente hace pensar dos segundos antes.
Por qué escribirlo al final sale caro
Cuando el microcopy se escribe al final, hereda los espacios que el diseño visual dejó libres, no los que el mensaje necesita. Un botón diseñado para tres palabras no tiene lugar para la frase que explica la acción. El texto se acorta hasta perder claridad, no porque fuera la mejor versión, sino porque fue la única que entraba.
Escribir el copy en paralelo al diseño evita ese problema. Si un mensaje necesita más espacio para ser claro, el layout se ajusta al mensaje y no al revés.
Un ejemplo de cómo esto cambia una decisión real
En el rediseño de Mexx, uno de los hallazgos fue que los productos digitales llegaban al checkout con costos de envío físico sin explicación. Parte de la solución no fue solo técnica —desglosar el costo antes— sino textual: la etiqueta "Producto digital — sin envío" en la tarjeta del producto, antes de que la persona llegara siquiera al carrito.
Esa etiqueta es dos palabras y un guion. Y forma parte de la razón por la que la tarea de transparencia de costos bajó su tasa de abandono en el test de usabilidad posterior. El texto no fue decoración de la solución. Fue la solución, en parte.
Cómo lo integro en el proceso
Escribo el copy de cada pantalla en el mismo momento en que diseño el flujo, no en una pasada final antes de entregar. Para los mensajes que importan de verdad —errores, confirmaciones irreversibles, estados vacíos— escribo dos o tres versiones y elijo contestando una pregunta: ¿esta frase le dice a la persona qué pasó y qué puede hacer? Si no contesta las dos, no está terminada, sin importar cuán prolija se vea.
Es la misma lógica que aplico al resto de la interfaz: nada se considera terminado hasta que se puede usar sin adivinar. Por eso el copy entra en el mismo momento que los estados de error, y no en una pasada aparte.
Seguí leyendo
- Mis personas de UX no tienen foto de stock (y por eso sirven)Una persona con nombre inventado y una sonrisa de banco de imágenes es decoración de informe. Cómo construyo personas que en realidad cambian una decisión de diseño.
- Construir y sostener un SaaS: lo que cambia cuando hay clientes pagandoHay una diferencia enorme entre construir un producto y sostenerlo un martes a las 3am cuando falla un webhook de pago. Lo que aprendí llevando GymSmartAccess de idea a negocio real.