9 of the worst UX portfolio mistakes — and how to fix them

Mistake #1: Neglecting usability on your portfolio website


Christian Jensen

2 years ago | 16 min read

I were to evaluate you for a design role, I’d begin with your portfolio. That’s where I get the best impression of your skills, strengths, and weaknesses. It’s also where I’m able to quickly disqualify a lot of candidates.

Some are disqualified based on the quality of their work. Others — and this is the unfortunate part — are disqualified because of how their projects are presented.

I’ve now reviewed enough portfolios to know the most common mistakes you should strive to avoid when presenting your work.

Some of them might stop me before I even get to see the quality of your work or prevent me from giving you the credit you deserve for a well-executed project.

I recently wrote a similar article, but the list of mistakes has now grown to 9. I sincerely hope your portfolio is already flawless, but if it’s not, I hope my tips below will bring it a little closer!

Mistake #1: Neglecting usability on your portfolio website

For anyone working or aspiring to work in UX, designing for usability over aesthetics should be second nature. Yet, I sometimes find myself on a UX Designer’s website, struggling to find my way around.

The navigation doesn’t follow standard design patterns. It’s especially bad on mobile. Buttons don’t look like buttons, links don’t look like links. The font sizes are too small to meet standards for good readability, and they’re not helped by the low contrast ratios. Nor by the typos.

Why it’s a problem

How to prioritize and balance usability, creative expression, and experimentation will depend on the exact role you’re after and the people you’re targeting with your portfolio.

However, if you’re going for a UX job, with accessibility and ease-of-use as key objectives of everything you do, it should be reflected in your portfolio site.

If it’s not, I question your ability to meet these objectives and design for great user experiences and usability.

What to do instead

Treat your portfolio as any other Design project. Get clear on who it’s meant for and what they want to accomplish and experience on your site.

Make sure it’s easy for them to do so by following standard design-, navigation-, and labeling patterns.

Follow accessibility guidelines for font sizes, contrast ratios, accommodating color blindness, and so on. You could even run some usability tests and improve it accordingly.

Go meta by including the design of your portfolio site as a case study in your portfolio. This is a great way to gain experience and expand your portfolio as a new Designer, in addition to the side projects I always recommend.

Simon Pan’s portfolio is a great example of usability and simplicity.

Mistake #2: Showing subpar work to seem more experienced

If you’re new in the field, you probably won’t have enough projects under your belt to even be thinking about this. You barely have enough work to make a portfolio in the first place, let alone be selective about which projects to show.

However, you will run into the problem of showing subpar work sooner than you think. It happens in one of two ways:

  1. You have a ton of experience and too many projects to count.
  2. Your skills improve rapidly, week over week, month over month.

Number 2 applies to most new Designers. You learn and practice daily, evolve your process, expand your toolkit, and improve your eye for aesthetics.

The project you did last week might already make you cringe when looking at it. Showing that cringe-worthy piece of work might make you seem more experienced, but it comes at a cost…

Why it’s a problem

When I look at your portfolio, I try to form an opinion about your skills based on all your work. If I see both “good” and “bad” work, it makes me think that I can’t rely on you to consistently produce high-quality design.

Including a higher number of projects to seem more experienced will cause more harm than good, if those extra projects aren’t your best work.

You are the average of your case studies, and mediocre ones will drag you down.

Don’t get me wrong, we all do projects that aren’t necessarily as good as our last one. We all do work we’re not super proud of. The key is being able to recognize that work as such. If you include subpar work in your portfolio, I question your ability to tell good design from bad.

Furthermore, seeing 20 case studies in your portfolio is overwhelming. Where do you want me to begin? Which of these case studies is most relevant? Even if all 20 case studies are great, leaving your reader with a sense of “paradox of choice” is not desirable.

What to do instead

Think quality over quantity! Simply go through all the projects you’ve done and prioritize. Which ones are you most proud of? Which ones produced the best results? Which ones best highlight your skills?

I would much rather see a portfolio with just 3 great case studies, than a portfolio with 3 great and 7 mediocre ones. As a rule of thumb, aim for 3 to 6 case studies in your portfolio. Show the very best one first.

