O processo
Para me certificar de que conseguiria basear minhas decisões de design nos problemas do usuário, desmembrei o processo de design para ter bem claro quais etapas eram interligadas.
Integrando o fluxo de pedidos ao processo de
plantação, colheita e rastreabilidade para
produtores orgânicos certificados.
Para me certificar de que conseguiria basear minhas decisões de design nos problemas do usuário, desmembrei o processo de design para ter bem claro quais etapas eram interligadas.
Encontrar uma maneira de automatizar o fluxo de pedidos do aplicativo atual de forma que o produtor atualize o sistema.
Um dos principais problemas do fluxo atual é que a previsão de disponibilidade deve ser perguntada e os pedidos devem ser separados manualmente, gerando margem de erro. Um risco atual é vender algo que não possa ser entregado
Para definir melhor o objetivo, fiz uma pesquisa de campo para entender o nosso público alvo, o produtor certificado de orgânicos.
São vários passos para conseguir essa certificação e uma das dores levantadas em pesquisa é que demora muito tempo tomar notas em campo de depois passar a limpo, as vezes o tempo para passar a limpo é o mesmo tempo de colheita.
Utilizando os dados da pesquisa realizada pela ABRAMO em 2017 com 1700 produtores rurais, assumi alguns conhecimentos prévios como certezas e fiz entrevistas semi estruturadas com 5 produtores, que correspondem a 80% da produção do aplicativo.
Após a pesquisa e as entrevistas, veio a proposta de construir um aplicativo para gerenciamento de plantação.
Dessa forma, o produtor irá cadastrar as suas plantações no aplicativo, assim como a previsibilidade de entrega. Pelo próprio aplicativo ele receberá os pedidos de todos os seus clientes. Além disso, irá diminuir a garga horária trabalhada, pois não precisará passar a limpo os dados colhidos no campo se utilizar o aplicativo enquanto colhe.
-O produtor consegue prever uma quantidade e quando vai colher.
As entrevistas mostraram que sim, cada cultura tem um tempo padrão do plantio à colheita, e por terem um cultivo semanal (para poder colher toda semana) eles acabam internalizando os processos e conseguem prever, com com certa precisão, o quanto vão conseguir colher na semana seguinte, de acordo com as variações climáticas e observações de campo.
- Gerenciar dados de colheita é uma tarefa que demanda tempo.
Sim, as entrevistas mostraram que passar a limpo as informações anotadas em campo, demanda muito tempo, além disso, algumas vezes é difícil entender a própria letra e os dados se perdem.
Perguntas o produtor:
Quais produtos você cultiva?
Me fale como é sua rotina.
Você faz algum controle das colheitas do mês por caderno computador ou celular?
O tempo influencia na colheita?
Você consegue prever a quantidade colhida? Com qual antecedência?
Foram duas personas definidas, o Gestor do Marketplace e o Produtor rural.
Ainda baseado nas entrevistas, consegui identificar as dores mais latentes do Gestor e do produtor rural que o app farmer poderia resolver.
Para entender melhor o que o usuário sentia em cada etapa, refiz a roda das emoções de Robert Plutchik para poder mapear mais facilmente as emoções de cada etapa do processo. Escrevi sobre no Medium.link para o artigo no medium.
Após o brainstorming de soluções para solucionar as dores descobertas em entrevista, propuz uma matriz de impacto e esforço para elencar, junto com o stakeholder, quais as soluções trariam maior impacto no negócio e qual o seu esforço de produção.
Assim, foquei nas soluções de alto impacto para proposta de M.V.P (produto mínimo viável).
Definimos que essas três etapas são o mínimo para o app poder ser lançado. Outras etapas são necessárias para o produtor ter a certificação, mas priorizamos essas por atenderem as necessidades de negócio.
Na produção orgânica, o agricultor é obrigado a não utilizar agrotóxico e fertilizante químico de alta concentração e solubilidade, não utilizar organismos geneticamente modificado e utilizar tecnologias (princípios e processos) conservacionistas (BRASIL, 2010).
Para se obter a Certificação, o produtor deve ter mapeado:
Preparação do solo, Adubação verde, Compostagem, Construção de estufa para produção de mudas, Plantio no campo, Transplante de mudas, Manejos e tratos culturais, Pragas e doenças, Colheita, Feira, Comercialização, Custos de produção, Plano de manejo.
Como M.V.P decidimos focar na rastreabilidade da plantação, colheita e venda, pois além de resolver do problema do produtor do caderno de campo, soluciona o problema do marketplace na automatização de pedidos e previsibilidade.
Uma reclamação dos produtores é que os aplicativos existentes focam apenas nas grandes propriedades, além da dificuldade de entendimento e falta de suporte.
Alguns aplicativos misturam idiomas e variáveis de sistema e outros parecem versões de desktop.
Fiz os fluxos ideais de como deveria funcionar o service blueprint e o fluxo do produtor usando o aplicativo.
No lado do marketplace, o ideal é que o sistema faça todas as separações de pedidos e controle de estoque.
No lado do produtor, foi decidido que ele só receberá pedidos dos produtos cadastrados. Ao cadastrar o produto ele já informa a previsão e conseguirá gerar relatórios de rastreabilidade de colheita e de venda, necessários para a certificação de produtor orgânico.
Fluxo interno do gestor
Fluxo do Produtor
Com os requisitos em mãos, e o fluxo mapeado, comecei a dividir os requisitos por telas.
Num primeiro momento o gestor receberá os relatórios por email, foquei então os esforços na concepção do aplicativo para o produtor.
Usei os wireframes para fazer o fluxo do usuário
Fluxo do Produtor
Após fazer algumas ideias no papel, pulei para a média fidelidade, pois ao explicar as telas para o stakeholder, percebi que ele tinha dificuldade em entender alguns fluxos, por causa da duplicidade de informações.
Lembrei então que o público alvo muitas vezes nem possui o ensino médio, então decidi apresentar um produto mais perto do final possível, com números e nomes reais de produtos, para evitar esse conflito e focar no processo.
Aqui começou a gerar dúvidas
Utilizei o plugin do figma chamado “Google Sheet Sync” para popular os cards com dados de uma tabela que criei, assim, o produtor na hora de testar, não irá se confundir com dados fictícios de um protótipo de baixa fidelidade.
Ao organizar dados na tela eu fui falar com o programador para tirar umas dúvidas de boas práticas para tabelas e outros elementos, descobri que ele havia saído da empresa.
Para sanar essas dúvidas e deixar o aplicativo mais fácil o possível de ser implementado, aprendi o básico de programação Front-End em React Native(linguagem utilizada pelo app atual) para poder projetar de forma a evitar maiores surpresas de layout.
Antes de ser contratado para fazer o aplicativo, eu já havia sido contratado para fazer a identidade visual, então já tinha pronto os elementos tipográficos, algumas ilustrações e as cores.
Segui uma linha parecida com o aplicativo já existente.
Etapa a ser executada, será utilizado o Useberry para dar tarefas e verificar os caminhos e Mapas de calor de cliques, assim como o tempo para executar tais tarefas, nos testes preliminares as pistas visuais em laranja cumpriram seu papel.
Os testes de usabilidade estão agendados, após essa etapa irei corrigir a interface e trabalhar na alta fidelidade.
A implementação não será feita agora.
Melhorias do case em desenvolvimento:
- Arrumar imagens em baixa resolução
- Mostrar mais fases do benchmarking
- Estruturar melhor o fluxo de usuários
- Hierarquia de informação das telas finais
(ainda sem o teste de usabilidade)
