Telas são uma forma de operar um processo. Se o processo ainda não está claro, uma interface bonita apenas organiza visualmente uma compreensão incompleta.
A pergunta anterior à interface
Antes de decidir onde ficará um botão, é preciso entender quem inicia a ação, quais dados são obrigatórios, o que precisa ser validado, quem pode aprovar, quais exceções existem e quem precisa ser informado depois. Essas respostas definem o comportamento do sistema.
Telas não carregam contexto sozinhas
Uma tela pode mostrar um formulário, mas não explica por que determinado campo existe, quem é responsável por ele ou o que acontece quando existe divergência. Esse contexto precisa estar modelado em regras, estados, permissões e eventos.
O risco de começar pelo protótipo
Quando a discussão começa apenas pela interface, é fácil transformar suposições em requisitos. O resultado pode funcionar tecnicamente e ainda exigir planilhas, mensagens e exceções fora do sistema porque o processo real nunca foi representado.
Uma sequência mais segura
Na Nexus, preferimos uma sequência simples: processo → responsabilidades → regras → dados → arquitetura → interface. Isso não elimina ajustes durante o desenvolvimento, mas cria uma base mais forte para decidir o que cada tela precisa permitir.
Onde a interface entra
Depois que o fluxo está claro, a interface ganha propósito. Ela reduz esforço, orienta decisões e apresenta somente o contexto necessário para aquele usuário naquele momento. O design deixa de ser o projeto inteiro e passa a ser uma camada da arquitetura.