Como estruturar um case de portfólio

No texto anterior eu disse que um case muito bom vale mais que dez medianos. Fica a pergunta prática: como se escreve esse case?

A maioria dos cases que eu vejo cai em um de dois formatos. Ou é galeria de telas, bonita e muda, ou é relatório acadêmico, com o duplo diamante passo a passo e cada etapa do processo descrita como se fosse obrigação. Os dois mostram o que a pessoa fez. Nenhum mostra por que ela fez.

A minha posição: um bom case responde, na ordem, às perguntas que quem avalia vai fazer. O que era o projeto? O que te pediram? O que você descobriu que era de verdade? O que você decidiu? E o que aconteceu depois? Eu uso uma estrutura de cinco blocos que segue exatamente essa ordem:

1. Contexto, em duas linhas.
2. O que foi pedido, literalmente.
3. O que realmente era.
4. As decisões, não as atividades.
5. O resultado, com uma nota honesta sobre o que não foi resolvido.

Pra mostrar cada bloco funcionando, vou usar um case meu: o app de um cartão premium, feito pra um banco grande em parceria com uma bandeira internacional.

Quem lê precisa saber onde está pisando, e só isso. Que produto, pra quem, em que momento. Se o contexto passa de duas linhas, quase sempre tem decisão escondida ali que devia estar mais pra frente.

No exemplo: um app de cartão premium, com duas marcas fortes dividindo o mesmo produto. A tensão cabe numa frase: premium e familiar puxam pra lados opostos.

Aqui vai o pedido como ele chegou, sem enfeitar. Esse bloco existe pra criar contraste com o próximo, e é o contraste que mostra o seu julgamento.

No exemplo, o briefing pedia proximidade com o app do banco, que era referência de execução, mas ao mesmo tempo uma experiência diferenciada.

Esse é o bloco mais importante, e o que quase todo mundo pula. É onde você conta o que descobriu que o pedido não dizia.

Imagem · 01

No exemplo, a definição de como combinar as duas marcas não estava fechada, e não cabia a mim. O projeto não podia ficar parado esperando essa resposta. O problema de verdade, então, era outro: o app não precisava saber qual seria a decisão de marca; precisava não depender dela. E não era só um app. Eram três superfícies: o aplicativo do cliente, um acesso web pra gestão do cartão e uma camada administrativa.

Repara que a informação "isso não era minha decisão" entra aqui, como contexto do problema. Ela não abre o case. Isso apareceu na primeira versão desse case: ele abria justificando o que não estava sob meu controle, e a primeira coisa que o leitor via era eu tirando o meu da reta.

"Fiz entrevistas, montei personas, desenhei fluxos" é lista de atividades; qualquer designer faria. Decisão é o que você escolheu, o que descartou e por quê. Em tópicos, curtos.

No exemplo:

• Identidade como configuração. Estruturamos tudo como whitelabel. Quando a definição de marca chegasse, alguém do banco aplicaria pelo painel administrativo, sem novo ciclo de desenvolvimento. A decisão que estava fora do meu controle virou um parâmetro.
• O diferenciado veio de olhar pra fora. O app do banco era referência de um padrão já estabelecido. Quem estava definindo o padrão seguinte eram os bancos digitais entrantes, com widgets, customização em tempo real e transições mais fluidas. A jornada continuou reconhecível; o comportamento passou a ser de outra geração de produto.
• Tema por cartão. Propus que cada categoria de cartão tivesse sua identidade no app, o que transforma a cor em sinal entre portadores e cria incentivo pra subir de categoria. Ficou implementado, a critério do banco ativar.

Aqui também entram os desafios que fugiram do plano, porque nunca é o mundo ideal. E entram as telas. Se a vaga é de Product Designer, quem avalia vai olhar o visual, a experiência e os detalhes de interação. A diferença é que, depois dos blocos anteriores, cada tela aparece como prova de uma decisão, e não como galeria solta.

