IA conversacional · Customer Engagement · Product Building
Brain 003
Uma demo de IA conversacional para analisar e criar campanhas de CRM
Em duas semanas, desenhei e construí uma demo funcional da Brain 003, uma ferramenta de Customer Engagement com IA. Eu queria testar se alguém conseguiria analisar e criar campanhas explicando o que precisa, em vez de começar configurando a ferramenta.
- Papel
- Product Designer / Product Builder
- Período
- 2026
Escopo
- Product Strategy
- Conversational UX
- Interaction Design
- Design Systems
- AI-assisted Development
Resumo executivo
Ir direto às decisões- Problema
- Em ferramentas de CRM e automação, quase tudo começa pela configuração. Antes de ver qualquer resultado, a pessoa precisa escolher público, canais, regras e forma de medir a campanha. Isso pressupõe que ela já saiba traduzir o que quer para a lógica da ferramenta. Na Brain 003, testei o caminho inverso: a pessoa explica o objetivo e a Brain ajuda a chegar na configuração.
- Minha atuação
- Trabalhei praticamente sozinho, com direção dos stakeholders. Defini os fluxos, desenhei a conversa e as telas, montei o Design System e construí a demo usando ferramentas de IA para gerar e revisar código. Como desenhava e implementava ao mesmo tempo, conseguia testar cada decisão rodando, e não só numa tela estática.
- Resultado
- Uma demo navegável com três fluxos completos. Em todos eles, a conversa termina em algo salvo no projeto: uma análise, uma campanha, um workflow ou um monitoramento. Não houve medição de impacto de negócio, e o case não tenta sugerir que houve.
- Por que importava
- Chat funciona bem para explicar um objetivo, mas é ruim para comparar opções ou revisar uma campanha com dez parâmetros. Telas tradicionais têm o problema oposto. Eu precisava definir em que momento usar cada um, sem cair num formulário disfarçado de conversa nem numa tela cheia de campos logo na entrada.
- Estado da solução
- Demo com acesso controlado. Dados, integrações (Slack, CleverTap, Blip, GTM) e agendamentos são simulados, e a própria interface avisa isso. Não é uma integração em produção.
- Demo de uma ferramenta de Customer Engagement com IA.
- Duas semanas, trabalhando praticamente sozinho com ferramentas de IA.
- Três fluxos: analisar campanha, criar campanha e taguear landing page.
- Sem métricas de negócio: o case mostra o que foi construído.
O problema
Para criar uma campanha numa ferramenta de automação, a pessoa precisa saber de antemão qual público usar, quais canais escolher, que regras montar e como a necessidade do negócio vira uma estrutura dentro da plataforma.
Na Brain 003, a pessoa começa dizendo o que quer alcançar. A Brain faz as perguntas que faltam e, quando a decisão precisa de mais forma, mostra um card ou uma tela. As telas continuam existindo; a conversa leva até elas com o que já foi decidido.
A pergunta que guiou a demo: dá para montar uma campanha só explicando o que se precisa?
Como a conversa foi estruturada
Os fluxos seguem a mesma sequência de seis passos, do pedido inicial até algo criado no projeto.
Sequência de cada fluxo: pedido, perguntas, proposta, ajustes, confirmação e execução.
01
Pedido
02
Perguntas
03
Proposta
04
Ajustes
05
Confirmação
06
Execução
O passo que mais importa é a confirmação. Até ali, tudo é uma proposta que pode ser ajustada ou descartada. Depois de confirmar, a proposta vira um item salvo no projeto, como um workflow, e deixa de ser só uma resposta no chat.
Criação de campanha: onze decisões em cinco etapas
Criar uma campanha na Brain 003 envolve onze decisões. Agrupei essas decisões em cinco etapas para que a pessoa saiba em que ponto está sem precisar conhecer a estrutura inteira antes de começar.
Criação de campanha em cinco etapas: estratégia (objetivo e público), plano de ativação (canais, conflitos e estimativa), experimentação e mensuração (teste A/B e mensuração), criação e ativação (revisão e campanhas) e acompanhamento (monitoramento e workflow mensal).
01
Estratégia
Objetivo · Público
02
Plano de ativação
Canais · Conflitos · Estimativa
03
Experimentação e mensuração
Teste A/B · Mensuração
04
Criação e ativação
Revisão · Campanhas
05
Acompanhamento
Monitoramento · Workflow mensal
Algumas decisões são respondidas em texto e outras em opções clicáveis. Ao lado da conversa fica o “Resumo da campanha”, que marca cada etapa como concluída, em definição ou pendente. Com isso, dá para conferir o que já foi decidido sem voltar no histórico do chat.
Os três fluxos da demo
Usei a mesma estrutura de conversa em três tarefas bem diferentes: entender o resultado de uma campanha que já rodou, criar uma campanha nova e preparar a mensuração de uma landing page.
Três fluxos da Brain 003: análise de campanha, criação de campanha e tagueamento de landing page.
Analisar
Análise de campanha
Identificar a campanha e com o que comparar
ROAS, resgate e resultado por segmento
Insights, ações, painel e workflow recorrente
Criar
Criação de campanha
Estratégia: objetivo e público
Canais, conflitos, estimativa e teste A/B
Revisão, criação e workflow mensal
Taguear
Landing page
Diagnóstico de GTM, GA4 e pixel da Meta
Eventos, UTMs e bloqueio por consentimento
QA, pendências e Sentinela de monitoramento
Se a estrutura só funcionasse na criação de campanha, eu teria apenas um roteiro bem feito. Por isso ela precisava aguentar tarefas diferentes. Na home, basta um “bom dia” para a Brain oferecer os três fluxos como ponto de partida.
Como cada fluxo termina
Os três fluxos começam na conversa, usam cards nas decisões que precisam de mais estrutura e terminam com algo salvo no projeto. Abaixo, duas telas de cada um.
Análise · Segmentos
Análise · Workflow recorrente
Criação · Estimativa
Criação · Workflow mensal
Tagueamento · Diagnóstico
Tagueamento · Sentinela
Todas as capturas são da demo. Dados, integrações (Slack, CleverTap, Blip, GTM) e agendamentos são simulados, e a interface indica isso.
Quando usar conversa e quando usar tela
Uma das decisões mais importantes foi não fazer tudo por chat nem tudo por configuração manual.
Conversa funciona melhor para explicar e explorar. Cards e telas funcionam melhor para comparar, revisar e editar. A Brain 003 alterna os dois.
Conversa
Para explicar e explorar
Dizer o objetivo com as próprias palavras
Esclarecer o que ficou ambíguo
+
Cards e telas
Para ver tudo junto
Comparar opções, valores e conflitos
Revisar, editar e confirmar
=
Brain 003
Os dois, conforme a decisão
A conversa conduz as perguntas
Card ou tela aparecem quando a decisão precisa de forma
O critério que usei: se a pessoa precisa comparar ou revisar vários itens ao mesmo tempo, a resposta vira um card ou uma tela. Se ainda está explicando o que quer, continua na conversa.
Troca de pontos: um dos primeiros fluxos completos
Foi um dos primeiros fluxos a funcionar do início ao fim. A pessoa faz o pedido, a Brain pergunta o que falta, propõe um workflow, espera a confirmação e cria o workflow no projeto. Depois, ainda dá para pedir mudanças pela conversa dentro do editor.
Pergunta
Proposta
Editor
Ajuste
Troca de pontos não faz parte dos três fluxos principais da demo atual. Mantive aqui porque mostra bem o caminho da conversa até um workflow editável.
O papel do Design System
Gerar código com IA é rápido, mas cada rodada tende a trazer um botão um pouco diferente, um espaçamento novo ou um componente que já existia com outro nome. Para segurar isso, o Design System passou a ter regras que o código gerado precisa seguir, com testes que falham quando alguma delas é quebrada.
Visão geral
Conversational
Coverage
Acessibilidade
Os tokens ficam centralizados em src/design-system/. Há regras escritas para os agentes de IA e uma suíte de testes (contratos do DS, axe com baseline, reflow, reduced motion e conflitos tipográficos) que roda em CI nos pull requests que mexem na interface.
As principais decisões
Decisão 01
Começar pelo objetivo, não pela configuração
Em disputa
Seguir o modelo comum das ferramentas de automação, com formulários e editor visual logo na entrada, ou deixar a pessoa começar explicando o que quer?
Alternativas
- Onboarding com configuração completa
- Chatbot genérico, sem nada salvo no projeto
- Conversa que leva a itens salvos e editáveis
Decisão
Começar pela conversa. Ela conduz as perguntas iniciais e, quando é preciso revisar, comparar ou editar, a Brain mostra cards e telas.
Trade-off
Exige cuidado para não empurrar tudo para o chat e um critério claro de quando a tela deve aparecer. Esse critério ficou menos formal do que eu gostaria.
Consequência
A mesma estrutura funcionou para análise de campanha, criação de campanha, tagueamento e workflows salvos.
Aprendizado
Chat sozinho não dá conta de uma campanha com muitos parâmetros. E começar direto pelas telas obriga a pessoa a já saber o que configurar.
Decisão 02
Usar o Design System como regra para o código gerado com IA
Em disputa
Como construir rápido com IA sem acabar com componentes duplicados e várias versões do mesmo padrão?
Evidência
- Rota /design-system com navegação própria e cinco camadas: foundations, components, patterns, conversational e coverage
- Tokens centralizados em src/design-system/ e exemplos montados com os componentes reais
- Matriz de cobertura, lacunas conhecidas e documentação dos padrões de conversa
- Regras para os agentes de IA e testes de contratos, acessibilidade, reflow, reduced motion e conflitos tipográficos em CI
Decisão
Tratar tokens, componentes, tipografia, espaçamento, estados, acessibilidade e documentação como regras que o código precisa cumprir, com testes para verificar.
Trade-off
Manter o sistema e os testes toma tempo. Corrigir diferenças visuais a cada nova rodada de código gerado tomaria mais.
Consequência
O Design System deixou de ser só uma referência para mim e passou a limitar o que a IA podia gerar.
Aprendizado
Com a IA gerando boa parte do código, ter o Design System só como referência visual não bastava. Ele precisou virar regra escrita e teste.
Decisão 03
O que precisava funcionar na demo
Em disputa
Com duas semanas e dados simulados, até onde valia a pena implementar de verdade?
Decisão
Priorizei fluxos completos do início ao fim, itens salvos no projeto, comportamento real da interface e limites claros, como a aprovação humana antes de disparos. As integrações externas ficaram simuladas.
Trade-off
A demo mostra bem a experiência e a estrutura por trás dela, mas não prova que as integrações funcionariam em produção nem que o produto gera resultado de negócio.
Consequência
Deu para testar a conversa, os itens salvos, a passagem entre chat e editor, o Design System e a acessibilidade em algo que roda.
Aprendizado
Deixar claro o que é demo e o que seria produção evita vender mais do que foi feito, inclusive neste case.
O que dá para ver na demo
A home começa por uma mensagem
Observação qualitativaNão há formulário de configuração na entrada, só um campo de mensagem com seletores de projeto, agente e modelo. Aqui, depois de um “bom dia”, a Brain já oferece os três fluxos: criar campanha, analisar campanha e configurar tagueamento.
Resumo lateral da campanha
Observação qualitativaAqui o resumo já acompanha a conversa: Estratégia, Plano de ativação e Experimentação estão concluídos, e Criação e ativação está em definição. Na conversa, os cards mostram os links com UTM e a revisão antes de criar.
Proposta antes de criar
Observação qualitativaA análise feita na conversa vira uma proposta de workflow com gatilho e etapas. Nada é criado até alguém clicar em “Confirmar e criar”.
Componentes reais na documentação
Observação qualitativaO Design System documenta o ConversationComposer usando o próprio componente do produto, com anatomia, tokens e arquivos de origem. Se o componente muda, a documentação muda junto.
Padrões que saíram dos fluxos
Observação qualitativaAlguns padrões nasceram nos fluxos e só depois foram documentados. O Journey Summary (o resumo da campanha) e a Workflow Proposal entraram na seção Patterns com status, regras e o componente de origem.
Desenhar e construir ao mesmo tempo
Como construí a demo praticamente sozinho, design e implementação andaram juntos. Eu definia um comportamento, implementava, testava no navegador e ajustava. Usei Claude, Claude Code, Claude Design, ChatGPT, Codex e Cursor para gerar e revisar código, sempre dentro das regras do Design System e com testes rodando. As decisões de produto e de design continuaram comigo.
O que só apareceu com a demo funcionando
Algumas coisas só dá para avaliar com a demo rodando: se a conversa continua de onde parou, como o scroll se comporta numa conversa longa, o que aparece durante o carregamento, como é ir do chat para o workflow e voltar, e se tudo continua usável em telas menores e pelo teclado. Mais de uma decisão que parecia certa na tela estática precisou mudar quando passou a lidar com tempo, estado e a sequência real de uso.
O que aprendi com o projeto
Poder implementar o que eu desenhava mudou a forma como decido. Em vez de defender uma interação numa tela parada, eu colocava a interação para rodar e via se funcionava. Também aprendi que construir rápido com IA pede mais cuidado com o Design System. Sem regras e testes, cada rodada de código gerado trazia pequenas diferenças que depois eu tinha que corrigir à mão.
Impacto
Experiência
Do pedido a algo salvo no projeto
A pessoa parte de um pedido em texto, revisa uma proposta e termina com um item salvo, sem precisar configurar tudo no primeiro passo.
Observação qualitativa
Produto
Três fluxos com a mesma estrutura
Análise de campanha, criação de campanha e tagueamento de landing page usam a conversa para as perguntas e cards ou telas quando a decisão precisa de forma.
Observação qualitativa
Design System com regras e testes
Tokens, componentes, padrões, matriz de cobertura, regras para os agentes e testes diminuem as diferenças visuais que aparecem a cada rodada de código gerado com IA.
Observação qualitativa
Negócio
Impacto de negócio
Não medido. Foi uma demo com dados simulados, então o case mostra o que foi construído, e não conversão, receita ou escala.
Hipótese
Operação
Testes automatizados
Os testes cobrem os fluxos de conversa, persistência, Design System, acessibilidade, reflow, reduced motion, tipografia e regressões de interface. Os testes do Design System rodam em CI com baselines versionados.
Observação qualitativa
Retrospectiva
O que funcionou
- Fazer a conversa terminar em algo salvo no projeto, em vez de só respostas no chat.
- Escolher entre texto e card ou tela conforme o tipo de decisão.
- Implementar cedo e testar estado, persistência e navegação na demo rodando.
- Ter Design System, regras e testes valendo tanto para mim quanto para os agentes de IA.
Limites
- O prazo era de duas semanas. Priorizei fluxos completos e deixei as integrações reais de fora.
- Dados e integrações são simulados; a demo não representa uma operação em produção.
- O impacto de negócio não foi medido.
- A acessibilidade ainda tem lacunas registradas na matriz: zoom de 200%, operações do editor de workflow pelo teclado e área de toque dos pontos de conexão entre blocos.
O que eu faria diferente
- Capturar as telas de cada fluxo assim que ele ficava pronto, e não depois.
- Deixar mais explícito o critério de quando sair da conversa para um card ou tela.
- Definir desde o início quais métricas de uso observar, caso a demo seguisse para testes com usuários.
Quer ver a demo?
O acesso à demo da Brain 003 é controlado por senha.
Próximo case