Acing the PD portfolio presentation

My process for product design portfolio presentations, plus a free Figma starter template

A brief guide to crafting the presentation

Over the last few months, I’ve sat in a number of portfolio presentations for product design applicants with a range of experience levels. I’ve been surprised at the mistakes I saw repeatedly in candidates, even at the senior level – mistakes that often prevented them from moving on to a final interview round. I wanted to share my thoughts on how product designers can avoid these common mistakes and craft something that impresses interviewers and makes their work easy to understand and talk about.

As a side note, I’ve recently been able to put this advice to the test, and was fortunate enough to land a Senior Product Design role at Handshake. I feel like this advice can apply to any designer between entry and senior levels, since that’s reflective of my own experience so far.

I’ve also put together a free Figma Community resource with a version of this guide and a simple starter template for your own presentation:

Download on Figma Community


Introducing yourself

In many of the interviews I sat in, designers had just one slide with a couple bullet points that covered themselves and their background. This is your chance to make a great first impression and give the interviewers an idea of who you are and what you’re interested in.

The information you choose to include here is definitely subjective, but you should feel like you can linger here for a bit. For example, I start off with a quick visual of some of my recent experience:

About me slide Starting off with a quick summary of related experience

I could have shown my recent experience in a bulleted list, but that would have missed an opportunity to show a bit of my attention to detail and playful storytelling. Keep your slides visual-heavy and use voiceover to fill in the details.

Your intro can also touch on other aspects of your life and interests. I spend the next few slides talking about my experience with graphic design, my photography, and a few animations. Bonus points if your intro conveys your creative interests and passion for design and design-adjacent fields.

About me slide Give interviewers an idea of your interests & related skills

In short, leave yourself space to share the things you’re passionate about. Giving interviewers insight into who you are is equally important to showing your work.

Selecting your case studies

Choosing which projects to walk through can be highly subjective and depend on the role you’re applying for. Here are some questions to ask yourself as you decide what to show:

  1. Which of my projects are in similar spaces to the role I’m applying for?
  2. Which of my projects are ’real-world’? Can I speak to how my project had an impact on its stated goals?
  3. Do my projects use platforms similar to the platforms I would be designing for on this team?
  4. Which of my projects am I most proud of and would like to do more of?

Most companies I’ve seen are looking for 2 - 3 projects for the portfolio review, and I’ve never had to show more than 2. However, it’s a good idea to have a mix of different projects ready to go so your can tailor the selections to whatever job you’re interviewing for. Try to get a sense of what team they’re looking to place a designer on so you can choose projects that are more aligned with that role.

I once helped interview a designer who showed marketing design projects while applying for a product design role. Even if the work is good, this can present a disconnect with your interviewers who are looking to evaluate your skills as they relate to the type of work they’re doing every day.

Presenting the work

When I was applying for my first product design role, my hiring manager gave me advice that’s stuck with me and helped land each one of my jobs: when you’re presenting design work, try to follow this framework:

  1. What problem were you solving, and why is it interesting or important?
  2. What did you do about it?
  3. What happened afterwards?
  4. What did it take to get there?

Let’s break down these steps.


  1. What problem were you solving, and why is it interesting or important?

Communicating the design challenge is integral to helping your audience understand what you ultimately designed. It should begin with talking about the context of problem in the first place – what does the company do? What team were you on? Was this a school project?

These bits of context are important, but shouldn’t take up too much time. For example, I spend one slide explaining the company, and three slides talking about the existing problems with one area of the product.

Context slide Give just enough context to set up your work

Nearly every presentation I’ve seen has spent too much time on setting up this initial project context.

Your goal here should be to give just enough information that interviewers can follow along and understand the state of the world the project took place in. Be succinct, and get into the work as fast as possible. Mock presentations with people unfamiliar with your work can be useful here.

Explaining how the problem is interesting or important depends on the project. You might have analytics data to share, business needs that needed to be met, or customer frustrations that make this problem a particular priority to solve. Interviewers should understand the pain you’re addressing or opportunity you’re going after, and why it was the right problem to be tackling.

Context also means giving a brief statement of what the project is about, a timeline, your role, and who else worked on it. Here’s an example from one of my projects:

Project intro Very important: a one-liner project description

A slide like this will ground your audience and give some signal as to what you really did on the project and your experience with cross-functional collaboration.

