Kevi Chat
Categoria
UX/UI Design
/
/
Como dei clareza à tela mais usada de um SaaS de atendimento via WhatsApp com IA — e como transformei decisões de reunião em comportamento documentado.
O produto
O Kevi Chat é uma plataforma brasileira de atendimento ao cliente via WhatsApp com uma camada de IA. Times conversam com clientes, organizam filas, acionam bots e apoiam o atendimento com recursos como transcrição e resumo.
A Área de Conversas é onde o atendente passa o dia inteiro. É a tela central: a mensagem chega aqui, o bot age aqui, o histórico vive aqui. Por ser a superfície mais usada do produto, qualquer atrito nela não é um detalhe isolado — é um incômodo que se repete milhares de vezes por dia.
Este case foca só nessa área, e de propósito. É onde a densidade de decisão de design é maior, e onde meu jeito de trabalhar aparece com mais clareza.
O problema não era desenhar a tela. Era duas outras coisas.
A Área de Conversas já existia. O desafio não era criar do zero — era resolver dois problemas que se acumulavam.
Primeiro: densidade sem clareza. Uma única conversa pode conter muitos estados ao mesmo tempo. Mensagem enviada, mensagem com erro, áudio transcrevendo, bot "pensando", chat silenciado, reação, mensagens de origens diferentes. Tudo disputando o mesmo espaço. O atendente precisava bater o olho e entender o que estava acontecendo — e isso nem sempre acontecia.
Segundo, e menos óbvio: o comportamento não estava documentado. No Kevi, as decisões de produto não vinham prontas em specs antes do design. Elas surgiam durante a conversa, na reunião. Sem regras escritas de como cada estado deveria se comportar, a implementação virava decisão do desenvolvedor no improviso — e o que era entregue nem sempre era o que tinha sido desenhado.
Então o trabalho tinha dois eixos: dar clareza visual a uma tela densa, e documentar comportamento com precisão suficiente para o handoff não depender de suposição.
Como eu ataquei isso
Meu processo aqui tem um passo que considero meu diferencial: eu caço decisão em transcrição de reunião.
Como no Kevi a decisão nasce na conversa e não no documento, eu começava cada frente puxando as transcrições das reuniões relevantes, lendo para achar o que realmente tinha sido combinado — o que ficou decidido, o que ficou em aberto, o que foi descartado e por quê. Só então desenhava.
Isso me dava duas coisas. O design respondia ao que o time de fato decidiu, não a uma suposição minha. E quando aparecia uma dúvida sem resposta na reunião, eu sinalizava como pergunta em aberto em vez de preencher no chute — o que dava aos stakeholders um ponto claro de decisão em vez de um fato inventado.
No fim de cada frente, o desenho e as regras viravam PRD. Não por burocracia: o PRD era o que garantia que o produto entregue fosse o produto pensado.
1. Onde mostrar o que o bot está "pensando"
Quando o bot age durante um atendimento, o atendente precisa entender o que ele está fazendo. A pergunta era: onde colocar essa informação?
A saída fácil era um modal. Clica, abre uma janela com os detalhes, fecha. Mas isso tinha um custo escondido: cada verificação tirava o atendente do fluxo da conversa. Numa tela onde a pessoa está lendo e respondendo o tempo todo, interromper para abrir e fechar janela é atrito puro.
Optei por manter tudo dentro da timeline, no próprio balão. A informação fica recolhida por padrão — quem só quer ler a conversa não é incomodado — e disponível para quem quer abrir. A decisão foi priorizar o fluxo de leitura acima da facilidade de implementação de um modal.
2. Um sistema para todos os tipos de balão
Esse foi o desafio mais complexo do projeto. Uma conversa no Kevi não é só texto: é áudio, imagem, vídeo, PDF, documento, chamada perdida. Cada tipo tem uma natureza diferente, e a tentação é desenhar cada um por conta própria — o que leva rápido a uma tela que parece seis produtos diferentes empilhados.
O problema tinha três frentes ao mesmo tempo, e a dificuldade estava justamente em resolvê-las juntas, sem que uma quebrasse a outra:
Consistência entre tipos muito diferentes. Um áudio e um PDF não têm nada em comum no conteúdo, mas precisam parecer parte da mesma conversa. Defini uma estrutura de balão comum — o esqueleto que todos compartilham — para que a variação entre tipos fosse de conteúdo, não de linguagem visual. O atendente reconhece que é uma mensagem antes de reconhecer que tipo de mensagem é.
Estados próprios de cada tipo. Cada mídia tem seu ciclo de vida. O áudio carrega, pode dar erro, pode ser reenviado, pode tocar. O PDF tem página. A imagem tem thumbnail. A chamada perdida não é bem uma mensagem. Precisei mapear os estados de cada tipo sem deixar que essa riqueza virasse inconsistência — estados equivalentes (como "erro" ou "carregando") se comportam e se parecem da mesma forma, independente do tipo de mídia.
Densidade. Tudo isso convive na mesma timeline, um balão embaixo do outro. Se cada tipo trouxesse peso visual próprio, a conversa viraria uma colcha de retalhos. A decisão foi manter o conteúdo específico contido dentro de um balão de comportamento previsível, para que a tela absorvesse a variedade sem parecer poluída.
O resultado é um sistema onde tipos radicalmente diferentes convivem como uma conversa só. A parte difícil não foi desenhar cada balão — foi fazer com que seis lógicas diferentes se lessem como uma linguagem única.
Resultado
O entregável central foi um sistema de componentes e estados documentado para a área mais usada do Kevi Chat. Cada estado com sua leitura visual e sua regra de comportamento.
O ganho concreto foi em consistência e handoff: ao documentar o comportamento em vez de só entregar telas, o desenvolvimento passou a ter uma fonte única de verdade sobre como cada estado deveria funcionar — reduzindo a ambiguidade que antes gerava decisão improvisada na implementação.
O que levei desse projeto
O trabalho mais valioso aqui não foi desenhar as telas — foi documentar comportamento. Num contexto onde a decisão nasce na reunião e não na spec, parte do meu papel como designer é capturar e formalizar essas decisões antes que se percam. Um bom PRD não é burocracia: é o que garante que o produto entregue seja o produto desenhado.
E amadureci na tradução de densidade em clareza. Uma tela cheia de estado não precisa parecer cheia. O trabalho com os tipos de balão me ensinou que o mais difícil não é desenhar cada peça, é fazer com que lógicas diferentes se leiam como uma linguagem só — a consistência é o que sustenta a clareza. Foi onde meu craft de UI mais evoluiu.
