Template de Estudo de Caso de Design: Como Escrever Estudos de Caso que Realmente Conquistam Trabalho

Todo gestor de contratação tem uma pilha de portfólios de design abertos em abas do navegador agora mesmo. Ele gasta trinta segundos em cada um. Talvez sessenta, se o hero fizer seu trabalho. O estudo de caso que ganha é aquele que responde à pergunta real do gestor nessa janela, não o que tem os mockups mais bonitos.

Este é o template na prática. Oito seções em ordem fixa, os números que importam e as imagens de processo que realmente têm peso. Se o seu portfólio atual parece trabalho de escola, este é o padrão de reescrita.

O que os gestores de contratação realmente leem

O gestor de contratação está procurando evidência de que você entregou algo que moveu um número. Todo o resto é contexto. Diagramas de processo, moodboards e parágrafos de "minha jornada" vêm depois, não antes. O estudo de caso que falha abre com a jornada. O que vence abre com o resultado.

Os designers que intuem isso entregam portfólios que convertem. Os que não intuem entregam portfólios que "recebem bons feedbacks" e nenhuma entrevista. A diferença é estrutural, não artística.

O template de oito seções

Essas oito seções, nesta ordem, cobrem todo estudo de caso que um designer precisa escrever. Projetos pilares recebem o tratamento completo. Projetos menores recebem uma versão comprimida. As seções continuam as mesmas.

Seção 1: O resultado em uma linha

Abra com o resultado, não com o contexto. Uma frase. O que o design entregou e o que mudou.

"Redesenhei o checkout de um SaaS B2B e aumentei a conversão em 32% no primeiro trimestre." Isso é uma abertura de estudo de caso. "Fiquei empolgado em assumir este projeto para uma startup em modo stealth no setor de fintech" é um estudo de caso que é fechado em cinco segundos.

Gestores de contratação confrontam essa abertura com o resto da página. Se o resto sustenta, continuam lendo. Se a abertura é vaga (transformou a experiência, reimaginou a jornada, criou uma nova forma de pensar sobre), eles assumem que os números estão ausentes porque são ruins. Escreva o resultado tão claramente quanto uma manchete de jornal de negócios.

Seção 2: O problema em um parágrafo

A seção de problema é onde a maioria dos portfólios perde o leitor. Ela parece uma revisão de literatura do negócio. Gestores de contratação não precisam da história da empresa, precisam da restrição que criou o desafio de design.

De duas a quatro frases, no máximo. O que estava quebrado. Quem sofria com isso. Por que continuava quebrado. Esse é o problema.

Um bom parágrafo de problema:

O fluxo de checkout tinha 63% de abandono no plano enterprise porque as equipes de compras não conseguiam compartilhar uma cotação com o financeiro sem screenshots. O fluxo existente presumia um único comprador com cartão de crédito. Corrigir isso significava redesenhar para uma compra por comitê, com fatura em 60 dias.

Sem backstory. Sem "o cliente veio até nós". Direto para a restrição. O artigo sobre princípios de design de landing page cobre a mesma disciplina para copy de marketing. Mesma regra para estudos de caso.

Seção 3: As restrições

Estudos de caso sem restrições parecem ficção. Todo projeto real tem restrições (prazo, equipe, plataforma, compliance, orçamento, sistema existente). Listá-las gera confiança porque prova que o designer trabalhou no mundo real, não num rebrand pessoal de uma marca da Fortune 500.

De cinco a sete tópicos. Mantenha-os concretos.

• Equipe de dois designers, um engenheiro, um PM
• Prazo de seis semanas do kickoff ao lançamento
• Design system existente travado, apenas adições, sem sobrescritas
• Apenas plano enterprise, checkout de consumidor intocado
• Precisa integrar com o fluxo de compras SAP existente
• Meta de acessibilidade WCAG AA desde o primeiro dia
• Nenhum trabalho novo de backend, apenas front-end e integração

Restrições não são reclamações. São prova de que o designer entendeu a caixa antes de desenhar dentro dela.

Seção 4: O processo, comprimido

A maioria dos estudos de caso de portfólio investe demais em processo. Incluem cada esboço divergente, cada artefato de workshop, cada moodboard. Gestores de contratação não leem isso. Eles procuram três coisas: o designer enquadrou o problema, o designer validou a solução, o designer entregou o que desenhou.

Mostre evidência de cada uma, uma vez.

