O Case Study de Design Tradicional Está Morrendo

O case study de design inflado está morrendo. O case study em si, não.

Essa distinção é o argumento inteiro, então guarde-a bem. O deck de 47 telas com seis semanas de documentação de processo está perdendo espaço para um Loom de três minutos de um produto funcional que alguém construiu em uma sessão. Quando um gerente de contratação consegue clicar em uma URL ao vivo em dez segundos, seu walkthrough do double-diamond começa a parecer um dever de casa que você está passando para ele.

Isso não é um aviso de morte para o pensamento. É um aviso de que a prova se moveu. O artefato está se tornando o argumento, e o slide deck explicando o artefato está se tornando opcional.

O thread que dividiu o Twitter de design

A briga foi a público quando o designer @andrewk postou um thread questionando se o case study tradicional já é obsoleto. Caiu pesado: cerca de 9,8 mil reposts e mais de 400 respostas, com designers divididos ao meio.

Essa divisão é o sinal. Metade da sala argumentou que o case study é um ofício sagrado. A outra metade apontou para seus próprios demos ao vivo e perguntou por que alguém precisaria do deck quando o produto está bem ali.

Nenhum dos lados está errado, e é exatamente por isso que se espalhou. O desacordo não é sobre se designers deveriam pensar. É sobre onde a evidência desse pensamento deve viver agora que entregar é quase gratuito.

O que realmente mudou (uma sessão, auth real, pagamentos reais, entregue no mesmo dia)

Veja ao vivo em cursor.com

O que mudou é que o custo de um artefato funcional desmoronou. Designers e fundadores independentes agora estão postando apps completos e funcionais, com auth, pagamentos e fluxos de dados reais, gerados em uma única sessão estendida e entregues no mesmo dia.

As ferramentas tornaram isso crível rapidamente. Uma build longa no Claude Code ou Cursor agora consegue manter um plano coerente ao longo de toda uma sessão em vez de desmoronar depois do terceiro arquivo. A confiabilidade de longo horizonte do Fable 5 e as recentes vitórias no CursorBench são a razão pela qual "em uma tomada" parou de soar como truque de demo e começou a soar como uma terça-feira qualquer.

Então a matemática virou. O case study antigo existia em parte porque construir a coisa real era caro, lento e dependia de engenharia. Você documentava o processo porque o processo era a maior parte do trabalho que você conseguia mostrar de verdade.

Agora a coisa real é barata de produzir. Quando você consegue entregar uma URL ao vivo até o fim do dia, uma reconstrução estática de como você teria construído isso parece uma versão pior de uma evidência que você já tem.

Entregável antigo vs. artefato funcional (a tabela honesta)

Aqui está a comparação que torna isso concreto. Isso não é hype, é uma diferença no que cada formato realmente faz pela pessoa que está avaliando você.

Leia a linha "o que pode esconder" duas vezes. O case study estático pode esconder que o design nunca sobreviveu ao contato com dados reais, estados reais ou um backend real. O artefato funcional não consegue esconder isso, porque o avaliador está dentro dele.

É por isso que o artefato vence em confiança. É mais difícil falsificar uma coisa que roda do que uma coisa que é renderizada.

O case study não está morto, o inflado está

Agora o contraponto honesto, porque a versão obituário desse argumento é preguiçosa.

Um demo ao vivo prova que a superfície funciona. Não prova, por si só, que você entendeu o problema, pesou os trade-offs ou escolheu essa forma em vez de três piores. Um app lindo que resolve o problema errado ainda é o problema errado, entregue mais rápido.

Essa é a armadilha em "o case study está morto." As pessoas ouvem isso e deletam o pensamento junto com o inchaço das telas. Eles não são a mesma coisa. O inchaço são os 12 slides de citações de personas e o moodboard que ninguém pediu. O pensamento são as duas decisões que realmente moldaram o produto.

Então o movimento não é "pare de explicar seu trabalho." O movimento é "pare de encher linguiça." Mantenha o julgamento, corte o teatro. Um artefato funcional sem nenhuma história por trás pode parecer "eu só dei uns prompts e pronto," e para cargos sênior isso é um risco real.

O que seu portfólio precisa provar agora (gosto, julgamento, enquadramento do problema)

Uma vez que entregar é quase gratuito, o bem escasso não é o output. São as três coisas que um app de uma tomada não consegue provar sozinho.

Gosto. Quando qualquer um consegue gerar uma interface passável, a distância entre passável e certo é o trabalho inteiro. Gosto são as mil pequenas decisões que um modelo não vai tomar por você: o que cortar, o que desacelerar, onde adicionar fricção de propósito.

Julgamento. Mostre a bifurcação. Mostre a versão que você matou e o motivo em uma frase. Um único "tentamos X, quebrou a confiança no checkout, então fizemos Y" prova mais do que uma narrativa de 40 slides de um caminho sem bifurcações.

