Como eu ensinei uma IA a falar do jeito certo no checkout

Como a criação de um Gem no Gemini me ajudou a transformar diretrizes de UX Writing em um assistente que aprende, consulta e responde como parte do time

Faz parte da rotina de UX Writer passar horas lapidando um guia de tom e voz, documentando padrões de mensagens de erro, definindo os CTAs com mais cuidado do que a maioria das pessoas percebe. Depois, entregamos tudo num documento organizado, com exemplos e justificativas (torcendo para que outros times utilizem).

E aí, numa sprint corrida, o designer escreve fora do tom “Ocorreu um erro inesperado. Tente novamente mais tarde.”

O documento ficou no Confluence, a pressa falou mais alto e a consistência foi embora.

Eu já vivi essa cena algumas vezes sendo responsável pela escrita de fluxos de pagamentos e foi ela que me fez criar o LeXAI: um Gem no Gemini treinado especificamente para o fluxo de checkout de um grande varejista digital brasileiro.

gem do checkout — ux writing & IA

O que é um Gem?

Gem é uma versão personalizada do Gemini que você configura com instruções, contexto e arquivos específicos. É como contratar um assistente e passar a ele o manual completo da empresa no primeiro dia: persona, tom, regras, exemplos, restrições.

Com os Gems, você cria instruções específicas e repetíveis para o Gemini seguir. Ao concentrar ali tudo sobre os seus objetivos e preferências, o Gem se torna um atalho sempre que você quiser explorar um tema com contexto consistente.

A diferença em relação a um prompt comum é essa: você não precisa reexplicar o contexto toda vez porque o Gem já sabe onde está, com quem está falando e como deve responder.

Diferente de outras plataformas onde você sobe um arquivo que rapidamente fica desatualizado, os Gems podem se conectar diretamente ao Google Drive, o que significa que quando você atualiza um documento de referência, o assistente automaticamente passa a considerar o novo conteúdo.

Isso muda tudo para quem trabalha com sistemas de design de conteúdo.

Por que o checkout precisava de um Gem próprio

O checkout de um e-commerce é uma jornada inteira de micromomentos: seleção de endereço, escolha de frete, aplicação de cupom, seleção de pagamento, confirmação de pedido. Cada etapa tem seu próprio vocabulário, seu próprio nível de tensão emocional e suas próprias regras de clareza.

Eu mantinha diretrizes separadas para:

• Tom e voz: como o produto se comunica nessa etapa (mais objetivo, menos brincalhão, zero ambiguidade)
• Mensagens de erro: categorizadas por tipo: validação de campo, erro de sistema, recusa de cartão, falha de CEP
• CTAs: mapeados por posição, hierarquia e ação esperada
• Contexto de produto: nomenclatura interna, fluxos, regras de negócio que afetam o texto

As diretrizes existiam há algum tempo, mas havia fricção para acessá-las.

confluence de diretrizes de writing

Cada vez que alguém do time precisava de um texto, a jornada era: abrir o Confluence, encontrar o documento certo, ler, interpretar, aplicar. Quatro passos que, na pressa, viravam um: escrever na intuição.

Eu precisava que as diretrizes fossem conversáveis, não apenas consultáveis.

O processo de construção

Definindo o escopo antes de abrir o Gemini

A primeira decisão foi sobre os limites do Gem. Ele seria especialista em checkout. Quanto mais específico o escopo, mais precisa a resposta.

As principais áreas a considerar ao escrever boas instruções para um Gem são as mesmas que guiam bons prompts em geral: persona, tarefa, contexto e formato. Você não precisa usar todas, mas usar algumas delas já ajuda o Gem a personalizar as respostas.

Organizei as instruções em quatro blocos e aqui vou colocar exemplos para resguardar os prompts que utilizei no projeto e manter a confiabilidade:

1. Persona: “Você é um assistente de UX Writing especializado no fluxo de checkout. Seu papel é ajudar o time a escrever textos consistentes com as diretrizes de tom, voz e estilo deste produto. Você não inventa padrões: consulta e aplica os que foram documentados.”

2. Tarefa: o que o Gem deve fazer: sugerir textos, revisar microcopies existentes, criar variações de mensagens de erro, verificar se um CTA segue o padrão definido.

3. Contexto: as diretrizes reais, em linguagem direta. Não joguei o documento inteiro: destilei as regras mais críticas e as exemplifiquei com antes e depois.

4. Formato: como o Gem deve estruturar as respostas: sempre apresentar o texto sugerido, explicar brevemente a lógica (qual diretriz foi aplicada) e, quando relevante, mostrar uma alternativa.

O que coloquei nas instruções e o que ficou de fora

A tentação inicial era colocar o guia completo, os documentos de fluxo, a lista de CTAs. Mas um Gem sobrecarregado de informação dilui o foco das respostas.

Pense no seu Gem como um novo colaborador chegando no primeiro dia. Você explica uma vez: “prefiro documentos em bullet points, nunca agende reuniões antes das 10h, use este guia de estilo para e-mails de clientes.”