Evidência de enquadramento: um diagrama, fluxo ou matriz de decisão que mostra como o escopo foi definido. Um mapa de jornada, um service blueprint, um resumo de análise competitiva, um screenshot de decision log. Um artefato, rotulado com o que ele respondeu.

Evidência de validação: um artefato de pesquisa ou teste. Resumo de teste de usabilidade com duas citações, resultado de teste A/B, screenshot de analytics mostrando o estado anterior, uma iteração de protótipo com mudanças anotadas. Um artefato, rotulado com o que ele mudou.

Evidência de entrega: o design de fato publicado. Não o comp final no Figma. A URL no ar, o screenshot da App Store, o fluxo gravado. Estudos de caso que mostram comps do Figma e nunca o produto entregue parecem designs de papel.

Seção 5: O decision log

Esta é a seção que a maioria dos designers pula. É a seção que gestores de contratação leem duas vezes.

Um decision log é uma lista curta de escolhas não óbvias feitas durante o projeto, com o trade-off e o resultado. Prova que o designer tinha opiniões testadas contra a realidade, que é o sinal mais contratável que um portfólio pode carregar.

De três a cinco entradas. Template para cada uma:

• Decisão: o que foi escolhido
• Alternativa: o que foi rejeitado
• Motivo: a restrição ou insight que guiou a escolha
• Resultado: o que aconteceu após o lançamento

Exemplo:

• Decisão: O compartilhamento de cotações foi reconstruído como um link público somente leitura, em vez de um fluxo nativo de CC ao financeiro.
• Alternativa: CC ao financeiro dentro do produto, exigindo criação de conta.
• Motivo: Compras e financeiro muitas vezes pertencem a sistemas diferentes e compras não esperaria um fluxo de criação de conta.
• Resultado: 71% das cotações enterprise foram compartilhadas em até 24 horas após a geração, contra 12% antes do redesign.

Decision logs são o mais próximo que um portfólio chega de uma entrevista prática. Escreva-os primeiro, depois escreva o resto do estudo de caso em torno deles.

Seção 6: O resultado, com números

A seção de resultado é o contracheque do estudo de caso. Tudo antes dela foi preparação. Os números aqui precisam ser reais, específicos e atribuíveis.

Três tipos de números funcionam.

Números de negócio. Receita, conversão, retenção, ativação, time-to-value, CAC, LTV. São os números que gestores de contratação querem primeiro porque mapeiam diretamente para a razão de o time de design existir.

Números de produto. Conclusão de tarefas, taxa de erro, volume de tickets de suporte, tempo na tarefa, adoção de funcionalidades. Provam que o design mudou o comportamento do usuário, o que prova que o design era bom.

Números de qualidade. Nota de auditoria de acessibilidade, melhoria em core web vitals, adoção do design system, tempo de handoff economizado. São os números de segundo nível, úteis quando os de negócio e produto não estão disponíveis (sob NDA, cedo demais para medir).

Um de cada categoria basta. Três números por estudo de caso vencem dez, porque três números específicos soam honestos e dez soam enchimento.

Se o projeto está sob NDA, diga isso claramente. Troque números exatos por faixas verificáveis ("um aumento de conversão na casa de dois dígitos baixos", "dobrou a ativação"). Não invente. Gestores de contratação têm amigos em todas as empresas, e eles perguntam.

Seção 7: Seu papel, sem rodeios

Todo estudo de caso precisa de uma resposta clara para a pergunta que o gestor de contratação realmente carrega na cabeça: o que esse designer fez pessoalmente.

De duas a três frases. Use "eu" quando o trabalho foi solo, "nossa equipe de quatro" quando não foi, e liste a contribuição específica nos dois casos.

Bom:

Liderei o design de interação e fui responsável pelo decision log. Trabalhei em dupla com um engenheiro no fluxo de checkout e com um PM no escopo. Outra designer da equipe cuidou do sistema visual, que eu apliquei mas não desenhei.

Vago:

Liderei o processo de design de ponta a ponta e colaborei de perto com parceiros multifuncionais para entregar uma experiência de usuário encantadora.

A versão vaga parece cortina de fumaça. Sempre gera mais perguntas na entrevista, não menos. Escreva a versão direta e guarde a entrevista para a conversa que você realmente quer ter.

Seção 8: A reflexão

Um parágrafo curto. O que você faria diferente se rodasse o projeto de novo.

