Sistema de Ocorrência do Cliente
Redesenhando um sistema de atendimento a partir da forma como as pessoas realmente trabalhavam
Um produto também pode ensinar maus hábitos
Consultar o banco de dados para encontrar novos chamados.
Escrever solicitações primeiro no Word antes de registrá-las.
Ignorar a interface principal sempre que possível.
Esses comportamentos apareciam repetidamente durante as entrevistas com clientes e analistas.
Não eram exceções, eram adaptações criadas para conseguir trabalhar apesar da ferramenta. Entender por que essas adaptações existiam foi o ponto de partida do projeto.
Sobre o projeto
O Sistema de Ocorrência do Cliente concentrava todas as solicitações registradas por clientes internos e externos da empresa, desde ajustes simples até incidentes críticos e indisponibilidades sistêmicas.
O projeto surgiu como uma iniciativa de inovação interna conduzida por um time formado por Produto, Negócio e Design, com o objetivo de repensar toda a experiência de atendimento.
Função
Product Designer
Pesquisa com usuários · Mapeamento de jornadas · Arquitetura da informação · Desenho de fluxos · Wireframes · Prototipação · Testes de usabilidade
Ferramentas
Adobe XD, Word, Excel
Entendendo o problema
As entrevistas mostraram rapidamente que os atalhos observados na introdução não eram casos isolados.
Eles apareciam em diferentes etapas da operação.
Clientes preenchiam formulários extensos, muitos campos obrigatórios não faziam sentido para determinadas solicitações e o tempo de sessão frequentemente encerrava antes da conclusão do cadastro.
Do outro lado, analistas procuravam chamados utilizando consultas SQL, acompanhavam atualizações por e-mail e navegavam entre diferentes telas para entender o histórico de uma mesma ocorrência.
As notificações também haviam deixado de cumprir seu papel. Cada alteração gerava novos e-mails para clientes e analistas, tornando difícil identificar o que realmente exigia atenção.
Em vez de reduzir esforço, a ferramenta distribuía informações entre diferentes canais e obrigava seus usuários a reunir tudo novamente para conseguir trabalhar.
Investigando a experiência
A pesquisa buscou compreender toda a jornada de atendimento as is, tanto para quem registrava uma ocorrência quanto para quem era responsável por conduzi-la.
Realizamos entrevistas com clientes e usuários internos, acompanhamos parte da rotina dos analistas e mapeamos as jornadas completas dos dois principais públicos envolvidos.
Ao organizar essas etapas visualmente, surgiu um padrão.
As dificuldades apareciam em momentos diferentes da experiência, mas tinham a mesma origem: o produto exigia esforço excessivo para executar tarefas que deveriam ser simples.
Redesenhando o processo para os analistas
Antes de desenhar qualquer interface, reorganizamos toda a lógica do atendimento.
Em conjunto com Produto e Negócio, revisamos responsabilidades, simplificamos etapas e estruturamos um fluxo que refletisse a forma como clientes e analistas realmente trabalhavam.
Essa jornada tornou-se a base do projeto.
Só depois dessa definição começaram os wireframes.
Nesse momento, o foco não estava na identidade visual, mas em validar organização, navegação e sequência das informações.
A primeira versão serviu como base para os testes com usuários.
Validando a proposta
A primeira versão navegável foi avaliada por dez analistas de diferentes níveis de atuação.
O roteiro simulava um dia de trabalho utilizando o sistema. Em vez de analisar telas isoladas, cada participante precisava executar tarefas comuns da rotina de atendimento.
O novo fluxo foi bem recebido e a reorganização da comunicação facilitou o acompanhamento do histórico das demandas.
Ao mesmo tempo, alguns pontos ainda exigiam ajustes.
- Localizar chamados pelo número de registro não era tão intuitivo quanto utilizar a busca.
- A área de conversa era facilmente compreendida depois de encontrada, mas seu acesso ainda passava despercebido.
- Usuários sentiram falta de orientações para o primeiro acesso, como tooltips ou uma breve apresentação do sistema.
- Alguns ícones não comunicavam claramente sua função.
- Surgiu também a sugestão de incorporar respostas rápidas para agilizar atendimentos recorrentes.
Esses resultados orientaram a evolução do conceito.
Refinando a solução
Mostrar apenas o que exigia atenção
Encontrar novas demandas era uma das atividades mais custosas para os analistas.
No sistema existente, todos os chamados apareciam juntos. Era responsabilidade do usuário descobrir quais realmente lhe diziam respeito.
A nova tela inicial reorganizou essa lógica.
Demandas sob responsabilidade do analista, atualizações recentes, notificações e atividades pendentes passaram a ocupar o centro da experiência.
A consulta ao banco de dados deixava de ser parte da rotina.
Wireframe e versão final.
Tornar cada ocorrência mais fácil de compreender
A interface buscou estabelecer uma hierarquia mais clara entre os elementos da tela. Informações essenciais, como identificação da ocorrência, status, responsável e prazo, ganharam maior destaque, enquanto conteúdos secundários passaram a ocupar posições de apoio.
O resultado foi uma leitura mais rápida do contexto de cada solicitação, reduzindo o tempo necessário para localizar as informações mais importantes.
Wireframe e versão final.
Tornar o processo visível
Outra dificuldade recorrente era descobrir em que etapa cada chamado se encontrava.
Status pouco intuitivos, responsáveis dispersos e ausência de contexto faziam clientes e analistas recorrerem constantemente a e-mails e outras telas para acompanhar o andamento das solicitações.
A versão final passou a comunicar continuamente responsáveis, status, prazos e próximos passos, reduzindo a necessidade de interpretações e consultas paralelas.
Encerramento
O projeto acabou sendo interrompido antes de sua implementação devido à mudança de prioridades e ao meu afastamento temporário após um acidente.
Ainda assim, percorreu todas as principais etapas de investigação, definição, prototipação e validação.
Foi meu primeiro projeto envolvendo um ciclo completo de Discovery, mapeamento de jornadas, redesenho de processos e construção colaborativa de uma solução baseada em evidências observadas em usuários reais.
Mais do que um redesign de interface, ele consolidou uma forma de pensar produtos que continuo utilizando até hoje.
Quando um sistema obriga seus usuários a criar processos paralelos para conseguir trabalhar, o problema raramente está apenas na interface. Ele está na forma como o produto foi concebido.