Do prompt à interface escalável
Ver protótipoOverview
O produto
A VeLVision é um SaaS de gestão para o setor automotivo, onde responder primeiro ao lead define a venda. Um agente de IA omnichannel foi a aposta estratégica para resolver duas dores: leads perdidos fora do horário e tempo gasto com leads não qualificados. O agente já rodava em apenas 6 clientes, cada um configurado à mão por CS, produto e engenharia em conjunto.
Meu papel
Product Designer responsável pelo design end-to-end. Conduzi o discovery, falei direto com stakeholders, estruturei e acompanhei os testes de usabilidade e apresentei decisões de iteração com base nas evidências coletadas.
Time e duração
Eu, um Product Owner, desenvolvedores de frontend e backend, um engenheiro de dados e contato direto com o time de CS. Do discovery ao deploy: 1 mês e 2 semanas.
Discovery
O contexto
O desafio não era construir a feature, era descobrir como torná-la configurável por quem não sabia o que era um prompt.
O CS já registrava quais personalizações os gestores mais pediam, e isso deu o ponto de partida — mas os pedidos diziam **o quê**, nunca **por quê**. Entender a motivação por trás deles foi o que o discovery precisou resolver.
O que investigamos
O que encontramos
Curadoria > interface
Trabalhei com a Engenharia para mapear quais variáveis de prompt impactavam comportamento, personalidade e regras de negócio da IA — e conduzi card sorting com usuários para priorizar quais quesitos tinham mais demanda de configuração. Essa curadoria definiu o escopo do fluxo e foi mais determinante que o design das telas.
Controle percebido
O gestor não queria customizar tudo; queria sentir que tinha escolha. O discovery não foi só sobre UX — foi sobre engenharia reversa do processo existente para entender quais pontos geravam mais interesse de configuração.
O estoque como prova
O gestor precisava de uma prova concreta de que a IA já conhecia o negócio dele — sem isso, qualquer promessa soava abstrata.
Zero jargão
Termos técnicos bloqueavam adoção — tudo precisava virar linguagem natural.
O CS como rede de segurança
O shadowing revelou que no processo manual, era o CS que absorvia a ansiedade do gestor a cada etapa: tirava dúvidas, dava exemplos e tranquilizava o cliente de que o produto iria funcionar. Esse humano era uma parte central do fluxo e eu ia tirá-lo do processo.
Medo de alucinação
Nos workshops, o principal temor dos gestores era a IA inventar informações sobre veículos ou condições da revenda. Retirando o contato humano do fluxo, esse medo precisaria de outro anteparo.
"Mas ela já integra o estoque diretamente?"
A decisão central
A direção
Tratar a configuração não como um formulário técnico, mas como uma camada de tradução entre engenharia e negócio: o fluxo inteiro girando em torno de decisões de negócio, nunca de parâmetros de prompt.
Os tradeoffs
| Decisão | Ganho | Custo |
|---|---|---|
| Simplicidade vs. flexibilidade | Cards pré-definidos derrubam a barreira de entrada | Limitam gestores com necessidades muito específicas |
| Abstração vs. transparência | Esconder a lógica de prompt facilita o uso | Cria uma caixa-preta para o usuário |
| Velocidade vs. riqueza | A meta de <5min mantém o setup rápido | Ajustes finos de comportamento da IA ficaram de fora |
A solução
A estrutura
Um wizard de 4 etapas, ordenado para construir confiança antes de pedir qualquer decisão ao gestor.
Os princípios
Do estoque à publicação
A ordem das etapas é a própria estratégia de confiança: primeiro a prova concreta (estoque integrado), depois as escolhas (personalidade), depois o compromisso (publicar). Cada etapa entrega segurança antes de pedir a próxima decisão.
Linguagem de negócio como interface
Cada label, cada opção e cada exemplo foram escritos na linguagem que apareceu nos workshops com gestores, não na linguagem da engenharia que gerou o dado.
Decidir, não preencher
Cards com perfis reais de comunicação em vez de campos abertos. O gestor escolhe entre opções concretas, não descreve do zero o que quer.
Mostrar antes de pedir
Cada card de personalidade inclui um exemplo real de conversa da IA. O gestor vê o comportamento antes de se comprometer com a escolha.
As etapas
- 01Conexão
Sincronização de estoque + escolha dos canais de atendimento.
O estoque era a principal incerteza dos gestores nos workshops — por isso a primeira etapa entrega uma prova concreta: ele vê os próprios veículos na tela antes de tomar qualquer decisão.
- 02Personalidade
Nome, perfil de comunicação e dados da revenda.
O discovery mostrou que o gestor queria sentir que tinha escolha — por isso cada opção vem com exemplos reais de conversa de como a IA se comportaria, enquanto a complexidade do prompt fica invisível.
- 03Regras e transbordo
Horários de atendimento, transbordo e distribuição de leads.
O card sorting e os workshops revelaram que essas eram as configurações com mais demanda — cada campo nasceu da priorização com usuários, não de uma lista técnica.
- 04Checkout
Visualização e edição.
checkout para uma visualização e edição macro das informações que foram cadastradas
As regras
Validação e iteração
O método
Revisei o protótipo com o CS e testei com 13 usuários em 3 sessões, com tarefas reais.
As iterações
Sincronização redesenhada
O erro mais contraintuitivo do projeto: o design original era eficiente demais. A integração acontecia rápido e silenciosamente — ninguém percebia que havia acontecido. Reforcei o tempo e o retorno visual, e ver o estoque integrado virou o gatilho que aumentava o comprometimento com o resto do setup.
Playground no checkout
Mesmo com diferentes exemplos e modelos, os usuários hesitavam em publicar — o medo de alucinação que apareceu no discovery reapareceu nos testes. O Playground foi adicionado como mais uma camada de confiança antes de publicar — literalmente o que o contato humano provia antes.
Mais materiais de apoio nos cards
Os textos iniciais dos cards de personalidade não bastavam para o gestor entender o impacto da escolha. Adicionei exemplos reais de conversa em cada prévia e textos de apoio contextuais — o gestor passou a decidir com mais confiança e sem pedir ajuda.
Campo "sobre a empresa" virou opcional
Nos primeiros testes, 3 de 6 usuários pularam o campo. Como ele afeta personalização e não qualidade, tornei-o opcional e adicionei um aviso no checkout. Na rodada seguinte, 4 de 7 pularam — e 3 desses voltaram para preencher depois do aviso. A autonomia do gestor ficou preservada sem custar a personalização.
Botão Publicar com estado intermediário
Em campos opcionais não preenchidos, o botão passou a exibir um estado de confirmação com mensagens explicando como o preenchimento melhoraria a personalidade da IA — uma camada de segurança no momento mais tenso do fluxo.
Antes e depois
Impacto
Para o negócio
Expansão destravada
A plataforma passou a ativar novos clientes no módulo de IA sem crescer o time interno na mesma proporção. O setup que antes bloqueava sprints inteiras agora acontecia em minutos, pelo próprio gestor.
Engenharia de volta ao core
Acabaram as ativações em sprints fechadas. As 2–4h de engenharia que cada ativação consumia voltaram para as entregas principais do produto.
Para o produto
Estratégia de confiança validada
A camada de tradução entre engenharia e negócio viabilizou a configuração sem suporte. O Playground substituiu o CS como mecanismo de confiança — e o comportamento dos usuários confirmou: 100% interagiram com a IA antes de publicar.
Aprendizados
A decisão invisível
A decisão mais crítica que tomei no projeto não foi visual — foi sentar com a Engenharia e decidir quais variáveis de prompt seriam configuráveis e quais seriam fixadas por regra. A interface é só a ponta visível desse processo.
Substituir um humano exige mais que usabilidade
Tirar o CS do processo não era uma questão de interface, era uma questão de confiança. O Playground não nasceu de uma prática de UX, nasceu de um vazio emocional que o shadowing tornou visível.
O escopo é a decisão de design
A curadoria com engenharia e o entendimento de valor dos usuários — quais variáveis expor, quais fixar — definiu mais o resultado do que qualquer decisão de layout ou interação. O que ficou de fora do fluxo importou tanto quanto o que entrou.
What's next
100% dos gestores usaram o Playground antes de publicar — esse comportamento é um sinal direto de onde a confiança ainda precisa ser construída. O próximo passo é usar os dados de interação do Playground para identificar padrões de dúvida e refinar os exemplos contextuais automaticamente.
Além disso, hoje o gestor ativa a IA e perde visibilidade do que acontece depois. Um dashboard de performance fecharia esse ciclo: monitoramento pós-ativação que mantém a confiança viva, gera valor contínuo e permite iterar o comportamento da IA com base em dados reais de atendimento.