O Extension Solution é um aplicativo de assistência técnica e extensão rural, lançado pela Fundação Solidaridad em dezembro de 2018. O usuário é o técnico extensionista: ele coleta dados do produtor durante a visita, online ou offline, e recebe de volta um diagnóstico e um plano de ação gerados automaticamente.

O produto tem duas faces. O aplicativo é a ferramenta de campo, usada na propriedade e muitas vezes sem conexão de rede. O painel administrativo web é a face de escritório, onde os dados coletados via app voltam em forma de acompanhamento e relatórios.

O produto nasceu de um Innovation Lab facilitado pela Onda em outubro de 2017, antes da minha entrada no time. Sete extensionistas da América Latina e da África foram entrevistados, e dessas conversas saíram as personas que guiaram os primeiros desenhos. O Lab terminou com jornadas de usuário e protótipos em papel votados pelo próprio grupo.

As restrições vieram todas do campo. Em várias regiões o produtor não tem acesso à internet e, em casos extremos, nem telefone, o que tornou o funcionamento offline uma condição do produto e não uma funcionalidade. O número de visitas por dia deixa pouco tempo disponível para o técnico em cada propriedade, então cada tela precisa pedir o mínimo de digitação possível. A recomendação que fechou o relatório do Lab é a que mais pesa na interface até hoje: a tela não deve carregar muita informação nem muitos botões.

A entrada no time foi em março de 2018, com o produto recém-lançado. Os testes de usabilidade com os técnicos já estavam em curso e o meu trabalho começou por eles: acompanhar as sessões pelo interior de São Paulo (Assis, Araçatuba, Barra Bonita, Piracicaba, Jaú e outras cidades), ver onde o extensionista travava e levar isso de volta para a interface.

Do ponto de vista de desenvolvimento, adotamos a metodologia de melhoria contínua para o produto. Então, ao longo desses anos, ele passou (e continua passando) por mudanças e adaptações para sempre estar de acordo com a necessidade do campo e alinhado com as tecnologias disponíveis. As mudanças ilustradas abaixo são exemplos dessa metodologia.

mudança 01 · a tela inicial

O protótipo em papel do Lab propunha uma home de boas-vindas, com meta da semana, vídeo novo e indicadores. A primeira versão em produção, anterior à minha entrada no time, resolveu isso como três blocos de contadores empilhados: produtores a avaliar, visitados nos últimos 30 dias e tarefas em aberto. A versão atual reorganiza a home em torno de três perguntas: "em que estágio estão os produtores da minha carteira?", "de quantos produtores eu ainda não fiz a coleta?" e "quantas e quais tipos de interações eu já fiz nos últimos tempos?".

status de sincronizaçãoA condição offline do produto virou informação visível no cabeçalho: o técnico sabe se o que coletou já subiu, e se ainda não subiu, ele pode atualizar a sincronização quando estiver em um local com rede.

carteira por nívelA leitura da home deixou de ser contadores soltos e passou a mostrar em que estágio está cada produtor da carteira.

mudança 02 · a coleta de dados

A coleta foi a prioridade número um votada no Lab, e o protótipo em papel já a resolvia como um checklist de temas em uma tela só, tudo à vista, com botões de finalizar e gerar plano de ação no fim da mesma tela. A primeira versão em produção manteve a lógica de tela cheia, começando pela escolha do formulário de avaliação. O problema vinha depois: um questionário longo, disputando a atenção do técnico com o produtor e sem indicação de onde ele estava ou quanto faltava pra acabar o questionário. A versão atual quebra o questionário em uma pergunta por tela, com barra de progresso no topo, opções em alvos grandes e a possibilidade de pular a questão. Menos digitação, menos leitura por vez e o técnico sabendo quanto falta.

botão pularPular uma pergunta deixou de custar o questionário inteiro: o técnico segue com outras perguntas e envia o que conseguiu levantar na visita.