Então fiz uma escolha editorial: entrei com as regras que mais causam erros de consistência quando ignoradas.

Para mensagens de erro, por exemplo, a diretriz mais violada era simples: nunca culpar o usuário, nunca usar voz passiva, sempre oferecer um próximo passo. Coloquei isso com três exemplos de antes e depois.

Os arquivos como memória de longo prazo

Além das instruções textuais, subi arquivos com os padrões documentados, incluindo a tabela de mensagens de erro por categoria e o mapa de CTAs por etapa do checkout.

Em vez de digitar a solicitação na caixa de chat e subir um documento toda vez que precisa de ajuda, você pode construir um Gem com esse conhecimento embutido.

exemplo do que fazer e do que evitar

Esses arquivos funcionam como a memória de longo prazo do assistente.

Testando antes de confiar

Antes de apresentar o Gem para o time, testei exaustivamente com casos reais, situações que eu sabia que eram problemáticas no cotidiano.

Joguei cenários como:

• “Escreva uma mensagem de erro para falha na aprovação do cartão de crédito”
• “Revise esse CTA: ‘Finalizar compra agora!’”
• “Qual é a diferença de tom entre a etapa de endereço e a de pagamento nesse produto?”

Na janela de visualização do Gem, você pode inserir prompts para testar como ele responde antes de salvar. Esse passo é fundamental — usar a janela de preview não salva o Gem automaticamente.

Nas primeiras versões, o Gem às vezes inventava diretrizes que não existiam e a solução foi reforçar nas instruções: “Se a diretriz não estiver documentada nos arquivos, diga que não há padrão definido e sugira com essa ressalva.”

Os desafios reais

Desafio 1: instruções muito genéricas produziam respostas genéricas e instruções muito específicas deixavam o Gem rígido demais. Encontrar o equilíbrio levou iterações… e a cada rodada de testes, eu revisava o que estava superexplicado e o que estava vago demais.

Desafio 2: o LeXAI não percebe nuance de negócio que não foi documentada. Se uma regra de produto muda e o arquivo não é atualizado, ele segue o que está escrito. Isso não um bug, mas exige disciplina de manutenção que antes não existia de forma estruturada.

Desafio 3: a ferramenta pronta é só metade do trabalho. A outra metade é mudar o hábito de quem precisaria usá-la. Apresentei o Gem em uma reunião de alinhamento, mostrei ao vivo como ele responde e criei um mini-guia de prompts para facilitar a entrada.

Os ganhos que não esperava

Ganho 1: Clareza sobre as minhas próprias diretrizes

O processo de construir o Gem me obrigou a rever o que estava documentado com um olhar novo. Se eu não conseguia explicar uma regra de forma que o assistente entendesse, era porque a regra estava mal escrita. Criei o LeXAI e acabei melhorando a documentação que já existia.

Ganho 2: Velocidade nas revisões

Revisões que levavam 20 minutos de leitura e comparação agora levam 3. Colo o texto no Gem, peço que verifique contra as diretrizes, recebo o diagnóstico com justificativa.

Ganho 3: Um parceiro de raciocínio, não só de execução

O que mais me surpreendeu foi usar o LeXAI não para gerar texto, mas para pensar. “Dado esse fluxo de erro de pagamento, qual seria o impacto de mudar esse CTA de ‘Tentar novamente’ para ‘Usar outro cartão’?” O Gem cruza as diretrizes, raciocina em voz alta e me devolve uma perspectiva ancorada nos padrões .

O que aprendi sobre criar um Gem que funciona

Se você está pensando em criar um Gem para o seu contexto de trabalho, aqui estão os princípios que consolidei:

Delimite antes de construir. Quanto mais específico o escopo, mais útil o resultado.

Priorize as regras mais quebradas. Não documente o que o time já faz bem, documente o que cai na hora do sufoco.

Use exemplos, não só definições. Uma diretriz como “seja claro e direto” não ensina nada. Exemplifique colocando antes e depois.

Instrua sobre o que fazer quando não sabe. O Gem precisa saber quando assumir e quando confessar a lacuna.

Trate como produto. Tem onboarding, tem manutençãoe tem versionamento. Um Gem sem manutenção envelhece como documentação aquela documentação do Confluence que ficou abandonada.

Como o Gem foi além da minha produtividade

Criar o LeXAI foi um projeto de intenção.

UX Writing de qualidade carrega escolhas: sobre o que dizer, como dizer, o que não dizer. Essas escolhas existem por razões: pesquisa, teste, aprendizado de ciclos anteriores.

Um Gem bem construído torna a boa decisão a decisão mais fácil. E isso, no fundo, é o que qualquer sistema de design de conteúdo deveria fazer.

apresentação para o time de produto — ux writing & IA

A escrita do checkout continua sendo humana, o que mudou é que agora ela tem memória.

Letícia Fernandes Amaral é UX Writer e Artesã de Experiências. Escreve sobre linguagem, produto e o que acontece quando as duas coisas se encontram.