Navigating the Portfolio Presentation, Part 2: Recommended Format
Unpacking what you should cover in your portfolio presentation.
Hey there! I’m Nicole, and I’m a product designer. I write this newsletter to share my experiences and lessons learned through my work as a product designer.
This is the second article in a multi-part series on navigating the portfolio presentation. In the last article, we covered an overview of the portfolio presentation and how to approach and manage your own presentation. In this article, we’ll focus on what your session will look like and what information you should include in your presentation. 👇
What to expect in your session
Your portfolio presentation will usually be scheduled for a full hour. That hour will break down as follows:
(~5 minutes) Introductions, waiting for people to arrive, and setting up. Your host (usually the hiring manager) will kick off the session with a few words to tee you up for your presentation. This will usually include brief introductions of the people in the room and what the format of the session will be.
(45 minutes) Your presentation. The rest of this article will cover how you should spend this time!
(10-15 minutes) Q&A from the audience. Your audience will take notes throughout your presentation and will ask any questions they had during this portion.
The duration allotted for your presentation might seem like a lot of time to fill. In reality, you’ll have to cover a lot of ground:
An introduction of yourself
Overview of your current role/company
A walkthrough of 1-2 projects
Closing remarks
Below, I’ll unpack each of these points in depth. And to help you understand what these points actually look like in application, I’ve also included personal examples of what I covered within my own presentation. That way, you can identify both the guiding ideas plus what those ideas might look like for your own presentation. Let’s take a look!
Recommended format
1. Your introduction
Starting off your presentation with a warm, enthusiastic introduction of yourself is a great way to hook your audience early on. If they can see your personality and feel like they can relate to you, whether through shared interests, hobbies, or similarities in your background, they’ll feel more invested in paying attention to the rest of your presentation — and giving you a positive response afterwards!
Your introduction is your first and best opportunity to infuse your personality into your presentation, while also covering important professional context about you. To do this, I recommend covering the following:
Your name, title/role, and where you’re located. This will be similar to your elevator pitch, in that you’ll want to establish preliminary, baseline information about yourself up front.
Hobbies, passions, and interests. Before diving into your professional background, you can mention more about your interests and what you like to do for fun. (If you’ve found any shared interests with members of your audience from the research we discussed in the first part of this series, those would be good to include!)
Your work experience and career history. Briefly cover your current role and last few roles to help the audience understand your background. Usually, this is also a good opportunity to touch on how you got into design — if you studied it in school, if you’re self-taught, if you pivoted from a different career path, etc. Designers come from all different backgrounds, so your audience might also be able to relate to this.
(Optional) Your design principles. Describing your approach to your work, in whatever way feels authentic to you, helps your audience better understand what kind of designer and team player you are. These could be specific to your design process or they could be about your approach to collaboration.
There’s a lot of information you could potentially include for each of these points, but your introduction should be the briefest part of your presentation. As such, I recommend including a format of three’s: mention three subpoints within each of these points. You can see what I mean in the example included below.
Example
For my presentation, I broke out the information as follows:
On my cover slide, I included my name, title/role, and where I’m located. When I loaded up my presentation, I thanked everyone for their attendance and moved into my introduction slides.
On my first slide, I included three points: 1) my current role, 2) my interest in design mentorship, and 3) my hobby as a 3D artist. By covering my interests both in product design (mentorship) and outside thereof (3D art), I covered a fuller picture of who I am. Addressing my current role and company helped me segue into the next slide.
On the following slide, I covered my work experience. I had my last three design roles listed and talked through my career progression chronologically — how I started as a graphic designer and illustrator, moved into visual design, and eventually landed in product design. Briefly talking about each of the companies I worked for in addition to where I currently worked also created context for the section following the introduction (the overview of my current role/company).
On the last slide of this section, I covered my design principles. I talked through three values that represented my approach to my work — one covering my design philosophy, one on my collaboration mentality, and one touching on both. I used visuals to illustrate specific examples of how those manifested in my product design work.
2. Overview of your current role/company
Your team, company, and product area all contribute to what your product design work looks like. By taking a few minutes to explain this to your audience, you’ll set them up to better understand your case study walkthroughs.
To provide a holistic overview, I recommend covering the following:
A high-level explanation of the company you work for. Similar to what you might mention in your elevator pitch, this could be the company’s mission statement, summarized in a way that helps the audience understand what the company does and how it monetizes its products/services.
(Optional) Overview of product ecosystem. If you work for a company that has multiple product offerings, it’s also worth describing them briefly in this section. This can show your audience the full scope of products you’ve worked with, interacted with, or have to consider when designing.
The users whom your company serves. Including this as part of the company overview will educate your audience about whom you’re designing for. I recommend including any level of detail that will paint a vivid picture of your users, like including high-level data points or a description of the ideal customer.
(Optional) How the users differ across products. To the same point above, if your company has various product offerings, you can indicate how the users might differ across the ecosystem. Specifically, if there’s business users (in a B2B model) versus consumer users (in a B2C model), highlighting this will show your audience that you have experience of designing for both groups.
Whether you’re at a startup or you’re coming from a well-known, established company, this section builds shared understanding with the group about what your scope of work looks like. It sets up your case studies for success, as your audience will be better equipped to understand the nuances of your work and how your projects might fit into the bigger picture.
Example
For my presentation, I included more visuals than text in this section. Particularly for the high-level explanation of the company, I found it more compelling to include mockups of the company’s main products. I talked through the company’s mission statement while showing those visuals, so the audience could see and hear what the company I worked for was focused on. Also, because the company was a small startup in a non-tech field, showing product visuals reinforced some of the credibility around my work.
The company also had an ecosystem of B2C and B2B products, so I had separate slides to showcase the full breadth of products within each of those realms. I mapped products to which part of the user journey they fell into, so that the audience could understand how each product supported the overall B2C or B2B missions. As an added detail, I also annotated which products I’d worked on, so they could also see how I’ve worked across the ecosystem.
3. Walkthrough of 1-2 projects
Choosing projects
Your audience will want to hear about one or two projects that you had an important role in. Ideally, these are projects that you led or worked on as the primary designer. (It’s important to note that even if you’re given the option to cover one or two projects, I’d recommend covering two. It’ll diversify your chances of including topics that are important to the audience, and will show a fuller breadth of your work and skills.)
There are different approaches for choosing which projects you should cover. You might only have two strong projects under your belt, in which case it’s straightforward to go with both of those. But if you have options, I recommend choosing projects that are different in some way: maybe one is focused on a problem your team wanted to solve, while the other one is on an opportunity your team wanted to pursue. By choosing two different projects like this, you can showcase a broader range of skills and abilities as a designer.
The trickiest part about telling the story behind your projects is forming it into a linear narrative. As a starting point, you can reference the below diagram — though this is by no means all-inclusive, so you should explore deviating from this depending on what will work best for your own projects.
View the full diagram (and duplicate it for your own use) on FigJam here.
This recommended format is broken into different sections: context, design artifacts, and the tail-end of the design process. Within each of these sections, there are topics included that you should consider touching upon in some way in your own presentation. Again, this doesn’t need to be treated as a hard-and-fast rule for what you need to include, but it provides an overview of options you should consider including.
Throughout your walkthrough — within each of these points and across the different sections — one of the main threads you should reinforce is collaboration. How you collaborate with others and who you collaborated with will be some of the most important aspects of your case study walkthroughs. Your audience will want to understand who you worked with, how you worked effectively with them, and how you leveraged collaboration to make the full project successful.
Let’s take a closer look at each of these sections.
What to cover in your projects
The information you include doesn’t need to be exactly the same for both projects; in fact, you should tailor the content to the story about the project you’d like to tell. But to tell a linear, clear narrative, I recommend hitting the following points in some way:
Context
Telling the background story behind your project will help your audience understand how this project came to be: why it was important and therefore why you worked on it. This also shows your audience that you have an understanding of the bigger picture, which is critically important for product design roles. To do that, consider including the following details:
Introduction. What is the product called? What was your role? What was the timeline? Who did you work with; what did the team look like?
Context about the product, team, or company. Products can range from tools intended for general audiences to tools designed for highly unique, expert, or niche users. If you feel like your audience would benefit from additional explanation, provide them with this at the start, so they can use that to contextualize and understand the rest of your presentation; without it, they might be confused.
If you can explain the product through an example that your audience will understand, that could be the most concise way to convey what the product does. More on that below.
Constraints. Were there any obstacles — if so, what were they? Identify any factors, whether internal (specific to your team or company) or external (due to macro trends in the industry, etc.), that had an impact on your scope of work. This could also be covered or reiterated in the next section on visual artifacts, like if you chose an approach due to limitations in research.
As you’re telling the story behind your project, you can naturally conclude this section with the problem definition. Your problem definition doesn’t have to be anything fancy or formal, but it should clearly outline what you were trying to solve. An additional angle to consider with that is:
The problem or opportunity. What were you trying to solve or pursue? Why was it important to your team and the larger business? How was it prioritized? How did you know this was the right problem or opportunity to prioritize? What research or data did you have to back this up? How was the problem defined?
Asking yourself each of these questions can help you workshop a concise, specific problem definition. This exercise is especially helpful if you weren’t provided a problem definition at the start of your project, or if the problem was initially unclear.
Example
For one of my presentations, I shared a project focused on designing a price estimator tool for car repairs.
For context, I explained what the product does, in terms my audience could understand and personally relate to. I used a few examples of common car repairs along with their prices, to show the audience how the tool works at a glance.
I also explained the product’s history: how I was the first dedicated designer on the product area, and we didn’t have much research or history of the product to start with. I explained how because of that, I wanted to lead a larger research effort to both inform this design project and the product’s future roadmap. That explanation provided valuable context, as my next section was digging into the research that we did as part of the design process.
Lastly, I defined the problem. I showed data visualizations to illustrate how prevalent the problem was with users. I also incorporated other data points like internal feedback, technical debt, and other factors that contributed to the product’s issues. I found it helpful to back up the problem definition by triangulating these various sources, showing my audience that I was considering multiple factors in my approach.
Design artifacts
While the other criteria that your audience is looking for might depend on the role and company, your visual craft will always be on the evaluation rubric.
Your audience will want to see a variety of visual artifacts, from low-fidelity wireframes to high-fidelity mockups. The full set of visuals you’ll want to consider including are:
User research artifacts (research findings, user quotes, data visualizations, etc.)
Sketches
Wireframes
Prototypes
High-fidelity mockups
The main point of showing these visual artifacts is to show how you workshopped your designs to get to the final results. You should take your audience through each step, so they can see how the solution came to be.
Because there’s a lot to show, you can be creative with how you present these. I’d recommend a few guiding points:
Clean up your designs. Even if you’re showing sketches or wireframes, you should still consider polishing them up, so your audience can understand at a glance what they’re looking at. Your visuals will only be shown for a few seconds or minutes throughout your presentation as you talk through them, so the easier you can make it for your audience to grasp what the visual is conveying, the better.
Show alternative iterations, including ones that weren’t selected. Good design is a process of iteration and refinement. To tell the full story behind your visuals, you should communicate how and why you landed on the final designs. Therefore, you should include any iterations you tried, trade-offs of the designs you were considering or evaluating, and why you ended up at the final result.
Consider the delivery. Could something be better shown through an animated gif of the prototype as you talk through it, so you don’t have to switch to a separate tab or screen to show the actual prototype? Could you dedicate an entire slide to the high-fidelity mockups without any accompanying text, so your audience can see the visuals big and clearly? Creating a smooth delivery of your visual artifacts is an important part of helping your audience see the details in addition to seeing how those visuals fit together.
Incorporate variety. Use different mediums like gifs or short videos to illustrate your points, and use different kinds of visuals to communicate. For example, show a data visualization to convey the users’ sentiment rather than just explaining it through text. Play around with the layout to keep things interesting, while balancing it with your content and overall story.
Example
My aforementioned case study of the price estimator tool was extensive. I remember covering too much in my initial draft of my presentation, and then I had to scale it back massively in order to fit into the time requirement. I found a good middle ground by including a few visuals that showed the breadth of design work I did, while also focusing more deeply on three important design decisions that I made for the user experience.
With each of these “design decision deep-dives,” I included the low-fidelity, high-fidelity visuals, and final designs. I walked the audience through what I was trying to solve with each of those design decisions: what idea I started with, how I iterated on it (and what those iterations looked like), and what the final result was (demonstrated through a gif prototype). I found this to be a helpful way of packaging all my visuals into a story that both showed my visual craft while also communicated how I made decisions and what my considerations were.
Tail-end of design process
For lack of a better name, we’ll refer to this remainder of topics as the tail-end of the design process. Certain roles and teams will place more emphasis on this section than others, so it’s important to cover it regardless. By doing so, you’ll show that you’ve managed the full design process end-to-end, and that you have experience working in a full product development workflow.
This section should include:
Testing. How did you test your designs with users: what were you looking for, and what did you define as success? How did you ensure that the designs were usable and intuitive? If you didn’t do evaluative testing, how else did you evaluate your designs to make sure they were the right solution and would be usable?
Developer handoff and support. Hopefully, you worked with the engineering team throughout the full design process and not just when you “handed off” the designs. But this portion is an opportunity where you can dive deeper into what that collaboration looked like — how you communicated the design and UX goals, what technical considerations or discussions came up, etc.
Go-to-market. Whether you shipped the product to a small subset of users to start with or it was launched through an AB test, you can explain what the strategy looked like for getting your design solution into the hands of actual users.
Success metrics and business impact. Ending your case study with this helps to close the loop around how your solution actually performed. Did it solve the problem(s) you had initially set out to solve? If so, how did you measure the success? What did you learn from the project? Showing data visuals in this section, if possible, can close the loop on any data that you presented earlier in your presentation.
If your solution wasn’t successful in the goals you set out to achieve, explain why. Projects not going according to plan is sometimes an unfortunate reality of our field, but you can still focus on the positives of the situation — what you and the team learned and how this project might have positively impacted other areas. Those takeaways can be just as important as success metrics, if you can apply them as such.
(Optional) Iterative improvements you or the team would like to make. Since products are never fully done, you can end with a slide on what additional features, changes, or other improvements you’ve recognized after this project. This can show your audience that you’re thinking ahead about the product’s potential and roadmap.
Example
To close out my case study, I went through each of these bullets as listed above in a linear fashion. This section was relatively faster than the previous ones, but I called out specific takeaways I had to show what I learned or found interesting in each step: how I tried out different approaches for working with engineers, how we implemented new technologies, how I created an asynchronous demo for product marketing, what metrics we tracked to evaluate success, and how we were now thinking ahead on building out the product’s feature set.
4. Closing remarks
After you’ve finished the walkthroughs of both of your case studies, you can start to close out your presentation. This concluding section can be brief, but it signals to the audience that you’re wrapping up; and with that cue, they can start preparing their comments and questions.
For the closing remarks, I’d recommend expressing a few words of appreciation to your audience for their time. You can include a slide with your name, website, and any other details like your LinkedIn or email in case they’d like to look you up or reach out. Then, you can end by opening it up for any questions from the audience.
As evidenced by all the points to include in your portfolio presentation, it’ll take time to figure out what details are most relevant to your projects and the role you’re interviewing for. However, this format can serve as a launching off point if you aren’t sure where to start, or if you’re worried about not including all the potential criteria that your audience might be looking for — because there’s a lot!
In the next part of this series, we’ll be covering how to practice and deliver your presentation so you can let your material shine — showing how much time, effort, and thought you’ve put into crafting your presentation.
Good luck! 🙌
I hope you found this newsletter helpful! If you’re interested in reading more, subscribe here for free and share it with a friend. You can also find me on Twitter (@wontonface).
If you have a topic idea or request you’d like me to cover, submit it here.
Hi Nicole, can you help me with a link to the third part of the series.