Esse é o sinal de senioridade. Designers juniores refletem em generalidades ("eu iteraria mais com usuários mais cedo"). Designers seniores refletem com especificidade ("subestimei o prazo da integração de compras em quatro semanas e teria escopado isso como um workstream separado no primeiro dia, em vez de embuti-lo no projeto de checkout").

Reflexão positiva demais ("tudo deu certo") soa como alerta de credibilidade. Reflexão negativa demais ("eu falhei") soa pouco profissional. Reflexão específica e tática soa como alguém que aprendeu com o projeto e aprenderá com o próximo.

---

O que cortar da maioria dos estudos de caso

A maioria dos estudos de caso de portfólio é mais longa do que precisa, e é por isso que gestores de contratação passam o olho. Corte o seguinte:

O parágrafo "sobre o cliente". Se o cliente é conhecido, o gestor já sabe. Se não é, o contexto pertence ao enunciado do problema, não a um bloco separado.

O moodboard. Quase nunca relevante para uma decisão de contratação. Guarde moodboards para arquivos internos de trabalho e apresentações a clientes, onde eles justificam o espaço.

O grid de ideação divergente. Nove conceitos numa página, oito deles rejeitados, é um artefato de workshop, não de portfólio. Mostre a direção final e a única alternativa que foi uma concorrente de verdade.

O reel de comps não entregues. Comps lindos de coisas que nunca foram ao ar dizem ao gestor que o designer talvez não entregue. É o sinal errado. Abra sempre com trabalho entregue.

O ensaio de estilo pessoal. Seções de "minha filosofia de design" são puladas. Se a filosofia é real, os estudos de caso vão demonstrá-la sem anunciá-la.

---

Tamanho do estudo de caso por senioridade

O tamanho de um estudo de caso muda com a senioridade, mas a estrutura não. As oito seções ficam. A profundidade dentro delas muda.

Qualquer coisa acima de 2500 palavras é um estudo de caso que ninguém termina. A regra para cargos sênior e staff é densidade, não tamanho. Mais julgamento por parágrafo, não mais parágrafos.

Como escrever o primeiro rascunho

O caminho mais rápido para um estudo de caso publicável é escrever nesta ordem, que não é a ordem em que o leitor vê.

1. Escreva o decision log primeiro. De três a cinco entradas. Essa é a parte mais difícil e aquela em que todo o resto se apoia.
2. Escreva a seção de resultado em segundo. Levante os números antes de escrever em torno deles.
3. Escreva problema e restrições em terceiro. Agora você sabe quais restrições importaram, porque sabe quais decisões elas guiaram.
4. Escreva a seção de processo em quarto. Escolha os três artefatos que merecem seu lugar.
5. Escreva as seções de papel e reflexão por último. Curtas, honestas, prontas.
6. Reescreva o resultado em uma linha no topo por último, depois que todo o resto estiver escrito. É a última frase redigida e a primeira lida.

Essa ordem força o pensamento difícil logo no começo. Designers que escrevem na ordem de leitura costumam terminar com prosa bonita e substância faltando.

Como apresentar o processo sem entediar o leitor

Seções de processo são onde a maioria dos portfólios é lida na diagonal até a morte. A solução é densidade, não exclusão.

Um screenshot anotado por artefato. Não uma galeria do arquivo de trabalho inteiro. Um único screenshot com três callouts explicando o que o artefato respondeu.

Um único vídeo de protótipo, com no máximo 30 segundos. Pule a gravação de tela sem edição. Corte o vídeo do protótipo num loop enxuto que mostre a interação principal, com rótulo.

Antes e depois, sempre. Qualquer comparação que inclua um "antes" é mais forte do que uma que não inclui. Até um esboço a lápis ao lado do produto entregue soa como progresso. O glossário de wireframe cobre que tipo de artefato inicial tem peso.

Um voxel, esboço ou frame de baixa fidelidade em vez de mais um comp polido. O contraste entre pensamento de baixa fidelidade e entrega de alta fidelidade prova que o designer trabalhou um problema em vez de decorar uma solução.

Se você quer um time que audita portfólios e reescreve estudos de caso com gestores de contratação no circuito, contrate a Brainy. Revisões de portfólio são uma das nossas ofertas de resposta mais rápida para designers sêniores e staff em busca de emprego.

O teste de aprovação e reprovação do estudo de caso

Passe todo estudo de caso por cinco checagens antes de publicá-lo no seu portfólio.

