Case Study — GPB · Sistema financeiro
O GPB é o sistema financeiro de um grupo empresarial brasileiro e substitui um sistema antigo em MS Access. A equipe de finanças usa todo dia: pagar e receber, conciliação, fluxo de caixa, fechamento do mês e impostos. Fiz a rodada de UX direto no código. O app abaixo é o próprio GPB, em modo demonstração: clique à vontade.
É o app de verdade, com dados fictícios gerados no seu navegador: dá para lançar, dar baixa e conciliar. Nada sai daqui, e recarregar volta ao começo.
Os nomes, valores e contas são inventados.
Telas
01 — O problema
A primeira versão web refez o Access tela por tela: doze abas soltas numa faixa que rolava de lado, uma coluna presa em 672 px até num monitor grande e todo formulário subindo de baixo, também no computador. Nenhuma tela dizia o que precisava de atenção hoje.
Quem usa é gente de finanças, não de tecnologia, que lança e concilia o dia inteiro. Lançamentos abria em "tudo", com milhares de títulos herdados do Access (alguns em aberto desde 2015). A regra da rodada: usabilidade vale mais que firula, e cada mudança se mede em cliques e dúvidas para fazer a tarefa do dia.
Para abrir Lançamentos, baixando tudo de novo a cada troca de aba. Agora baixa uma vez e as outras telas usam na hora.
02 — Antes e depois
Mesmos dados fictícios nas duas versões. O que muda é a ordem: primeiro o que pede ação, depois o resto.
01 — No computador
O que melhora: A tela inteira trabalhando
O menu virou lateral e agrupado por tarefa: Visão geral, Dia a dia, Fechamento do mês e Configuração. Pagar e receber abre em "Para pagar agora", com o total, os vencidos e os próximos 7 dias antes da lista, e o aviso dos títulos antigos com um botão para revisar um por um.
Visibilidade do status
A pessoa vê o que está acontecendo antes de precisar perguntar.
02 — No celular
O que melhora: Pegada de app
As abas que rolavam de lado viraram um menu no ☰: a rotina do dia em cartões, o fechamento e a configuração em lista. Formulários e avisos abrem em folha de baixo ou em tela cheia, nunca num modal espremido.
É a área mínima de toque recomendada. No GPB, todo alvo no celular tem pelo menos isso.
03 — Decisões
Para cada tarefa, a ferramenta certa: assistente para o que tem começo, fim e várias decisões em ordem; checklist para o ciclo que passa por várias telas; triagem para a fila de itens parecidos; e formulário rápido para o que se faz de olho fechado.
Prevenção de erros
Melhor que uma boa mensagem de erro é um desenho que não deixa o erro acontecer.
04 — No celular
Uma rodada só de responsivo: modais viraram folhas de baixo ou telas cheias, o ☰ abre a rotina em cartões, e um kit de celular entrou para todas as telas (faixa de números, lista agrupada por dia, barra de ação fixa e o botão +). De 360 a 1440 px, nenhuma das 13 telas rola de lado.
Lei de Jakob
As pessoas esperam que o sistema funcione como os aplicativos que já usam no dia a dia.
A rotina
Folhas e assistentes
Entrega · Design engineering
Não teve Figma no meio. Li as 13 telas no código, escrevi a análise, e cada decisão foi direto para o React do produto, numa branch, em commits por assunto, com os testes passando.
Para revisar sem tocar em produção, o app ganhou um modo demonstração com dados fictícios em memória. É ele que roda no topo desta página.
13telas lidas no código e mapeadas
Cada tela foi ligada à função do Access que ela substitui, com quem usa, quantos cliques custa a tarefa do dia e os problemas por severidade. A rodada partiu dessa lista, e não de gosto.
5peças novas para o celular
KpiStrip, GroupedList, ParamSummary, BottomActionBar e Fab entraram no kit compartilhado, junto com a folha de baixo, o assistente, a triagem e a pilha de painéis. As telas usam as mesmas peças, e o comportamento é o mesmo em todas.
0 pxde rolagem lateral, de 360 a 1440 px
Um script com Playwright passa pelas 13 telas em várias larguras e mede rolagem lateral, letra abaixo de 12 px e alvo abaixo de 44 px. O que aparecia virava tarefa, até a lista zerar.
77commits por assunto, numa branch
Cada mudança tem um commit com o porquê, e as decisões que dependiam do cliente ficaram marcadas no código até serem resolvidas, uma por uma. O merge é uma decisão de quem revisa.
Resultado
Ferramentas
Posso mostrar as decisões e o que está por trás de cada tela.