Reformulação de Plataforma Gestão e Acompanhamento Agronômico

A plataforma era um SaaS de gestão de áreas agrícolas: a partir da análise de imagens das áreas cadastradas, gerava relatórios com IA para diferentes estágios do plantio.

Quem usa são engenheiros agrônomos e gestores de usinas, que precisam entender a situação da sua cultura para guiar as tomadas de decisão.

Antes de chegar a esse modelo, a plataforma já havia passado por diversas reformulações. Clientes com muitas áreas refaziam o mesmo fluxo para cada relatório, e cada produto novo exigia adaptar a interface. O desafio era entender o negócio a fundo para tornar a plataforma escalável e encurtar o caminho de quem depende dos relatórios para decidir.

Para entender todo o contexto, conduzi várias etapas de avaliação em diferentes áreas da aplicação:

• Mapeamento da jornada atual
• Entrevistas com gestores e POs
• Feedback de clientes registrado ao longo do último ano
• Análise de consumo dos módulos
• Análise de vídeos de sessões de uso
• Backlog de melhorias registradas
• Exploração da documentação vigente
• Benchmark de concorrentes

O objetivo era identificar quais problemas eram estruturais e quais poderiam ser resolvidos apenas na camada de interface.

Após a exploração, as evidências reveladas ao time apontavam quatro problemas principais.

Antes · experiência existente

1. 01 Jornada não linear ou inconclusiva O caminho até as solicitações era confuso, repetitivo e nada otimizado. O usuário preenchia os mesmos dados várias vezes, e módulos e relatórios eram consumidos em solicitações unitárias, o contrário do que a plataforma deveria entregar: otimizar tempo e resultado.
2. 02 Estados inconsistentes Novos produtos nem sempre compartilhavam uma estrutura coerente com os existentes.
3. 03 Dificuldade de escala O produto era pouco escalável: cada novidade causava problemas técnicos ou adaptações não planejadas.
4. 04 Segurança e dados A plataforma ainda não contava com um modelo de multiusuários e gestão de acesso, o que gerava compartilhamento indevido de senhas.

A partir desse diagnóstico, os fluxos foram reorganizados buscando reduzir decisões desnecessárias, criar padrões reutilizáveis e tornar a navegação mais previsível.

Direção proposta

1. Modelo de navegação
2. Stack + design system
   1. Padrões de interação
   2. Componentes reutilizáveis
3. Fluxos especializados

Cada decisão responde a um ou mais problemas do diagnóstico. As conclusões e as propostas foram minhas, apresentadas ao time.

• 01 Jornada não linear ou inconclusiva

Solicitar vários relatórios de uma vez

Cada solicitação exigia refazer o fluxo inteiro, mesmo para a mesma área.

Minha proposta

Selecionar várias áreas, definir um ou mais relatórios para cada uma e solicitar tudo de uma vez. Se falta algo, a plataforma indica onde resolver.

Concessão

Cada solicitação tem um limite de volume.

Critério

Esforço de interação e clareza sobre o que falta em cada área.

Situação

Integrada à nova versão

Uma solicitação por vez × várias de uma vez

Alternativa A · uma por vez

• Uma área por solicitação
• Repetição para cada área
• Erro descoberto no fim

1. Escolher uma área
2. Adicionar os dados
3. Definir um relatório
4. Solicitar

Tudo de novo para cada relatório e cada área

Alternativa B · várias de uma vez

• Várias áreas selecionadas
• Pendência indicada antes do envio
• Uma solicitação para tudo

1. Selecionar várias áreas
2. Ver o que falta em cada uma
3. Definir um ou mais relatórios por área
4. Solicitar tudo de uma vez

• 02 Estados inconsistentes
• 03 Dificuldade de escala

Reformular a base em vez de ajustar aos poucos

A plataforma não tinha estrutura para receber novos produtos, e cada atualização da interface era lenta.

Minha proposta

Reformular sobre uma nova arquitetura, mantendo o que já era familiar.

Concessão

