Reconstruir um sistema de vale-transporte em operação, instável e sem documentação, que precisa funcionar sem internet e ainda assim impedir fraudes.
Fraktal SoftwaresSob NDA · Discovery
Vale-transporte corporativo
Reconstruir um produto que já funciona, sem repetir os erros
Como mapeei uma operação em funcionamento há 4 anos e estruturei a V2 em cinco ambientes, com regras que protegem a empresa sem constranger o passageiro.
- Empresa
- Fraktal Softwares
- Produto
- Plataforma B2B de vale-transporte em vans (cliente sob NDA)
- Plataforma
- Dois apps, terminal POS e dois painéis web
- Minha participação
- Do kickoff ao escopo: mapeamento As Is, discovery, arquitetura em módulos e releases
- Time
- Conduzi as decisões de produto, validando cada etapa com o cliente do briefing à definição do escopo, dos módulos e das releases
Fiz o mapeamento As Is dos sistemas atuais, conduzi o discovery e estruturei a V2 em cinco ambientes e quatro releases, prontos para a prototipação.
Regras aplicadas na hora do embarque, uma trilha de auditoria confiável e o fim das recusas indevidas por falha do sistema.
Um negócio provado, preso a um sistema que não aguenta crescer
O cliente opera há 4 anos uma plataforma B2B de vale-transporte em vans: empresas contratam o benefício, colaboradores embarcam com cartão ou bilhete digital e motoristas licenciados validam a passagem e recebem no dia seguinte. O negócio funciona e está em expansão, mas o sistema virou um passivo: sem documentação, dependente de uma única pessoa, e cada correção quebrava outra parte. O contrato era de arquitetura e design da V2, para que qualquer fornecedor pudesse desenvolver depois.
Mensagens erradas no embarque
O app às vezes dizia “sem saldo” para quem tinha saldo. O motorista recusava o embarque, o colaborador passava constrangimento e o RH recebia a falha do sistema como se fosse uma infração.
Operação sem sinal
Em muitas rotas não há cobertura de celular. A leitura precisa funcionar offline, e é justamente aí que ficam as brechas para fraude.
Leituras que somem
Sem uma trilha confiável, saldo, assiduidade e pagamento do motorista ficavam sem comprovação, e a equipe reconstruía tudo com planilhas e WhatsApp.
Objetivos do projeto
- Aplicar as regras de uso no momento da leitura, online ou offline
- Ter uma trilha única e auditável de cada tentativa de embarque
- Nunca tratar uma falha técnica como irregularidade do passageiro
- Padronizar a leitura com terminais POS, com o celular como contingência
Mapear o que existe antes de propor o que vem
Participei deste projeto do kickoff até a definição de escopo, módulos e releases, e saí da Fraktal antes da prototipação. Por ser um projeto sob NDA, nomes, região e dados foram omitidos.
Mapeamento As Is
Como o produto já estava em operação, comecei pelo que existe. Usei um acesso de teste ao painel, pedi aos responsáveis que gravassem a tela operando os dois apps e fiz uma reunião técnica com o responsável pelo sistema. Com isso, inventariei 62 telas no app do motorista e 39 no app do colaborador, documentei regras, cadastros e relatórios e cruzei o que o cliente declarou com o que eu observei.
O que isso me mostrouAs regras de uso existiam no cadastro, mas o painel tinha relatórios dedicados a encontrar justamente as violações que elas deveriam impedir. Ou seja: a regra era detectiva, não preventiva. Também encontrei o débito do saldo antes do embarque, leituras que levavam semanas para chegar ao servidor e relatórios que filtravam pela data de envio, e não pela data da viagem. Levei 16 pontos em aberto ao cliente antes de definir qualquer arquitetura.
Formulário de discovery
O cliente respondeu ao formulário que eu criei, com perguntas sobre visão, dores, pessoas, o que manter e o que mudar.
O que isso me mostrouA resposta mais importante não foi uma funcionalidade, e sim uma regra de comunicação: o sistema precisa distinguir passagem autorizada, bloqueio confirmado por regra e falha técnica, para que um erro do sistema nunca vire acusação contra o passageiro.
Quatro personas, a mesma viagem
A colaboradora
34 anos, trabalha em turnos e embarca com cartão ou QR Code.
Precisa ter certeza de que o embarque foi registrado e nunca ser barrada por um erro que não é dela.
O motorista
47 anos, celular antigo, rotas em áreas sem sinal.
Precisa embarcar sem fila, continuar operando se o terminal apagar e receber certo no dia seguinte.
A gestora da empresa
39 anos, cuida do benefício no RH.
Precisa pagar só o que foi usado e saber quem usou, quando e em qual van.
O administrador da operação
42 anos, acompanha viagens, terminais e repasses.
Precisa detectar fraude antes do prejuízo e investigar uma leitura sem reconstruir tudo à mão.
Três princípios para a V2
Cada princípio responde a algo que o mapeamento As Is revelou.
Regra preventiva, não detectiva
As regras de uso (duas passagens por dia, intervalo de 60 minutos, cadastro ativo, saldo) passam a ser aplicadas no momento da leitura, mesmo offline, com uma base autorizada carregada antes da rota.
Nasce deA contradição encontrada no As Is.
Uma trilha que não some
Cada tentativa de leitura recebe um identificador único e fica registrada mesmo antes de sincronizar, com quem, onde, quando, qual regra foi aplicada e qual mensagem foi exibida.
Nasce deAs leituras que desapareciam e as investigações manuais.
Nunca culpar o passageiro
Quando o sistema não tem segurança para afirmar, a mensagem diz que é uma falha técnica e orienta a contingência, em vez de recusar o embarque.
Nasce deAs recusas indevidas relatadas no formulário.
As decisões, uma a uma
Para cada uma: o problema, o que eu fiz e por que fiz assim.
Arquitetura
Cinco ambientes, com o terminal no centro
Problema
Hoje a leitura depende do celular pessoal de cada motorista, com marcas, versões e baterias diferentes. Isso torna impossível garantir que todos os veículos aplicam a mesma regra.
Decisão
Estruturei a V2 em cinco ambientes: app do colaborador, app do motorista, terminal POS, painel da empresa contratante e painel da operação. O terminal passa a ser o leitor principal, e o app do motorista vira contingência. Cada ambiente foi detalhado em módulos com userflow, e o escopo foi dividido em quatro releases.
Por quê
A Release 1 entrega o caminho da leitura de ponta a ponta em todos os ambientes, e as seguintes acrescentam operação, contingência e financeiro, sem que uma release dependa de algo que ainda não existe.
Terminal POS
Três respostas no momento do embarque
Problema
O motorista toma uma decisão em segundos com base no que a tela mostra. Quando a tela erra, ele recusa um passageiro regular.
Decisão
Especifiquei o resultado da validação com três estados visualmente distintos, legíveis a um metro e com som diferente: passagem autorizada, bloqueio confirmado por regra (sempre com o motivo e o próximo horário liberado) e falha técnica, que orienta a contingência sem atribuir responsabilidade ao colaborador. O terminal mostra ainda uma barra permanente com bateria, conexão, versão e leituras pendentes.
Por quê
O motorista só recusa quando a regra foi confirmada com dado atualizado, e o colaborador nunca é exposto por uma falha do sistema.
Contingência
Quando o terminal falha, a operação não para
Problema
Se a bateria do terminal acaba no meio da rota, o motorista precisa continuar operando, mas dois aparelhos lendo o mesmo veículo geram cobrança duplicada.
Decisão
Desenhei um handoff controlado: o motorista marca o terminal como indisponível, informa o motivo, vincula temporariamente o celular ao veículo e opera com as mesmas regras e a mesma base. Ao final, as leituras dos dois aparelhos são conciliadas e a contingência é encerrada formalmente. O painel alerta quando um veículo fica muito tempo em contingência.
Por quê
Continuidade para o motorista, sem leitura duplicada para a empresa, e um sinal para a operação de bateria ou terminal com defeito.
Painéis
Investigar uma leitura em vez de reconstruí-la
Problema
Quando um embarque era contestado, a equipe cruzava apps, painéis, planilhas e relatos para descobrir o que aconteceu, e muitas vezes não chegava a uma conclusão.
Decisão
No painel da operação, previ um módulo de investigação: a busca por identificador, cartão, pessoa ou veículo devolve a linha do tempo daquela tentativa (horário real da leitura, horário da sincronização, regra aplicada e mensagem exibida). Os relatórios passam a ser refeitos sobre essa mesma trilha.
Por quê
A empresa, a operação e o suporte consultam a mesma fonte, e a causa de uma recusa aparece em minutos.
Painéis
Permissões desenhadas do zero
Problema
No sistema atual, o cadastro de usuário não tem nenhum campo de papel ou permissão. A diferença entre o que a equipe interna e o que a empresa cliente enxergam está escondida no código.
Decisão
Separei o painel da empresa contratante do painel da operação, cada um com perfis de acesso explícitos e verificação no servidor. No painel da empresa, o departamento define as regras e o colaborador mostra o valor herdado, com a exceção marcada.
Por quê
Cada pessoa vê só o que deve ver, e as regras ficam num lugar só, com precedência visível.
Como validar e acompanhar
Saí do projeto antes da prototipação, então não acompanhei a implementação. Estes são os indicadores que eu usaria, ligados à definição de sucesso do cliente:
Recusas por falha técnica
O que medirO número de embarques recusados que depois se mostraram regulares.
ObjetivoValidar que o resultado em três estados acabou com as recusas indevidas.
Tempo até a sincronização
O que medirO intervalo entre a leitura e a chegada do dado ao servidor.
ObjetivoConfirmar que a fila offline não deixa leituras perdidas por semanas.
Investigações manuais
O que medirQuantas ocorrências precisam ser reconstruídas fora do sistema.
ObjetivoMedir se a trilha única substitui planilhas e relatos.
Uso de contingência
O que medirO tempo e a frequência de veículos operando pelo celular.
ObjetivoIdentificar terminais com defeito antes que virem problema na rota.
O que este projeto me ensinou
- Num produto que já funciona, o primeiro trabalho do designer é entender o que não pode quebrar. Redesenhar começa por mapear.
- Cruzar o que o cliente declara com o que o sistema mostra revela problemas que nenhuma entrevista revelaria sozinha.
- Em ambientes instáveis, a mensagem certa é tão importante quanto a regra certa: ela decide se o passageiro embarca ou passa constrangimento.
- Mapeamento As Is
- Discovery
- Arquitetura de informação
- Offline-first
- Produto B2B
- UX writing