For a great example of this, check out the portfolio by Christina Richardson. She’s showcasing 3 case studies on her portfolio website, letting visitors know they can reach out for more samples.

Portfolio website by Christina Richardson

Mistake #3: Case studies without context

I sometimes come across a case study without any mentioning of the context in which it was carried out. I can’t tell if it was a school project, a freelance project, a corporate project, or a fourth option.

Why it’s a problem

I’m a big proponent of side projects and creative work of any kind that lets you practice your skills. However, there’s no denying that your unsolicited redesign is different than a corporate project. Or a freelance project. Or a school project.

And all those are different from each other. And the difference matters. The financial and business constraints can be different, the time pressure can be different, everything can be different depending on the context.

If you don’t explain the context in each case study, I’m missing some important information about the project and your experience.

I might even think you’re trying to hide something.

Do you in fact have real-world experience, or are all your projects imaginary app concepts designed in your spare time? Whatever you do, don’t try to sell your unsolicited redesign of Spotify as the real deal

What to do instead

Simply begin each case study by stating the context of the project. Let me know if you worked on the project at the 3rd semester of your bachelor program, or as a freelance project for a paying client.

You won’t be judged for either, but context matters.

Show that you understand how context matters by explaining how it impacted your project.

If it were a school project, perhaps you didn’t have to consider the market viability? Maybe you did an unsolicited redesign of an existing app, knowing that you didn’t have the same financial and technical constraints as the

Designers who created the original? Or maybe your freelance client put you under a super tight schedule and budget, which forced you to shorten the research phase?

No matter the context, any project comes with its own set of constraints and opportunities. At the very least, explain the context in your case study so the reader can make their own judgment about these. Better yet, show that you understand them as well.

Mistake #4: Case studies without role description

This mistake was also covered in my previous article on the topic.

Most of you are probably well aware of the importance of mentioning your role in a project that was carried out by 10 people, from initial research, through UX and UI, to final development and implementation. However, I still see a lot of case studies where I have to search for that information. It should be obvious to me what you did in a given project, and what kind of team you worked with, if any.

Why it’s a problem

If you don’t explain your role in a given project, I can choose to draw one of two extreme conclusions:

  1. You did all the work.
  2. You did none of the work.

I would love to give you the benefit of the doubt, but if you’re up against ten other promising candidates for a position, that’s unfortunately not what will happen.

I will of course assume you did some of the work, but if I don’t know what, I can’t give you credit for any of it.

What to do instead

Your role in the project and the structure of the team should be explained at the beginning of each case study. Make it easily accessible and understandable so it doesn’t leave me with any doubts.

There’s another benefit to paying a bit more attention to this. It shows another aspect of your experience. One thing is to have done the UX work. Another thing is to have worked with a team of Researchers and UI. Or collaborated iteratively with a couple of FE Devs.

Or participated in a workshop with your PM, Head of Marketing, and COO. It all adds to your experience and makes you a more interesting candidate. This is true whether you were the UX Lead or the UX Intern.

Along these same lines, take the opportunity to show you’re a team player! Your case studies should first and foremost highlight your skills and experience, but there’s nothing wrong with giving credit where credit’s due. As Renee Fleck puts it in this article about portfolio mistakes to avoid as a junior designer:

“This is also an opportunity to explain how you communicated and collaborated with the rest of the team, and how your contribution is evident in the final results.”

Explain how you collaborated with a colleague, and how they did something that greatly contributed to the project. It tells me that you value your colleagues, that you can thrive in a collaborative environment, and that you want to make your colleagues look better rather than take the credit yourself.

Mistake #5: Case studies without a problem statement

When a case study doesn’t begin with a problem statement, it’s not necessarily because someone forgot to include it.

It’s likely because they didn’t have one in the project itself. It’s still way too common to kick off a project with only a vague idea about the problem to solve. This can be okay if defining the problem is part of the project. Often, however, it’s not.

Why it’s a problem

Product Design is about solving problems and satisfying needs. More than that, it’s about solving the right problems. The problems that really matter to your target group.

