Plataforma de Gestão
UX/UI Design | UX Research
Negócio e problema
Em 2017, foi lançado um sistema de gestão de sinistros para centralizar todo o ciclo operacional de uma seguradora, do aviso inicial ao pagamento ao segurado. Com o crescimento da operação até 2023, o produto começou a mostrar sinais claros de esgotamento: lentidão, excesso de campos sem uso, bugs frequentes e dificuldade crescente para configurar o sistema para novos fluxos.
O suporte virou intermediário obrigatório para qualquer ajuste, e isso não escalava.
O desafio era evoluir o produto para um modelo mais flexível, permitindo customização de fluxos e reduzindo a dependência técnica para operações do dia a dia. O maior receio interno era aumentar a complexidade de um sistema já difícil de manter, sem comprometer a operação em andamento.
Como atuei no projeto
Atuei de ponta a ponta, da pesquisa ao acompanhamento do desenvolvimento, em colaboração próxima com a PO e os stakeholders.
Pesquisa e descoberta
Conduzi pesquisa quantitativa e qualitativa, com entrevistas com usuários e stakeholders, e organizei os dados em Affinity Mapping. Fiz também benchmark de mercado para buscar referências.
Estrutura e design
Montei o fluxograma com a distribuição de informações e campos por tela, prototipei no Figma e mantive o Design System, criando novos componentes para o projeto.
Decisões e priorização
Defendi, com base nas entrevistas, os perfis de acesso por time, aprovados como pilar da nova arquitetura, e ponderei impacto para o usuário e esforço técnico na priorização.
Validação e homologação
Validei protótipos com stakeholders, conduzi as reuniões de homologação com os clientes e fiz validações contínuas com protótipos e questionários, mesmo sem testes formais.
Handoff e backlog
Alinhei e fiz o handoff com o time de desenvolvimento, gerenciei o backlog, criei as tarefas no ClickUp e acompanhei o desenvolvimento até a entrega.
Qualidade
Auditei o design com o sistema em homologação e testei os fluxos em ambiente de desenvolvimento, fazendo o papel de QA, para checar se a entrega seguia o que foi desenhado.
Como cheguei à solução
Trabalhei em colaboração próxima com a PO e stakeholders ao longo de todo o projeto, incluindo reuniões de homologação de entregas que eu conduzia diretamente com os clientes. A pesquisa combinou análise quantitativa (volume de erros, padrões de uso, tickets de suporte) com entrevistas qualitativas com usuários e stakeholders. Esse cruzamento foi essencial para separar o que era percepção interna do que era problema real de operação.
Um dos pontos mais importantes surgiu das entrevistas: a necessidade de perfis de acesso diferenciados por time, com cada equipe acessando apenas as funcionalidades do seu papel. Internamente havia resistência, pois criar perfis parecia aumentar a complexidade, mas os dados mostravam que a falta dessa separação gerava ruído operacional e risco de erro. Defendi a decisão apresentando perfis reais de uso e problemas concretos, e a proposta virou um dos pilares da nova arquitetura. A solução foi estruturada em três frentes, guiadas por um critério de priorização:
Fluxos customizáveis
Por tipo de processo: cada time poderia configurar seu próprio ciclo sem depender de desenvolvimento.
Campos dinâmicos
Criação e gestão de campos sem intervenção técnica, reduzindo a dependência do time de suporte.
Perfis de acesso
Por função, separando responsabilidades dentro da operação e reduzindo ruído e risco de erro entre times.
Critério de priorização
Impacto para o usuário e esforço técnico, considerando que os primeiros times a migrar teriam suporte dedicado de um dev na implementação.
Mesmo sem testes formais no escopo, conduzi validações contínuas durante reuniões com stakeholders e usuários, usando protótipos e questionários para reduzir riscos antes de cada entrega.
O que foi entregue
O MVP foi entregue em produção, com a operação usando e testando o produto em ambiente real. A nova estrutura permitiu que os times configurassem fluxos e campos sem depender do time técnico, resolvendo diretamente o gargalo de suporte que motivou o projeto.
A decisão de perfis de acesso por time, uma das mais debatidas internamente, foi validada na prática: a separação por função reduziu ruídos operacionais e deu mais clareza sobre responsabilidades dentro da operação.
O que aprendi
Esse projeto foi onde mais me aproximei de um papel estratégico dentro do produto. Conduzir reuniões de homologação diretamente com stakeholders, defender decisões de design com base em pesquisa e navegar tensões internas de priorização me deu uma visão mais clara de como design e produto precisam operar juntos para entregar algo que realmente funciona.
O principal aprendizado foi sobre como comunicar decisões de design para audiências não-técnicas. Mostrar os perfis reais de uso e os problemas concretos que a ausência de separação causava foi mais eficaz do que qualquer argumento teórico sobre boas práticas de UX.
Se fosse repetir, teria estruturado um plano de testes de usabilidade mais formal desde o início, com métricas definidas antes da entrega, não depois. Isso teria dado mais segurança nas decisões e mais evidência para apresentar aos stakeholders ao longo do processo.