Enquadramento do problema. O demo responde "você construiu?" O enquadramento responde "isso deveria existir, e nessa forma?" Essa pergunta é onde designers sênior ganham o título, e é a parte que um modelo é mais fraco em entregar.

Perceba que nenhum desses precisa de 50 telas. Precisam de uma coisa ao vivo e de algumas frases honestas sobre as decisões que você tomou ao construir.

Como reconstruir seu portfólio este mês (comece com a coisa ao vivo, mantenha um log de decisões curto)

Veja ao vivo em cursor.com

Você consegue reconstruir isso em um mês sem destruir o que tem. A forma é simples: comece com o artefato, sustente com julgamento, corte o resto.

1. Comece com a coisa ao vivo. A primeira tela de cada projeto é uma URL clicável ou um walkthrough de 60 a 90 segundos do produto funcionando. Não um hero shot, o produto real. O avaliador deve tocar algo real antes de ler uma palavra.

2. Mantenha um log de decisões curto. Três a cinco decisões por projeto, cada uma em uma linha. A decisão, a alternativa que você rejeitou, o motivo. Essa é a evidência de julgamento que um demo sozinho não consegue carregar.

3. Mostre uma bifurcação por projeto. A versão que não foi entregue e por quê. Essa é a forma mais rápida de provar que você estava pensando, não apenas gerando.

4. Corte o teatro de processo. Delete os slides de persona, os mapas de empatia que você nunca usou, o moodboard, as telas de "ideação". Se não mudou o produto, não merece espaço.

5. Coloque a data de entrega nele. "Da ideia ao ar em uma sessão" ou "entregue em um fim de semana" é agora uma credencial. Sinaliza que você consegue se mover na velocidade que o trabalho realmente se move em 2026.

Essa é a migração inteira. Comece com o artefato, prove o julgamento em cinco linhas, jogue fora o enchimento que sempre foi enchimento.

FAQ

O case study de design está completamente morto?

Não. O case study inflado e cheio de processo está morrendo como padrão. O que ele provava, que você consegue pensar e entregar, agora vive melhor dentro de um artefato funcional mais um log de decisões curto.

Devo apenas postar um protótipo funcional sem nenhuma explicação?

Não, e essa é a hipercorreção mais comum. Um demo sem história parece "eu só dei uns prompts e pronto," o que te prejudica em cargos sênior. Combine o artefato ao vivo com três a cinco decisões de uma linha e uma bifurcação que você rejeitou.

O que é um app de uma tomada, exatamente?

Um produto completo e funcional, muitas vezes com auth, pagamentos e dados reais, construído em uma sessão estendida em uma ferramenta como Claude Code ou Cursor e entregue no mesmo dia. O julgamento humano ainda está envolvido. O que desmoronou é a distância entre a ideia e a coisa ao vivo.

Isso significa que designers júnior estão em apuros?

A barra mudou de "você consegue descrever um método" para "você consegue entregar e defender." Isso ajuda quem consegue construir, porque um artefato clicável é mais honesto do que um deck. O risco é para portfólios que escondiam substância rasa atrás de slides de processo.

Como eu provo meu pensamento se o case study sumiu?

Você não precisa do case study longo para provar pensamento. Use um log de decisões curto: a decisão que tomou, a opção que rejeitou, o motivo em uma frase. Três a cinco desses ao lado de um artefato ao vivo provam mais julgamento do que uma narrativa de 40 telas.

E quanto a trabalhos complexos de enterprise ou de sistemas que não podem ser feitos em uma tomada?

Então seu artefato é diferente, mas o princípio se mantém. Mostre uma fatia funcional ou um componente funcionando, e anexe o log de decisões a ele. A mudança é "comece com algo real e clicável," não "reconstrua todo o seu SaaS em um fim de semana."

O ponto final (o artefato é o argumento)

O artefato é o argumento agora. Quando você consegue entregar a alguém uma coisa que roda, o deck explicando como você teria construído vira a cópia mais fraca de uma evidência que você já tem.

O thread do @andrewk dividiu designers em cerca de 9,8 mil reposts e mais de 400 respostas porque ambas as metades estavam defendendo algo verdadeiro. Uma metade defendeu o pensamento. A outra defendeu a prova. A resolução é que a prova se mudou para a coisa funcional, e o pensamento se mudou para cinco linhas honestas ao lado dela.

Então não lamente o case study. Aposente o inflado, mantenha o julgamento e comece com a coisa ao vivo. Processo fora, produto dentro.

Os designers vencendo a sala em 2026 não são os que têm o deck mais grosso. São os que conseguem dizer "clique aqui," e então explicar, em cinco linhas, exatamente por que está formado do jeito que está.