Mais esforço no início e uma transição gradual: parte das mudanças, como a navegação lateral por áreas, foi levada antes à versão em uso e testada com um grupo de clientes antes de chegar a todos.

Critério

Custo de cada atualização, espaço para novos relatórios e autonomia do cliente para usar a plataforma sozinho.

Alternativas

Atualizar por partes ou reformular a interface sobre uma nova biblioteca de componentes.

Situação

Em desenvolvimento e testes até o fim da minha participação. Nem todas as mudanças previstas couberam no período.

• 04 Segurança e dados

Acesso por perfis

Várias pessoas do cliente participavam da jornada, com responsabilidades diferentes, mas a conta não distinguia quem era quem.

Minha proposta

Acesso multiusuário, com perfis por responsabilidade.

Concessão

A primeira versão teve poucos perfis e ainda não detalhava permissões.

Critério

Separar as responsabilidades de cada pessoa ao longo da jornada.

Situação

Implementado na versão em uso

Com a arquitetura da nova plataforma pronta, tínhamos direções e regras para o uso. Todas as mudanças convergiam para o mesmo efeito: otimizar o consumo da plataforma.

Das entregas ao impacto esperado

1. Problemas 01 · 02 Menu por áreas Responsabilidades separadas e linguagem única entre os produtos Em uso
2. Problema 01 Uso guiado Sugestões inteligentes e dados já preenchidos
3. Problema 01 Principal Solicitação em lote Vários relatórios e áreas de uma vez
4. Problemas 02 · 03 Escalabilidade Base para novos produtos e melhor gestão dos dados
5. Problema 04 Acesso por perfis Cada pessoa com o próprio acesso Em uso

Otimização do consumo Efeito comum de todas as entregas

• HipóteseNovos clientes
• HipóteseMais planos contratados pelos clientes atuais

Hipóteses e indicadores possíveis

Entrega	Hipótese	Indicador possível
Menu por áreas	Com cada área no seu lugar, o usuário encontra e gerencia áreas e relatórios sem pedir ajuda.	Chamados de suporte sobre navegação; tempo para encontrar uma área.
Uso guiado	Sugestões e dados já preenchidos reduzem erros e abandono no meio do fluxo.	Taxa de conclusão das solicitações; erros por solicitação.
Solicitação em lote	Pedir vários relatórios de uma vez aumenta o volume por solicitação e encurta o caminho até o resultado.	Relatórios por solicitação; tempo do início ao envio.
Escalabilidade	Uma base comum permite lançar produtos sem adaptações não planejadas.	Tempo para lançar um produto; ajustes de interface por lançamento.
Acesso por perfis	Com acessos individuais, mais pessoas de cada cliente usam a plataforma.	Usuários ativos por cliente; contas com mais de um perfil.
Impacto no negócio	Com o consumo otimizado, a plataforma atrairia novos clientes, e os atuais contratariam planos maiores.	Novos contratos; mudanças de plano; relatórios solicitados por cliente.

Hipóteses e indicadores propostos para acompanhar a proposta; não são resultados medidos neste case.

Foi o projeto em que mais apliquei o que aprendi até aqui: do mínimo atrito de usabilidade até ajudar o time a otimizar processos e a nutrir uma visão de qualidade para o produto.

A interação com toda a cadeia do produto me permitiu entender cada etapa e seus responsáveis, e lidar com o produto de maneira interna e externa. O contato direto com liderança, produto, engenharia e negócio enriqueceu as decisões, e cada pessoa teve sua importância no que foi decidido.

Com quem as decisões foram construídas

Liderança

• CPO
• CTO

Produto

• PM
• POs

Engenharia

• Front-end
• Back-end
• QA

Negócio

• Customer Success
• Estratégia
• Marketing

Uma base sólida permite que um produto alcance mercados cada vez maiores.

A qualidade muda a experiência do usuário, e, num produto que já era referência, essa responsabilidade é ainda maior.

Algumas ideias foram além do escopo da reformulação.