Microcopy de producto: quién escribe y cuándo se revisa

Microcopy de producto es el texto que hace funcionar la interfaz: etiqueta de campo, mensaje de error, estado vacío, confirmación de acción destructiva y texto de espera. Eso es diseño de interacción, no texto de marketing. Quién escribe importa menos que el momento en que el texto entra al proceso y el criterio con que se revisa.

Tres tipos de texto, tres dueños distintos

Microcopy es el texto más corto del producto, y el único que cambia un estado.

Contenido editorial es el texto largo: artículo, página de ayuda, nota de versión. Vive en un CMS, se lee en secuencia y cambia sin un nuevo despliegue.

Texto de marketing pertenece a la campaña: anuncio, landing page, correo. Vive en un calendario y muere con la campaña.

El problema empieza cuando los tres se mezclan. Un titular de landing page dentro de un estado vacío convierte el siguiente paso en un discurso de venta.

Carbon declara que sus guías de contenido son para quien escribe o revisa texto en las interfaces de producto de IBM (Carbon, Content (en inglés)). Y tiene sentido. El texto de interfaz no es trabajo de un departamento aparte.

Por qué el microcopy es parte del diseño de la interacción

El texto no es leyenda del componente. Es el componente en un estado.

Material Design dice que todo campo de texto debe tener etiqueta, siempre visible y nunca truncada (Material 3, Text fields (en inglés)). WCAG exige etiquetas o instrucciones que identifiquen los controles de un formulario (W3C, 3.3.2 Labels or Instructions (en inglés)).

Nielsen Norman Group resume la división del trabajo en una línea: quien escribe usa palabras en lugar de píxeles para comunicarse con el usuario (NN/g, UX Writing Study Guide (en inglés)).

GOV.UK agrega la prueba. Si tienes que explicar cómo funciona la interfaz, el problema es la interfaz (GOV.UK, Writing for user interfaces (en inglés)).

Cuándo entra el texto al proceso

El texto va antes del layout, no después.

El texto que llega después de la pantalla diseñada se vuelve leyenda de decisiones ya tomadas. Un estado que nadie puede nombrar suele ser un estado que nadie diseñó.

Carbon hace las preguntas en ese orden: cómo queda la página sin contenido y qué pasos puede dar el usuario para llenarla (Carbon, Empty states (en inglés)).

GOV.UK pide que el equipo sepa por qué hace cada pregunta y corte lo que no necesita (GOV.UK, Question pages (en inglés)).

Escribir el texto primero es una prueba de alcance. La frase que no se puede escribir suele ser un estado que no existe. El mismo orden aparece en el trabajo de estado vacío y carga y en el de formulario de un solo campo.

Quién escribe cuando no hay UX writer

Quien es dueño del estado escribe el texto. No el diseñador por defecto, y no la mejor pluma del equipo.

En la mayoría de los equipos, el diseñador de producto escribe la etiqueta y el estado vacío. Soporte escribe el error que ya explica por ticket, e ingeniería escribe el mensaje que dispara el sistema.

Quien cuida la pantalla escribe su texto, sea cual sea su cargo.

Un equipo sin writer no necesita un cargo nuevo. Necesita que el texto entre al proceso con el mismo dueño del estado que describe.

Mensaje de error

GOV.UK exige que el mensaje diga qué salió mal y cómo corregirlo (GOV.UK, Error message (en inglés)).

El mismo sistema exige un resumen de errores arriba de la página y un mensaje junto al campo con error (GOV.UK, Error summary (en inglés)).

WCAG pide que el error se describa en texto, con el ítem en error identificado (W3C, 3.3.1 Error Identification (en inglés)).

NN/g agrega posición y momento: muestra el mensaje cerca del origen y no lo muestres antes de que el usuario termine (NN/g, Error-Message Guidelines (en inglés)).

Lo difícil es saber cuándo ser específico deja de ayudar. Un mensaje que lista todas las causas posibles queda más largo que la acción que bloquea.

Material recomienda reemplazar el texto de apoyo por el texto de error, para que el layout no salte cuando aparece el mensaje (Material 3, Text fields (en inglés)).

Estado vacío

