Um banco de exemplos adaptáveis é uma biblioteca interna de microcopies “semi-prontas”: modelos curtos que já nascem com estrutura, intenção e variáveis para personalização. Em vez de copiar e colar frases fixas, você mantém padrões reutilizáveis que podem ser ajustados ao contexto (produto, etapa, canal, risco, público, idioma) sem perder consistência. A meta é acelerar a escrita, reduzir divergências entre telas e facilitar revisão, QA e tradução, mantendo espaço para nuances.
Esse banco não substitui diretrizes de linguagem nem resolve debates de tom por si só. Ele funciona como um kit de peças: você escolhe um modelo, preenche variáveis, aplica regras de adaptação e valida com o cenário real. O resultado é menos improviso, menos retrabalho e mais previsibilidade na experiência.
O que torna um exemplo “adaptável” (e não apenas uma frase pronta)
Um exemplo adaptável tem três características principais: estrutura estável, variáveis explícitas e regras de uso. A estrutura estável é o esqueleto da mensagem (o que precisa estar presente). As variáveis são os campos que mudam (nome do recurso, prazo, valor, motivo, ação). As regras de uso dizem quando aplicar, quando evitar e quais alternativas escolher conforme o risco ou o canal.
- Estrutura estável: mantém o padrão de informação que o usuário precisa para agir.
- Variáveis: permitem personalizar sem reescrever do zero.
- Regras: evitam uso indevido, inconsistências e mensagens genéricas.
Exemplo de modelo (não final):
[Situação] + [Impacto] + [Opção principal] + [Alternativa/saída] (com variáveis: {recurso}, {prazo}, {limite}, {canal})Quando um banco de exemplos vale mais do que “boas frases”
O banco é especialmente útil quando há repetição de cenários com pequenas variações, como: mudanças de plano, limites atingidos, tentativas de login, permissões, indisponibilidade temporária, etapas de verificação, convites e compartilhamento, confirmações de ações sensíveis, mensagens de manutenção, e orientações rápidas em listas e cards.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Ele também ajuda quando o produto cresce em times e superfícies: web, app, e-mail transacional, push, central de notificações, e áreas administrativas. Sem um banco, cada equipe tende a criar versões próprias do mesmo recado, gerando ruído.
Como organizar o banco: taxonomia prática
Uma organização simples e funcional combina “cenário” com “intenção” e “componente”. Assim, você encontra rápido e evita duplicatas.
1) Por cenário (o que está acontecendo)
- Conta e acesso (login, senha, verificação, sessão expirada)
- Pagamentos e cobrança (cartão recusado, fatura, reembolso)
- Planos e limites (upgrade, downgrade, limite atingido)
- Dados e importação (upload, processamento, falha parcial)
- Permissões e compartilhamento (convites, papéis, acesso negado)
- Disponibilidade (instabilidade, manutenção, offline)
2) Por intenção (o que a mensagem precisa provocar)
- Orientar próximo passo
- Reduzir dúvida/ansiedade
- Prevenir erro
- Solicitar confirmação
- Explicar restrição
- Oferecer alternativa
3) Por componente (onde aparece)
- Texto de botão
- Helper text
- Tooltip
- Banner
- Modal
- Toast
- Inline message
Na prática, você pode indexar cada item com tags: cenário, intenção, componente, severidade, canal, produto/área, idioma.
Ficha padrão de cada modelo (template de documentação)
Para o banco ser realmente reutilizável, cada modelo precisa de uma ficha curta e padronizada. Isso evita que o banco vire uma coleção de frases sem contexto.
- ID: código único (ex.: PAY-CARD-DECLINED-01)
- Cenário: cartão recusado
- Intenção: orientar recuperação
- Componente: inline + CTA
- Quando usar: pagamento falhou por recusa do emissor
- Quando não usar: falha técnica do gateway; saldo insuficiente confirmado
- Variáveis: {bandeira}, {final_cartao}, {valor}, {tentativas_restantes}
- Versões: curta, padrão, detalhada
- Alternativas: tentar outro método, atualizar cartão, falar com suporte
- Notas legais/risco: evitar afirmar causa não confirmada
- Exemplos preenchidos: 2–3 instâncias reais
Esse formato é o que permite que outra pessoa, em outro time, aplique o modelo com segurança.
Passo a passo para construir o banco de exemplos adaptáveis
Passo 1: Levantar os cenários mais frequentes e mais críticos
Comece com uma lista curta. Priorize por volume (aparece muito) e impacto (gera abandono, suporte, erro). Fontes comuns: tickets recorrentes, logs de eventos, auditoria de telas, fluxos de pagamento, permissões e importação.
- Liste 20–30 cenários iniciais.
- Marque quais têm variações (ex.: “limite atingido” por tipo de limite).
- Identifique quais exigem cuidado (financeiro, privacidade, segurança).
Passo 2: Agrupar por “famílias” de mensagem
Famílias são padrões que se repetem com variáveis. Ex.: “ação bloqueada por permissão”, “processo em andamento”, “falha temporária”, “confirmação de ação irreversível”.
O objetivo é reduzir 30 cenários para 8–12 famílias, cada uma com 2–4 modelos.
Passo 3: Definir variáveis e regras de preenchimento
Para cada família, liste o que muda e como muda. Variáveis mal definidas geram textos quebrados (“Seu {recurso} foi {ação} com sucesso”). Prefira variáveis que se encaixem naturalmente.
- Variáveis de objeto: {arquivo}, {projeto}, {equipe}
- Variáveis de estado: {status}, {motivo}, {prazo}
- Variáveis numéricas: {limite}, {usado}, {restante}
- Variáveis de ação: {acao_principal}, {acao_alternativa}
Inclua regras: pluralização, gênero quando aplicável, formato de moeda e data, e limites de caracteres por componente.
Passo 4: Criar versões por densidade (curta, padrão, detalhada)
O mesmo cenário pode exigir diferentes níveis de detalhe. Em um toast, você precisa de uma versão curta; em um modal, pode usar a padrão; em uma tela dedicada, a detalhada. Manter as três evita improvisos.
- Curta: 1 frase + ação.
- Padrão: 1–2 frases + ação + alternativa.
- Detalhada: inclui contexto adicional e critérios (quando necessário).
Passo 5: Validar com exemplos reais (preenchidos)
Um modelo só fica pronto quando você testa com dados reais: nomes longos, valores altos, casos sem variável (ex.: usuário sem e-mail), e idiomas se houver. Coloque 2–3 exemplos preenchidos na ficha para mostrar como fica.
Passo 6: Publicar com governança mínima
Defina quem pode criar, quem revisa e como versiona. Sem isso, o banco vira um mural de frases conflitantes. Uma governança leve já resolve: um responsável por área + revisão periódica + changelog.
Modelos prontos para cenários comuns (com variáveis e opções)
A seguir, um conjunto de modelos adaptáveis. Use como base e ajuste variáveis, canal e densidade.
1) Sessão expirada
Curta (toast): “Sua sessão expirou. Entre novamente.”
Padrão (inline): “Por segurança, sua sessão expirou após {minutos} min sem atividade. Entre novamente para continuar.”
CTA: “Entrar”
Alternativa: “Voltar”
Regras: não prometa que dados foram salvos; se houver rascunho, incluir variável {status_rascunho}.
2) Ação bloqueada por permissão
Padrão: “Você não tem permissão para {acao} em {recurso}. Peça acesso a um administrador da equipe.”
Variação com caminho direto: “Você não tem permissão para {acao} em {recurso}. Solicite acesso para {admin_nome}.”
CTA: “Solicitar acesso”
Regras: se não houver admin identificável, remover {admin_nome} e oferecer “Ver membros da equipe”.
3) Limite atingido (uso/assinatura)
Padrão: “Você atingiu o limite de {tipo_limite}: {usado}/{limite}. Para adicionar mais {item}, faça upgrade do plano ou remova itens.”
Curta: “Limite de {tipo_limite} atingido ({usado}/{limite}).”
CTAs: “Fazer upgrade” e “Gerenciar {item}”
Regras: evitar “não é possível” sem alternativa; sempre oferecer ação de gerenciamento quando existir.
4) Processamento em andamento
Padrão: “Estamos processando {arquivo}. Isso pode levar até {tempo_estimado}. Você pode continuar usando o app.”
Variação quando bloqueia: “Estamos processando {arquivo}. Para evitar inconsistências, {acao} ficará disponível quando terminar.”
Regras: só usar {tempo_estimado} se houver base; senão, trocar por “alguns minutos” e oferecer status.
5) Falha temporária (instabilidade)
Padrão: “Não foi possível {acao} agora. Tente novamente em instantes.”
Com alternativa: “Não foi possível {acao} agora. Tente novamente em instantes ou {acao_alternativa}.”
CTA: “Tentar novamente”
Regras: não atribuir culpa ao usuário; se houver status page, incluir link no canal apropriado.
6) Upload inválido (tipo/tamanho)
Padrão: “Esse arquivo não é compatível. Envie um {formatos} de até {tamanho_max}.”
Variação com detalhe: “O arquivo {nome_arquivo} tem {tamanho_atual}. Envie um {formatos} de até {tamanho_max}.”
Regras: se {nome_arquivo} for longo, truncar; manter formatos em lista curta (ex.: “PDF ou PNG”).
7) Dado duplicado
Padrão: “Já existe um {item} com {campo} “{valor}”. Use outro {campo} ou edite o existente.”
CTA: “Ver {item} existente”
Regras: quando {valor} for sensível (e-mail, documento), mascarar parcialmente.
8) Confirmação de ação sensível (irreversível)
Padrão (modal): “Excluir {recurso}?”
Texto de apoio: “Essa ação remove {impacto_principal} e não pode ser desfeita.”
CTAs: “Excluir” (primário) e “Cancelar” (secundário)
Regras: se houver recuperação (lixeira), não dizer “não pode ser desfeita”; trocar por “Você pode restaurar em até {prazo}”.
9) Convite para equipe (envio e status)
Padrão: “Convite enviado para {email}. Ele expira em {prazo}.”
Variação se já convidado: “{email} já tem um convite pendente. Reenviar?”
CTAs: “Reenviar convite” e “Copiar link” (se aplicável)
Regras: se não houver expiração, remover a frase e oferecer “Reenviar” como alternativa.
10) Pagamento falhou (causa não confirmada)
Padrão: “Não foi possível concluir o pagamento. Verifique os dados do cartão ou tente outro método.”
Variação com tentativa: “Não foi possível concluir o pagamento. Você ainda tem {tentativas_restantes} tentativa(s).”
CTAs: “Tentar novamente” e “Trocar método”
Regras: evitar afirmar “cartão recusado” se o provedor não confirmar; manter linguagem probabilística.
Como adaptar rapidamente um modelo ao contexto (sem perder consistência)
Checklist de adaptação em 5 pontos
- Componente: cabe no espaço? (toast vs modal vs inline)
- Momento: antes de agir, durante, depois? (muda o foco da mensagem)
- Risco: baixo, médio, alto? (define necessidade de alternativa e detalhe)
- Dados disponíveis: quais variáveis são confiáveis? (evitar placeholders vazios)
- Ação disponível: existe um próximo passo real? (não oferecer CTA que não funciona)
Exemplo prático de adaptação do mesmo cenário “limite atingido”:
Modelo base: “Você atingiu o limite de {tipo_limite}: {usado}/{limite}. Para adicionar mais {item}, faça upgrade do plano ou remova itens.”Em um card (curto): “Limite de {tipo_limite} ({usado}/{limite}).” + botão “Gerenciar”.
Em um modal (padrão): incluir as duas opções (upgrade e gerenciar) e, se existir, variável {beneficio_upgrade} (“Aumente para {novo_limite}”).
Em um banner persistente: remover urgência excessiva e focar em orientação contínua: “Você está no limite de {tipo_limite}. Gerencie itens ou faça upgrade.”
Regras para evitar que o banco vire “frases genéricas”
1) Proibir modelos sem variável de contexto quando o cenário exige
Alguns cenários ficam vagos sem um objeto: “Algo deu errado” não ajuda. Crie uma regra: se houver {acao} e {recurso} disponíveis, eles devem aparecer.
2) Manter alternativas reais (não decorativas)
Se o modelo oferece “tente novamente” e “fale com suporte”, mas o suporte não está disponível naquele canal, o banco precisa de uma variação por canal.
3) Incluir limites de caracteres por componente
Sem limites, o modelo “padrão” vira texto de modal e acaba usado em toast. Documente limites aproximados (ex.: toast 60–90 caracteres; helper 80–120; banner 120–180) e crie versões curtas.
4) Prever casos sem dados
Se {tempo_estimado} não existir, o modelo deve ter fallback. Documente isso na ficha: “Se {tempo_estimado} estiver vazio, usar ‘alguns minutos’”.
Operação do banco no dia a dia (uso, revisão e evolução)
Fluxo simples de uso
- Identifique cenário e componente.
- Busque no banco por tags (cenário + componente).
- Escolha a versão (curta/padrão/detalhada).
- Preencha variáveis com dados reais.
- Valide regras de uso e canal.
- Registre se precisou criar variação (para evoluir o banco).
Quando criar um novo modelo vs criar uma variação
- Novo modelo: quando a estrutura muda (novas informações obrigatórias, nova intenção).
- Variação: quando muda apenas canal, densidade, ou uma condição (ex.: com/sem admin, com/sem prazo).
Controle de qualidade com “amostras preenchidas”
Uma prática que evita regressões é manter, para cada modelo, um pequeno conjunto de amostras preenchidas com casos extremos: nome longo, valor alto, plural, ausência de variável. Isso ajuda a detectar frases quebradas e problemas de truncamento.
Mini-biblioteca adicional: micro-modelos por tipo de UI
Botões (ações frequentes com variável)
- “Adicionar {item}”
- “Salvar {recurso}”
- “Reenviar {codigo}” (quando aplicável)
- “Continuar para {etapa}”
Helper text (restrições e critérios)
- “Use {criterio} para {beneficio}.”
- “Aceitamos {formatos}. Tamanho máximo: {tamanho_max}.”
- “Você pode alterar isso depois em {local}.”
Banners (situação + ação)
- “{Situacao_resumida}. {acao_principal}.”
- “{Situacao_resumida}. Saiba mais em {link}.” (quando houver conteúdo de apoio)
Toasts (feedback rápido)
- “{Recurso} salvo.”
- “Não foi possível {acao}. Tente novamente.”
- “Copiado para a área de transferência.”
Esses micro-modelos funcionam como blocos de construção: eles não substituem modelos por cenário, mas aceleram a montagem de mensagens consistentes em componentes pequenos.
