Vamos conversar sobre portfólios de design

O que olhamos quando contratamos (ou não) designers

Como membro de uma equipe de design multidisciplinar que só cresce, avaliar portfólios é uma prática quase diária na VTEX.

Estar constantemente a par do que é produzido por designers do mercado é para mim uma oportunidade única, além de um trabalho que levo muito a sério, especialmente estando em contato com designers de diferentes habilidades e todos os níveis de experiência.

Ainda assim, estaria mentindo se dissesse que este trabalho não traz uma certa dose de frustração. Muitos portfólios têm problemas de apresentação ou de formato, que prejudicam sua avaliação e podem muitas vezes deixar candidatas(os) no meio do caminho, mesmo quando suas entregas são de qualidade.

Este texto é um compilado de impressões que adquiri ao longo do meu tempo avaliando e contratando designers, com feedbacks e contribuições do restante da equipe (principalmente do querido Rodrigo Muniz, que escreveu o primeiro draft).

Aqui, falo sobre o que consideramos um bom portfólio para Designers de UX / Produto, aqueles que criam a experiência do usuário e constroem produtos digitais de ponta à ponta. Todas as contratações recentes de nossa equipe de design têm portfólios que seguiam estes conselhos em maior ou menor medida.

Sem firulas, este texto é um guia do que gostaríamos de ver nos portfólios de designers que recebemos na VTEX.

Cases são a melhor forma de mostrar seu trabalho

A falha fundamental que desqualifica boa parte dos portfólios de design que recebemos é o fato de que eles não apresentam o problema resolvido e as decisões tomadas para chegar na solução.

Por que, sério, são apenas duas coisas que estão sendo avaliadas: a qualidade de execução e a clareza na tomada de decisões. Enquanto a execução costuma receber mais atenção nos portfólios, o processo de tomada de decisão é inexistente na maior parte deles.

No final das contas não faz tanta diferença mostrar “só” uma UI incrível, uma excelente interação animada ou um mapa de arquitetura super complexo. Absolutamente nada disso importa se não estiver claro o como e o por quê você chegou a cada um desses entregáveis e quais foram seus resultados. Afinal, de que adianta estar tudo lindo e não ter resolvido problema algum?

Escrever a história por trás dos seus projetos é a melhor forma de trazer à tona os problemas, aprendizados e resultados do seu processo. No final, é isso o que todos querem ver: cases, cases, cases.

E sim, isso significa contar uma história, mas não precisa ser um tijolo de texto. Não precisa nem ser um texto de fato — você é designer e sabe que há várias formas de contar uma história.

Uma estrutura básica para um bom case poderia cobrir os seguintes tópicos:

O Problema

Definição do problema, pesquisa, métricas, entrevistas, briefing inicial. Como o problema foi atacado, porque foi atacado, porque este problema importa para o mundo.

As Limitações

Com que tipo de limitações você estava lidando: tempo? Dinheiro? Tecnologia? Conhecimento?

As Soluções

Hora de apresentar a solução criada. Sempre bom mostrar sua evolução com os processos mais importantes para a realização do projeto: wireframing? sketching? card sorting? prototipagem HTML/CSS? Sketches são peças importantes para mostrar o processo, lembre-se de registrá-los! 😄️

“Como eu ajudei”

A maioria dos projetos é feita em equipe. Como você ajudou na posição de designer do projeto? O que poderia ter sido melhor na interação com a equipe e na execução? Quem mais estava com você criando essa solução?

Lições Aprendidas

O projeto foi ao ar? Deu errado? Que feedbacks recebeu? Que métricas registrou? Que melhorias você faria/quer fazer?

Por último, é sempre bom lembrar

Seja Breve

Realmente, não precisa escrever um volume de proporções bíblicas. Só que também não adianta ter cases do tamanho certo, mas encher o portfólio de projetos fracos ou que não sejam relevantes para a posição que você busca. Ter projetos demais no portfólio atrapalha mais do que ajuda.

Foque em apresentar de três a cinco projetos. Seus melhores projetos. Se você não os considera muito bons, tire. Um portfólio com três projetos excelentes sai na frente de outro com três projetos excelentes e dois meia-boca.

Há quem compare o portfólio com um suco de laranja: basta que uma esteja estragada para que a jarra inteira fique com gosto ruim. ¯\_(ツ)_/¯

Seja Honesto

A maior parte dos projetos de software dá ruim em algum nível. Venda seu peixe, mas seja honesto para mencionar o que deu errado e o que você aprendeu com isso. Um bom projeto é um projeto no qual você sai melhor do que entrou.

Claro, cabe o bom senso de abandonar o barco e não focar em projetos onde as coisas deram muito errado — a não ser que você consiga mostrar um grande aprendizado em cima dele. 😉

Revise seu texto (e peça para um amigo revisar também)

Pode parecer óbvio, mas não é. Todo mundo erra de vez em quando, mas quando a ortografia e estrutura de um texto deixam a desejar, isso afeta muito a avaliação de quem está lendo. Se você não manja tanto de texto, vale pedir feedback para um amigo ou até para (des)conhecidos na internet.


Este não é um guia para ser seguido à risca. Seu case pode, ou não, ter qualquer uma dessas partes, já que cada projeto é diferente. Mas só de se propor a escrever sobre seu projeto e organizar seu processo, ele já vai comunicar muito mais valor para avaliadores.

Pense que, em geral, não vão te contratar pelo que você já fez, mas pelo que você é capaz ou tem potencial para fazer. Exatamente por isso é essencial comunicar de forma clara seu processo e seus projetos.

Como qualquer outra peça de comunicação, vale pensar em qual o público e qual o objetivo do seu portfólio: afinal, ele é só mais um projeto de design ✨

Agradecimentos: Rodrigo Muniz, Bernardo Lemgruber, Lara Campelo, Alena Miklos, Gabriel Galc, Luiza Breier


P.S.: Tentei manter esse post o mais breve possível, por isso recomendo muito a leitura dos artigos abaixo, infelizmente disponíveis apenas em inglês.