Fernanda MartinsCase 04 · Mobyan · Stefanini
MobyApp
O aplicativo Android que conecta a Mobyan aos técnicos em campo. Quando falhava, virava retrabalho, custo operacional e técnico pagando do próprio bolso para conseguir trabalhar.
- Meu papel
- Product Design: pesquisa, arquitetura e interface
- Plataforma
- Android, uso em campo
- Pesquisa
- 4 entrevistas presenciais e 50+ respostas
- Status
- Protótipo aguarda implementação
Quando o técnico paga do próprio bolso, a operação quebrou.
O MobyApp centraliza as ordens de serviço dos técnicos que atendem em campo. Na prática, não cumpria esse papel. Travamentos frequentes, informação escondida e dado inconsistente atrapalhavam a produtividade. Técnicos relatavam perda de tempo, retrabalho e até pagar por aplicativos externos para suprir as falhas.
Uma nota de 2,4 na Play Store e reclamações que apontavam problemas críticos.
Os reviews já contavam o que estava quebrado.
Comecei pelas avaliações públicas. Elas falavam de evidências que sumiam, rotas que reiniciavam e informação que o app antigo guardava e o novo perdia.
As evidências somem quando você precisa retornar à página, tem que refazer todo o processo.
Não adianta organizar rotas pois reinicia o tempo todo. Trava muito, não salva informações.
O app existia para centralizar o trabalho, e os técnicos estavam trabalhando fora dele.
Fui ouvir quem estava na rua.
Fiz quatro entrevistas presenciais com técnicos e supervisores, uma pesquisa quantitativa com mais de 50 respostas e uma análise heurística completa do fluxo. Com isso, mapeamos quantos técnicos cada problema atingia.
O técnico não sabia se a ordem estava mesmo no estado que o app mostrava.
CNPJ, endereço e histórico exigiam cliques demais para aparecer.
Pouca visibilidade do material disponível.
O app não aguentava a rede móvel de campo.
Não era bug. Era estrutura errada. O padrão se repetia entre os técnicos, não era caso isolado.
Um MVP que ataca cada padrão de falha.
Nada de feature por feature. O MVP foi desenhado para responder aos gargalos que a pesquisa mapeou. Construí o protótipo no Figma Make, com o comportamento do sistema simulado sem precisar de backend: em vez de discutir em palavras, a gente mostrava o produto funcionando.
O que entrou no MVP
- 1Dados essenciais visíveis
- 2Cópia rápida de laudos
- 3Roteirizador com mapa
- 4Histórico por data e status
- 5Resumo diário de OS e valores
Com o Figma Make e IA, o protótipo simulava o sistema de verdade. Validamos antes de alguém escrever código.
O que era externo virou parte do produto.
Cada decisão responde a um motivo concreto para o técnico sair do app.
CNPJ, endereço e número de série ficavam escondidos. O técnico copiava para outro lugar para conseguir usar.
Os três aparecem direto na ordem, e o laudo pode ser copiado de uma vez.
A organização de rotas se perdia, e o técnico recorria a outro aplicativo.
O deslocamento entre ordens é planejado no próprio app.
O técnico não confiava no status mostrado e refazia o que já tinha feito.
Histórico visual por data e status, e um resumo do dia com ordens e valores.
Se o técnico precisa de outro app para trabalhar, o que falta é estrutura, não mais uma tela.
O protótipo foi apresentado e aguarda implementação.
O time de produto planeja aplicar o design system oficial da Mobyan sobre essa nova estrutura, com as próximas iterações guiadas pela realidade de campo. Ainda não há resultado medido em produção. confirmar se já foi aprovado
A estrutura nova é a base para o design system da Mobyan, desenhada a partir de quem usa o app na rua.