top of page
Capa do case

Simplificando a coleta de dados no campo:

Um redesign focado na experiência de inspeção agrícola.
Do papel para condições extremas

O ponto de partida deste projeto era um desafio de transformação digital: criar a versão mobile do tradicional "Caderno da Embrapa". Na prática, esse caderno é a ferramenta onde o técnico agrícola registra tudo o que encontra enquanto caminha pela plantação — apontando pragas, doenças e plantas daninhas. É como um prontuário médico: o profissional anota os sintomas para que o Engenheiro Agrônomo possa, mais tarde, receitar o defensivo correto.

Sobre este case

Atuei no desenvolvimento do produto original — sendo responsável pelas telas de seleção de ofensores, registro de inputs e fluxo de monitoramento. Essa vivência me deu acesso direto às dores dos técnicos de campo, que carrego como base para este estudo.

O que você vê aqui é um redesign conceitual e independente. As soluções apresentadas são propostas minhas, desenvolvidas a partir dos insights reais daquela operação — e não refletem o produto em produção nem o trabalho de outros designers envolvidos no projeto.

Entregando valor antes do primeiro passo

Durante as pesquisas, os técnicos trouxeram uma dor clara: dados vitais sobre o histórico da área só podiam ser consultados no dashboard web, lá no escritório. No campo, eles iniciavam a inspeção às cegas.

Para resolver isso, trouxe essas informações para a linha de frente. Ao selecionar um talhão, o técnico vê um card de contexto com um raio-x rápido da área: a cultura e o estádio fenológico — que direciona quais ameaças procurar —, os DAE (Dias Após a Emergência), que indicam a vulnerabilidade da planta naquele momento, e o histórico de monitoramento com o status atual do talhão. Com isso, o técnico sabe antes de dar o primeiro passo se está entrando numa área estabilizada ou num foco crítico de infestação.

Card com informações sobre o talhão
 
 
 
 
Travamento de contexto

Com o técnico contextualizado, o próximo desafio era como iniciar a coleta. O fluxo original permitia registros avulsos: o técnico escolhia o talhão na hora, mas o dado caía numa aba genérica de registros — sem pertencer a nenhuma sessão, sem rastreabilidade de quando foi coletado ou dentro de qual inspeção. Na hora de analisar, o Agrônomo via uma lista misturada de registros formais e anotações de passagem, sem conseguir distinguir um do outro.

O problema não era o dado em si, era a falta de contexto ao redor dele.

No redesign, o botão de adicionar ocorrências só aparece depois que o técnico toca em "Iniciar monitoramento". Esse clique cria uma sessão com início definido, talhão vinculado e todos os registros agrupados dentro dela. Não é possível gerar um dado fora dessa estrutura. (A tela de registros não foi reprojetada neste estudo — o foco aqui é na decisão de arquitetura que impede a geração do dado solto.)

Quando o app sincroniza, o painel recebe pacotes rastreáveis — cada registro pertence a uma sessão, cada sessão pertence a um talhão, cada talhão pertence a uma inspeção. O Agrônomo finalmente consegue separar o que foi vistoriado de forma planejada do que foi anotado de passagem.

Fluxo iniciar monitoramento
 
 
 
 
O gargalo do "Vai-e-Vem"

Sessão iniciada e contexto travado, é hora de registrar o que foi encontrado. O maior aprendizado aqui foi comportamental: o aplicativo original forçava o usuário a se adaptar à lógica do sistema, ignorando a realidade da lavoura.

Imagine o técnico parado num ponto e encontrando três pragas diferentes no mesmo metro quadrado. No fluxo antigo, registrar isso era exaustivo:

  1. Abrir o mapa e selecionar o local.

  2. Achar a 1ª praga e salvar.

  3. Ser expulso de volta para a tela do mapa.

  4. Reabrir o mapa, achar o mesmo local, para só então adicionar a 2ª praga.

 

Sob o sol forte e usando luvas, repetir esse caminho a cada ofensor multiplicava o esforço. Com até 20 talhões por dia, essa fricção custava um tempo valioso da operação.

O sistema havia sido desenhado com foco na praga isolada, mas o modelo mental do técnico foca no ponto de inspeção — ele avalia um quadrante inteiro de uma vez. Para refletir essa lógica, mudei a arquitetura do fluxo de "um por vez" para um modelo de prancheta, inspirado num carrinho de compras: o técnico registra a 1ª praga, a 2ª, uma doença, e todos os apontamentos vão se agrupando numa única tela. No final, ele revisa tudo e faz um salvamento em lote de uma só vez.

O resultado é uma redução drástica no número de cliques e na carga cognitiva. Como a coleta ocorre 100% offline, a lentidão do fluxo antigo não era culpa da rede — era fricção de interface. O novo modelo entrega a navegação fluida que o contexto exige.

fluxo prancheta
 
 
 
 
 
O Desafio da lista gigante

Dentro desse fluxo contínuo, outro gargalo persistia. O catálogo do sistema tinha dezenas de pragas e doenças cadastradas — e no meio da lavoura, com o reflexo do sol na tela e luvas nas mãos, cada segundo de scroll para achar um item gerava frustração.

Os técnicos relataram uma dor recorrente: perdiam tempo buscando o mesmo inseto repetidas vezes, quando na prática a rotina deles se resumia a registrar sempre as mesmas 4 ou 5 opções — que variam conforme o ciclo da planta. A proposta foi simples: permitir que o técnico favorite e fixe os itens mais recorrentes no topo da lista. Embora a funcionalidade de favoritos tenha sido validada pelo time na época, este case traz minha visão de interface para esse problema.

Uma mudança pequena na arquitetura de escolha que devolve o controle ao técnico e elimina a maior parte da navegação em tela sob condições adversas.

favoritos
 
 
 
 
 
Conclusão: Muito além da interface

​O maior aprendizado deste projeto foi entender que otimizar cliques é consequência, não objetivo.

No fluxo original, registrar cada ofensor exigia 7 passos que recomeçavam do zero — repetidos por dezenas de pontos em até 20 talhões por dia. Mas o problema real não era o número de cliques: era que a interface ignorava o modelo mental do técnico. Ele não pensa em "registrar uma praga", ele pensa em "avaliar esse ponto".

Quando a ferramenta passa a funcionar com essa lógica, a agilidade aparece naturalmente. E quando ela também impõe a estrutura certa no momento da coleta, o dado que chega ao dashboard já está limpo — entregando valor não só para quem está na lavoura, mas para o Agrônomo que vai tomar a decisão de defensivo.

 

 

 

 

Obrigada por ler até aqui! Se quiser trocar uma ideia sobre este case, desafios de UX ou design de produto em geral, fique à vontade para entrar em contato pelas minhas redes.

bottom of page