App de Vistoria
UX Research
Negócio e problema
O aplicativo de vistoria agro foi criado em 2019 para apoiar vistoriadores durante inspeções em campo: preenchimento de relatórios, consulta de dados da fazenda e acesso às informações do segurado. O produto havia sido desenvolvido sem participação de UX, com foco técnico e sem considerar as condições reais de trabalho em campo.
O desafio não era só melhorar a usabilidade: era entender como a vistoria realmente acontecia.
Com o crescimento da operação, o volume de chamados no suporte aumentou de forma expressiva, sinal de que o produto havia se distanciado da realidade de quem o usava no dia a dia. Faltava entender onde, na prática, ele falhava para quem trabalhava em campo.
Como atuei no projeto
Fui responsável pela pesquisa e pela descoberta do projeto, do trabalho em campo à apresentação dos resultados.
Pesquisa de campo
Apliquei shadowing com três vistoriadores, no contexto real de uso: na lavoura, sem internet e com o sol na tela do celular, e na sede da fazenda, com internet e na sombra.
Mapeamento de funcionalidades
Listei as funcionalidades que poderiam entrar no app, com base nos outros aplicativos que os vistoriadores já usavam para realizar as vistorias.
Benchmark de mercado
Analisei os concorrentes e as funcionalidades que ofereciam, complementando o que a pesquisa de campo e os apps usados pelos vistoriadores mostravam.
Síntese
Organizei os insights da pesquisa em um backlog estruturado de melhorias, que depois foi apresentado aos stakeholders do projeto.
Viabilidade técnica
Debati com o time técnico, em reuniões de alinhamento, a viabilidade das funcionalidades solicitadas pelos usuários.
Apresentação
Apresentei os dados da pesquisa aos stakeholders e à equipe interna de Produto, o que abriu uma discussão estratégica sobre integrar ou desenvolver as ferramentas paralelas.
Como cheguei à solução
Conduzi pesquisa em campo utilizando shadowing e observação contextual, acompanhando três vistoriadores em dias distintos durante suas rotinas reais de trabalho. A equipe em campo incluía também pessoas da área de negócios e um auditor responsável por acompanhar as operações, o que permitiu capturar perspectivas diferentes sobre os mesmos problemas.
O que encontrei foi diferente do que os relatórios de suporte sugeriam. O trabalho acontecia em três momentos distintos e desconectados, e os vistoriadores supriam as lacunas do app com ferramentas paralelas. Quatro pontos resumem o que observei:
Campo
Sem conectividade, com exposição ao sol, deslocamentos constantes e pressão operacional.
Sede da fazenda
Onde os relatórios eram preenchidos, com o cliente presente para validação em tempo real.
Galpão
Usado para análises finais de culturas colhidas, em alguns tipos de seguro específicos.
Ferramentas paralelas
GPS por satélite para registrar rotas, já que não havia sinal de internet nas lavouras, e outros aplicativos para guardar o que o sistema não guardava offline.
Cada ferramenta extra era uma evidência concreta de um gap que o produto ainda não resolvia. Foi esse mapeamento, e não só os relatórios de suporte, que deu base ao backlog de melhorias apresentado aos stakeholders.
O que foi entregue
Este projeto não envolveu o desenho de telas nem entrega em produção. O entregável foi um backlog estruturado de melhorias, construído a partir dos insights da pesquisa e apresentado aos stakeholders.
A apresentação gerou discussões que foram além do design: a equipe de negócios questionou se algumas ferramentas paralelas usadas pelos vistoriadores deveriam ser desenvolvidas nativamente dentro do produto ou integradas via API. Essa conversa, que surgiu diretamente das observações em campo, abriu um direcionamento estratégico que não estava no escopo original da pesquisa.
As principais oportunidades identificadas foram:
- Funcionamento offline como requisito, não diferencial
- Simplificação dos fluxos operacionais mais repetitivos
- Melhor separação entre perfis de acesso e visibilidade de informações essenciais
- Confirmações de ação em etapas sensíveis do processo
- Melhorias de performance para reduzir fricção durante o uso em campo
O que aprendi
Esse projeto reforçou algo que entrevistas remotas raramente mostram: o contexto de uso transforma completamente o problema.
Ver um vistoriador usar um GPS por satélite porque o app não funcionava sem internet foi mais revelador do que qualquer relatório de suporte. O usuário já havia criado a solução: o produto só precisava aprender com ela.
Se fosse repetir o projeto, dedicaria mais tempo a duas frentes: aprofundar as conversas individuais com os vistoriadores para entender nuances entre perfis de operação diferentes, e envolver o time técnico mais cedo para discutir viabilidade das soluções identificadas, especialmente a decisão entre desenvolver nativamente ou integrar via API, que teria impacto direto no roadmap do produto.