Resultado é dado, e de preferência dado que outra pessoa possa conferir. E nota honesta é dizer o que não foi resolvido, ou o que saiu do seu alcance.

No exemplo: o app foi lançado, passou de 100 mil downloads e ficou em operação até 2026, quando a parceria entre as duas marcas acabou no Brasil. A avaliação na loja hoje é 2,3. As reclamações se concentram em funções que viraram padrão de mercado depois do lançamento e na falta de integração com o app do banco, não na estrutura entregue. O meu contrato ia até a entrega, e eu não acompanhei a evolução depois. A lição que fica no case: produto premium não é o que se entrega no lançamento, é o que se mantém.

Esconder o 2,3 seria fácil. Contextualizar mostra que você entende produto além da entrega.

E se o seu escopo terminou antes da validação? Tudo bem. Não invente um escopo só pra ter o que mostrar. Mostre como você acompanharia, o que avaliaria e quais seriam os próximos passos.

Uma coisa que fica clara quando você está do lado de quem contrata: a maioria dos portfólios chega muito parecida. Então quem avalia já abre cada um sabendo o que precisa que aquela pessoa faça no time, e procura isso.

Imagem · 02

Se a vaga pede mais força no delivery, o olhar vai pra execução. A pessoa entende de design system, de design atômico, de como montar a componentização? Como fica o resultado final? Tem equilíbrio de paleta, entende de psicologia das cores, de hierarquia da informação e tipográfica, de espaçamento, das heurísticas de design?

Se a vaga é de alguém que vai ajudar mais em pesquisa, workshop e discovery, na parte que antecede a estratégia, o olhar vai pro raciocínio. E aí os desafios que fogem da alçada do design ganham peso: o deadline curto demais, a informação que você não conseguiu acessar, a mudança repentina no meio do projeto. Quem avalia quer entender como você se virou. É ali que aparecem, juntos, o hard skill e o soft skill, e é isso que dá personalidade a um case no meio de tantos parecidos.

Na prática, vale olhar a vaga antes de mandar o portfólio e se perguntar qual dos seus cases responde melhor ao que ela pede.

Só tem um cuidado: o case não pode virar a história da sua vida. Quem avalia precisa bater o olho e entender rápido o que você fez.

Imagem · 03

Por isso funciona ter uma versão resumida, que deixa bem claros os pontos que interessam: como você se vira no inesperado, o que você sabe de pesquisa e indicadores, como fez a proposta de valor ser validada e como ficou a entrega de design. Os detalhes maiores ficam disponíveis pra quem tiver curiosidade, numa versão estendida ou na conversa da entrevista.

O erro mais comum é abrir o Figma e começar pelo layout do case. Escreve primeiro, em texto corrido, como se fosse explicar o projeto pra alguém numa conversa. O gargalo de um bom case quase nunca é o visual; é conseguir dizer em poucas linhas o que estava em jogo e o que você decidiu. Quando o texto está de pé, a diagramação fica fácil.

Tem uma ironia aqui. No texto anterior eu disse que quem avalia pergunta se você seguiu um template ou se entende de verdade cada etapa. E agora estou te dando uma estrutura.

A diferença é o que vai dentro. Os cinco blocos são um esqueleto pra organizar o raciocínio, e não um formulário pra preencher. Se o bloco 3 não tiver uma descoberta de verdade, ou se o bloco 4 for só a lista de atividades com outro nome, quem avalia percebe na hora. Nenhuma estrutura cria pensamento onde ele não existiu.

Tem um problema que muita gente vai ter ao aplicar isso: e quando o seu melhor case é confidencial? Como mostrar raciocínio sem expor o cliente? Esse vale um texto próprio.

Enquanto isso, pega o case mais forte do seu portfólio e escreve só o bloco 3, em três frases: o que você descobriu que o pedido não dizia. Se não sair, esse case ainda não está mostrando o seu pensamento.