O Decision Log: por que os melhores designers documentam as decisões que ninguém perguntou

Um designer sênior e um designer pleno podem entregar a mesma tela. O sênior lembra por quê. O pleno lembra o quê.

Essa diferença é um artefato. Um registro curto, datado e estruturado de cada decisão de design com o raciocínio anexado. O decision log. A maioria dos designers não mantém um porque a faculdade nunca pediu e o último time não tinha. A prática não se propaga por acidente.

Os times que definem o padrão em 2026 já usam isso. A Linear tem design RFCs. A Vercel entrega product specs junto com as specs de engenharia. A Anthropic publica notas de pesquisa. A Stripe mantém design review docs. Brian Lovin guarda os dele em um site pessoal público. Jordan Singer lança pequenos produtos com diários de design públicos anexados. Mesmo artefato em todas as salas.

Este é o playbook. O que é um log, por que gestores de contratação o leem primeiro, de onde veio a prática, o template de seis campos, onde guardá-lo, exemplos reais, o modo de falha e como começar amanhã.

O artefato que a maioria dos designers não mantém

O artefato mais subestimado do design é o decision log. Não o case, não o arquivo do Figma, não o deck. Um registro curto, estruturado e datado de cada decisão de design com o raciocínio anexado, escrito antes de o trabalho ir ao ar.

O custo de pular isso aparece em silêncio. Seis meses depois, o designer não sabe dizer por que os campos do formulário ficam empilhados em vez de na mesma linha, quem decidiu ou o que foi cortado. Três anos depois, o portfólio tem seis projetos e zero decisões defensáveis. O designer é pleno para sempre.

O que um decision log realmente é

Um registro estruturado de escolhas de design, alternativas consideradas, restrições em jogo, raciocínio por trás da decisão, responsável e resultado. Seis campos, datado, concreto, ligado a artefatos. Essa é a definição inteira.

Não é um case. Cases apresentam cada escolha como inevitável. Um log mostra a escolha como ela foi feita, com as alternativas na mesa, as restrições que as eliminaram e o resultado que o designer agora assume.

Não é ata de reunião. Um log registra o que foi decidido e por quê, mesmo quando a decisão aconteceu numa mensagem de trinta segundos no Slack. O roadmap olha para frente. O log olha para trás, para cada decisão já tomada, datada, assinada, pronta para ser defendida.

Por que gestores de contratação o valorizam mais que mockups

Mockups polidos mostram resultado. Decision logs mostram julgamento. Gestores seniores de contratação em 2026 leem o log primeiro porque resultado é barato com IA e julgamento não.

Um modelo entrega uma landing page polida em oito minutos. O gestor que olha essa página não aprende nada sobre o designer que a entregou. Mesmo modelo, mesmo prompt, mesmas referências do Dribbble. O log é o único artefato que sobrevive à commoditização do polimento pela IA, porque o log não é o resultado, é o rastro de escolhas que produziu este resultado em vez dos outros dezoito.

A leitura leva dois minutos. O gestor abre o log, passa os olhos por cinco entradas e vê como o designer pensa. Alternativas específicas, restrições nomeadas, raciocínio concreto, resultados assumidos, a disposição de escrever "eu faria diferente hoje". Essa é a entrevista inteira, comprimida em um doc.

De onde veio a prática

O decision log é mais velho que o software. Christopher Alexander escreveu linguagens de padrões que se leem como decision logs em escala de edifício, cada padrão datado, nomeado, justificado, com alternativas anotadas. Arquitetos mantêm cadernos de projeto há séculos.

O software herdou isso pela cultura de RFC. A IETF publica documentos Request for Comments desde 1969. ADRs (architecture decision records) na Spotify, Pivotal e Thoughtworks são o mesmo artefato em escala menor. A herança mais recente vem dos laboratórios de pesquisa. A Anthropic publica notas de pesquisa que se leem como decision logs no nível do modelo.

Três linhagens, mesmo artefato. Designers são os retardatários, e o padrão está subindo rápido o bastante para que "tarde" comece a soar como júnior.

O template de seis campos, copie isto

Seis campos. Decisão, Alternativas, Restrições, Raciocínio, Responsável, Resultado. O template é curto de propósito. A disciplina está em escrevê-lo, não em desenhá-lo. Copie este bloco. Use amanhã.

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

Uma entrada por decisão real. De cinco a dez entradas por projeto. Dispense a capa. O bloco acima é o trabalho.

Como escrever cada campo sem rodeios

Cada campo tem uma regra. Pule a regra e o log vira teatro.

Decisão. Uma frase, no presente, concreta. "Empilhar e-mail e senha na vertical." Não "achamos que vertical poderia funcionar." Se a decisão ainda não foi tomada, não escreva a entrada ainda.

Alternativas. Lista numerada, de duas a quatro opções reais que estavam na mesa. Nada de espantalhos. Se só uma foi considerada, escreva essa e explique por que a busca parou.

