Droz - Chat
Redesenhando o core do produto para que agentes parassem de perder tempo com a ferramenta e voltassem a focar no cliente.
A Youpay é uma fintech que oferece uma carteira digital para os pais e alunos que facilita a gestão do dinheiro, diminui a burocracia e facilita os pagamentos escolares.
Meu papel
Responsável do início ao fim do projeto, entendimento com stakeholders, entendimento do problema e desenvolvimento das soluções
Duração
2 Meses
Time
1 Product Designer, 1 PM, time de engenharia
Problema
Técnico
A estrutura de renderização da listagem de conversas e da visualização de tickets gerava gargalos de performance conforme o volume de atendimentos crescia, devido a forma como foi construída tecnicamente.
Dos usuários
Os agentes já conviviam com lentidão do produto, o que aumentava o tempo de resposta e resolução dos tickets feitos pelos agentes. Fora isso, a interface acumulava decisões de design que faziam sentido quando o produto era menor, mas que agora criavam atrito pela falta de contexto rápido dos tickets e informações importantes dos clientes.
O que eu precisava entender
Precisava entender como os agentes realmente trabalhavam, não como achávamos que trabalhavam. Conduzi entrevistas com clientes ativos do Droz Chat, com os seguintes objetivos:
Junto com time de engenharia, entender a arquitetura do produto e seu funcionamento.
Entender o contexto real de uso: quais times e tipos de usuários utilizavam o produto.
Identificar gargalos e retrabalho no fluxo de atendimento.
Mapear o valor percebido: o que eles não abriam mão.
Além das entrevistas, também conversei com o time interno de suporte, que tinha contato diário com as reclamações dos clientes e acumulava uma visão qualitativa valiosa sobre os pontos de atrito mais frequentes.
Principais descobertas
Os agentes operavam em alto volume de atendimentos, muitas vezes alternando entre ferramentas paralelas para buscar contexto do cliente durante um atendimento. Dentro do próprio produto, a falta de informação visível na listagem forçava a abertura de cada conversa individualmente para entender do que se tratava, gerando retrabalho constante. Ao mesmo tempo, ficou claro que os agentes já reconheciam valor no produto e não queriam abrir mão dele. O problema não era o produto em si, era a fricção que havia se acumulado conforme ele cresceu.
Validação
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Solução
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Aprendizados
A comunicação com os stakeholders e desenvolvedores desde o início do projeto foram fundamentais, pois envolviam muitas regras, objetivos de negócio e viabilidade técnica junto disso. Com todos esses desafios conseguimos conciliar o negócio com as necessidades de nossos usuários.
Droz - Chat
Redesenhando o core do produto para que agentes parassem de perder tempo com a ferramenta e voltassem a focar no cliente.
O Droz Chat é um Helpdesk B2B destinado a profissionais do setor de suporte, tornando possível a centralização de atendimentos dos seus clientes através de diversos canais
Meu papel
Responsável do início ao fim do projeto, entendimento com stakeholders, entendimento do problema e desenvolvimento das soluções
Duração
2 Meses
Time
1 Product Designer, 1 PM, time de engenharia
O problema em dois níveis
Técnico
A estrutura de renderização da listagem de conversas e da visualização de tickets gerava gargalos de performance conforme o volume de atendimentos crescia, devido a forma como foi construída tecnicamente.
Dos usuários
Os agentes já conviviam com lentidão do produto, o que aumentava o tempo de resposta e resolução dos tickets feitos pelos agentes. Fora isso, a interface acumulava decisões de design que faziam sentido quando o produto era menor, mas que agora criavam atrito pela falta de contexto rápido dos tickets e informações importantes dos clientes.
O que eu precisava entender
Precisava entender como os agentes realmente trabalhavam, não como achávamos que trabalhavam. Conduzi entrevistas com clientes ativos do Droz Chat, com os seguintes objetivos:
Junto com time de engenharia, entender a arquitetura do produto e seu funcionamento.
Entender o contexto real de uso: quais times e tipos de usuários utilizavam o produto.
Identificar gargalos e retrabalho no fluxo de atendimento.
Mapear o valor percebido: o que eles não abriam mão.
Além das entrevistas, também conversei com o time interno de suporte, que tinha contato diário com as reclamações dos clientes e acumulava uma visão qualitativa valiosa sobre os pontos de atrito mais frequentes.
Principais descobertas
Os agentes operavam em alto volume de atendimentos, muitas vezes alternando entre ferramentas paralelas para buscar contexto do cliente durante um atendimento. Dentro do próprio produto, a falta de informação visível na listagem forçava a abertura de cada conversa individualmente para entender do que se tratava, gerando retrabalho constante. Ao mesmo tempo, ficou claro que os agentes já reconheciam valor no produto e não queriam abrir mão dele. O problema não era o produto em si, era a fricção que havia se acumulado conforme ele cresceu.
Validação
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Solução
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Aprendizados
O aprendizado mais importante não foi sobre design. Foi sobre timing. Uma reformulação técnica obrigatória abriu uma janela que dificilmente se abriria de outra forma, e saber reconhecer esse momento e aproveitá-lo foi tão decisivo quanto qualquer decisão de interface. Problemas estruturais, quando aparecem, são também uma oportunidade.
Droz - Chat
Redesenhando o core do produto para que agentes parassem de perder tempo com a ferramenta e voltassem a focar no cliente.
A Youpay é uma fintech que oferece uma carteira digital para os pais e alunos que facilita a gestão do dinheiro, diminui a burocracia e facilita os pagamentos escolares.
Meu papel
Responsável do início ao fim do projeto, entendimento com stakeholders, entendimento do problema e desenvolvimento das soluções
Duração
2 Meses
Time
1 Product Designer
1 PM
Time de engenharia
O problema em dois níveis
Técnico
A estrutura de renderização da listagem de conversas e da visualização de tickets gerava gargalos de performance conforme o volume de atendimentos crescia, devido a forma como foi construída tecnicamente.
Dos usuários
Os agentes já conviviam com lentidão do produto, o que aumentava o tempo de resposta e resolução dos tickets feitos pelos agentes. Fora isso, a interface acumulava decisões de design que faziam sentido quando o produto era menor, mas que agora criavam atrito pela falta de contexto rápido dos tickets e informações importantes dos clientes.
O que eu precisava entender
Precisava entender como os agentes realmente trabalhavam, não como achávamos que trabalhavam. Conduzi entrevistas com clientes ativos do Droz Chat, com os seguintes objetivos:
Junto com time de engenharia, entender a arquitetura do produto e seu funcionamento.
Entender o contexto real de uso: quais times e tipos de usuários utilizavam o produto.
Identificar gargalos e retrabalho no fluxo de atendimento.
Mapear o valor percebido: o que eles não abriam mão.
Além das entrevistas, também conversei com o time interno de suporte, que tinha contato diário com as reclamações dos clientes e acumulava uma visão qualitativa valiosa sobre os pontos de atrito mais frequentes.
Principais descobertas
Os agentes operavam em alto volume de atendimentos, muitas vezes alternando entre ferramentas paralelas para buscar contexto do cliente durante um atendimento. Dentro do próprio produto, a falta de informação visível na listagem forçava a abertura de cada conversa individualmente para entender do que se tratava, gerando retrabalho constante. Ao mesmo tempo, ficou claro que os agentes já reconheciam valor no produto e não queriam abrir mão dele. O problema não era o produto em si, era a fricção que havia se acumulado conforme ele cresceu.
Solução
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Validação
A partir disso, a direção foi clara: trazer a informação para onde a decisão acontece, não forçar o agente a ir buscar ela. Isso significou repensar o que aparece na listagem, o que fica visível ao abrir um atendimento e como o agente transita entre conversas sem perder o fio. O resultado foi uma interface que trabalha a favor do agente, não contra o tempo dele.
Aprendizados
O aprendizado mais importante não foi sobre design. Foi sobre timing. Uma reformulação técnica obrigatória abriu uma janela que dificilmente se abriria de outra forma, e saber reconhecer esse momento e aproveitá-lo foi tão decisivo quanto qualquer decisão de interface. Problemas estruturais, quando aparecem, são também uma oportunidade.