A frase "design não é só visual" costuma ter aprovação unânime em reunião. O apoio acaba quando o negócio trava e é preciso decidir quem senta na mesa. Aí o design vira o time que deixa bonito depois, com a decisão já tomada em outro lugar.
O visual é o resíduo
O que aparece na tela é a parte visível de uma cadeia de decisões que fica escondida: qual problema vale resolver, qual comportamento justifica a prioridade, qual trade-off o time aceita. Cor, tipografia e espaçamento são a camada que sobra depois que essas perguntas foram respondidas, ou ficaram sem resposta.
Quando o brief pula direto pra "faz uma tela moderna", o visual sai sem nenhuma decisão amarrada nele. Parece design. É achismo com acabamento.
Um sistema com tese aguenta a pergunta "por que essa forma e não outra" com uma resposta que chega até o negócio. Sem tese, a resposta é "porque ficou bonito".
Uma discussão de 1919
A discussão é mais velha que o produto digital. Walter Gropius fundou a Bauhaus em 1919 juntando marcenaria, tipografia e arquitetura no mesmo prédio. A aposta era que forma e função saem da mesma decisão, e não de duas etapas, uma que resolve e outra que decora.
"A forma segue a função" nem é da Bauhaus. É de Louis Sullivan, arquiteto americano, em 1896. A escola alemã transformou a ideia em método de ensino e de produção em série, décadas antes de existir tela.
A mesma pergunta virou disciplina mais duas vezes. A ergonomia cognitiva, no pós-guerra, tratava de reduzir erro humano em painel de avião e de usina. A IHC (interação humano-computador), nos anos 1980, levou a pergunta pro computador: entender o modelo mental de quem usa antes de desenhar a interface. As duas nasceram de decisão sob risco.
A IBM de 1956
Antes de existir "tech" como setor, a IBM já tratava design como decisão de negócio. Em 1956, contratou Eliot Noyes pra montar um programa de design da empresa inteira (produto, arquitetura de loja, identidade visual) sob a mesma tese, com Paul Rand cuidando da marca.
A decisão foi de Thomas Watson Jr., CEO da IBM. A leitura dele era que a imagem de competência da empresa dependia de cada ponto de contato dizer a mesma coisa. Em 1973, ele resumiu isso numa frase que virou princípio: "good design is good business".
Tudo isso numa empresa de máquina de escrever e mainframe, sem internet nem app. O problema era manter decisão coerente em escala global, e o visual era onde essa coerência aparecia.
Onde o design acontece
O trabalho pesado sempre aconteceu antes de qualquer ferramenta abrir: separar o comportamento de usuário que é sinal do que é ruído, escolher a métrica que a solução precisa mexer, entender qual objeção de stakeholder é territorial e qual é técnica.
Isso é arquitetura de decisão. Tela, máquina de escrever e prédio são o registro dessa decisão, pra outra pessoa usar sem reabrir a discussão.
Com a decisão nomeada, fica mais fácil saber quem deveria tomá-la: em geral quem estudou o problema, e não o cargo mais alto da sala. O time rende mais quando cada um decide sobre o que domina.
Quando o design entra só no fim, o aprendizado sai caro. Pede a tela, não gosta, pede outra versão, continua sem gostar, até alguém perceber que a pergunta certa nunca foi feita.
O teste da tela que some
Pega qualquer entrega de design e pergunta: se essa tela sumisse amanhã, que decisão de negócio ficaria sem dono? Se a resposta for nenhuma, aquilo era decoração com processo de aprovação em volta. Se apontar pra uma aposta específica, era design, mesmo escondido atrás do pixel.
A decisão ainda precisa se provar depois do lançamento, no dado e no comportamento de quem usa, olhando pra métrica que ela tentava mexer: conversão, retenção, tempo até o primeiro valor. E produto que funciona segue sendo ajustado, uma decisão de cada vez, conforme o uso mostra o que a hipótese não previu.
Quem passa a ver design assim troca a briga sobre gosto pela briga sobre critério. Cansa mais numa sexta à tarde, e foi esse tipo de briga que manteve o programa da IBM de pé por décadas depois de Noyes.
Pra você, founder: toda tela aprovada carrega uma decisão de negócio, mesmo quando ela nunca é dita em voz alta. Nomear essa decisão antes de pedir o visual costuma poupar rodadas de ajuste.
Pra você, designer: uma pergunta simples ajuda a abrir essa conversa: qual decisão de negócio essa tela representa? Vale fazer cedo, e não só quando o pedido chega sem contexto.
Pra você, PM: um brief que já chega como tela pronta deixou pra trás uma decisão que o time poderia ter tomado junto. Trazer essa decisão no brief costuma evitar retrabalho lá na frente.
Pra você, tech: a mesma lógica vale pro código. Arquitetura decidida sem contexto de negócio também é achismo, só que compilado em produção. Entender o porquê antes de implementar poupa retrabalho do mesmo jeito.
