Notebook sobre um pufe verde, diante de cortinas azul-marinho, mostrando o formulário de um projeto com a lista de voos.

Gestão de Voos

UX/UI Design | UX Research

Contexto

Negócio e problema

A empresa oferecia serviços de drone para produtores rurais: pulverização, leitura de lavouras e detecção de pragas. Quando um produtor contratava o serviço, a empresa alocava um piloto para executar a operação em campo. Conforme as operações cresciam, o acompanhamento interno das missões se tornava cada vez mais difícil.

O problema não era falta de informação, e sim excesso de dispersão.

Não havia uma plataforma centralizada: status de voos, dados de missões e informações operacionais circulavam entre planilhas e grupos de WhatsApp, gerando ruído de comunicação e perda de contexto. O desafio era reunir tudo em um único lugar, para que a equipe interna (operadores e pilotos) acompanhasse o progresso das operações de forma clara e hierárquica.

Piloto operando o controle de um drone em campo aberto, com a tela do controle visível e o terreno desfocado ao fundo
Atuação

Como atuei no projeto

Conduzi o design da plataforma, da pesquisa exploratória à validação do protótipo com os stakeholders.

  • Pesquisa exploratória

    Conversei com o stakeholder principal e com dois pilotos de drone para entender quais informações eram essenciais no acompanhamento das operações e onde estavam os pontos de fricção.

  • Benchmark de mercado

    Analisei plataformas concorrentes, complementando a pesquisa exploratória com referências de mercado para o desenho da plataforma.

  • Arquitetura da informação

    Estruturei o escopo do sistema em um sitemap com sistema de cores próprio, que separava o que era leitura do que era ação dentro da plataforma.

  • Style Guide e protótipo

    Criei o Style Guide e prototipei as telas da plataforma no Figma, com foco em clareza de status e em hierarquia visual consistente.

  • Gestão de backlog

    Gerenciei o backlog do projeto ao longo das iterações, mantendo o escopo alinhado com os stakeholders.

  • Validação

    Validei o protótipo com os stakeholders em alinhamentos frequentes e focados em ajuste fino, o que permitiu iterar com velocidade.

Abordagem

Como cheguei à solução

O projeto começou com uma pesquisa exploratória com o stakeholder principal e dois pilotos de drone, para entender quais informações eram essenciais no acompanhamento das operações e onde estavam os maiores pontos de fricção.

Com os insights em mãos, estruturei a arquitetura da informação e desenvolvi um sitemap com um sistema de cores próprio, que separava o que era leitura do que era ação. Complementei com um benchmark de plataformas concorrentes. O sitemap ajudou na organização interna do projeto e na validação com stakeholders, tornando mais fácil identificar gaps e alinhar expectativas sobre o que o sistema deveria cobrir.

Sitemap da plataforma em fluxograma: Login, Projetos, Criar projeto, Visualizar projeto, Missão, Lista de voos e Importar arquivos, com marcação de quais campos e botões cada perfil (Admin, Operador ou ambos) enxerga

O principal desafio de design foi transformar uma operação tecnicamente complexa, com hierarquia de projetos, missões e voos, em algo que qualquer operador acompanhasse sem treinamento extenso. Para isso, a solução foi construída em torno de quatro princípios:

  • Clareza de status

    O operador precisava saber, em segundos, o que estava acontecendo.

  • Informação e ação

    Separação entre informação e ação, para reduzir o risco de erro em operações críticas.

  • Hierarquia visual

    Consistente, refletindo a estrutura real das operações: projeto → missão → voo.

  • Redução de ruído

    Telas com alto volume de dados exigiam foco, não decoração.

Com a arquitetura definida, criei o Style Guide e prototipei as telas no Figma, gerindo o backlog do projeto ao longo das iterações. Os alinhamentos com stakeholders foram frequentes e focados em ajuste fino: o escopo estava bem definido desde a primeira reunião, o que permitiu iterar com mais velocidade.

Resultados

O que foi entregue

O resultado foi o protótipo da plataforma, validado com os stakeholders, que reúne em um só lugar informações antes dispersas entre planilhas e WhatsApp e oferece à equipe interna uma visão unificada do andamento das operações.

O protótipo também serviu para alinhar a visão operacional entre os diferentes perfis do time (pilotos, operadores e coordenação), com a proposta de reduzir a dependência de comunicação informal para coordenar as atividades.

Tela de lista de projetos com busca, filtro e botão Criar projeto, e tabela com projeto, cliente, cultura, data de criação, número de voos e ações de baixar, editar e excluir
Tela de lista de projetos
Tela de dados de um projeto com formulário (cliente, país, CEP, estado, cidade, data de criação e tipo de cultura) e, abaixo, mapa da fazenda com áreas demarcadas
Exemplo de um projeto já cadastrado com seus dados e o mapa da fazenda, anexado no momento do cadastro
Tela de uma missão com parâmetros de voo (drone, sensor, velocidade, altura, tempo e GSD) e lista de voos com operador, data e ações, além do botão Novo voo
Tela onde o usuário visualiza a missão e a lista de voos, dentro de um projeto
Modal Nova missão com campos de drone, serial, operador, sensor, velocidade, altura, tempo, GSD e fase da cultura; os campos Missão e Voo aparecem bloqueados por serem preenchidos automaticamente
Cadastro de uma nova missão dentro de um projeto. Os campos desativados são preenchidos automaticamente pelo sistema

As principais melhorias propostas foram:

  • Visibilidade clara da hierarquia entre projetos, missões e voos
  • Acompanhamento de progresso operacional pensado para tempo real
  • Separação explícita entre ações e leituras, pensada para reduzir risco de erro
  • Base escalável para futuras evoluções da plataforma
Reflexão

O que aprendi

Esse projeto reforçou a importância da arquitetura da informação em produtos com estruturas hierárquicas complexas. Mais do que organizar telas, o desafio foi criar uma lógica de navegação que refletisse como os operadores pensavam sobre o próprio trabalho, não como o sistema havia sido estruturado tecnicamente.

O sistema de cores no sitemap, que começou como uma ferramenta interna, acabou se tornando um instrumento de alinhamento com stakeholders: uma forma de tornar visível a distinção entre o que o sistema mostra e o que ele permite fazer. Esse tipo de artefato intermediário, que facilita conversas antes do protótipo existir, é algo que levo para outros projetos.

Se fosse repetir, ampliaria a pesquisa para incluir mais perfis dentro da operação, especialmente coordenadores que acompanhavam múltiplos projetos simultaneamente, para entender como a plataforma se comportaria em cenários de alta demanda operacional.

Próximo projeto