May 6, 2021
The portfolio presentation is the most important part of a product design interview loop. It’s the right time to demonstrate that you can Do The Work. Sadly, these presentations are usually packed into a single-hour meeting with a room full of strange faces. This can induce anxiety and leads many people to make easy-to-avoid mistakes.
In the spirit of avoiding these mistakes, here are my thoughts on giving a great product design portfolio presentation.
Share context up front about who you are, the organization you work for, and what kinds of problems you like to solve. A portfolio presentation should feel like telling a story: introduce the characters (you), the environment (the organization, problem space, your team), and the conflict (the problems you worked on).
Keep it short.
Some things to mention about yourself up front:
Remember that nobody knows your company as well as you. Set context about your organization by talking about:
I’ve seen too many designers start their presentation with So we wanted to improve the onboarding of our product, and here’s what we made… But this is skipping way too many steps in the design process. Answer questions like:
I might argue that how designers identify and prioritize problems is more important than the actual artifacts they ship. I'm sure it'd be a fun debate. Ultimately: it's your job to prove that you're a curious person who wakes up every day hungry to make your customers' lives easier.
Define your constraints early: we had one engineer and two weeks, we didn’t have good data, our design system didn’t have the right components, we were building for a new platform, we were fighting confusing regulations…
Be prepared ahead of time with one or two stories that show how you and your team navigated specifically challenging tradeoffs.
Interviewers want to know:
If it’s relevant, explain how your company builds products as a meta-constraint:
Remember, the protagonist in every great story faces insurmountable obstacles, and must sacrifice, be creative, or redefine themselves in order to win.
You’ll raise eyebrows and keep interviewers engaged if you can teach them anything during your presentation.
Bring interviewers along for the ride, explaining how you explored potential solutions to the problem and how you were able to validate or reject those solutions. It’s important to see that you are able to explore wide and fast, and not get tunnel vision on the first idea that hits your canvas.
Talk about ideas that did not work.
My favorite presentations show artifacts from each phase of a project with clear articulations of what was useful, what didn’t work, how customers responded, and how that feedback informed the next iteration.
When possible, show a live final product. Screenshots and screen recordings are fine, as long as it’s reflective of the thing that customers ended up using. When it’s not possible to show the final product, get as close as possible by sharing high fidelity prototypes or mockups with lifelike data. No lorem ipsum.
I realize this won’t be possible for many people; the final artifact might be private, or might have been shut down at the last minute. Good substitutes for a final artifact are high fidelity prototypes or screen recordings of a feature using realistic data.
For senior-and-above roles, this final artifact will be calibrated against your prototypes or mocks. The more senior the designer, the more likely it should be that they were able to drive decision making and prioritization so that what was designed ended up being shipped.
Did you solve the problem you set out to solve? Yes or no. Now, explain.
Talk about quantitative or qualitative outcomes. Always map these back to the original problem context you set at the beginning of the presentation. Include customer quotes, charts, graphs, numbers, or any other real artifact that makes it clear you are able to own an outcome and use that outcome to guide further decision making.
Not everything works. It’s okay. Talk about how you learn through the act of shipping software. If there were positive outcomes, great! If your product failed, how did you and the team regroup?
A very popular design interview question goes something like: if you had unlimited time and resources, what would you have done differently? You should know the answer to this question and have no problem elaborating.
Bonus: you should actually show what you would have tried next, given another shot on goal.
Bonus+: Identify non-obvious outcomes, like:
Aside: This is where many agency designers stumble when they are applying for an in-house position. This topic likely deserves another blog post, but my advice to any designers working in agencies: fight hard to get the results of your work post-handoff in order to calibrate a success rate for your design decisions. When this isn’t possible, be clear about this constraint so that interviewers don’t make incorrect assumptions about your process.
Be clear about your direct contributions to a project. It’s easy for interviewers to spot someone taking undeserved credit. Be forthcoming about where your smaller contributions fit within the larger team effort. This honesty and clarity demonstrates cross-functional collaboration skills and, more importantly, humility.
Great designers know that software development is a team sport, and seeing that you can give praise as well as you take credit is a positive hiring signal.
Thanks to [Effy Zhang](twitter.com/effyyzhang), [Kathy Zheng](twitter.com/pifafu), and [Marshall Bock](twitter.com/marshallbock) for reviewing drafts of this post.