Restrições. Lista com marcadores, nomeadas, com fonte. Capacidade da engenharia, regras de marca, tickets de suporte, piso de acessibilidade, orçamento de performance. Sem elas, o log parece lavagem de gosto.

Raciocínio. De três a cinco frases, sem "achamos". Use porque. Use comparado a. Cite a restrição ou o dado que decidiu. Linke o artefato.

Responsável. Nomeie o designer. Nomeie o revisor. Logs anônimos não sobrevivem ao contato com um revisor sênior.

Resultado. Preenchido de duas semanas a dois meses após o lançamento, datado. O que a métrica fez, o que foi revisitado, o que mudaria da próxima vez. A disposição de escrever "eu errei sobre o bloqueio do magic-link" é o sinal de maior confiança no log.

Onde guardar o log

O log mora onde o time realmente vai abri-lo. O lugar importa menos que a cadência.

Notion. A configuração mais fácil para o time todo. Um banco de dados, uma entrada por decisão, seis campos como colunas. A maioria dos times de produto já paga por ele e um designer monta tudo em uma hora.

Linear docs. A escolha certa se engenharia e design já vivem lá. As decisões ficam ao lado das issues que as originaram, e a passagem para RFCs de engenharia é um clique.

Um arquivo markdown no repositório. A escolha certa para design engineers e donos de design system. Um decisions.md na raiz do repo ou em /docs/decisions/ parece sério porque é versionado com o código. Engenheiros respeitam esse formato à primeira vista.

Um pequeno blog privado ou site pessoal. A escolha certa para um designer individual construindo um rastro público. Brian Lovin faz assim. Site estático, entradas datadas, links públicos. A peça funciona como vitrine de portfólio e presença de contratação.

Escolha um. Rode por um trimestre. O primeiro movimento que falha é escolher uma ferramenta e nunca mais abri-la.

Os design RFCs da Linear e as product specs da Vercel

A Linear trata design RFCs como artefatos de primeira classe nos seus docs. Toda decisão de design relevante sai com um RFC, escrito antes do trabalho, revisado pelos líderes de design e engenharia, arquivado junto com o projeto. O RFC faz parte do trabalho, não é um relatório depois.

A Vercel entrega product specs junto com as specs de engenharia no mesmo repositório. A decisão de design e a de engenharia ficam no mesmo doc, datadas, com responsável, revisadas. O time trata a spec como o contrato. Quando o v0 lança uma nova superfície, a spec faz parte do artefato de lançamento.

Ambos os times tratam a justificativa escrita como parte do ofício. Não um relatório de quarta à tarde. Não opcional. O artefato é o trabalho, do mesmo jeito que o arquivo do Figma é o trabalho, e um designer que aparece sem um parece inacabado.

As notas de pesquisa da Anthropic e os design review docs da Stripe

A Anthropic publica notas de pesquisa que se leem como decision logs no nível do modelo. O que tentaram, o que funcionou, o que não funcionou, qual é o próximo passo. Curtas, datadas, com responsável, linkadas. Leia três e a prática fica óbvia. As notas são o registro, não a propaganda.

A Stripe mantém design review docs que sobrevivem a ciclos de produto. A Stripe Press é a superfície pública, a prática interna é mais antiga. As revisões são escritas, arquivadas e revisitadas quando o próximo ciclo encontra uma decisão parecida. Memória institucional que se acumula ao longo dos anos em vez de ir embora quando um designer sênior sai.

Se você quer ajuda para construir isso no ofício do seu time, contrate a Brainy. A BrandBrainy entrega a camada de ofício que a IA não consegue fingir. A ClaudeBrainy entrega os Skill packs e as bibliotecas de prompts que transformam o log de disciplina em padrão.

Brian Lovin e Jordan Singer mantêm os deles em público

Brian Lovin mantém um site pessoal de longa data que funciona como um decision log público do próprio trabalho. Páginas curtas, escrita direta, escolhas de design explicadas em três ou quatro frases cada, datadas, linkadas ao produto no ar. Anos de entradas. O site serve como portfólio e presença de contratação, o uso duplo em que o playbook do anti-portfólio se apoia.

Jordan Singer lança pequenos produtos com diários de design públicos anexados. Cada projeto tem um registro escrito das decisões por trás dele, publicado abertamente, com a disposição de dizer em voz alta "isso não funcionou". O diário é marketing, registro e artefato de contratação ao mesmo tempo.

Ambos são templates que qualquer designer em atividade pode copiar esta semana. Site estático, entradas de seis campos, datadas, públicas, linkadas. Quinze minutos por entrada. Três por mês. Um ano depois, o log público soa sênior de um jeito que nenhum case do Behance jamais soa.

A parte de cautela: racionalização post-hoc

Um decision log escrito depois que o trabalho foi ao ar e o resultado já é conhecido não é um log, é um discurso de vendas. Gestores seniores de contratação percebem a diferença em dois minutos.

