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

Photo by Chastagner Thierry on Unsplash

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

Designers love to say they are problem solvers, but saying that discounts a lot of your hard work around framing problems.

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).

A sample “Before and After” screenshot

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:

1. Ask your manager for an Analytics account

2. Find the date when your design changes went live

3. 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.