Carbon advierte que el estado vacío suele tratarse como detalle de última hora, y pide título escrito como afirmación positiva (Carbon, Empty states (en inglés)).

La misma página también pone un límite. Más contenido no es mejor solución, porque cada línea en la página tiene costo cognitivo.

NN/g trata el estado vacío de aplicación compleja como problema propio, con tres guías (NN/g, Designing Empty States in Complex Applications (en inglés)).

El estado vacío es el único lugar donde un texto más largo suele valer la pena. Tiene espacio, el usuario no tiene nada que leer y la próxima acción es el mensaje. Cuánto texto lee de verdad una persona en pantalla tiene medición propia, reunida en tipografía y lectura en pantalla.

Etiqueta de campo

Material mantiene la etiqueta visible, alineada al texto escrito, corta y nunca truncada (Material 3, Text fields (en inglés)).

GOV.UK pide una pregunta por página y marca el campo opcional como opcional (GOV.UK, Question pages (en inglés)).

La etiqueta también es el nombre accesible del campo, y por eso WCAG la exige (W3C, 3.3.2 Labels or Instructions (en inglés)).

El límite: una etiqueta que necesita un párrafo de explicación es un campo que no debería existir. GOV.UK enuncia la regla como empieza con menos (GOV.UK, Writing for user interfaces (en inglés)).

Confirmación de acción destructiva

Material afirma que los diálogos son interrupciones por definición, así que deben usarse con moderación (Material 3, Dialogs (en inglés)).

NN/g advierte contra la confirmación de rutina, porque un diálogo que todos descartan no protege a nadie, y pide especificidad con el nombre y la cantidad de registros (NN/g, Confirmation Dialogs (en inglés)).

WCAG pide que los envíos legales, financieros y de datos sean reversibles, verificables o confirmados (W3C, 3.3.4 Error Prevention (en inglés)).

La etiqueta del botón es el control más barato. “Eliminar 3 registros” evita más error que un diálogo que repite la palabra “eliminar”.

Texto de espera

NN/g midió tres límites: 0,1 segundo para manipulación directa, 1 segundo para el hilo de pensamiento y 10 segundos para la atención (NN/g, Response Time Limits (en inglés)).

Debajo de un segundo, el texto de respuesta solo agrega ruido.

Carbon pone esqueleto de carga en contenedores, indicador de progreso cuando la espera pasa de un instante y notificación cuando el proceso tarda minutos (Carbon, Loading (en inglés)).

La regla: el texto existe para responder lo que la interfaz no puede responder de forma visual. Cuando la pantalla ya muestra movimiento, la palabra “cargando” es decoración.

El criterio de revisión

La revisión ocurre por criterio, no por preferencia. Cuatro chequeos atrapan la mayor parte del texto malo de una interfaz.

¿El texto nombra el estado? “Sin resultados” lo nombra, y “Algo salió mal” lo esconde.

¿El texto dice cuál es la próxima acción? Un mensaje sin próximo paso es un callejón sin salida, solo que educado.

¿Es la versión más corta que todavía funciona? GOV.UK enuncia la regla como empieza con menos (GOV.UK, Writing for user interfaces (en inglés)).

¿Sobrevive a la traducción y al lector de pantalla? Un texto que solo funciona en un idioma no está listo, que es el mismo problema descrito en design system después del lanzamiento.

La pregunta de tono viene después de estas cuatro, no antes.

Cuándo el mensaje genérico es la respuesta correcta

Cuatro casos donde gana lo corto y genérico.

La causa es desconocida, o la lista saldría mal. Un mensaje que adivina enseña al usuario a desconfiar de todos los demás.

El texto específico confirmaría información que el sistema no debe confirmar. Login, recuperación, existencia de cuenta.

El estado ya fue aprendido. Quien vio el mismo error tres veces no lee el cuarto.

El texto específico es más largo que la acción que protege. “Tu sesión expiró, vuelve a entrar con las credenciales que usaste antes” pierde contra “Sesión expirada, entra de nuevo”.

GOV.UK afirma que no hace falta decir lo siento en un mensaje de validación. También dice que no hay lugar para el humor en un servicio que la persona usa bajo estrés (GOV.UK, Writing for user interfaces (en inglés)).

La regla es sobre costo, no sobre tono.