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.
Dry run offer: If you are preparing for your portfolio presentation, feel free to grab a time on my calendar and Iāll gladly give you feedback in a presentation dry run. Schedule a dry run.
Thanks to Effy Zhang, Kathy Zheng, and Marshall Bock for reviewing drafts of this post.
A small favor
Was anything I wrote confusing, outdated, or incorrect? Please let me know! Just write a few words below and Iāll be sure to amend this post with your suggestions.
The email newsletter
Get updates about new posts, new projects, or other meaningful updates to this site delivered to your inbox. Alternatively, you can follow me on Twitter.