Contenido de autoservicio que responde antes de que pregunten: cómo escribir para recorridos y tooltips

Los centros de ayuda están construidos para quien ya sabe que algo va mal. El usuario choca contra un muro, abre una pestaña nueva, escribe una pregunta, escanea resultados y —si tu documentación es buena— encuentra una respuesta. Cada paso de ese viaje ocurre fuera de tu producto, cuando la frustración ya ha aterrizado.

La guía dentro del producto invierte el orden. Un tooltip anclado al campo donde la gente duda, un paso de recorrido que explica la pantalla que alguien acaba de abrir por primera vez, un elemento de la lista de tareas que enlaza directamente con el ajuste del que habla: todos responden a la pregunta antes de que el usuario llegue a formularla conscientemente. La trampa: el contenido escrito para un centro de ayuda casi nunca funciona dentro del producto. Tiene la forma equivocada, la longitud equivocada y está organizado alrededor de tu lista de funcionalidades en lugar del momento del usuario.

Esta guía trata de cómo escribir contenido de autoservicio diseñado para aparecer, no para ser buscado: los artículos, las líneas de tooltip y los textos de recorrido que sostienen el onboarding guiado. Está escrita para quien es dueño del contenido de onboarding: product marketers, responsables de soporte y fundadores que hacen los dos trabajos a la vez.

El contenido buscado y el contenido servido son especies distintas

Un artículo de centro de ayuda presupone un lector motivado. Llegó con una pregunta, tolerará tres párrafos de contexto y hará scroll. Dentro del producto no se cumple nada de eso. El usuario está a media tarea. Un tooltip consigue quizá doce palabras de atención. Un paso de recorrido consigue veinticinco antes de que el ojo se vaya al botón Siguiente. Una tarjeta incrustada en un estado vacío consigue un titular y una frase.

Esa restricción cambia lo que significa «escribir bien». En un centro de ayuda gana la exhaustividad. Dentro del producto gana la oportunidad: las doce palabras correctas en la pantalla correcta ganan a un artículo perfecto de 800 palabras que nadie abre. El artículo de 800 palabras sigue importando, pero como segunda capa, a un clic del momento, no como puerta de entrada.

Así que el modelo de trabajo es una escalera: línea de tooltip → tarjeta breve en contexto → artículo completo. Cada peldaño responde a la misma pregunta con distinta profundidad, y cada peldaño enlaza con el siguiente. Escribe la escalera como una sola pieza, no como tres activos inconexos.

Parte de los momentos, no de las funcionalidades

El plan clásico de documentación es un espejo del producto: una sección por funcionalidad, un artículo por ajuste. El plan de contenido de onboarding debería ser un espejo del recorrido. Antes de escribir nada, levanta un inventario de momentos de duda:

1. Abre tu analítica de embudo o de finalización de pasos y lista cada pantalla donde los usuarios nuevos se atascan o se caen.
2. Para cada punto de atasco, escribe la pregunta que el usuario haría en voz alta en ese instante exacto, con sus palabras y no con las tuyas. No «Sobre el pipeline de ingesta», sino «¿Por qué no aparecen todavía mis datos?».
3. Ordena por cuántos usuarios nuevos llegan a cada momento durante su primera semana.

Esa lista ordenada es tu backlog de contenido. En un SaaS B2B típico, la cabeza de la lista es deprimentemente consistente: qué pasa después del registro, cómo conectar datos o importar el trabajo existente, dónde aparece el primer resultado, cómo invitar a un compañero y qué significa el panel vacío. Si no escribes nada más, escribe esas cinco escaleras.

Escribe primero la pregunta y respóndela en la primera frase

Cada pieza de la escalera nace como una pregunta formulada tal y como la escribiría un usuario. Conserva la pregunta como título del artículo, literalmente. «¿Dónde veo mi primer informe?» rinde mejor que «Visión general de informes» tanto en tu buscador interno como en el fragmento del buscador, porque coincide con la intención palabra por palabra.

Y después responde en la primera frase. No tras un párrafo de posicionamiento, ni tras una captura de pantalla: la primera frase resuelve la pregunta y todo lo que viene después es detalle de apoyo.

¿Dónde veo mi primer informe? Tu primer informe aparece en Informes → Semanal en cuanto tu fuente de datos termina su primera sincronización, normalmente en menos de 15 minutos desde que la conectas.