barra de progressoA barra no topo responde em campo a pergunta que aparecia nos testes, quanto ainda falta para completar o questionário.

ajuda por perguntaO ícone de informação permite explicar a pergunta ao produtor sem sair da tela nem interromper o preenchimento.

Estruturar a linguagem visual foi um trabalho de seleção e padronização: escolher, entre acervos diferentes, um conjunto de ícones e fontes que se sustentasse como família e compusesse todas as áreas do produto. Um produto em melhoria contínua há sete anos só se mantém coerente se essas decisões forem tomadas e reaplicadas com consciência.

O mapa de navegação é o documento que sustenta as duas faces. Ele lista cada tela, de onde se chega a ela e para onde ela leva, antes de qualquer decisão de layout. Serve para achar caminho sem saída, tela duplicada e profundidade excessiva enquanto ainda é barato mudar, e é o que o time de desenvolvimento consulta para saber o que existe.

+

+

A jornada do usuário e a necessidade de uso aparecem em dois contextos com exigências opostas. No campo é a vez do aplicativo: a coleta acontece com campos de alvos grandes e o mínimo de digitação, o aparelho na mão do técnico extensionista, que dá feedback ao vivo para o produtor. No escritório é a vez do computador: a leitura é de conjunto do que foi coletado em campo, listas, filtros, comparação entre produtores e exportação de relatórios. Manter as duas faces reconhecíveis como o mesmo produto, sem forçar a interface do campo dentro da tela do computador, é o principal trabalho de sistema deste projeto. Abaixo, parte dos principais fluxos do aplicativo e exemplos de tela do painel administrativo.

O painel administrativo foi construído com base no CoreUI, uma biblioteca pronta de componentes administrativos. A decisão vem de uma leitura de prioridade: o painel é ferramenta interna de escritório da equipe, usada por quem já conhece a metodologia do trabalho. Essa decisão permite que o esforço de design de interface fique onde precisamos de mais resultado: no aplicativo, na mão do técnico em campo.

No painel administrativo, focamos esforços na arquitetura da informação: quais telas existem, o que cada perfil de acesso vê (permissionamento) e como o dado coletado na visita pelo app chega ao relatório que o projeto entrega ao cliente.

Cada projeto tem um ciclo de vida e por isso os números oscilam de um ano para o outro. A quantidade de projetos ativos não indica crescimento ou queda do produto. A medida de sucesso que nos interessa está além dela: é o impacto na vida de cada produtor que passa a trabalhar com melhores práticas por causa da nossa solução.

2023

28

projetos ativos

+5K

novos produtores cadastrados

+15 MIL

produtores impactados

+14 MIL

interações criadas

+1K

tarefas criadas

cadeias

cana

café

soja

pecuária

cacau

mate

laranja

palma

países

argentina

bolívia

brasil

colômbia

paraguai

peru

uruguai

2024

31

projetos ativos

+6K

novos produtores cadastrados

+28K

produtores impactados

+18K

interações criadas

+20K

tarefas criadas

cadeias

cana

café

soja

pecuária

cacau

mate

laranja

palma

países

argentina

brasil

colômbia

méxico

paraguai

peru

uruguai

2025

19

projetos ativos

+7.5K

novos produtores cadastrados

+140

técnicos usando o app

+14K

interações criadas

+4K

tarefas concluídas

cadeias

cana

café

soja

pecuária

cacau

mate

laranja

palma

países

argentina

brasil

colômbia

méxico

paraguai

peru

uruguai

A vida de um produto não pode ser baseada apenas em insights de início de jornada. Quando a gente fala em melhoria contínua, são os anos seguintes, em que cada melhoria precisa conviver com o que já existe e com quem já aprendeu a usar do jeito antigo. Sete anos no mesmo produto, entrando como executora e chegando à coordenação, deslocaram a pergunta de trabalho de menos "como esta tela deveria ser?" para mais "com tudo o que aprendemos e estamos vendo na prática: o que entra agora, o que espera e o que não vale o custo de mudar?"