How to write better case studies with one simple tip.

I have been in the design industry for over 4 years now, and as a design lead, I have interviewed and hired other designers. But when I was a junior designer, I applied for a fair number of jobs, and I can say that it was at least challenging to get into UX and get that first job.

Since I’ve hired and mentored other designers, I've noticed one common mistake that a lot of junior designers have made. In fact, it is so common that I have seen more than 70% of junior designers make the same mistake.

I have already written an article with many useful takeaways where I talked more about the career-level and job-searching mistakes of junior designers. However, I want to talk about something specific and actionable today.

When I am looking for a junior designer’s case study, either for a role I am hiring or during a mentorship session, one common thing I have seen is to include as much process as possible in one case study.

As a hiring manager, I don’t want to know what process you used in your project; I want to know why and how you did it. I don’t want to see your wireframes or storyboard if they do not add any value to the solution.

One thing you need to keep in mind is that I, or any other hiring manager, don’t have a lot of time to look through your portfolio. We are mainly looking at it while we are making our coffee or during the 5–10 minutes of extra time we have. Even when we allocate special time to look through an applied candidate's profile, we are just skimming through it.

So we absolutely hate those case studies, which are really long, and most of the content in those case studies is just useless and does not provide any information that leads to the solution.

And I know that when you have worked really hard on those projects, you want to show every piece of it so that you can provide all the context. I certainly used to think the same when I was a junior.

I am also not saying this because I want to save some time for myself or other hiring managers. There is a bigger problem here, which is that all the junior designers focus on “what” and not “why."

When I ask junior designers about why they have included certain steps in their case studies that had zero impact on the final result, the majority of them answer that they want to show what they did on this project.

So please remember to focus on WHY and HOW, not on WHAT while writing case studies.

This advice is not only about what steps to show in your case studies; it is also about what to write in those steps. When you are writing content in your case study, keep in mind to write about why and how, why you made certain decisions, and how that helped with the solution.

So while you are writing your case study remember this order, Why, How, and What.

1. First prove, Why did this step/process was necessary for your project?
2. Then, How did this step/process help the project?
3. By focusing on those two, you will automatically find out what steps/processes you did in this project.

For some reason, all the junior designers have this mindset that if they include all the different types of processes in their case study, it will make them look like better designers. Let me tell you, it doesn’t.

It is always beneficial to demonstrate that you are a generalist and you are aware of different industry practices, but this does not always imply that by simply mentioning all of the different types of UX processes you will be considered a good candidate for the role. In fact, it is quite the opposite.

UX is a really wide field, and even designers with 6+ years of experience might not have worked on all the UX processes, but they are still amazing designers. What is more important than knowing all the processes is knowing when to use which process.

As a hiring manager, when I am looking for junior designers to hire and I am reading their case studies, I just want to know why they made certain decisions about going with the UX process over others and then how that helped the user or finding the solution.

Why would one perform usability testing to find out about the efficient layout of the navigation bar when they could just perform a card sorting activity at the start of the project?

Demonstrating that you have done usability testing and it has improved the design is a step forward, but when you add some real-life constraints like time and budget to those projects, you can actually see it is two steps backward.

Do you really think showing 12 sketches of wireframes will make you stand out more from other candidates? And do you think that by not showing sketches of wireframes, I will think you are not a UX designer? No. And removing those wireframes from your lengthy case study will help the hiring manager focus on the things that matter more.