Un usuario que solo lea esa línea ya se ha llevado aquello a lo que venía. De eso se trata. Escribir con la respuesta por delante le parece un desperdicio a quien redacta («¡no se leerán el resto!») y es exactamente lo correcto para quien lee.

Un momento, una idea

El peldaño del tooltip tiene sitio para una sola idea. Si tu borrador de tooltip contiene la palabra «además», divídelo. La misma disciplina se aplica un nivel más arriba: un paso de recorrido debe orientar («aquí viven tus flujos»), no enumerar («aquí puedes crear, duplicar, archivar, etiquetar y exportar flujos»). Enumerar funcionalidades es para lo que sirve la propia interfaz.

Un presupuesto de longitud práctico que ha aguantado bien producto tras producto:

• Tooltip u hotspot: una frase, de 8 a 14 palabras, con el verbo delante.
• Paso de recorrido: un titular de 4 a 6 palabras más una frase de 15 a 25 palabras.
• Elemento de lista de tareas: una frase de acción —«Conecta tu primera fuente de datos»— más una recompensa en una línea: «para que tu panel se llene solo».
• Artículo detrás del momento: de 150 a 400 palabras. Si necesita más, está cubriendo dos momentos.

Escribe para el estado de la pantalla

La misma pantalla necesita palabras distintas el día uno y el día treinta. Una lista de proyectos vacía es un momento de enseñanza («Los proyectos mantienen ordenados tus flujos: crea uno para empezar»), mientras que una llena no necesita nada. Los tooltips de primera visita no deberían dispararse nunca dos veces: un usuario que vuelve y ve el mismo «¡Bienvenido!» por tercera vez aprende a descartar todo lo que le muestres, incluida la única pista que le habría salvado la semana.

Esto es menos una regla de escritura que una regla de segmentación, pero tiene una consecuencia al escribir: etiqueta cada pieza de contenido que produzcas con el estado que da por supuesto. «Espacio de trabajo nuevo, sin datos conectados» se lee muy distinto de «datos conectados, ningún informe abierto». Cuando el contenido y el estado no concuerdan —un tooltip que explica un botón que no existe en el plan del usuario— se erosiona la confianza en todas las pistas posteriores.

Retira lo que deja de funcionar

El contenido dentro del producto se pudre más rápido que la documentación porque el producto se mueve por debajo. Monta una revisión mensual sobre tres números por pieza:

• Tasa de interacción: de los usuarios que la vieron, ¿cuántos hicieron clic, la desplegaron o siguieron el enlace?
• Delta de finalización del paso: ¿los usuarios que la vieron completan el paso que apoya más a menudo que quienes no la vieron?
• Tasa de descarte instantáneo: cerrada en menos de un segundo significa que el contenido es ruido en esa pantalla.

Un tooltip con mucho descarte y sin delta de finalización no es neutro: está entrenando a los usuarios para ignorarte. Elimínalo. Un paso que sigue en rojo incluso con guía suele significar que el propio flujo necesita trabajo de diseño: el contenido era la herramienta equivocada, y eso también merece saberse.

Un ejemplo trabajado

Toma el atasco más común en los productos de datos: el usuario conectó una fuente, el panel sigue vacío y la primera sincronización tarda diez minutos. La escalera para ese único momento:

• Tarjeta de estado vacío (titular y línea): «Tus datos están en camino: la primera sincronización tarda unos 10–15 minutos. Te avisaremos cuando tu panel esté listo».
• Elemento de lista de tareas: «Conectar una fuente de datos ✓ → Espera tu primer informe (automático)».
• Artículo, con la respuesta por delante: «Si tu panel está vacío justo después de conectar una fuente, espera de 10 a 15 minutos a que termine la primera sincronización. Aquí te explicamos cómo comprobar el estado de la sincronización, qué significa quedarse atascado en el paso 2 y cuándo escribirnos…».

Nadie busca «cuánto tarda la primera sincronización» durante esos diez minutos: simplemente concluye en silencio que el producto está roto. La versión servida evita esa conclusión; la versión buscada habría llegado demasiado tarde.

El beneficio se acumula

Cada pregunta respondida sobre la marcha es una conversación de soporte que nunca empieza, pero el premio grande es el impulso: los usuarios que nunca se atascan no vuelven a replantearse su decisión de probarte. El contenido de autoservicio escrito para momentos es trabajo de activación con sombrero de redactor, y es de la escritura con más apalancamiento que puede hacer un equipo de SaaS.