Redesenhando a
Experiência de Operação de Drones

Do software de terceiros à independência total

A GTEEX é uma empresa de tecnologia voltada ao agronegócio que durante muito tempo, dependeu de softwares de terceiros para operar e configurar seus Drones de pulverização. No entanto, foi chegado o momento para se desvincular e desenvolver o próprio controle de drones, sendo maiores, com mais capacidade de carga e com a identidade da GTEEX. Era hora de criar um sistema 100% autônomo.

Meu objetivo ia além de criar telas bonitas: precisávamos organizar um grande volume de dados de configuração em uma interface intuitiva para os pilotos em campo.

Melhorando a interface, sem herdar os mesmos erros

Antes de qualquer decisão, eu precisava entender os motivos de cada mudança, precisava de evidências para fazer ou deixar de fazer algo. Então, para planejar essa interface complexa, eu precisei garantir antes de começar qualquer tela:

Organizando a arquitetura para entender com clareza

Projetar um sistema com +100 de telas no Figma exige organização, e por isso, mapeei a arquitetura anterior para garantir que ninguém ”se perderia” no meio do processo. Ficou extenso, mas virou uma boa base, só faz sentido reorganizar informação depois de entender exatamente onde e por quê ela está ali hoje.

Ao final do projeto, pude resumir a essência em seis pilares:

Estudando os concorrentes

Fui atrás de uma das interfaces mais usadas do mercado, a da DJI Agras T40, olhei e mapeei vídeos, prints/fotos, o funcionamento das luzes e botões físicos do controle. Mapeei o que pude da interface por categoria de tela: login, ativação do controle, autenticação, ambientação, alertas de conectividade, home, Início de voo, configurações de RTK, etc.

Entendi o que estava mais bem organizado no concorrente e, ao mesmo tempo, percebi que o software utilizado pela GTEEX estava alinhado em diversos pontos ao que o mercado já estava acostumado. Estávamos no caminho certo em relação à funcionalidades e configurações.

Fui falar direto com quem pilota no campo

Entrevistei pilotos com o objetivo encontrar dificuldades reais, priorizando quem já usa o controle há tempo e quem deixou de usar. Um deles, com cinco anos de experiência no setor, apontou a tela de radar do software usado pela GTEEX como superior à da DJI e à da XAG, mas revelou que um conhecido seu deixou de comprar por acreditar que não havia integração de mapeamento com outros drones.

A pior parte é que não é verdade.

Essa função existe, só não era encontrada. Outro problema do mesmo sentido, foi a pontuação de outro piloto que destacou que gostaria de filmar com o drone, pois ele considera a câmera decentemente boa e gostaria de mostrar ao patrão. No entanto, essa função também existe, mas estava escondida nas configurações do dispositivo.

Outro entrevistado, um dos primeiros pilotos GTEEX na Bahia, descreveu a interface como ”simples e sem firula”, mas criticou dizendo que o único defeito era que controle esquenta, trava, precisa reiniciar e isso o deixa perdido durante voos pela noite.

Observação 1

Um cliente seu deixou de comprar por acreditar que não havia integração de mapeamento com outros drones, mas a função existe, só não era encontrada.

Observação 2

A tela de radar do software usado pela GTEEX foi elogiada, considerada superior à da DJI e à da XAG.

Observação 3

Um dos pilotos deseja gravar a tela durante o voo, mas acredita que não é possível.

Unindo forças com outros times

A perspectiva do piloto não bastava sozinha. Antes, durante e depois da pesquisa com usuários, aconteceram diversas reuniões com o time de desenvolvimento de hardware, que era quem, de fato, tinha intimidade direta com o controle físico, com o time de treinamento de pilotos em campo e, portanto, sabe das necessidades do drone e dos seus usuários.

Foi com eles que validei, o que fazia sentido manter e o que deveria ser cortado na nova versão. Ouvir quem constrói e quem usa o produto não é bom, é essencial!

Insights de ouro para o redesign

Juntando netnografia, análise de concorrentes, entrevistas, a arquitetura atual e o alinhamento com o time de hardware, surgiram alguns insights para o redesign:

Colocando tudo que o piloto precisa, na primeira tela

Em uma área de 200 ha operada por um drone de 100 L, a repetição é parte da rotina. No cultivo de soja no Centro-Oeste e no MATOPIBA, são realizadas, em média, de 8 a 10 aplicações durante um ciclo de 4 a 5 meses, cada uma durando aproximadamente uma semana. Na prática, isso significa que o piloto faz exatamente o mesmo trajeto de pulverização várias vezes ao dia. Portanto, ter iniciar/configurar a mesma rota repetidamente é uma carga desnecessária.

Partindo desse contexto, projetei o dashboard inicial com foco em exibir as informações mais relevantes para a continuidade da operação:

• Qual drone está conectado;
• Status da bateria;
• Último voo realizado, com a opção de repetí-lo em um único clique;
• Barra superior com todas as informações principais dos dispositivos: wi-fi, rede móvel, bateria do controle e drone, rtk, etc...

