Writing
/
How to give a great product design portfolio presentation

How to give a great product design portfolio presentation

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.

Set useful context

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:

  • Who you are, where you're from...the basics
  • What kinds of problems you’ve worked on in the past (how did you get here?)
  • Notable past accomplishments
  • Side projects you’ve shipped

    • Remember that nobody knows your company as well as you. Set context about your organization by talking about:

  • Who your customers are
  • How the business makes money
  • How the organization measures success
  • Where you sit within the broader organization

    • Explain how you identify problems

    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:

  • What was wrong with the onboarding?
  • How did you know?
  • What did the data or research suggest that helped the organization realize this was a problem?
  • Why did the company choose to work on this particular problem before any other problems?
  • What people or systems decided how much time and energy to devote to solving this problem?
  • How did the team agree upon a way to know when they had solved the problem, qualitatively or quantitatively?

    • 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 constraints and tradeoffs

    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:

  • How do you think critically about risks, dependencies, side effects, or externalities?
  • What do you do to overcome constraints that customers won't care about (e.g. bureaucracy)?
  • How do you navigate technological and organizational headwinds?

    • If it’s relevant, explain how your company builds products as a meta-constraint:

  • Does the team gravitate towards scrappy MVPs and shipping iteratively?
  • Or does the team build up towards big releases on a strict cadence?
  • Does your organization have a research team?
  • Or are designers expected to run research themselves?
  • Do you have a design system?
  • Or did you have to create bespoke components as you go?

    • Remember, the protagonist in every great story faces insurmountable obstacles, and must sacrifice, be creative, or redefine themselves in order to win.

    Teach your interviewers something

    You’ll raise eyebrows and keep interviewers engaged if you can teach them anything during your presentation.

  • What surprised you while working on a project?
  • What ideas did you try that turned out to be incorrect? Or even better: what worked better than you could have ever imagined?
  • Did you learn something about your industry, your business, psychology, pricing models, or design systems?
  • Did your work affect other key metrics within the organization?
  • Did you discover non-obvious externalities in your problem space?
  • Did you execute a creative go-to-market strategy?

    • Show how the work evolved over time

    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.

    Show the final artifacts

    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.

    Explain the outcomes

    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:

  • Developed new components that improved the organization’s upstream design system.
  • Open sourced some novel tool or technology.
  • Mentored or coached a younger designer throughout the project.
  • Received meaningful external recognition from press or influential customers.
  • Published a blog post so that other designers could learn from your experience.

    • 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 contributions

    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.

    Read next