O sinal está no campo de alternativas. Um log vivo lista alternativas que realmente estavam na mesa, muitas vezes com uma delas soando forte. Um log post-hoc lista três opções que o autor nunca considerou a sério, feitas para que a opção escolhida pareça óbvia. O gestor já fez esse mesmo exercício cem vezes. Sabe como é o verniz.

O outro sinal está no campo de resultado. Logs vivos incluem resultados que não bateram com a previsão. "Esperava aumento de conversão, o teste ficou estável, veja o que deu errado." Logs de teatro só incluem vitórias, arredondadas para parecerem melhores do que foram.

A correção é desconfortável. Escreva a entrada antes de o trabalho ir ao ar. Date. Submeta a um revisor que vai questionar. Preencha o resultado duas semanas depois, mesmo quando a notícia é ruim. Principalmente quando a notícia é ruim. A entrada honesta se acumula.

Como usar o log em entrevistas e revisões

Um log se paga duas vezes. Uma quando o trabalho vai ao ar, outra quando o designer conduz um gestor de contratação ou um revisor sênior pela decisão.

Numa entrevista, o log substitui a apresentação do case. Abra o doc. Escolha três entradas. Para cada uma, leia a decisão, nomeie a alternativa mais forte, nomeie a restrição determinante, explique o raciocínio em duas frases, compartilhe o resultado incluindo o que mudaria da próxima vez. Cinco minutos por entrada, quinze no total. O gestor aprende mais sobre julgamento do que um deck de case de quarenta e cinco minutos mostraria.

Numa revisão sênior, o log é a conversa. O revisor lê a entrada, questiona o raciocínio, pergunta por que a alternativa mais forte foi cortada. A discussão afia a próxima decisão antes de ela ser tomada. É isso que uma boa design review é. Não feedback sobre pixels renderizados, e sim debate sobre a decisão por trás deles.

Um designer que consegue defender o log defende o trabalho. Um designer sem log não defende nada.

O novo padrão: trabalho sênior sem log parece júnior

O decision log não é mais um extra desejável para seniores. É o sinal mais barato de julgamento sênior que um designer pode entregar, e o custo de pulá-lo está subindo.

Um portfólio sênior com log público parece sênior. Um sem log parece trabalho que talvez fosse sênior, difícil dizer. Gestores leem os dois. O primeiro recebe o retorno. Um júnior com log em três projetos pequenos parece à frente do próprio nível. Um júnior com doze shots perfeitos no Dribbble e sem log parece o mesmo júnior de um ano atrás.

Gosto é o último fosso em 2026 porque a produção virou commodity, e o log é o artefato público que prova que o gosto existe no trabalho. Se você entrega como híbrido de design engineering, o log funciona também como RFC de engenharia na camada de design. Se você está subindo a nova escada de carreira em design, o log é o artefato em que a escada se apoia.

FAQ

O que é um design decision log?

Um registro curto e estruturado de escolhas de design com o raciocínio anexado. Seis campos por entrada: Decisão, Alternativas, Restrições, Raciocínio, Responsável, Resultado. Datado, concreto, ligado a artefatos.

Em que ele difere de um case?

Um case apresenta cada escolha como inevitável. Um log mostra as escolhas como foram realmente feitas, com as alternativas na mesa, as restrições que condicionaram a decisão e o resultado assumido. Cases vendem. Logs documentam.

Onde devo guardá-lo?

Onde o seu time realmente vai abri-lo. Notion para times de produto, Linear docs para times que já estão lá, um arquivo markdown no repo para design engineers, um pequeno site privado para um rastro público individual.

Qual deve ser o tamanho de cada entrada?

Curto. O template inteiro cabe numa tela. Quinze minutos por entrada.

E se minha empresa não adotar isso?

Faça por conta própria. O log individual de um designer se acumula entre empregos. Brian Lovin e Jordan Singer mantêm os deles publicamente. A prática é sua, não do seu empregador, e o artefato vai com você.

Comece o log esta semana

Três movimentos. Monte o armazenamento. Escolha Notion, Linear, o repo ou um pequeno site. Monte em trinta minutos. Escolha o que você vai abrir amanhã.

Escreva três entradas sobre decisões já tomadas. Decisões reais deste trimestre. Seis campos cada. Alternativas honestas, restrições reais, sem rodeios, resultados datados e sem verniz. As três primeiras são as mais difíceis, as outras ficam mais rápidas.

Mostre o log a um revisor sênior. Peça que ele questione o raciocínio. Encare a crítica como sinal. Atualize as entradas. A primeira revisão é onde o log começa a se acumular.

Se você quer ajuda para construir a prática do decision log no ofício do seu time, contrate a Brainy. A BrandBrainy entrega a camada de marca e ofício que a IA não consegue fingir. A ClaudeBrainy entrega os Skill packs e as bibliotecas de prompts que transformam o log de disciplina em padrão. Os times que já usam isso estão se afastando. O padrão está subindo, e o designer que começa esta semana é o que os times citados vão estar lendo daqui a um trimestre.