Regra de negócio densa vira fluxo claro antes da tela
Regra de negócio densa só vira fluxo claro quando produto, design e engenharia a escrevem juntos, antes de qualquer tela.
Regra de negócio densa só vira fluxo claro quando produto, design e engenharia a escrevem juntos antes da primeira tela. Desenhar antes disso é adivinhar.
Cheguei a essa ideia em dois lugares. Num grande banco, entre 2023 e 2024, desenhei jornadas de crédito e empréstimo para o produtor rural.
Depois, em plataformas SaaS, com um time internacional, documentei regras de negócio e dei suporte ao time de desenvolvimento durante a entrega.
Nos dois casos, o trabalho difícil não estava na tela. Estava em entender a regra a ponto de explicá-la em poucas palavras.
Este texto conta como chego a esse entendimento e por que ele precisa vir antes do primeiro rascunho de tela.
Quem lê não precisa ser designer. Basta ter um produto em que o cliente se perde entre condições, exceções e prazos que só o time conhece.
Também não é um texto sobre ferramenta. É sobre a ordem do trabalho: primeiro a regra, depois a tela.
Onde a regra densa trava o fluxo
No banco, meu trabalho foi transformar regras de negócio densas em fluxos claros para quem produz no campo.
Regra densa é a que tem exceção, condição e dependência. Quem a conhece de cor costuma esquecer que o cliente não conhece.
Quando ela chega ao design pela metade, a tela herda a confusão. Surgem campos sem explicação, erros vagos e passos fora de ordem.
O produtor rural não tem obrigação de saber como o banco decide. Ele precisa saber o que fazer agora e o que vem depois.
Para a tela dizer isso, alguém tem de ter entendido a regra inteira antes. Esse alguém não pode ser só o designer.
Por isso trabalhei perto de produto e de engenharia, para garantir a viabilidade técnica e a consistência das decisões de design na entrega.
Viabilidade e consistência dependem da mesma coisa: todos lendo a mesma regra, do mesmo jeito, antes de alguém começar a desenhar ou a programar.
Documentar com produto e engenharia
Nas plataformas SaaS, documentar regras de negócio fazia parte do meu trabalho, junto com fluxos, wireframes e telas de alta fidelidade.
Em projetos para grandes instituições financeiras, também documentei regras e fluxos para alinhar produto, design e tecnologia.
Documentar, aqui, não é escrever um manual. É pôr cada regra em linguagem simples, com o caso comum e as exceções lado a lado.
Produto diz por que a regra existe. Engenharia diz o que o sistema já faz e o que custa mudar. Design diz como isso aparece para quem usa.
Quando os três leem o mesmo documento, a discussão sai da tela e vai para a regra. É ali que ela tem de acontecer.
No SaaS, eu também facilitava dinâmicas de cocriação e alinhamento entre as equipes de Produto, Design e Tecnologia.
Essas sessões rendem mais com a regra já escrita na mesa. Ninguém precisa lembrar de cabeça como o sistema decide.
Do documento ao fluxo claro
Com a regra escrita, o fluxo quase se desenha sozinho. Cada condição vira uma pergunta, e cada exceção vira um caminho com nome.
Os wireframes passam a testar a ordem dos passos, não a regra. A alta fidelidade cuida do texto, da hierarquia e do sistema de design.
Nas plataformas SaaS, criei fluxos, wireframes e interfaces de alta fidelidade em conformidade com o sistema de design.
Dei suporte à equipe de desenvolvimento durante a entrega, com a regra documentada ao lado.
A entrega também muda: com a regra escrita, a dúvida de quem implementa tem onde ser respondida, sem depender da memória de ninguém.
Depois do lançamento, analisei métricas e feedback para melhorias contínuas.
A regra escrita ajuda nessa leitura: fica mais fácil saber se o problema está na regra ou na tela.
Se o seu produto tem regra densa, comece pelo documento, não pela tela. Junte produto e engenharia e escreva cada regra até caber numa frase simples.