Many designers may have question marks when it comes to what they should be putting in their case studies. But I notice a great deal of conventional wisdom about how to build case studies takes a certain perspective, or assumes certain things are true. I also notice that I do not make those same assumptions. This is probably nowhere clearer than in this opinion piece I wrote recently:
Pulling further on this thread, I’d like to offer more detail on this perspective.
Conventional wisdom
To start, though, I want to talk about what the conventional wisdom is, and my thoughts on it.
Personally, I’ve met dozens of early career designers and have seen the same pattern of conventional wisdom applied over and over, to the exclusion of all else. I refer to this as a formulaic approach. You might be wondering what I mean by a “formulaic case study,” however. You’ve probably seen it — it generally involves:
1. Writing out a problem statement.
Have you ever watched an infomercial and then immediately asked yourself:
“Why would someone need that product, though?”
“Would anyone really ever fall and spill cereal all over themselves like that?”
If you have found yourself in this situation, this is a sign that you have the power of reason. The resultant effect is that you are able to call codswallop on things pretty quickly. However, like in any Greek tragedy, all great powers come with a great weakness: in this case, the tragedy is that all other people also have this power. This includes the people on your interview panel. So when you show up before an interview panel with a case study built on a use case that no one would ever reasonably have, we can tell.
There is also no requirement that problems be phrased in the “problem statement” format. Of note: the paragraph above this one does, indeed, describe a problem and scenario. But also of note: it was not written in the form of a problem statement. Chances are, however, that you still clearly understood me and the context I was setting.
What I mean by this is: if you want to explain a problem that your proposed software can solve, just explain it. If your problem statement doesn’t actually add clarity (for instance: you recite your problem statement to a friend and s/he still has fundamental questions that indicate no real comprehension), then you don’t have a problem statement. You just have a problem.
Speak plainly and clearly, using your own, individual thoughts and words. You are trying to get people to understand a use case before you get into the weeds of your proposed solution to it — that’s your one job at this point. Now is not the time to check an item off a checklist — it’s a time to build some context about something your audience has probably never heard of. This will likely require more than just a statement.
2. Doing some “research.”
You might be familiar with what I’m referring to, and this is usually in the form of a Google Form survey. However, because the premise (the use case) doesn’t exist in reality, the “research” about it is neither convincing nor insightful. Because of this, the questions asked in these surveys are usually irrelevant, surface-level, and unfocused — again, this is because the problem isn’t real, and the designer is likely just checking off a list item (research = researched ✅), rather than pursuing some kind of truth sincerely.
Typically, humans ask questions to gain information and arrive closer to some kind of truth. Because there is no problem to solve, the questions serve no purpose. While reading the questions, you might feel they are actively avoiding some kind of elephant in the room, too. This is because the premise on which they use to build these questions, itself, is usually unable to stand.
3. Including a “persona.”
I have never been able to determine where any of the information about the people depicted in designer personas come from. But also, again, a persona can’t plug a plausibility-shaped hole in one’s case study. If it’s of any use, I’ve been a designer for closer to a decade, and I’ve never made one. I’ve also never worked with a designer that has made one in our time together.
Fundamentally, customers are the people generating the demand for your product or service, and what you propose building is the supply to that demand. If there is no actual demand (because there is no problem to solve, there’s no value to provide to anyone, ergo, there’s no actual business or product here), it follows that you have no customers. So how can one make generalizations about customers if those customers can never hope to exist in the first place?
To borrow from a mentee’s own words:
I always feel like I’m pulling [personas] out of my ass a little bit.
Always listen to the voice in the back of your head: it’s your natural voice of reason — your superpower. To paraphrase the words of an 18th century philosopher: if you are stomaching things that, in your heart, you know not to be reasonable, what you’re doing is betraying that ingrained, natural sense of reason and skepticism in your mind — the one that pursues truth and understanding, and wants the best for you. Don’t do that to yourself. Listen to your reason.
Besides, if you think something is unreasonable, the interviewers on your panel will probably feel the same way.
4. A section about “process.”
Like I said, there’s no use case to solve for here, so there’s no real work to have a “process” around. Putting that to one side, for my part, I’ve never doubled a diamond in my career, to my knowledge, and I don’t think I’ve ever witnessed another designer doing that on the job, either.
I know it sounds cool to say that one works using a process from a 1990s art theory book, but I feel like the cooler thing to do is to tell the truth whenever you can and do honest work. This is just my assumption, but I get the sense that people respond more strongly to things that “click” for them intellectually more than they do to complicated looking graphs that over-explain an otherwise pretty simple concept.
If it’s helpful, here’s advice from a recruiter while I was going through the hiring pipeline with a certain famous, blue social media company. The recruiter recommended that candidates:
Do not focus on process in the presentation (e.g., UX research, stakeholder management, post-its, sketches, low fidelity, etc.).
Here’s an equivalent of this prep email excerpt, but from a recruiter from a certain fruit company, who recommends that candidates:
[Say l]ess about process (slides of text) and more about the work, flows, & screens.
5. Some “competitive analysis.”
You know what I mean by this. It usually looks like some screenshots of other services, and a checklist comparing their offerings. Again, the problem is not real, so what competition is there to analyze?
Even if you do have a plausible problem area, most of the time, these problems are not being solved by any of the listed “competitors.” Think sincerely about the problem you want to solve, and how you think people really do get around the issue you are seeing them have. Are they going to random-website-dot-com? Or are they doing something very manual and repetitive, using something in real life that sort of gets the job done, with multiple chains of tools that, in combination, kind of solve for their use case? Being honest, this is most likely the case.
Demonstrate that you can think independently about topics. Don’t put your brain on autopilot and copypaste some “competitors.” Figure out what people are actually doing in this problem area to get their needs met, and then look into that sincerely.
6. A “site map.”
I have never been in a situation where I’ve needed to do this, and have never seen another designer make one, either. I don’t know why I would. Product designers don’t make websites, they make webapps/native apps (and things like this), which are usually highly dynamic and respond to user behavior in complex ways. I don’t know how I would make a site map of something that is not a site, or why I would want to.
7. An image of some stickies, images of one’s notebook, mid/lofi wireframes, etc.
I know, I know, stickies are on The Design Process List. But, quoting the blue social media app recruiter again:
Do not focus on process in the presentation (e.g., UX research, stakeholder management, post-its, sketches, low fidelity, etc.).
If you whiteboarded with your peers while you guys sat in a room/call together, trying to make sense of some functionality and what should happen at each step, that can be fun to mention in passing (maybe flash a little pic of you guys smiling together!). Because you really did that. And you were trying to figure something out with your peers. Otherwise, resist the urge to Check The List Item.
Also, don’t trouble yourself with the gray boxes. Quoting Juan Ramirez, who writes:
I know that low-fi design looks on paper like the right way to iterate and build a product. In fact, I was taught over and over that designing in low-fi was a more efficient way to create a product. … But at a certain point, I realized that putting together a wireframe took me longer than putting together a high-fidelity design…
I know you probably feel like you need the gray boxes but, again, you don’t; secretly, you probably know that.
8. A “design system” at the end of your case study.
There is often a “design system” at the end, usually with a scale of a few type sizes, maybe some color blocks, even a few buttons. Probably looks like this:
A design system is something people make in Figma because it helps them — and other designers on their team — find components faster. It is (ideally) not a series of font sizes and some color swatches on a screen. People don’t consume design systems visually — design systems are highly functional and are mostly consumed through Figma’s asset search tab.
Design systems (ideally) allow you to find patterns fast when you’re working on features, and also allows you to figure out the different states components can be in. Here’s an example of one in a production setting:
They don’t exist to look cool or show some type scales or color blocks for visual fun. They exist to be used by designers while we’re working. They’re just Lego blocks for us. By contrast, the layout included above exists for aesthetic reasons. It’s clear that this was not made as an internal tool to assist in moving fast while designing, but as something to check off on a list.
Truthfully, the artifact included above does not show that one knows how to make design systems, but rather the opposite: it shows that someone has never made a design system before (even a tiny one), nor ever worked with one, and has significant misunderstandings about what a design system is.
9. Write out a “learnings” section.
Again, if there’s no real premise here for the work, what did one learn? This problem is usually reflected clearly in this section. Examples of learnings I’ve seen are generic pieces of life advice, like: “design is complicated,” “communication is key,” or “not all feedback is worth considering.” Do we really need to be brought through a twenty minute case study for these learnings?
Let’s start over. Imagine you felt like designing a mentor/mentee matching experience into LinkedIn. If you were to design its core flow, then consider what you might do to move forward, you could reasonably arrive at something like:
I can’t build a Linkedin mentor/mentee matching experience for real but, if I could, I would watch for some key indicators that it’s actually working for our users: is this driving engagement on the platform? For users who are exposed to this new experience, are they DMing more? Are they liking and following more? Are they connecting at higher rates? Concerning subscriptions, which is how LinkedIn makes the lion-share of its revenue, is this new experience driving acquisition of new subscribers? Is it helping retain current subscribers?
Or:
I want to better understand what mentors get out of mentoring. The value prop seems clear for mentees, but less so for mentors. Are they getting notoriety and fame in the design world? Proof that they are thought leaders? Or are there designers who sincerely want to build a business out of mentoring people? Or all of the above?
Determining their top motivations for mentoring could change the roadmap for mentors. For example, if they tend to be interested in mentorship in order to build fame, then building features that enable mentees to review them, or allow them to track the minutes they’ve spent mentoring, with some kind of leaderboard , and more features to encourage competition among mentors, or external validation — these could all be great options.
But if these are mostly small business owners with mentees they hope to monetize, perhaps building out analytics tooling that tracks their customer behavior, gives them suggestions about how to improve their margins, features that allow for integrations with services like MailChimp, features that allow them to build subscribers to paid, exclusive content they make — these could be higher priority for the mentor that’s more interested in building a business.
I just made this up, but this is what I would be thinking about after building a proof-of-concept for an experience like this. These are substantial reflections. You don’t have to have the answers, just think about some reasonable next steps if you were to actually build this thing, as if it were actually going to be your business you were going to build.
What if we tried something different?
I’ve talked about the conventional wisdom, and my perspective on it. Embedded in that are suggestions for what to do, but to make sure those don’t get buried in there, here’s what I’d advise:
Explain your premise very clearly
This is your first order of business. It’s extremely important that you explain the premise of your case study in a way that any stranger would understand. Put down the personas, random stickies, generic Google Form surveys, and wireframes. Instead, try to structure your case study as if you were explaining your product solution to a loved one.
Recruiters and hiring managers may be prone to skim portfolios and use gut feeling when deciding to move forward with your candidacy (perhaps only revisiting it with a finer comb when you’ve been selected as part of a smaller batch to move forward with). However, when on an interview panel presenting your case studies, the scrutiny placed on these is far more acute, and so making sure people understand what you’re talking about is of utmost importance in that context. This is why it’s so critical that they understand your premise. If they don’t understand what you’re even talking about, none of the decisions you make following that will make any sense to them. They are going to be sitting there feeling like they’re missing something.
It’s a lot like when you’re in class, following your teacher in lecture, you turn around to pick up something you dropped, and now you understand nothing and are completely, hopelessly lost for the rest of the session. Don’t leave them feeling like this! When we give our feedback about your work internally, give us something to talk about. Make sure we understand you. Your content should reflect that.
Here are some things to consider:
- Would anyone off the street understand what the business is?
For example:
“I want to design a new vertical within Spotify: Spotify audiobooks. Audiobooks are a multi-billion dollar industry, but participating in this market is strewn about various different services, creating very disjointed experiences for users. This gives Spotify a unique advantage on the market, in the same way that they had for podcasts.
But let me explain what Spotify’s business is in more detail: it’s an app that allows you to listen to music and podcasts, and allows musicians and podcasters to put their work up and gain listener bases and fans, generating revenue for themselves. Users can go on the free plan and get ads, or can pay for a subscription and listen unlimited, both which generate revenue for Spotify, with subscriptions being the lion-share of Spotify’s revenue…”
- Would anyone off the street understand why the software you made should exist?
Consider if you secretly wonder if other, better solutions currently exist. For example, people might be asking:
“Can’t you just use Google Docs for that?”
“Can’t you already get that on Uber Eats?”
“Couldn’t you just use Amazon?”
- Would anyone off the street understand what you did, step-by-step? Would they think it’s reasonable that you took the actions that you did?
- Would anyone off the street agree with the design you ended up with? Would that design seem reasonable to them?
- Would the people on the interview panel — complete strangers — understand the problem area my work lives in after my case study? Do they have a fundamental grasp of what I’m even talking about?
- Would the people on the panel feel the quality of my work is high?
- Would the people on the panel feel that I made decisions they respect, or can logically follow?
- Would the people on the panel actually understand what I proposed? Are you showing incredibly up-close detail of your solution that people can see clearly over a screenshare? Is it clearly visible? Can you show a screenrecording of your solution being used to really help them understand?
- If you’re making a fix to something that previously existed, did they understand what was there before at all? Is that problem self evident? Can you explain that better? That way, we can decide for ourselves if your fix seems reasonable.
Consider this: even if you work on a famous product, you’re probably going to be working on parts of it that are unknown to others. Ask yourself: do you think the average person is familiar with Meta’s ads platform? Do you think the average person knows much about Twitter’s subscription service? Or how it handles payments? You don’t, and you’re an average person, so the answer to all this is a resounding “no.” Make sure that you explain what you’re working on before getting into the weeds. Otherwise, it’s a super awkward thirty to forty-five minutes for everyone (or a nonsensical, boring read to people looking at your personal site).
Make sure your case study’s premise is plausible
Making sure to explain your premise before getting into all the details is one thing, but for this to even work, the premise has to actually make sense at all. Speaking plainly here: we don’t need another delivery service for your favorite snack brand. We have a delivery app, and it’s called Uber Eats, and it’s fit for purpose — it’s great, that’s solved, it’s done. In my view, it would be a bad idea to propose another Uber Eats, especially when you’re before an interview panel.
If you have an improvement you’d like to see Uber Eats make (might be nice to be able to easily request people pay you back following a group order, for example), then build a case study on that. That kind of thing can be plausible. Otherwise, find something else to build. There’s no way around this — yes, you’re going to need to use your noggin. Those prompts you got from your bootcamp are not going to cut it.
The trick is to propose whatever solution to whatever problem because you believe the software you’re proposing makes sense and should exist as a real product/business, or is a sincere improvement to a current product/business. In other words:
- It’s not just a clone of an existing app,
- It’s not just a website redesign of your local store from around the block (websites display static information, so it’s not product work!).
I talk more about this in two opinion pieces, if you’d like more information. The first one:
In this one, I also provide some prompts that could be worth exploring, if you’re out of ideas. The second one, as mentioned earlier, provides more detail on this perspective, if you think that’d be helpful:
Don’t follow a formula
As mentioned earlier, a formulaic approach (see above) is the conventional advice featured in most educational content, but I currently have no reason to believe that this reliably works towards helping one get jobs easily. Also, I don’t think experienced designers are following this advice, that I’ve seen.
Make sure that the people on your panel understand what you’re saying. If you’re making an improvement to some existing product, for example, make sure they understand the “before” — and the “after” you’re proposing. If you’re making a whole new, novel product, make sure they understand the landscape that exists right now, so that they can determine for themselves if they feel this product has legs and solves a real problem.
I tend to write case studies that are somewhat chronological. “I joined Communities at Twitter, which wants to help incentivize users to engage on the platform. Twitter cares about ‘serving the public conversation,’ but driving engagement also increases users exposed to ads from our enterprise customers, which is how our business makes money… Communities can help drive engagement by greasing the wheels of interaction between users, so it’s a win for all of us. So here’s what I did towards that end…”
You can stop to detail funny moments that happened, for example (seriously, interviewers get bored — we’re people, too!), if they’re pertinent, or show some quick deep dives into a few parts of the UI. It breaks up the chronology a little, allowing you to press pause and detail some cool stuff you want to highlight. Notice, however, the distinct lack of personas or problem statements or mentions of lofi wireframes, etc.
But, again, this is the key: you can do literally anything you want! Including use a formula. (But I wouldn’t recommend that.)
Make your case studies engaging
When you have company, there is a common expectation that you entertain them, making coming all the over to your place worth their while. When you get into tech, you’ll find that you’ll be randomly recruited on to interview panels with some regularity. It can get repetitive and, anyway, interviewing is a very large commitment. So, as a candidate, make it worth their while: make it interesting and fun for them! Here are some tips that can help:
- The most crucial way to make sure your case study is engaging is if it makes any sense at all. It’ll be extremely immersion-breaking if interviewers are consistently mentally noting a bunch of holes in the claims you’re making, or solutions you’re proposing, or are hopelessly confused about what you’re saying,
- Use humor, if you like!
- Make sure your craft is good. You’re a designer, and so there’s a general expectation that you bring a certain je ne sais quoi to your work. You can have a lot of fun with the visuals, and bring in real personality!
- I would recommend about a two minute introduction at the start. You can talk about yourself however you want — how you became a designer, a super cool, formative thing that happened in your life, I don’t know, anything. Go crazy for two minutes.
Think of it this way, if it helps: all your interview panels are a stage, and you and the panelists are merely players.
Have sincere thoughts
The advantage to making case studies that are built on real use cases is that your “takeaways” can actually be believable — because they are sincere, most likely. As mentioned earlier, do I need to listen to a fifteen minute case study to learn that “communication is key”?
I would much rather hear about your thoughts about this thing’s chance for profitability — a (generally okay) proxy for if there is sincere market demand for what you’re proposing. If you worked with others, tell me about those disagreements. To revisit the LinkedIn mentor/mentee matching service: what do they make of the problem mentees are reporting around the limited utility of all these repetitive, one-off mentoring sessions, when they’d really rather longer form, extremely deep working sessions? How can the product facilitate that? Do you need to change the business model? Would something like this suit the average mentor, or a mentor that might be more interested in monetizing their mentees? What do you think? What’s your inclination on this? Do you even think this is a real, serious problem — or, at least, one worth focusing on right now at this stage of the product?
If you’re on the job right now, and you’re presenting work you did for a company, you can also just say you feel differently about the product direction the team went in, and why. You can talk about what you’d do differently if it was your call. You can represent their views, and then represent your own. You can build a case for why you think it should be different, and how you’d sanity check these assertions on the market.
I don’t want this to get much longer, so I’ll stop here. This is what I’d broadly recommend for the content in your case studies. As you notice, it’s really just about being a good writer, which is where all my case studies start (I just write a script and simultaneously figure out the visual compositions that go with it). If you feel it’s helpful, look out for two future opinion pieces I write, where I hopefully discuss — at extreme, painful length (because I know me) — how to make a good (1) portfolio site and (2) portfolio presentation. Or maybe it’ll be one, mega article. I don’t know.
As always, let me know what you think, and if you have questions or concerns, or if you just disagree! I can always be reached on LinkedIn, as well, if you’d like to discuss a matter privately, and I’m also on ADPList. Or just reach out and I can see if I can find us some time. Always happy to help, always happy to discuss.
