How to put up the right UX Design Portfolio for your Dream Job - Part 2

May 5, 2020

Career, Design, Work

Is there an ultimate formula for what makes a great UX portfolio? I’m not sure. But I believe that UX portfolios differ based on the target audience and projects. Hence, I’ll share my perspective on the primary stuff that makes a great UX portfolio based on my experience, conversations with some senior designer friends who interview designers for the UX Design role, research, and the portfolio that got me my dream job. So, let’s dive straight in.

If you’ve not read the part one of this series, here you go: How to put up the right UX Design Portfolio for your Dream Job - Part 1

What makes a great UX Portfolio?

Relevant & contextual projects

It can be tempting to put up all the good stuff. Designers love to show their best work. Why not? But bear in mind that recruiters won’t have all the time to look at every project on your portfolio. 1 to 3 projects are okay. Pick projects that are relevant to the company; As I mentioned in the part 1 of this article, knowing your potential employer is key.

Is your employer a data-driven company? Include projects that highlight your use of data to make design decisions. Is the company you are applying to about people and collaboration? Include projects that tell a story of how you collaborated with people to build something. Does the company care about visuals and design aesthetics? Include projects that highlight your visual design skills.

The small wins

A common theme in most portfolios are full-blown designs and redesigns. That’s great! Designers love to design from a product/app idea to finish. If you are applying to a big company, it’s likely that teams are distributed to different parts of the experience or product funnel. Most companies, and especially established ones already have a viable product, and when you eventually join, you might find yourself working on a tiny bit of the product, and might not be designing anything from scratch anytime soon.

If you’ve worked on a feature that improved user experience or, a tiny but clever product improvement that impacted metrics, that’s okay to have as a project in your portfolio. Good companies care about small, incremental wins. Keep this in mind when outlining what projects to include in your portfolio.

Simplicity

My portfolio was bullet points, as I mentioned in part 1 of this article. I’m someone who likes to write long articles and stories, but understanding what recruiters want to see — “key highlights”, helped me narrow down my story to bullet points. Recruiters/interviewers are bombarded with applications and portfolios and as such, have lots of work to do. Chances that they will read your 20 minutes project story are slim. In the interview, you will be asked questions. I’ll choose to anticipate questions and prepare for them instead of writing a long story. Keep your story simple and concise.

A compelling story

I’ve seen and reviewed design portfolios, and in some cases, there’s barely any context. It’s just images, mockups, links to prototypes, or the product. It isn’t surprising; we designers often think visually. Sometimes, it can be challenging to convince people that what we do is much more than beautifully arranging text, rectangles, and images. That an app, digital product or website isn’t the outcome of our work, but rather a means for people to meet a need or desire in the real world in which our work is the intentional decisions we make by connecting the dots through these digital mediums to create and enhance experiences, and thereby giving people stories to tell.

Hence, our portfolio should be a story of the conscious and informed decisions we made to create experiences that impact people’s lives and grow businesses. It should tell a story of our learnings, our trials, our failures, and our wins.

Starting each project with context

Most compelling stories start with chaos and end with a resolution, but also starts with establishing context. Movies are great examples. One big part of the story is to unveil the characters in the movie. How would you understand a movie if you have no clue who the characters are, their behaviours, motivations, etc; and how it extends to the role they play? Likewise, in your portfolio, you want to introduce your projects by first, establishing context.

About yourself

You probably want to start your portfolio with an introduction of who you are. In my case, I highlighted what drives me as a person and also as a designer, my experience with people, design, research, and technology. I also highlighted my values, my hobbies, and what I do in my current role. You might want to include skills or specialties like writing if you write, speaker if you speak at events or conferences, etc.

Sometimes, it can be challenging to write about yourself, but researching and understanding your potential employer or client might inspire you. It is up to you how you write about yourself. In essence, It’s about being sincere, self-aware, and writing you. Remember, keep it short and concise.

Project overview

Each project should start with a name; you can choose to start with a GIF if you want to. It’s okay to add fun and memorable details to your portfolio, but here are some examples for outlining a project overview:

• Project/product/company name and, or description.

• Project type — Example: web app, mobile app, b2b, etc.

• Year/date.

• Results — relevant metrics or outcome.

• Feature image.

Every project has its nuance, and project overviews can come with varying details. It’s up to you to use your judgment.

Your role & responsibilities

The end product of our work as UX Designers is one that involves other roles or specialties such as research, product management, engineering, and a bunch of other roles depending on the project or company. Sometimes, we might find ourselves involved in some of these roles. I love being involved in the research and discovery phase of a problem, and I’ve always been involved in the front-end implementation of some of my designs. Were you involved in research, leading the team, defining requirements, data analysis, etc? Including it in your project context.

Explicitly stating what you were involved in for each project featured on your portfolio will help give interviewers a better context, understand your strengths, and help them digest your story smoothly.

The Why (the problem, the challenge)

Why this project? Why did it need your input as a designer? Why did the company or stakeholder(s) invest in it? Why are you involved? Why should the world care? Why is this problem relevant to the business, company, or stakeholder(s)?