The problems that make sense to solve from a business perspective. You can easily go through a Design project and end up with a “solution”, perhaps even one that solves something — but did you actually solve what you should have?

If you don’t begin your project with a clearly defined problem statement, a deep understanding of the problem you want to solve or the need you want to meet, you have nothing to guide your process. You have nothing against which to measure the success of the project.

Whether you failed to begin with a problem when you worked on the project, or simply forgot to include it in your case study, I’m missing a key piece of information when evaluating your portfolio.

What to do instead

Begin each project — and each case study — with a clearly defined problem statement. You may present it as “Problem statement”, or “The problem”, or “The challenge”, or “What we wanted to fix”, or “The user need”. The exact wording is less important than the content.

Tell me why the project even happened in the first place. And make sure it’s stated as an open-ended problem and not a solution in disguise.

Simon Pan’s Uber case study is a great example of this. Three clear goals made it easy to evaluate potential solutions and the success of the final outcome.

Uber case study by Simon Pan

Another example to learn from is the Zillow case study by Frances Tung. She visualizes the problem with screenshots and pointers to the exact usability issues they wanted to solve.

Zillow case study by Frances Tung

Beginning with a problem statement will also help you avoid this next mistake…

Mistake #6: Case studies without an ending

With a problem statement as the beginning of your case study, an ending to conclude on the project should come naturally. Yet I often see case studies that sort of just “fade out”. There’s no clear ending, just a long presentation of the process.

Why it’s a problem

While I love seeing your process, you’re ultimately hired to create results. Each case study should illustrate your ability to do so. The end of the case study is the natural place to do this (although starting your case study by showcasing the final solution can work as well).

What to do instead

End each case study with a conclusion to the project. Show the final solution and tell the story about what happened. Did it go live? How did it impact the metrics you wanted to improve?

If possible, add some testimonials or quotes from user interviews or usability testing. Use what you have to give your case study a natural ending, and tie it together with the initial problem statement.

Mistake #7: No explanation of WHY you did what you did

This mistake was also covered in my previous article on the topic.

I quite often come across a case study that’s presented almost like a Design Process template, or as a list of common UX methods.

We did research, then we did ideation, then we did paper sketches, then we made a digital prototype, then we tested it, and finally we ended up with this solution.

Why it’s a problem

When it comes to your portfolio, it makes sense to show the outcome of each design project. It also makes perfect sense to show how you got to that outcome — the process you went through and the tools and methods you used.

Now you demonstrate your understanding of the standard Design process and showcase your experience doing personas, user journey maps, wireframes, usability testing, etc.

However, knowing the Design process and the most common UX methods is just a baseline requirement. It’s typically not enough to make you stand out from other candidates.

What to do instead

You should absolutely tell a story about your process of getting from problem statement to final outcome. This is essential. Learn from Maarten van Hoogdalen who used feedback to iteratively improve his own portfolio:

“Don’t just show your final designs, show the process, show your research and tell a compelling story rather than just an image of the screens and the explanation of the buttons.”

On top of the what and how of your project, I’d recommend focusing on why you did what you did. Why did you use these methods and tools? Why did you make the decisions you did? Why did you make these tradeoffs?

Making this the center of attention in your portfolio tells me that you understand the tools we use in UX, and that they are just that — tools! Tools at your disposal when you need them and when it makes sense to use them.

It tells me that you’re able to think critically, reflect on the challenge you’re facing at any given step in a project, and deliberately choose a way forward.

Mistake #8: Case studies presented as “perfect”

It’s only natural for us to present ourselves in the best way possible. We try to look flawless and don’t talk about our weaknesses or mistakes. This is especially true when we meet someone new. And the same seems to be the case in most portfolio case studies.

They’re presented as perfectly linear processes, beginning with research and ending with a perfect implementation of the designed solution. No tradeoffs or corners cut along the way, no backtracking to correct missteps earlier in the project.

Why it’s a problem

No projects are perfect. There will always be tradeoffs. The perfect solution won’t be the one to get implemented. The process will never be as linear and sequential as depicted in the models we’re inspired by. And that’s okay! It’s part of what we do.

