Conteúdo self-service que responde antes da pergunta: como escrever para tours e tooltips

Centrais de ajuda são feitas para quem já sabe que alguma coisa deu errado. O usuário bate numa parede, abre uma nova aba, digita uma pergunta, varre os resultados e — se a sua documentação for boa — encontra a solução. Cada passo dessa jornada acontece fora do seu produto, depois que a frustração já aconteceu.

A orientação in-app inverte a sequência. Um tooltip fixado no campo em que as pessoas hesitam, um passo de tour que explica a tela que alguém acabou de abrir pela primeira vez, um item de checklist que leva direto à configuração de que ele fala — tudo isso resolve a dúvida antes de o usuário formulá-la conscientemente. O detalhe: conteúdo escrito para central de ajuda quase nunca funciona dentro do produto. É o formato errado, o tamanho errado e está organizado em torno da sua lista de funcionalidades, não do momento do usuário.

Este guia é sobre escrever conteúdo self-service pensado para ser entregue no momento certo, não para ser pesquisado — os artigos, as linhas de tooltip e os textos de tour que sustentam o onboarding guiado. Ele é para quem cuida do conteúdo de onboarding: product marketers, líderes de suporte e fundadores que acumulam as duas funções.

Conteúdo pesquisado e conteúdo entregue são espécies diferentes

Um artigo de central de ajuda pressupõe um leitor motivado. Ele chegou com uma pergunta, tolera três parágrafos de contexto e rola a página. Dentro do produto, nada disso é verdade. O usuário está no meio de uma tarefa. Um tooltip ganha talvez doze palavras de atenção. Um passo de tour ganha vinte e cinco antes de o olho escorregar para o botão Avançar. Um card embutido em um estado vazio ganha um título e uma frase.

Essa restrição muda o que significa "escrever bem". Na central de ajuda, vence a completude. No produto, vence o timing: as doze palavras certas na tela certa ganham de um artigo perfeito de 800 palavras que ninguém abre. O artigo de 800 palavras continua importando — mas como segunda camada, a um clique de distância do momento, e não como porta de entrada.

Então o modelo de trabalho é uma escada: linha de tooltip → card curto no contexto → artigo completo. Cada degrau trata a mesma dúvida em uma profundidade diferente, e cada degrau leva ao seguinte. Escreva a escada como uma peça só, não como três materiais desconexos.

Comece pelos momentos, não pelas funcionalidades

O plano clássico de documentação espelha o produto: uma seção por funcionalidade, um artigo por configuração. O plano de conteúdo de onboarding deve espelhar a jornada. Antes de escrever qualquer coisa, monte um inventário dos momentos de hesitação:

1. Abra o analytics de funil ou de conclusão de etapas e liste toda tela em que os novos usuários empacam ou abandonam.
2. Para cada ponto de trava, escreva a pergunta que o usuário faria em voz alta naquele exato momento — com as palavras dele, não as suas. Não "Sobre o pipeline de ingestão", e sim "Por que os meus dados ainda não apareceram?".
3. Ordene por quantos novos usuários batem em cada momento na primeira semana.

Essa lista ordenada é o seu backlog de conteúdo. Num SaaS B2B típico, o topo dela é deprimentemente parecido: o que acontece depois do cadastro, como conectar dados ou importar o trabalho que já existe, onde aparece o primeiro resultado, como convidar um colega de time e o que significa o painel vazio. Se você não escrever mais nada, escreva essas cinco escadas.

Escreva a pergunta primeiro e resolva na primeira frase

Toda peça da escada nasce como uma pergunta formulada do jeito que o usuário digitaria. Mantenha a pergunta como título do artigo — literalmente. "Onde eu vejo o meu primeiro relatório?" rende mais do que "Visão geral de relatórios" tanto na busca dentro do app quanto no snippet do buscador, porque bate com a intenção palavra por palavra.

Depois, resolva na primeira frase. Não depois de um parágrafo de posicionamento, não depois de uma captura de tela — a primeira frase mata a dúvida, e tudo o que vem em seguida é detalhe de apoio:

Onde eu vejo o meu primeiro relatório? O seu primeiro relatório aparece em Relatórios → Semanal assim que a sua fonte de dados conclui a primeira sincronização — normalmente em até 15 minutos após a conexão.