Once you’ve set up the context, you’re ready to give your problem statement and the goals for the project. Here’s a format I’ve used:

Project intro Use a slide to clearly state your project’s goals

How you format and communicate this information is flexible, but should generally give interviewers an idea of what you set out to achieve by working on this project. When you lay out concrete goals here, you can refer back to them as you explain the rationale for your decisions throughout the presentation.

  1. What did you do about it?

Now, you show the work. I’ve found the most success with embedding my Figma prototype of the designs directly into the presentation so I can click through and give voiceover on the outcome. For product design interviews, I don’t think still snapshots of designs will cut it. The more you can interactively demonstrate your designs, the better interviewers can evaluate your interaction and experience design skills. Even better is pulling up a live product to click through, if you have access to it.

Focus on walking through a few major flows and explaining what’s happening as you go. I use a navigational element on the side of the prototype to quickly access other flows that I’ve put together, which can be useful for jumping between flows and showing as much of the project as possible.

Project prototype Interactive prototypes make your work easier to evaluate

I’ve heard feedback from some interviewers that having an interactive prototype to play with after the presentation was very helpful when filling out their scorecards. I’ll get more into scorecards a bit later.

Your focus should be on telling the story of the experience and how it’s responding to the user needs and project goals you’ve already laid out, while demonstrating various aspects of your design skills and creativity.

  1. What happened afterwards?

Here’s your chance to share how this product measured up to its stated goals. Did you impact the desired metrics? Did customer feedback change? If available, you can show visualizations of key metrics, screenshots of customer feedback, or anything that helps close the loop on what happened to the state of the world as a result of the work. Not everything needs to be a data point; qualitative results are great to share too.

Project results Tie your results back to the stated project goals!

  1. What did it take to get there?

This is where you talk about the design process – only after you’ve shown the product and its results. More on the sharing the design process in the next section.

Sharing your process

The most common issue I saw in interviews was designers presenting their process before ever showing the final product.

In my own experience, an applicant’s design process is useful to understand but never terribly interesting. If you lead with the design process, I’m left wondering: okay, so what? What did you actually make?

Instead, I like to treat the process more like an appendix. I have a good amount of slides summarizing the pivotal moments of the process and the artifacts from along the way, and I’ll brush through them after walking through the product prototype. But they’re not incredibly in-depth and are meant more as slides that I can pull up while answering questions about the project. Here’s an example: when asked more about what sort of discovery research occurred, I can pull up this slide and give more context:

Project process Example of a slide summarizing a design activity

I find that spending less time up front on context will give you more time on the final product, and if your interviewers are interested they’ll ask follow-up questions about the process that you can answer with visuals already in hand.

The portfolio scorecard

For any somewhat mature company, your interviewers will likely be grading your presentation on a defined scorecard. It’s useful to think a bit about what the interviewers’ experience is like so you can tailor your materials to that experience. For example, I assume a few things:

  1. Your interviewers haven’t had time to look at your website or resume

This is useful to think about while putting together the ’About me’ section of your presentation. You don’t need to give your life story – just enough to recap your experience and interests before jumping into case studies.

  1. Your interviewers are context switching or coming from back-to-back meetings

This assumption can help you think about how to present your work in a way that can be quickly understood by people with no prior context. Don’t assume your interviewers know or care as much about the problem space as you do.

  1. Your interviewers aren’t immediately filling out your scorecard after the interview

… which is a great argument for crafting your presentation as an artifact that can be left with the interviewers to reference later on.

I like to drop a link to the Figma prototype in the Zoom chat at the top of the presentation so that folks can click through it on their own and reference it while writing their scorecards. This is also an argument for hitting a sweet spot of information density on your slides – giving just enough explanations in text that it can stand on its own as a readable document.

As an interviewer, I can click through and refresh my memory while writing my scorecard, which is especially helpful when I don’t have time to write the review directly after the interview.

Get started with a Figma Community template

I would strongly recommend assembling your presentation in Figma. Being able to share the deck with just a link is a huge advantage over using something like Keynote, and you can embed your prototypes right into the presentation.

To help you get started, I’ve put together a free Figma Community workbook + kit! The template includes some starters for your background section, your projects, and your process, as well as a workbook style exercise to decide on what you’ll be presenting on.

Download on Figma Community