Set useful context
A portfolio presentation should feel like telling a story. Introduce the characters (you), the environment (your organization, team, problem space), and the conflict (the problems you worked on).
Keep it short. Mention:
- Who you are and how you got here
- What kinds of problems you've worked on
- Notable accomplishments and side projects
Nobody knows your company as well as you. Set context about your organization:
- Who your customers are
- How the business makes money
- Where you sit in the broader organization
Explain how you identify problems
Don't start with "So we wanted to improve onboarding, and here's what we made." That skips too many steps.
Answer the real questions:
- What was wrong? How did you know?
- What did data or research suggest?
- Why did the company choose this problem over others?
- How did the team agree on success metrics?
How designers identify and prioritize problems is often more important than the artifacts they ship.
Define constraints and tradeoffs
Be prepared with stories about navigating difficult tradeoffs. Interviewers want to know:
- How do you think about risks and dependencies?
- How do you overcome constraints customers don't care about?
- How do you navigate organizational headwinds?
The protagonist in every great story faces obstacles and must sacrifice or be creative to win.
Show how the work evolved
Bring interviewers along for the ride. Show artifacts from each phase with clear articulations of what was useful, what didn't work, and how feedback informed the next iteration.
Talk about ideas that did not work. This is gold.
Show the final artifacts
When possible, show a live final product. If not, share high-fidelity prototypes with realistic data. No lorem ipsum.
For senior roles, this artifact will be calibrated against your prototypes. The more senior the designer, the more the final shipped product should reflect what was designed.
Explain the outcomes
Did you solve the problem? Yes or no. Now explain.
Talk about quantitative and qualitative outcomes. Map them back to the original problem context. Include customer quotes, charts, numbers—anything that proves you own outcomes and use them to guide decisions.
Bonus: Show what you would have tried next, given another shot.
Be clear about your contributions
Be honest about your direct contributions. It's easy to spot someone taking undeserved credit. Great designers know that software development is a team sport—give praise as well as you take credit.