O usuário que lê só essa linha conseguiu o que veio buscar. É esse o objetivo. Escrever com a resposta na frente parece desperdício para quem escreve ("ninguém vai ler o resto!") e é exatamente o certo para quem lê.

Um momento, uma ideia

O degrau do tooltip comporta uma única ideia. Se o seu rascunho de tooltip tem a palavra "também", divida em dois. A mesma disciplina vale um nível acima: um passo de tour deve orientar ("é aqui que ficam os seus fluxos"), não enumerar ("aqui você pode criar, duplicar, arquivar, etiquetar e exportar fluxos"). Enumerar funcionalidades é papel da própria interface.

Um orçamento de tamanho que se sustentou em produtos bem diferentes:

• Tooltip / hotspot: uma frase, 8–14 palavras, verbo na frente.
• Passo de tour: título de 4–6 palavras mais uma frase de 15–25 palavras.
• Item de checklist: uma frase de ação — "Conecte a sua primeira fonte de dados" — mais uma linha de recompensa: "para o seu painel se preencher sozinho".
• Artigo por trás do momento: 150–400 palavras. Se precisar de mais, ele está cobrindo dois momentos.

Escreva para o estado da tela

A mesma tela precisa de palavras diferentes no primeiro dia e no trigésimo. Uma lista de projetos vazia é um momento de ensino ("Projetos mantêm os seus fluxos organizados — crie um para começar"), enquanto uma lista cheia não precisa de nada. Tooltips de primeiro acesso nunca deveriam disparar duas vezes; quem volta e vê a mesma dica de "Boas-vindas!" três vezes aprende a fechar tudo o que você mostra — inclusive a única dica que salvaria a semana dele.

Isso é menos uma regra de escrita e mais uma regra de segmentação, mas tem consequência na escrita: marque cada peça que você produz com o estado que ela pressupõe. "Espaço de trabalho novo, nenhum dado conectado" é muito diferente de "dados conectados, nenhum relatório aberto". Quando conteúdo e estado se contradizem — um tooltip explicando um botão que nem aparece no plano do usuário —, a confiança em toda dica seguinte se desfaz.

Aposente o que parou de funcionar

Conteúdo in-app apodrece mais rápido que documentação porque o produto se mexe embaixo dele. Estabeleça uma revisão mensal de três números por peça:

• Taxa de interação — de quem viu, quantos clicaram, expandiram ou seguiram o link?
• Delta de conclusão da etapa — quem viu conclui a etapa apoiada com mais frequência do que quem não viu?
• Taxa de descarte imediato — fechado em menos de um segundo significa que aquele conteúdo é ruído naquela tela.

Um tooltip com descarte alto e delta zero de conclusão não é neutro: ele está treinando o usuário a ignorar você. Corte. Uma etapa que continua vermelha mesmo com orientação costuma significar que o fluxo em si precisa de design — o conteúdo era a ferramenta errada, e saber disso também vale.

Um exemplo resolvido

Pegue a trava mais comum em produtos de dados: o usuário conectou uma fonte, o painel continua vazio e a primeira sincronização leva dez minutos. A escada para esse único momento:

• Card de estado vazio (título + linha): "Os seus dados estão a caminho — a primeira sincronização leva cerca de 10–15 minutos. Você recebe um aviso quando o painel estiver pronto."
• Item de checklist: "Conecte uma fonte de dados ✓ → Aguarde o seu primeiro relatório (automático)."
• Artigo, resposta na frente: "Se o seu painel está vazio logo depois de conectar uma fonte, espere 10–15 minutos até a primeira sincronização terminar. Veja como conferir o status da sincronização, o que significa 'parado na etapa 2' e quando falar com a gente…"

Ninguém pesquisa "duração da primeira sincronização" durante esses dez minutos — a pessoa só conclui em silêncio que o produto está quebrado. A versão entregue no momento certo evita a conclusão; a versão pesquisada chegaria tarde demais.

O ganho acumula juros

Cada dúvida resolvida dentro do fluxo é uma conversa de suporte que nunca começa, mas o prêmio maior é a inércia positiva: quem nunca empaca não reavalia a decisão de testar você. Conteúdo self-service escrito para momentos é trabalho de ativação vestido de redação — e está entre os textos de maior alavancagem que um time de SaaS pode produzir.