Let's talk about design portfolios

What we look for when we (don't) hire designers

Daniel Fosco
UX Collective
Published in
5 min readNov 3, 2016

--

As member of a multidisciplinary design team that's always hiring, evaluating design portfolios is a daily practice here at VTEX.

Being always up to date on what’s produced by other designers in the industry is not only a unique opportunity, but a task I take very seriously, as I get to look at portfolios from all skill-sets and experience levels.

And yet… I would be lying if I said this task isn't frustrating as well. Many portfolios have presentation or formatting issues that make evaluation harder and may entirely disqualify candidates, even when their design delivery is solid.

This article is a compilation of impressions and lessons learned on my time evaluating and hiring designers, with feedbacks and contributions from the rest of the team (specially from Rodrigo Muniz, who wrote the first draft).

Here, I go over about what we consider a good portfolio for UX / Product Designers, those who create the user experience and build digital products end to end. All the recent hires from our design team have portfolios that follow this advice one way or another.

To make it clear: this is a guide for the kind of design portfolios we would like to receive from applicants at VTEX.

Cases are the best way to present your work

The fundamental flaw that disqualifies most design portfolios we receive is the fact they don't present the problem that was solved and the decisions taken to reach the solution.

Because, really, only two things are being evaluated: quality of execution and clarity in decision-making. While execution usually receives more love from portfolios, the decision-making process is inexistent in most of them.

It doesn't matter that much to show a really good UI, excellent animated interactions or a complex IA map if how and why you reached these deliverables is not clear. Even more, if they had no noticeable impact or results in the end, why show them at all? What's the point of good design if not to solve problems?

Writing the story behind your project is the best way to bring forward the problems, lessons and results of your design process. In the end, that’s all everyone wants to see: cases, cases, cases.

And yes, that means telling a story, but it doesn't need to be a text of biblical proportions. It doesn't even need to be a text — if you're a designer, you know there are many ways to tell a story.

A basic structure for a good case could cover the following topics:

The Problem

Problem definition, research made, metrics raised, interviews, initial briefing. How the problem was chosen, why it was chosen and why it matters for the world.

Limitations

What kind of limitations you were dealing with? Time? Resources? A new technology? Knowledge of the subject at hand?

Solutions

Time to present the solution created. It's always good to show your evolution with the most important processes used in the project: wireframing? sketching? card sorting? HTML/CSS prototyping? Sketches are a important part of the design process, make sure you document them! 😄

Your role

Most projects are a team effort. How did you help as the designer in the project? What could have been better in the team interaction and execution? Who else was creating the solution with you? Take ownership of the work you've done and give credit where credit's due.

Learned Lessons

Did the project go live? Did it sink? What feedbacks did you receive? Which metrics did you register? What kind of improvements would you do / want to do?

And remember

Be concise

Really, you don’t need to write a ton of text to present your work this way. It’s another problem to write good cases, but base them on projects that are not relevant to the position you’re looking for. Or even cases based on projects that are just… average.

Having too many things in your portfolio hurts more than it helps.

Focus on presenting three to five projects. Your best projects. If you don't consider them top-notch, take them out. A portfolio with three excellent projects has a head start on another with three excellent and two weak ones.

Some compare portfolios to orange juice: all it takes is one bad orange for the whole jar to taste weird. ¯\_(ツ)_/¯

Be honest

Most software development projects go wrong in some level. Promote youself, but be honest and mention what went wrong and what you learned from it. A good project is a project you came out better than you went in.

As always, use common sense to know if you should drop a project where things went really bad — unless you're able to show you learned a lot from it. 😉

Review your text (and ask a friend to review it as well)

It may seem obvious, but it’s not. Everybody makes mistakes once in a while but when orthography and text structure are sorely lacking, it affects how you’re perceived by someone in a hiring position. If you need some help, ask for feedback from a friend or even random people online.

This is not a guide to be followed step by step. Your portfolio may not follow some (or any) of these suggestions, as each person is different and may require a different approach.

By telling a story about your projects and showing your process, your portfolio will already communicate so much more to people interested in your work.

In general terms, people won’t hire you only for the things you’ve done, but also for what you’re capable of doing. This is why it’s essential to clearly communicate your design process and the outcome of your projects: so others can visualize how much value you will bring to their team.

As with any other communication piece, think about your portfolio's audience and goals — after all, it's just another design project ✨

I tried to keep this article as short as possible, so I recommend the articles below as further reading on the subject:

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

This post was originally published in Portuguese at VTEX Lab’s Medium.

--

--