Preguntas de entrevista Redactor UX

Empiezo por identificar lo que realmente siente la persona usuaria en ese momento, casi siempre frustración o incertidumbre, y escribo pensando en esa emoción y no en la lógica interna del sistema. Para un mensaje de error busco tres cosas con el mínimo de palabras posible: qué ha pasado, por qué le importa al usuario y qué hacer a continuación. Evito culpar al usuario o esconderme detrás de un código técnico como 'Error 403', salvo que el equipo de soporte realmente lo necesite, en cuyo caso lo coloco en un enlace de detalles y no en el titular. Para los estados vacíos, trato ese momento como una invitación y no como un callejón sin salida: en lugar de 'No se encontraron resultados', propongo un siguiente paso concreto, como ajustar un filtro o añadir el primer elemento. Siempre leo el texto en voz alta antes de publicarlo, porque una frase que parece correcta en una maqueta de Figma suena mecánica al pronunciarla, y esa suele ser la señal de que necesita otra vuelta.

Trato la guía de tono como una restricción que agiliza el trabajo, no como una jaula. Antes de escribir algo nuevo, reviso si ya existe un patrón para esa situación, porque la coherencia importa más para el usuario que una frase original en cada pantalla. Cuando una guía realmente no encaja con un caso nuevo, no la ignoro en silencio: señalo el vacío a quien gestiona el sistema de contenido y propongo una adición, con ejemplos, para que la próxima persona que redacte no choque con el mismo problema. También he hecho lo contrario, cuando una guía pensada para el tono de marketing terminó copiada en pantallas de producto donde sonaba demasiado informal para algo como un aviso de eliminación de datos. Trabajar dentro de un design system también significa construir textos como componentes reutilizables cuando tiene sentido, plantillas con variables en lugar de frases sueltas, para que el equipo de desarrollo pueda implementarlas de forma coherente sin volver a consultarme cada vez.

La brevedad es un medio, no el objetivo, así que nunca recorto una palabra solo para cumplir un límite de caracteres si eso cuesta la comprensión del usuario. Mi método consiste en escribir primero la versión más clara y luego buscar las palabras que no aportan nada: expresiones dudosas, sustantivos redundantes, cualquier cosa que la interfaz ya comunique de forma visual. Un botón junto a un icono de papelera no necesita decir 'Eliminar este elemento de forma permanente', basta con 'Eliminar', porque el icono y el contexto ya llevan el significado. Donde no cedo es en la ambigüedad: si acortar 'Tu sesión caduca en 5 minutos' a 'Sesión caducando' ahorra espacio pero deja al usuario sin saber si debe guardar su trabajo ahora mismo, mantengo la versión más larga. Las limitaciones de espacio en móvil hacen este equilibrio más difícil, así que suelo escribir una versión completa y una versión recortada en paralelo, y pruebo cuál de las dos sigue permitiendo actuar correctamente sin releer dos veces.

Escribo cada texto asumiendo que lo leerá un lector de pantalla y que se traducirá a un idioma con una estructura de frase muy distinta, porque ambas cosas son ciertas para una parte importante de los usuarios. Eso significa evitar frases que dependen de una posición visual, como 'haz clic en el botón de la derecha', ya que una persona que usa lector de pantalla no tiene noción del diseño, y usar etiquetas que describen la acción en vez de un texto de enlace decorativo como 'haz clic aquí'. Para la localización evito modismos y juegos de palabras que no sobreviven a la traducción, mantengo una estructura de frase simple para que el cambio en el orden de las palabras no rompa el sentido, y nunca construyo una frase concatenando fragmentos alrededor de una variable, porque las reglas de género y plural cambian tanto entre idiomas que una frase montada en inglés suele romperse en francés o español. También aviso pronto a los traductores sobre los límites de caracteres, porque una palabra que cabe en inglés suele ocupar un 30 % más de espacio en alemán o francés.

Teníamos un paso de onboarding que pedía 'Confirma tu espacio de trabajo', y en las pruebas, tres de cinco participantes se detuvieron a preguntar qué era un espacio de trabajo, un término que no habíamos introducido antes en el flujo. Había asumido que la palabra se explicaba sola porque el equipo de producto la usaba todo el tiempo internamente, y ese es justamente el error: estaba escribiendo desde el vocabulario del producto y no desde el del usuario. Reescribí el paso para explicar el concepto en lenguaje simple primero, algo parecido a 'Aquí vivirán los proyectos de tu equipo. ¿Te parece bien?', y repetí una prueba rápida con cinco participantes nuevos. Los cinco lo entendieron de inmediato y avanzaron sin dudar. El cambio más importante llegó después: añadí una regla a nuestra guía de estilo, todo sustantivo propio del producto necesita una definición en lenguaje simple la primera vez que aparece en un flujo visible para el usuario, no solo en la documentación.

