Most are a collection of case studies describing, in detail, the process for each project. Which might sound reasonable; but as a hiring manager I know how a design process works. The particulars of process look remarkably similar from project to project, and don’t actually tell me much about what makes the work unique.
It surprises me that this approach is so common. Designers have the skills to treat their portfolios as a design exercise: to understand their users and create experiences that meet their needs.
Or is it just me? Are other hiring managers getting signal I’m missing? I asked in the Designers Guild, a popular design community, and other design managers agree:
“I see a lot of process heavy narratives that focus on explaining each step of the process and what happened during that step, which leads to a very generic/repetitive process narrative.” (Matthew Mang)
“Whenever I see tons of process I immediately think this person is outing themselves as entry level.” (Luis Guzman)
So, what should you do instead?
Framing the Problem
Again, your portfolio is itself a product, with known target users and a clear success metric:
Your users are design managers and recruiters. Each is looking for a needle in a haystack, where the haystack contains multiple needles. They’re incentivized not to linger on a given candidate: since most will be below their bar, their best bet is to dismiss candidates quickly and expand the number they can screen. Time is not on your side.
Success looks a lot like success for an e-commerce site: you want conversions. Every time a hiring manager or recruiter contacts you, that’s a conversion. Granted, there are good conversions and bad ones.
And as design manager Mike Mariano noted, “The portfolio is just a means to a phone screen, where the real interview begins.” You’re trying to pique someone’s interest rather than to give them a complete picture.
Presenting Your Projects
As you consider how to represent a project, think about what you did differently — from other designers, from other projects, from your standard approach. On occasion that will be process-related (how you did what you did), but more often it boils down to what you did, why you did it, and what you learned along the way. Tell a story about you, and why your involvement in this project produced a unique and interesting result — rather than a story about a design that happened and you were there. Here’s how you might do that:
- Show how your design and thinking evolved, and why.
- You probably tried a few things and got them wrong. Talk about it! Those twists and turns are inevitable, and in fact are signs of a good, healthy design process. What’s more, they provide a window into how you think and your ability to adapt based on new information.
- Tell me what you learned — about the problem space, about design in general, about collaboration. If you had it to do over again, what would you change?
- Show your work at full size. I want to know what your mockups, wireframes, or prototypes look like, and that’s tough with a thumbnail.
- Don’t put your mocks in a perspective frame. Yes, every mockup looks better that way. You know that, and I know that, which means you’re not fooling anyone. You’re just making me tilt my head and squint. Show me the thing, full size, head-on.
- Give me a brief overview of your process: I do want to know that you went through various stages of ideation, iteration, and collaboration. A few thumbnails and/or a couple sentences should do it. And again, I’m particularly interested in moments when you changed your approach based on new information.
- Don’t describe how a design process works. “Sketches are a useful step in the design process because they allowed us to iterate rapidly.” I already know that, and you’ve included your sketches — so I know you know it, too. (And honestly, I don’t even care that much. If you’ve never sketched anything and I love your work, I’ll hand you a Sharpie and a piece of paper on your first day and we’ll sort it out.)
- Don’t get too deep into process details. Yes, there were two PMs in the first brainstorm and three in the second one. And you used Magic Post-It Pro XP to transcribe the post-its. It’s not useful for me to know.
- Give me an overview of the problem and domain, but don’t go too deep. I want some context, and I want to know that you understood the context…but I’m not looking for an education.
- Tell me which parts you did — what you started with, what leeway and constraints you had, what you changed, what you wish you could have changed. Before & after shots are incredibly valuable if you can manage them.
- Keep it short! Just as you would with any design project, prioritize ruthlessly to ensure your user sees and absorbs the things that matter most. Everything you add decreases the probability that any one thing will be seen.
- Check your spelling and grammar. Not everyone will care, but for those who do — myself included — a poorly written portfolio is a strong negative signal about your attention to detail. If English isn’t your first language, enlist a friend or colleague as proofreader.
The Home Page
While the projects matter most, your portfolio’s home page makes the first impression. Some suggestions there:
- Introduce yourself concisely, humbly, and uniquely. Limit yourself to a sentence or two, and focus on what makes you different from other designers. At least half of the portfolios I’ve seen say something like, “Passionate about solving design problems with simple solutions.” (Mine used to say, “I like making stuff, for people.” That’s arguably still too generic but conveyed two important things: a bias toward action—I don’t like planning stuff, I like making stuff — and a bit of humor or irreverence.)
- Provide either a standard aesthetic, or a superb one. Most portfolios are straightforward Squarespace sites, and that’s fine! If you have the time and effort to turn your portfolio’s design into a true showcase of your talent, even better — but that’s really time-consuming, and anything less than your best won’t present well. Better something polished and standard than something half-assed and bespoke.
- Make your thumbnails count. If a visitor only saw your home page, what would she take away about you?
- Label your projects! No matter how well you do with thumbnails, they can still feel abstract. Think about what information will matter, and what won’t. One designer noted, “I don’t name my projects by company or product, I name them based on the problem.” Other useful info: the date, which parts you did, and the type of work.
- Curate! I care more about seeing a couple great projects than a lot of projects. In fact, I’ll have a better emotional reaction with fewer projects, because I won’t feel like I’m missing anything.
- Don’t get too clever, at least not at the expense of your viewer’s time. A lengthy animated intro, for instance, is a risk.
Confused? Overwhelmed? Don’t be afraid to ask others — even hiring managers for jobs you’re looking at — for feedback. I’m happy to provide an opinion myself; drop me a line. But be prepared for me to try and recruit you…
Thanks to Frances Yun, Timery Crawford, and Raymond L for reviewing and proofreading.