Episode 191
UX Portfolio Myth: Your case studies don’t need to show the full UX process (Myth 3 / 5)
14 min listen
Episode 189
14 min listen
Listen to the Episode
Episode Summary
UX process breakdowns showing up in full inside a portfolio case study is one of the most common UX portfolio myths, and one that’s quietly overwhelming people with long, complex projects. In this episode, Sarah Doody continues her five part series on UX portfolio myths with the third one, the belief that every case study needs to walk through the whole end to end process.
Sarah argues the opposite works far better. Going deep into just one or two parts of a UX project beats trying to show everything you did, especially if you’ve worked on something that spanned six months, a year, or longer. Trying to cram in every step just skims the surface of all of it and overwhelms the person reviewing your work, which defeats the purpose entirely.
She backs this up with a clip from her interview with Alexander Zeh, former Head of Product Design at ManyChat, who said he’s specifically listening for problem solving language, phrases like “I facilitated,” “I unblocked,” “I synthesized,” because those signal maturity in how someone thinks, not just what they produced.
The bulk of the episode is a screen share walkthrough where Sarah rebuilds a weak case study slide by slide, showing exactly what it looks like to go from a shallow “next, I made some wireframes” slide into one that actually explains the problem, the decision, and the impact.
If your UX case studies currently read like a list of what you did, and you’ve been stuck trying to figure out how to fit a two year project into one portfolio piece, this episode shows you exactly what to change and why.
Create your dream career, and life
- Learn how to advance your UX career in our UX Career Roadmap
- Watch our free masterclass about how to get hired faster in your UX job search
- Stories of how UX and Product people got hired after working with us
Watch
Discussion Questions About The Episode
- If your current case study reads like "I did this, then this, then this," what's one part of that project you could go deeper on instead?
- Think of the longest project you've worked on. What's the one specific slice of it that would actually matter most to the role you're applying for right now?
- If you're applying for different types of roles, would your case studies need to highlight different parts of the same project? What would that actually look like for you?
Episode Notes & Links
Episode Transcript
Sarah (00:00)
Your portfolio must show the whole end-to-end process is a total myth. It is better to go deep into a few parts of a project than to show the entire thing.
Welcome back to Career Strategy Podcast, where we are in the middle of a five-part series about the five UX portfolio myths that are keeping you stuck and likely costing you interviews and job offers. So make sure to check the show notes or just scroll back to see the other myths we have addressed so far. first one being you need three to five projects in your portfolio, totally false. Second myth,
You need a portfolio website, also false. And this week, myth number three: you must show the whole end-to-end process for every project in your portfolio. So that is false. As I said, it’s much better to go deep into a few parts of a project than to try and show the whole thing. What is going to happen?
Is you’re just gonna get overwhelmed trying to show everything. And if you somehow get everything into the project, you’re gonna overwhelm the recruiter, the hiring manager, right? Because they don’t need to see every single thing you did. Recruiters and hiring managers don’t want hundreds of screens and output of every step of the double diamond process or whatever process we’re following. They want to hear.
What you did and how you think as it relates to what they are looking for in the jobs they are hiring for. Now, this is even more important for you if you’ve worked on projects that were really, really long, right? Many of you have worked on projects that spanned six months, 12 months, or more, right? And all of a sudden, your portfolio just feels so overwhelming because you’re like,
How the heck am I supposed to put this two year project into a case study in my portfolio? And that’s where you get stuck. Maybe you’re stuck there right now. And permission to not show the whole entire end to end process. I am backing up all of these myths with what I’m hearing from recruiters and hiring managers, as well as what I see working for.
People who are getting hired in my career strategy lab program. And I want to share with you what Alexander Zay said. Who, when I interviewed him, he was the head of product design at ManyChat. And he said, I want to see problem solving, that you understand consequences of your decisions and why you’re doing things. I facilitated, I unblocked, I synthesized. Phrases like that signal.
Maturity. And that is one of the things that Alexander is looking for when he’s betting candidates. If you want to hear more of my conversation with Alexander, you can listen to the full thing on episode 172 of the Career Strategy podcast. I will also link it in the show notes.
So I am going to share my screen and show you what it means to not show everything you did, but only focus on a few parts of a project because this is gonna help you, especially if you’re struggling with your portfolio right now.
Sarah (03:28)
Okay, so to help you really visualize this, here is why your portfolio does not need to show all the steps for every single case study. This is a familiar kind of UX process diagram. I got it from Nielsen Norman group. But when you try and show every single one of these steps, your portfolio ends up skimming the surface of what you did because you’re only focusing on what you did.
So let me give you an example.
Okay, so imagine we’re looking at a UX portfolio presentation here. And the slide says, I conducted interviews and a survey with account managers. And then there’s some kind of survey graphs at the right. The next slide might say, I analyzed the research and identified insights and pain points. And then there’s some like research, synthesis, affinity map type thing happening at the right.
Next part of the case study might sound like I identified two personas. And then next, it might say, next, I made some wireframes. So what is wrong with these four slides in this portfolio? The problem is that it’s only focusing on what you did. Because when you try and show everything you did over the course of a two months,
let alone two-year project, you are essentially going to be showing the recruiter nothing because you’re only telling them what you did. And recruiters and hiring managers actually want you to go deep into a few parts of the project and go beyond just the what. They also want to know how did you do that thing? Why did you do it that way? Why did you make certain decisions? Who else
Was involved. How did you collaborate with them? What happened? How did this inform other parts of the project or the product? What was the impact to the team, the timeline, the company, your stakeholders, the users? So they want to know more than just what you did and what you were responsible for. So to help you visualize how this might translate.
To your portfolio presentation, let’s look at just the part of a project where maybe it was more focused on interface design. And instead of just having one slide that says, Next, I made some wireframes, which is only telling us what you did, going deeper beyond the what would look something like this. So it would start out with.
A page in the presentation that would set up maybe the problem we were trying to solve to begin with, right? So on this slide, it’s telling us the page in the small purple text at the top, it’s saying page customer dashboard. Now we have context of what we are working on, right? Then that large text, I call it a headline, it’s describing the problem. It’s saying navigating between customers.
Used to involve going between two pages, the list page and the customer detail page. And then below that, in smaller text, it says constant switching between the two pages slowed account managers down all day long. Great. Now we have context as to what we were designing for, right? The problem we were trying to solve and the problem it was causing these users. And then we have a visual.
Of kind of a list page and a customer detail page to emphasize this issue of constant back and forth, back and forth, right? Okay. Then we would next want to see more of the solution. So we still are showing the customer dashboard and we have a wireframe of the full customer dashboard. There is a section at the left that’s kind of highlighted in purple, and then the
The big text, the headline on this slide says, a left customer navigation reduced friction of switching between two accounts. And they loved it. I no longer have tons of browser tabs open because my customer list is always there. That’s a quote from one of the account managers. So what’s this doing? It is helping the reader, the user of the portfolio, understand not just.
That you made some wireframes, but it is starting to go deeper into what parts of that wireframe were meaningful, were important to the solution. And now I’m gonna show you how you can further go deeper into this by getting into the nitty-gritty of this left customer navigation part of the interface.
So the next slide in this portfolio might be something like this. Where now that we’ve established, hey, the problem was switching between a list and a detail page, the solution was this customer navigation that persisted so they didn’t have to switch back and forth. And now we are going to go into detail of that left navigation. And to do it, we just like zoomed in or blew up.
That part of the wireframe. Because if we did not do this, it would be really hard to see the details, right? This is not like rocket science graphic design. This is just zooming into a wireframe. But what does this allow us to do? Well, it allows us to talk about specific parts of that left interface. So the text on this slide might say something like, the search feature along with customer details made it easy to find the right information at the right time.
And then now, because we can actually see the details of this left navigation of the interface, we can call out details about the search, the customer info, what happens when you click on one of the customer rows. Okay, it expands, and here’s why that’s important, et cetera. And this is what it means to tell recruiters and hiring managers not just that next I made some wireframes, but explaining the
The wireframes, in this case, the left navigation, why it was important, how parts of that left navigation helped those busy account managers be able to get the right information or find the right customers more quickly. So if your portfolio sounds like
I conducted interviews and a survey with account managers. I identified two personas. Next, I made some wireframes. That is a giant five alarm fire that you are only telling them what you did, which is what they do not want to hear. What they want to hear is what you did it, how you did it, why you did it, who was involved, and what happened. And that
Is why you do not need to show every single step of the entire UX process. Because if you try and answer all those questions we get went through, you’re gonna be overwhelmed and you’re gonna overwhelm your user, and this case study is going to be way too long. So it’s a lot better to focus on maybe one or two parts of the overall project versus try and show the whole thing. So
If you worked on a two-year project that went from nothing to full launch, and you are trying to get hired for, let’s say, a user researcher role that has also a little bit of product design skills, then what your case studies need to show are research and product design. We don’t need to see everything else. So maybe for that two-year project you worked on.
Maybe
you only focus on the user research because you’re trying to get hired for a user research role, right? And maybe a second project in your portfolio focuses on just the product design that you worked on, even though that project was maybe six months long or something like that. So permission not to force every single case study to cover every single step of the UX process because you’re gonna end up with.
too much, you’re gonna be overwhelmed, and you’re gonna overwhelm those users of your portfolio.
All right, so that was myth three. You do not need to show the whole end to end process for every project in your portfolio. Coming up next week, we have myth four, which is you can’t show work that didn’t launch or work that didn’t go as planned or went wrong in your eyes. Totally false. I’m gonna tell you why. And that is all for today. If you’re new to this series, make sure you check out the show notes.
Catch the previous myths, or just scroll back wherever you are listening to or watching this podcast, and you will see the other episodes in this 5UX portfolio myths series. We are in the middle of. All right, that is all for today. I will see you next week when I share why you absolutely can include and talk about projects that did not launch or projects that you think went wrong.