Un desarrollador quería lanzar 'Entrada inválida' como mensaje de error para un campo de número de teléfono porque coincidía con la salida por defecto de una librería de validación y no requería trabajo extra. Yo me opuse porque no le dice al usuario qué está mal en realidad: un prefijo faltante, caracteres de más o una simple errata requieren correcciones muy distintas, y un mensaje genérico deja a cada persona adivinando. En lugar de discutir solo sobre el tono, pregunté qué casos de validación distinguía ya la librería internamente, y resultó que existían tres estados de error distintos por debajo pero todos se agrupaban en un solo mensaje. Escribí tres reemplazos cortos y específicos, y le mostré al desarrollador que el coste extra de implementación rondaba los veinte minutos, porque la lógica ya existía, solo no estaba expuesta. Ese cambio de enfoque, pasar de 'mi preferencia de redacción' a 'este es el volumen de tickets de soporte que esto genera', logró que se implementara. Al mes siguiente vimos una baja en los tickets de soporte relacionados con ese campo.

Cuando llegué, las decisiones de tono vivían en la cabeza de cada redactor y en hilos de Slack dispersos, así que cada función nueva reinventaba reglas que ya existían en algún lugar. Empecé la guía por los patrones de mayor fricción: cómo redactamos los estados de error, cómo nos referimos al producto en sí, las reglas de mayúsculas y cómo tratamos números y fechas, en lugar de intentar documentarlo todo de golpe. La construí como una referencia viva dentro de nuestra herramienta de design system, junto a los componentes a los que aplicaba, para que alguien que colocara un componente de botón viera la regla de texto justo ahí en vez de buscar en una wiki aparte. También puse en marcha una revisión ligera: cualquier patrón nuevo que apareciera dos veces en un sprint se proponía como adición a la guía en lugar de quedar como una decisión suelta. Seis meses después, redactores nuevos e incluso personas fuera del equipo de contenido la consultaban por su cuenta al escribir sus propios textos, lo cual era la señal real de que se había vuelto útil y no solo decorativa.

Empiezo por asegurarme de que la prueba realmente evalúa una sola variable, porque es fácil cambiar sin querer el tono, la longitud y el verbo de la llamada a la acción a la vez, y luego no saber qué cambio produjo el resultado. En una prueba reciente sobre un flujo de cancelación de suscripción, aislamos solo el enfoque de la oferta de retención, manteniendo igual el texto del botón y el diseño, y dejamos correr la prueba hasta alcanzar el tamaño de muestra que calculó el equipo de datos para tener significancia estadística, sin mirar los resultados antes de tiempo. La variante que nombraba un beneficio concreto que el usuario perdería superó a un genérico '¿Estás seguro?' por un margen claro, pero también revisé la métrica posterior, es decir, si los usuarios que se quedaron por ese mensaje seguían usando el producto un mes después, porque un truco de redacción que solo retrasa la cancelación no es una victoria real. Me importa la métrica que sobrevive más allá del clic inmediato, no solo el resultado de la prueba en sí.

Intento entrar en un proyecto antes de que los wireframes estén cerrados, porque un texto escrito después de fijar el diseño pelea por un espacio que nunca se pensó para él. Con los diseñadores, esbozo un contenido aproximado junto a sus primeros flujos para resolver juntos el conteo de palabras y la jerarquía de la información, en lugar de ajustar frases dentro de cajas después. Con los investigadores, asisto yo misma a las sesiones de prueba con usuarios en vez de limitarme al informe resumido, porque el tono y la duda sobre una palabra concreta suelen suavizarse en un resumen escrito pero se notan claramente al ver a alguien leer una pantalla en voz alta. También pido a los investigadores que incluyan un par de preguntas de comprensión en sus guiones de prueba, como pedirle a alguien que explique con sus propias palabras lo que acaba de decirle una pantalla, porque eso revela textos confusos que una simple prueba de finalización de tarea no detectaría.

La función real de ese texto es hacer la consecuencia concreta y específica, porque sonar alarmante por sí solo no dice lo que realmente está en juego. 'Esta acción no se puede deshacer' es cierto pero olvidable, así que nombraría exactamente qué desaparece: proyectos guardados, historial de facturación, acceso del equipo, lo que corresponda en cada caso, para que la decisión se tome sobre riesgos reales y no sobre una advertencia genérica ya vista cien veces en otros productos. También ajustaría la fricción de la confirmación a la gravedad de la acción: un solo botón de confirmar es suficiente para eliminar un borrador, pero para algo tan definitivo como eliminar una cuenta, pediría escribir el nombre de la cuenta o una frase de confirmación, tanto para frenar un clic impulsivo como para evitar un doble toque accidental. Mantendría también el texto del botón específico, 'Eliminar cuenta' en vez de un genérico 'Confirmar', porque en un momento de tanto riesgo, la ambigüedad es lo último que quieres entre el usuario y una acción que no podrá revertir.