Teste de leitura rápida. Um leitor consegue captar problema, abordagem e resultado só pelos títulos e pelas primeiras frases? Se não, a escaneabilidade está quebrada. O artigo sobre design de hierarquia visual cobre a correção estrutural.

Teste de números. Há pelo menos dois números reais na página? Se não, o estudo de caso é uma história sem punchline.

Teste de papel. Um leitor consegue responder "o que esse designer fez pessoalmente" em menos de 10 segundos de leitura? Se não, a seção de papel está vaga demais.

Teste de decisão. O estudo de caso mostra pelo menos três decisões não óbvias com trade-offs nomeados? Se não, o designer parece um executor, não um pensador.

Teste de entrega. Há evidência de que o trabalho realmente foi ao ar? Uma URL, um screenshot em dispositivo real, um link da App Store, um screenshot de código em produção. Se não, o estudo de caso é uma peça especulativa, não profissional.

Cinco checagens. Cinco minutos. Todo estudo de caso, toda vez.

---

FAQ

Qual deve ser o tamanho de um estudo de caso de design?

Entre 800 e 2500 palavras, dependendo da senioridade. Estudos de caso júnior ficam entre 800 e 1200, nível pleno entre 1200 e 1800.

Sênior de 1500 a 2200. Estudos de caso staff e principal podem chegar a 2500 se as decisões e os números justificarem. Qualquer coisa mais longa perde o leitor.

O que todo estudo de caso de design deve incluir?

Oito seções em ordem: um resultado em uma linha, um parágrafo de problema, restrições, uma seção de processo comprimida, um decision log, resultados mensuráveis, uma declaração direta do seu papel pessoal e uma reflexão curta. Todo estudo de caso precisa das oito, mesmo que algumas tenham só duas frases.

Como escrever um estudo de caso sem quebrar um NDA?

Troque números específicos por faixas verificáveis ("um aumento de conversão na casa de dois dígitos baixos") e troque marcas nomeadas pelo setor ("uma fintech com mais de 100 clientes enterprise"). Declare o NDA claramente no topo do estudo de caso. Não invente números nem marcas. Gestores de contratação checam, e estudos de caso fabricados acabam com carreiras.

Como mostrar o processo sem fazer o leitor dormir?

Limite a três artefatos (um para enquadramento, um para validação, um para entrega). Anote cada artefato com o que ele respondeu. Troque vídeos longos de protótipo por cortes de 30 segundos da interação principal. Inclua sempre uma comparação de antes e depois. Densidade vence volume em toda revisão de portfólio.

Qual é o maior erro que designers cometem em estudos de caso?

Abrir com o contexto em vez do resultado. A primeira linha de um estudo de caso deve ser o resultado do projeto, não a empolgação de começá-lo. Gestores de contratação leem de cima para baixo. Se o resultado está enterrado na segunda página, o estudo de caso já está perdido.

Como escrevo um estudo de caso se ainda não entreguei o projeto?

Entregue algo primeiro. Estudos de caso não entregues soam especulativos, e gestores de contratação os descontam. Se o projeto precisa aparecer antes do lançamento, rotule-o claramente como "em desenvolvimento" e foque nas seções de decision log e pesquisa. Nunca mostre comps não entregues como se fossem reais.

O portfólio é uma página de vendas

Todo estudo de caso é uma página de vendas do designer que o escreveu. O produto é o designer. O comprador é o gestor de contratação. O preço é uma entrevista de quarenta minutos.

Páginas de vendas que vencem são diretas, específicas e honestas. Abrem com o resultado, provam com restrições e decisões, sustentam com números e fecham com uma declaração clara de quem é o vendedor. Páginas de vendas que perdem escondem o resultado atrás do processo, enchem a história de contexto e deixam o leitor se perguntando o que de fato comprou.

Escreva as oito seções. Corte a gordura. Publique o estudo de caso. Depois faça de novo para o próximo projeto, e o seguinte, até o portfólio parecer um conjunto de apostas entregues que deram retorno, não um conjunto de jornadas que você curtiu.

Se você quer um time que audita, reescreve e entrega portfólios que convertem em entrevistas, contrate a Brainy. Rodamos este template em portfólios de produto, marca e UX, e a estrutura se sustenta toda vez.

Leitura relacionada

• Princípios de Design de Landing Page
• Design de Hierarquia Visual
• Como Apresentar Identidade de Marca a Clientes
• Preços de Design de Identidade de Marca