Contexto
Trabalhei em features web e mobile do Trinio OS, uma plataforma de comércio e fulfillment omnichannel. O app mobile (React Native + Expo) é a ferramenta de trabalho de quem faz a separação: escaneiam o código de barras dos itens, confirmam quantidades, tratam itens sem estoque e movem os pedidos pelo ciclo de vida do fulfillment.
Problema
- O operador não pode perder trabalho. Se o app fecha, a conexão cai ou a pessoa é chamada no meio da separação, a sessão de picking precisa ser recuperável.
- A realidade produz exceções: item sem estoque, item errado escaneado, um pedido que a loja não consegue atender. Esses casos precisam de um caminho projetado, não de um aviso de erro.
- O mesmo produto atende tipos diferentes de tenant, então a funcionalidade precisa ter escopo: um tenant de checkout não deveria nem ver os menus de pick-and-pack.
- Operadores trabalham rápido em telas pequenas. Densidade de interface e latência do toque até o feedback são requisitos funcionais, não polimento.
Minha responsabilidade
Trabalho no nível de feature no dashboard web e no app mobile: fluxos de separação e conferência, leitura de código de barras, tratamento de exceções, retomada de operações interrompidas, comportamento offline com persistência local, notificações push, além de melhorias contínuas de UI, UX, performance e regras de negócio. Trabalhei sobre a arquitetura e os padrões já existentes da plataforma.
Trabalho representativo
- Retomar o que foi interrompido: reutilizar pedidos da sessão de separação anterior em vez de começar tudo de novo.
- Aceitar lotes de separação sem fulfillments no app, para o fluxo corresponder a como a operação realmente distribui o trabalho.
- Código de barras e códigos de referência: expor EAN/SKU no código de referência e mostrar o código de barras da separação, para a leitura e a busca manual concordarem.
- Tratamento de exceções: um modal de confirmação dedicado para itens sem estoque, com motivo, em vez de um beco sem saída.
- Notificação no app quando um novo pedido chega para separação: visibilidade sem sair da tela.
- Performance na lista de separação: reduzir o trabalho executado no caminho do toque que abre o card de separação.
- Consistência: padronizar cabeçalhos, mensagens de status, gavetas de pendências e blocos de resumo entre as telas internas, e recuperar espaço vertical no mobile.
- Escopo por tenant: esconder menus e fluxos de pick-and-pack dos tenants de checkout, e aplicar permissão de escrita onde era necessário.
- Regras de negócio: itens pendentes devem considerar apenas os pedidos da própria loja; corrigir os filtros de atrasado e urgente; mostrar as tags de urgência e atraso no app.
Como eu abordei
O padrão que usei de forma consistente: entender a operação primeiro (quem faz o quê, em qual dispositivo, sob qual restrição) e depois mapear isso nos padrões existentes da plataforma em vez de inventar um novo. Estado que precisa sobreviver a interrupção fica local e é tratado como autoritativo até o servidor confirmar, para o operador nunca perder um passo. Exceções são modeladas como estados explícitos na UI, não como falhas. Para tudo que é repetitivo e voltado ao usuário, eu meço o custo em toques e em latência percebida, não em elegância.
Decisões e trade-offs
- Local-first para trabalho em andamento. Trade-off: o app pode manter estado que o servidor ainda não aceitou, o que obriga a regras explícitas de reconciliação e torna bugs mais difíceis de reproduzir. Bloquear esperando a rede não era aceitável no chão de um galpão.
- Exceções como telas de primeira classe. Trade-off: mais superfície de UI e mais estados para manter, mas menos becos sem saída para o operador e menos improviso informal.
- Escopo por tenant na fronteira da UI. Trade-off: o front-end precisa conhecer os tipos de tenant; o benefício é que fluxos não suportados não podem ser alcançados por acidente.
- Padronizar componentes entre telas. Trade-off: mexer em várias telas ao mesmo tempo, em troca de um produto que deixa de parecer vários apps separados.
Resultado
Operacional em vez de numérico: o fluxo de conferência deixou de perder o trabalho do operador em interrupções, os casos de exceção ganharam um caminho definido, e o app ficou consistente o suficiente para ser ensinado.
O que aprendi
- No mobile, confiabilidade é uma feature: o que acontece na falha importa tanto quanto o caminho feliz.
- Em produtos multi-tenant, "quem pode ver isso" é uma decisão de design tomada cedo, não uma permissão remendada depois.
- Feedback operacional vence suposição: espaço de tela e um toque a mais são custos reais.