Since writing part one of this article, I’ve gotten a lot of portfolio review requests, and have reviewed 22 portfolios. Designers like to talk about user problems in portfolios without any context to how the problem impacts the business, or the business opportunities that make the problem worth investing in. Yes, they call us User Experience Designers, but when a company is hiring a UX Designer, they are making a business investment. When articulating your problem statements or why the project needed a UX Designer, be sure to articulate why the problem is relevant for people and also for the business.

In essence, your why is the guiding light to the story you tell. Establishing a compelling reason why you were involved as a designer is the anchor for recruiters to hold on to as you show and tell your work.

A problem backed with evidence

Knowing what problems are worth solving is hard; solutions are easy. A good problem statement is one that is backed with evidence of why the problem and investment are worth the time and effort.

Good practice in the design process is gathering evidence to understand the problem. This could be quantitative data analysis, user feedback, user behaviours, metrics, competitor analysis, interviews, heuristic reviews, dogfooding, etc. Your why should always be backed by one or more of these and should tie back to the business’ bottom line.

Putting people in the center of your story

A vital part of designing anything is understanding the people you are designing for. While data about the problem is great, designers must also have data/knowledge about the people they are designing for — who they are, their behaviours, motivations, possibly their daily lives, how they influence the market or industry, perhaps the different groups inside the audience that has different needs, and all you can ever know about your audience. Usually, this part is shown on portfolios as personas, empathy maps, etc. In my portfolio, I did not add diagrams but had two bullet points that highlighted my understanding of the people I was designing for. This is up to you to choose how you present this information on your portfolio.

In essence, the goal is to show and tell your understanding of the people you designed something for, and how that knowledge influenced your design decisions.

A well-defined goal or hypothesis

Now that you’ve made the problem clear and showed your understanding of the people you designed for, stating the project’s goal will make much sense. I’ve reviewed portfolios where the goal was the first thing that was stated before the problem. This might not be wrong, but I think a project’s goal will be easier to understand after context is given by first outlining the why.

You want to state the goal of the project in one or two short and concise sentences, clearly articulating both the business and user goals. The outcome(s) you want or expect. You might want to state a hypothesis at this point — based on evidence X, we will do Y, and hope to get result Z.

How you got there (solving the problem)

Every designer and design has a slightly or largely different process. But here you want to articulate what you were responsible for, your thought process, your understanding of the domain you are designing for, how you collaborated with relevant stakeholders, the decisions you made and why, your assumptions, the opportunities you spotted, questions you asked that brought clarity, the concepts explored, methods employed, the barriers and constraints you faced, trade-offs, and your overall influence on the project and how it all shaped the outcome of the project.

This is where the story peaks, and you want to demonstrate your ability to communicate concisely with words and thoughtful explanations that tie back to the problems you were trying to solve.

On a side note, one thing I’ve learned the hard way is to document/journal what happened every day I participate in a design endeavour — the things we did as a team, my contribution, photographs of collaborative sessions, sketches, white-boardings, etc. This will go a long way in helping you write your portfolio story when the time comes because as humans, we are likely to forget stuff.

How you tested and validated your ideas or solutions

Good companies will look out for this trait (testing and validating ideas) when reading about your process. Bad designers assume the first idea or solution will solve the problem without any form of validation. Sometimes you could be lucky. I work at a company where every design change we make to our products is validated through A/B testing, and believe it or not; your designs will fail 9 out of 10 times.

As you write your process, you want to highlight how you or the team decided to validate solutions or ideas — the results, feedback, metric, or behaviors you expected, the group of audience you tested with, the type of testing used, tools, your definition of success and failure, and what was done afterwards.

Again, each project comes with its nuance. The overall goal is to show your awareness that ideas and designs are only intentional guesses until proven otherwise.

The solution(s)

Here, you want to show and tell the outcome of the process — what solution(s) were arrived at, and why. It’s also good to mention concepts that failed and why; what you learned from it and how it got you to the final solution. Keep in mind that iterations are key parts of problem-solving, and no one expects that you get it right the first time.

As you show and tell the solutions (mockups, designs, screens, etc.), explain the design thinking behind them. If you have interactive prototypes or links to the product or app, definitely include them in your portfolio.

Implementation

I like to be involved in the implementation decision from the onset. Outline the technical choices deliberately made to build a better product, the technical challenges faced, and how it was navigated. Again, this might vary depending on the project or conditions around a project. If you were involved in the implementation or technical decisions, it’s safe to include it in your portfolio.

Results & Impact

I see this left out in portfolios. But this is the outcome of your work, not mockups, prototypes, or even an app in the app store. You want to tell the impact of your work in the real world. What happened after the solution was shipped? How was your design validated? What metrics or business goals were impacted? How did your audience receive it? What did you learn?

Your learnings

A big part of our job as designers is learning. You want to show this mindset in your portfolio. Reflect on what went well, what didn’t, what you’d do differently, what you learned, and how the project has made you a better designer.

Conclusion

Like I mentioned at the beginning of this post, there is no perfect formula for what makes a great portfolio. Not every project must have all the details outlined in this article. The trick is to treat your portfolio like a design project and applying storytelling to showcasing your work.