Negotiating trade-offs and reaching the right balance between innovation and technical viability, between a long and thorough user research project and the time available, between the perfect solution and the budget… It’s all part of the job.

Furthermore, experimenting with the process, trying new methods and tools, and challenging yourself and your approach, is an important part of learning and growing as a Designer.

I want you to be explorative, make mistakes, and learn from them!

Leaving out the less-than-perfect from your case studies will not only make me suspect you’re hiding something — it’s a missed opportunity to show how the project made you a better Designer.

What to do instead

Don’t go for perfect. Explain the tradeoffs you had to make, and how you made them. Discuss the corners you had to cut. Present the experimental methods and tools you used, what you learned, and how you will do better in your next project. Consider a dedicated “Retrospective” at the end of your case study.

Mistake #9: Case studies that are difficult to “scan”

This mistake is part of the first one on the list: Neglecting usability in your portfolio. Enabling a good reading experience should be one of your top priorities when designing your portfolio and the case studies within. In fact, I think it’s so essential that it deserves its own headline.

Why it’s a problem

If you’re targeting potential employers or clients, chances are they won’t have a ton of time when looking at your portfolio.

They’re likely weighing it against tens or even 100+ other portfolios. Your portfolio needs to be easy to navigate and comprehend. The same goes for each case study.

I’ll most likely have a quick look at the case study introduction — hopefully with a good problem statement — and then scroll to the ending. Then I’ll scan through the body of the case study on a hunt for the most interesting bits and pieces.

First of all, I’m trying to get a sense of your process and the methods and tools applied. How you got from the problem statement to the outcome. If I can’t spot this connection,

if I can’t see the thread running through your case study, I might give up and move on to another case study. Or another portfolio.

Additionally, just as your overall portfolio site, the presentation of each case study can be judged as its own UX project.

It’s not just about the project you’re presenting — it’s about how you’re presenting it. A poorly presented case study will give me a bad experience, even if you did well in the project you’re presenting.

What to do instead

When you design your case study, think about your portfolio’s target group. Think about their situation when visiting your site.

Think about their state of mind and the time pressure they’re facing. Now, design your case study according to that.

Consider what you’ve read earlier in this article: Provide the essential information about the project context and your role in it. Begin your case study with a clear problem statement.

End it with the project outcome and your final solution. In between, show your process. Show how you arrived at the final solution, and why you did what you did.

Design your case study so that it communicates all the essential information in the fastest, clearest way possible.

Add a big bold headline for each stage of the process, or each method or tool you used. Use plenty of visuals, accompanied by thoughtful, targeted captions. Tell me a story about your project, but use as few words as possible.

Highlight the sections, the decisions, and the methods you want me to notice. I will only read bits and pieces of your case study, at least at first, so do your best to make me read the right bits and pieces.

Christina Richardson’s portfolio is again an example to follow.

Web Rental Tracking case study by Christina Richardson

Key takeaways

I’ve evaluated enough portfolios, and experimented with my own, to have spotted some patterns and common mistakes. All these mistakes will drag you down, and some of them can mean immediate disqualification. Luckily, most of them are easy to fix, and the others are well worth your time and effort.

Treat your portfolio as one of your Design projects, and make sure it’s designed with usability and accessibility in mind. Prioritize your projects and go for quality over quantity in your portfolio. Adding subpar projects to seem more experienced will drag down your average.

Make sure you explain the context and your role in each of your case studies. To assess your experience, I need to know if I’m looking at a school project or a freelance gig, and exactly what you’re responsible for.

Begin each case study with a problem statement and end it with a summary of the project outcome and your final solution. Demonstrate your ability to use the UX toolkit by showing not only what you did but why you did it.

Include your learnings and things that could have gone better. No project is perfect and we’re all experimenting and growing all the time.

Tell me the full story, but don’t think you need a wall of text to do that. I’m probably in a hurry, so make sure I can scan through your case study and still get the key takeaways.

If you do, I’m much more likely to read it all and check out the rest of your portfolio! 🚀

Originally published at on June 3, 2020.


Created by

Christian Jensen

UX Designer, investor, and NFT nerd, writing about innovation, investing, product design, and culture ✍️







Related Articles