The easiest way to tell a good story in portfolio review

Cyborg by Alena Kosareva

“You need to improve your storytelling skills.”

“You need to define problems better.”

“You need to make sure they understand your projects.”

As UX designers, we probably heard some of those comments before but not clear about “how”. How can we include all the good things in my portfolio deck? There are definitely multiple ways to tell a good story. But after seeing and trying all the options, I found the easiest way to tell a good story that can fit most projects. Also, it includes all the good stuffs you want the interviewers to know.

First and foremost, let’s understand your interviewers deeply:

1. They are human: their attentions are short. Your portfolio deck is better to be a flat and clean structure so that they can immediately understand your projects.
2. They are designers or design managers: they must be attracted by design problems and challenges. We got problems everyday. I’ve never seen a designer doesn’t like problems. When you present your work, you need to define problems first clearly so that they understand what you’re trying to solve.
3. They are evaluating you for their companies: so they need to understand what you have done and take notes about all the great jobs you have done. Your presentation should be easy to digest and have good details that they can take notes.

But how? Let’s deep dive!

1. The skeleton: the easiest structure to tell your story

Design project varies by companies and products. But I found the best way is to start with problems. Here is a structure I would use to present my work to strangers:

Agenda — Give interviewers an expectation about what you are going to say. So that they can be ready to take notes.

Context — A quick intro about:

1. The product: What does it solve or achieve
2. The project: Who you worked with? How long did you take? What’s the scope?

How might we — Introduce 3 problems you solved. Always start with problems. Because your interviewers are problem-solvers too — they are driven by problems naturally.

Closing — Impact or reflection, or any closing words.

2. To start: defining the “problem” well

First, why do I suggest to start with problem statement? Instead of challenges or the feature name? For challenges, interviewers need context to understand. That context is the problem. If you start with feature name, interviewers might not familiar with the feature at all. It takes time for them to fully understand a feature. The first question they saw a feature is “What are problems this feature is trying to solve?”

So why don’t we start with problems?

What is a good definition of a problem? Let’s see some examples:

Some bad ones:

How might we make this button clear for users to understand

• Too small and too detailed. Why is it critical to make a button easy to understand? What users are trying to achieve?

How might we make this experience easy and friendly for users

• Too broad. What experience specifically? Who are your users?

How might we make the onboarding flow easy to go thru

• Too design-related. Why does users need to go thru this onboarding flow?

Better ones:

How might we make the complicated product easy to onboard for business expertise so that they can get their jobs done quickly?

• Clarify the challenge, the users, and what they are trying to achieve.

How might we make the browsing experience easier to digest so that customers can shop with confidence?

• Describe the experience you are trying to improve, who are the users and what they need to improve your business.

How might we integrate a note-taking experience while users are in online meetings?

• Describe the experience you are trying to invent, the complicated scenario: people are in meetings and they need to take notes.

Remember the goal of defining problem is to stimulate empathy from your interviewers, so that they are curious about your work, they can think with you together, and they can understand your problem-solving skills. Thus, a good “how might we” could include these elements:

• What’re user goals?
• What are the design challenges you are facing?
• Why is it important for users?

3. To fulfill your story: prioritizing your content

Now you get a good story to start with HMW. How to talk about this HMW so that interviewers can understand how you solved the problem?

I know everyone got a lot to say! You’ve done millions of explorations and discussions to land on the final design. Here is a good way to think about this: according to Julie Zhuo’s article about Junior designer VS Senior designer, this is how we solve a problem in a more organized way:

Image from Julie Zhuo’s article Junior Designers vs. Senior Designers

We know you tried lots of ways at the beginning. But you probably spent more time on one path because of a couple of reasons. Making sure to spend more time to explain the right path. So your interviewers can understand how you made choices and why.

Interviewers are more curious about how you make choices

Here is a good way to explain:

1. Briefly talk about routes you tried, how you evaluated, and why they failed — but don’t spend too much time on why things didn’t work. Because nobody cares about a wrong path. Just to give clear statement why they didn’t work.
2. Talk about the final version. Why it worked for your users?
3. Pick 1 or 2 challenges you faced. It could be challenges from engineers, from PMs, from your leadership, from the complexity of the project, or from your users. How did you overcome the challenge?
4. Final results. Does everyone agree with you? Do your users happy with it?

Don’t:

1. Don’t tell too much details, edge cases, too many stories if they are not super important — You can put them in appendix. Don’t be afraid to be asked about details. Just tell them confidently why you designed in this way.

Some myths:

“ They said they wanted to hear about my design process.”

You’re talking about your design process using examples in each HMW! We all know double-diamond, Lean UX, etc. We just need real project examples😄

“They said they wanted to know the challenges.”

Blend your challenges under each HMW story. Your interviewers will understand challenges you faced better with real examples.

“They said they wanted to hear any research I did.”

Research is not a process you must do. We just need to understand in what situation, you need research, and how you did research briefly. So again, putting research under each HMW so we can understand how you learn from research and what design or product decisions you made because of the research.

Final words

Now you have the skeleton, the starting HMW, and the meat for your stories, I’m sure 99% of your interviewers can understand how awesome you are.😃 Let me know your thoughts on telling a good story!