Explícame cómo abordas la redacción de un microtexto para un mensaje de error o un estado vacío.

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.

¿Cómo trabajas con un design system y unas guías de tono ya existentes?

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.

¿Cómo equilibras la brevedad con la claridad en el texto de una interfaz?

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.

¿Cómo escribes textos que funcionen tanto para accesibilidad como para localización?

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.

Cuéntame de una vez que las pruebas con usuarios revelaron que tu texto generaba confusión.

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.

Describe una situación en la que un desarrollador o un product manager cuestionó tu redacció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.

Cuéntame sobre una guía de estilo de contenido que hayas creado o mantenido.

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.

¿Cómo llevas a cabo o interpretas una prueba A/B sobre variantes de texto?

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í.

¿Cómo colaboras con diseñadores de producto e investigadores durante el proceso de diseño?

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.

¿Cómo redactarías un flujo de confirmación para una acción destructiva, como eliminar una cuenta?

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.

Redactor UX

El redactor UX da forma a cada palabra que el usuario encuentra en los momentos clave de un producto: etiquetas de botones, mensajes de error, flujos de onboarding, estados vacíos y esos pequeños instantes que generan confianza o confusión. Los entrevistadores buscan candidatos capaces de explicar el razonamiento detrás de una frase, y de producir además un texto que se lea bien. Espera preguntas sobre la colaboración con diseñadores y desarrolladores, la defensa de una elección de palabras bajo presión, y la prueba de que un cambio de texto realmente movió una métrica.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Responder preguntas por competencias Cómo responder a "¿Cuáles son tus puntos fuertes?"

Preguntas de entrevista habituales para Redactor UX

Preguntas conductuales para puestos de Redactor UX

Preguntas técnicas para candidatos a Redactor UX

Lo que buscan los reclutadores en las entrevistas para Redactor UX

Qué evaluar al contratar a un redactor UX

Pide un antes y después de un texto concreto, no solo un enlace a un portafolio, y haz que explique el razonamiento detrás de cada elección de palabra.
Comprueba si la persona puede justificar una decisión de redacción con una métrica de usuario o de negocio, no solo con una preferencia de sonido.
Fíjate en si trata la guía de estilo como algo que ayuda a construir y actualizar, en lugar de un documento que solo consulta.
Indaga cómo maneja un desacuerdo con desarrolladores o product managers. Los mejores redactores reencuadran la objeción en torno al impacto en el usuario, no defendiendo una opinión personal.
Pregunta por una vez en que una prueba reveló un problema inesperado. Alguien que no pueda nombrar ninguna probablemente no ha estado lo bastante cerca de usuarios reales.

Preguntas que puedes hacer al entrevistador

→¿Cómo encaja el equipo de content design dentro de la organización de producto, y a quién reportan los redactores UX?
→¿Cómo es el proceso de revisión cuando los plazos de redacción y desarrollo entran en tensión?
→¿Cómo se mantiene hoy la guía de estilo o el sistema de contenido, y quién es responsable de sus actualizaciones?
→¿Puedes contarme cómo se probó o midió una decisión de redacción reciente?
→¿Cómo se ve el éxito en este puesto durante los primeros seis meses?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

UX Designer

Creativo9 preguntas

Redactor publicitario

Disponible en otros idiomas

English Français