Um outro frame reúne outros voos e mapas pesquisáveis, sem exigir navegação profunda pra chegar neles. Pra quem repete o mesmo trajeto todos os dias, isso elimina o custo de reencontrar, toda vez, o que já é rotina de trabalho e antecipa a próxima ação.

Ajustando interface e linguagem para a realidade do piloto

Boa parte dos botões estavam com texto com baixo contraste, dificultando a leitura

Boa parte dos botões de CTA tinha contraste tão ruim que ficava praticamente ilegível. Isso se torna mais preocupante quando se entende que o ambiente de uso é um campo aberto sob luz solar, ou seja, bastante claridade. Corrigir esse ponto era essencial para garantir que piloto consiga ler devidamente as informações na tela do tablet ou celular mesmo sob a claridade, sem precisar procurar uma sombra para trabalhar.

Além da questão de cores de contraste, houve ainda um problema com a terminologia/nomenclatura das palavras, provavelmente devido à erros de tradução no software. Por isso, para reduzir o esforço do usuário em decifrar um vocabulário estranho, reduzindo a curva de aprendizado, substituí os termos que confundiam quem estava aprendendo, por termos mais familiares. Por exemplo:

Novo enredoNovo mapeamento

Divisão de encomendasSegmentação

Analisando a organização visual nas telas mais usadas

Nas telas de "Iniciar trabalho" e "Modo de trabalho", as mais acessadas no dia a dia, as informações pareciam visualmente soltas na tela, de forma desordenada.

Reorganizei o layout em blocos, agrupando os dados que são relacionados dentro de cada um deles. Assim, fica mais fácil separar funções distintas e o piloto consegue ler e localizar algum dado de forma mais fácil.

AntesDepois

‹›

Já na tela de segmentação, adicionei uma barra na parte inferior pra escolher o tamanho da área a ser segmentada, um recurso que outras marcas já ofereciam e que a GTEEX ainda não tinha. A barra reduz o trabalho manual de ajuste e aproxima a experiência do que o mercado já popularizou.

AntesDepois

‹›

Na tela de registro de download e upload dos mapeamentos, havia uma poluição visual por conta das quatro barras de progresso empilhadas.Além disso, a linguagem era técnica desnecessariamente e ainda continha termos com tradução ruim, como citei na seção anterior (como "cheque completo" para check complete).

O progresso geral estava confuso e suscetível a dúvidas sobre o status real da operação, já que o carrregamento/feedback até 100% ocorria em diversas etapas intermediárias.

Para corrigir, defini uma única barra de progresso para transmitir previsibilidade e controle e também a exibição das etapas do processo são indicadas de forma sutil por pontos (milestones), usei um tom de voz mais empático e informativo para ajustar expectativas e ansiedade de espera do usuário.

AntesDepois

‹›

Se o usuário não encontra, não existe!

Durante as entrevistas, identifiquei duas funcionalidades essenciais que já estavam no ecossistema, mas estavam escondidas na interface, o que gerou desde a perda de vendas até a frustração operacional do piloto.

Descobri que a empresa havia perdido uma venda simplesmente porque um potencial cliente acreditava que a GTEEX não aceitava mapas gerados por drones de outras marcas. A funcionalidade existia, mas estava tão escondida na estrutura antiga que parecia não existir.

Para matar essa objeção comercial na raiz, criei um botão/atalho de importação de mapas logo no dashboard inicial, onde o piloto vê as informações básicas antes de iniciar seus voos. Agora, ao acessar o controle, fica claro que o sistema é compatível com o mercado.

Outro relato que mereceu atenção foi o de um piloto que desejava gravar a tela do controle GTEEX durante a operação (para mostrar ao seu superior), mas acreditava não ser possível.

Para acessibilizar a gravação, que até então ficava na barra de ferramentas do android, inseri um botão dedicado de "Gravar Tela" integrado diretamente à interface de voo ao vivo. O piloto não precisa mais buscar no sistema, pois com apenas um toque na tela durante o voo, ele inicia a gravação rapidamente e sem perder o foco no drone.

Confira mais algumas telas do projeto

Use as setas esquerda e direita ou os controles do carrossel para navegar pelas imagens.

‹

›

Imagem 1 de 4

Aprendizados & Impacto

O sucesso do redesign do controle da GTEEX foi medido pela nossa capacidade de dar respostas claras às dores mapeadas no início do projeto. Ao olhar para o produto finalizado, o impacto consiste em três frentes principais:

Decisão 01

Cortando objeções de venda

A inclusão do botão de importar mapas no dashboard resolve uma das objeções dos compradores, que era não saber da existência de uma feature. Feature escondida é feature inexistente.

Decisão 02

Aprendizado + rápido

Ao alinhar a nomenclatura da interface ao vocabulário já consolidado do mercado agrícola, reduzimos o tempo e o atrito de novos usuários.

Decisão 03

Reorganizando dados

Os dados mais importantes ficam ao topo da hierarquia e a UI de forma geral foi reorganizada por similaridade, encontrabilidade e a visualização foi melhorada.