Seis etapas, nenhum botão de salvar

O AMM CompraFácil é um portal de compras públicas: órgãos governamentais publicam licitações, fornecedores privados as disputam. Antes de qualquer lado poder agir, a organização precisa ser cadastrada, e pela lei brasileira de licitações esse cadastro é pesado. Classificação jurídica, endereço institucional, um representante legalmente responsável, documentos reconhecidos em cartório, declarações formais.

O domínio é genuinamente difícil. A lei de licitações tem sua própria taxonomia: esferas administrativas, poderes do Estado, administração direta versus indireta. Quem preenche isso são servidores municipais, não especialistas em direito administrativo. Um requisito declarado desde o início era que o sistema tinha que dar a mão ao usuário, porque o assunto nunca daria.

O volume de dados é definido por lei, não por nós. Cerca de 45 pontos de dado e 7 anexos de documento ao longo de todo o cadastro, com quase nada opcional de um jeito que o design pudesse remover.

E não havia salvar. Uma decisão de stakeholder tomada sob pressão de cronograma, quatro meses para colocar uma plataforma inteira de compras em produção, descartou o estado de rascunho. O cadastro tinha que ser concluído em uma única sessão.

O processo não era meu para desenhar. Sob o prazo, os gerentes de projeto conduziram a definição de requisitos com os especialistas de domínio enquanto o design trabalhava as telas em paralelo. Eu fui contra. Requisitos mediados por um terceiro, sem acesso direto do designer ao especialista, tinham cara de que produziriam lacunas. E produziram. Então construí um controle em volta disso.

Nenhuma lacuna preenchida por suposição. Antes de desenhar qualquer coisa, cada spec era lida contra o fluxo e toda ambiguidade, contradição e campo faltante voltava para ser resolvida com o especialista, em vez de interpretada e mandada para o desenvolvimento como um chute.

O protótipo virou o instrumento de auditoria. Construir o que a spec descrevia trouxe à tona três classes de erro que nenhuma revisão de documento teria pego: campos coletados no cadastro que sumiam da tela de visualização, informação exigida na consulta que nunca era capturada na origem, e o mesmo conceito com nomes diferentes entre documentos. Cada um teria chegado a um desenvolvedor como decisão de design e voltado como retrabalho.

Um ponto em que eu fui à fonte. Quando uma spec pedia Administração: Direta ou Indireta como um campo selecionado pelo usuário, eu conferi a lei por trás em vez de aceitar o campo como estava escrito. Essa checagem produziu a decisão central do fluxo.

Toda decisão abaixo remonta à mesma restrição. Em um fluxo que o usuário não pode pausar, a moeda do design não é polimento. É fricção removida por tela.

Derivar em vez de perguntar. Administração não é uma escolha independente, é uma consequência. Uma prefeitura é sempre administração direta, uma autarquia sempre indireta. Pedir os dois é redundante, e ainda permite combinações impossíveis enviadas de boa-fé. Então a pergunta foi removida. O usuário escolhe o tipo de organização, um substantivo concreto que ele conhece porque é o nome do lugar onde trabalha, e o sistema preenche a classificação jurídica, travada, marcada como automática.

Revelar em vez de despejar. A etapa 2 tem oito campos com dependências entre eles. Mostrados de uma vez, viram um paredão, e um paredão é onde alguém decide voltar depois, o que neste sistema significa nunca. Em vez disso, a etapa abre com uma pergunta: esfera administrativa. Cada resposta revela o próximo campo e poda suas opções. Municipal não oferece poder judiciário, porque municípios não têm um, e a interface diz isso em vez de omitir silenciosamente.

Preencher em vez de digitar. A etapa de endereço funciona por uma busca de CEP. Rua, bairro, cidade e estado chegam pré-preenchidos e travados, cada um destravável individualmente se estiver errado. O usuário digita o CEP e o número, as duas coisas que a busca não tem como saber. Quatro campos digitados removidos do meio do fluxo, onde o custo de abandonar já é alto.

Herdar em vez de escolher. A etapa de documentos pede a papelada institucional, mas quais documentos dependem do que a organização é, decidido três etapas antes. Em vez de apresentar uma checklist completa e pedir para o usuário julgar o que se aplica, a etapa chega já filtrada. Uma autarquia vê sua lei de criação e seu estatuto. Uma prefeitura vê a lei de criação marcada como não aplicável, com o motivo declarado. O usuário nunca precisa decidir se um documento jurídico se aplica a ele.

Tornar o fim visível. Na revisão, um envio incompleto não apenas deixa o botão cinza. Uma checklist diz exatamente o que falta e quantos itens restam. Raciocínio de goal-gradient aplicado no pior momento possível para perder alguém, o ponto onde ir embora custa mais caro.

Protótipos como meio de trabalho. Cada etapa saiu como um protótipo HTML funcional de arquivo único, com cascatas condicionais, buscas de CEP e campos derivados todos ao vivo. Não um mockup clicável: algo que um stakeholder podia preencher errado e ver o que acontecia. Protótipos que quebram são dado, e isso é mais barato de aprender no navegador do que numa sprint.

Depois o Figma, de propósito. Sem um design system versionado num repositório, porque design e desenvolvimento estavam construindo o sistema enquanto o projeto corria, as telas de produção foram reconstruídas e refinadas no Figma a partir desses protótipos. Esse segundo passe pegou inconsistências de componente que o markup gerado não tinha resolvido, e virou o ponto em que o sistema foi de fato imposto.

Entregue ao desenvolvimento e acompanhado até o fim. Construído pelo time de desenvolvimento contra as telas do Figma e a exportação de tokens, dentro da janela de quatro meses para a plataforma inteira.

Apresentado e aprovado pelo cliente logo no primeiro passe. Construído, passou pelo QA e em testes, dentro do prazo de quatro meses para a plataforma inteira.

O resultado transferível não é uma métrica de conversão; o produto ainda não foi lançado. É o que a restrição produziu.