How to lay out your design portfolio to make your work stand out
Defining Goals, Problems, and Solutions help interviewers evaluate your portfolio in favorable terms

When I helped my organization hire a new designer, I was shocked at how many design portfolios went wrong at the first step.
Iโm not a hiring manager and donโt have access to all the criteria for specific design positions. Still, I noticed several designers make a critical mistake: they donโt define how they want their portfolios to be evaluated.
They either follow a linear process, which raises red flags, or donโt do enough to clearly explain a project's Goal, Problem, and Solution, often forcing them to be evaluated using visuals.
Laying out your progress and the problem youโre trying to solve (and how you solved it) is critical in conveying that you know how to work as a designer.
Hereโs why thatโs important.
The first mistake designers make is failing to frame the problem
In my experience, design problems are messy and complex. Even if the design solution is obvious, you may work with team members who reject that or are unfamiliar with it.
The first mistake I see many designers make is jumping directly into โproblem-solvingโ without taking the time to talk about two key things:
Why does this problem matter?
What were you trying to do without over-explaining context?
I learned this the hard way, since my first design project was very niche. I worked in a specialized field, Healthcare UX, and designed a gesture-based interface to aid junior surgeons in Laparoscopic Cholecystectomies.
I lost out on many interviews as I bored recruiters with too much context about Laparoscopic surgery.
However, jumping straight into problem-solving mode by saying, โThe problem was that surgeons weren't communicating well in the operating room, and hereโs how I solved it,โ isnโt that helpful either.
I first needed to take a moment to address one thing: why does this matter? After all, if you canโt explain why this design project might matter to others, you donโt understand what you did.
When I considered this first question, I had my breakthrough: I can try to explain the demands and duties of a surgeon, but itโs far less effective to convey why this matters from the patient's perspective.
Even if your audience has never been a patient, they can easily understand why this project matters. When someoneโs under anesthesia, and their life is at risk, the last thing they want to imagine is being kept in surgery for an extra 30 minutes because surgeons are having arguments.
Hereโs how I framed my problem. I first started out with two sentences of context:
โLaparoscopic surgery is a technique that leads to faster patient recovery, but itโs tricky because surgeons arenโt looking directly at a patientโs organs: theyโre looking at a screen with a live camera feed. As a result, communication breakdowns can often occur with navigation, as phrases like โGo thereโ can mean next to nothing.
I then conclude by talking directly about the problem Iโm trying to address: โI needed to design an interface to help surgeons annotate the live camera feed to improve communication and help guide the surgery.โ
Framing the problem clearly and understandably is critical because the next two sections, Goal, and Solutions, depend heavily on a well-framed problem.
Clearly defined goals help people evaluate your work beyond visuals
If framing the problem correctly is how we convey why your work matters, defining the goal is crucial in getting people to understand what to evaluate you on.
Consider these two statements:
Company X asked me to design this, so I did
I was tasked with re-designing Product Yโs workflow because users werenโt engaging with it
The first statement says little else other than that you're following orders. I have no idea what the goal of this project is, and I have no way of evaluating it other than visually.
However, the second statement is much better at establishing your focus and how you should be evaluated. For example, if youโre re-designing a workflow, are you doing user research to uncover how users work and where things are going wrong?
If we look at the process you set up from start to finish, it should ideally spell out the steps you took to achieve this goal and (ideally) a way to measure success or failure.
You might have noticed that I included the metric of user engagement. Metrics like these help us evaluate our work, and a few UX metrics are easy to understand and relate well to business.
However, these metrics donโt always have to be business metrics. For example, in my laparoscopic surgery example, I might mention that these actions significantly reduced operating times and surgical errors.
These arenโt traditional metrics but are still ways to measure whether my design was effective, so interviewers can understand whether you succeeded.
Doing this is important because the last section, the Solution, is where Designers often screw up.
The solution is not just the visual change; itโs what happened
Designers tend to be somewhat bad at showing โSolutionsโ beyond pure visuals, and itโs (partially) not your fault.
Once you hand over your designs, you'll be immediately put on another project, and you might not have access to figure out if your design solution solved the problem.
This is why designers often use โBeforeโ and โAfterโ screenshots, but this approach has several issues (including hurting your portfolio).
Unless the change is drastic, it can be hard to know if youโve solved the problemโ, and putting such high emphasis on changed visuals leads to teams thinking that matters more than the design process.
I know real-world problems are messy, and solving them is never clear-cut. However, rephrasing your โSolutionโ question can help.
If you think of the Solution section as โHow did you solve (or make progress towards) the problem/goal that you stated?โ you should be able to find ways of doing this beyond showing visuals.
The first and most convincing is showing that you move the needle.
If you mentioned the goal of this project was adoption, and then, once your design changes were implemented, the adoption went up by 15%, thatโs the easiest thing to point to that will get organizations to hire you. That can be as easy as three steps:
Ask your manager for an Analytics account
Find the date when your design changes went live
Look at the โUser Adoptionโ section and see if itโs trending upwards.
However, if you donโt have something as clear-cut as that, we turn to what we defined in the Goal/Problem sections for clues for progress.
In my case, my gesture-based interface was never adopted into surgical environments. We wrote research papers, demoed the interface at a medical conference, and shelved it. However, I can still show progress towards the Goals/Problem sections.
For example, I might mention that on one of our final tests, a laparoscopic surgeon successfully used it during training, annotating live video and integrating it into their process. I might also mention how medical personnel used it and showed decreased task completion time at the conference.
You might mention how well the application tested in the later rounds of user testing, how stakeholders approved of the direction and even demoed it, or some other definitive measure of progress to show that you did add value.
You guide the conversation around your design portfolio
An interviewer often has hiring criteria you may or may not fit into, but that doesnโt mean you shouldnโt try to guide the conversation.
You are the one who knows the most about the work youโve done: taking the time to set the parameters that you want your design work to be evaluated on is often one of the most essential pieces.
If you fail to provide this, I (and other interviewers) will have to consider your work with our framework, which may not be in your favor.
So ensure that you spell out the Goals, Problems, and Solutions around your design work in a way thatโs simple and easy to follow.
Clarifying why your problem matters, your project's goal, and how you solved (or made progress) towards it may be the ticket to getting you the job you want.
Iโve revamped my Maven course to teach Data Informed Design. If you want to learn this valuable skill, consider joining the waitlist.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, The Resilient UX Professional, provides advice on how to find a design job and advance your design career.
Well said! I havenโt touched my portfolio in years and Iโm now in a management roleโฆcurrently noodling on the best way to tell my story, and appreciate your posts so much!