How to create absolutely killer case studies that look great to any prospective client or employer, and can help land you the job you really want.

Overview

When it comes to UI and UX design, typically writing case studies is the last thing on most designers’ minds.

That being said, you can drastically improve your odds of success in the industry by having some high-quality, heavy-hitting case studies as part of your portfolio.

Today, I’m going to show you how you can create absolutely killer case studies that look great to any prospective client or employer, and can help land you the job you really want.

What makes a great case study

Think of a case study as a highlight reel of your project. You want to include a little bit of history, the greatest hits, and why it all matters.

Chiefly, the common denominators of all successful case studies include:

1. A punchy opening
2. A robust presentation
3. A compelling narrative
4. A tour of deliverables, and
5. Insightful takeaways

These four, key things are what separate okay case studies from ones that will get you hired. Thankfully, putting a case study together that will turn heads at HR isn’t rocket science; all it takes is the right formula, narrative, and structure to make it happen.

Let’s go over how to do just that.

How to put together a professional case study

The hook

This typically reflects the value proposition of your product or showcases the solution as an offering.

This is generally done with a punchy one-liner that either is or is in-line with your value proposition for your product: one sentence that describes the value that your project aims to provide for your users.

After that, a brief sub-deck that goes over what your product is and what it does.

Lastly, you’ll want a dynamic mockup, shot, of video of your final product in action. This doesn’t have to be to an insane degree, but you want it to look really appealing, and evoke the sense that you really care about presentation, and first impressions.

The problem

After the hook, you want to describe your project’s problem. This is your overarching design problem that you’re trying to solve, who you’re trying to solve it for, and why it matters.

The problem should be your driving “why” behind the actions you’ve taken, steps you’ve gone through, and deliverables you’ve provided, which support the solution that you’re presenting in your case study.

When writing your problem statement, the following overarching formula can work well:

“Users feel ___________________ about __________________, so we need to _________________, so that _________________ can __________________, without ________________________.”

As an example:

“Users reported that the toggling feature wasn’t working well, leaving them frustrated. This ultimately resulted in sub-par experiences, and disengagement. We wanted to tackle this by redesigning the feature set from the ground-up so that users can create their necessary lists without undue friction, to drive better overall outcomes.”

another example:

“We noticed users really struggling with the document creation feature, and reported that the process was confusing. We wanted to rework the document creation process so that it is more inviting, easier to understand, and facilitates better user movement through the document creation process.”

You see what we’re doing here? Describing the overall problem, the emotional impact, and what we’re looking to do about it.

This sets the tone for the rest of the case study and lets your readers know that you’ve given some real thought to what you’re about to show them.

The goals

After the problem, your goals represent what you’re trying to accomplish, business objectives, and desired outcomes.

Your goals will almost always essentially be inversions of your problem(s). Based on the examples above, some of your goals could be:

• Re-tool document creation process for greater usability, utility, and emotional satisfaction by at least 40%.
• Increase user engagement and feature usage by at least 35%.
• Increase recurring subscriptions through expectation fulfillment by at least 10%.

These goals are concrete, measurable, and have outcomes whose impacts are felt both by users and by the business who is offering the solution.

Most user goals will include:

• Better usability in terms of friction vs process traversal.
• More engaging process that stimulates optical cortex while providing haptic feedback.
• Better overall aesthetic considerations and presentation layer of product.
• Greater overall satisfaction of experience.
• Greater overall perceived performance of solution.
• Greater overall perceived convenience of processes.
• Greater overall impact of process outcome(s).

Most business goals will include:

• Higher overall user engagement.
• Higher overall user satisfaction that results in proliferation of product throughout user cohorts and virality.
• Higher overall profitability through margins of offering, followed by volume of active, paying users (margin x volume).
• Lower user turnover.
• Lower service expense per user.
• Lower cost of deliver per user.
• Lower total overhead, and lower overhead per user.
• Lower maintenance cost(s) and associated product fees on the business-side.

Of course, there are others which are completely valid, and these are the most common while serving as common denominators for user/business success.

Now that we’re through the preliminaries, let’s get into the meat of your case study.

Discovery

In discovery, you’ll discuss the deeper background of the problem, the research you did to figure out a suitable approach, validation of your initial observations/hypothesis, analysis of your research results, conclusions you’ve drawn, and the next steps you’re looking to take.

• Digging deeper into the problem, background, and domain of issue.
• User research.
• Initial hypothesis validation.
• Analyzing results.
• Conclusions & next steps.

Design

In design, you’ll showcase low and high-level deliverables which indicate what you’re looking to create, the structure, what your users will see, what they’ll do, how they’ll do it, what they’ll get out of it, and how the business will deliver those results to your users.

• Initial concepts — what your initial thoughts are on what your product will look and feel like.
• Information architecture — the structure of your product and where users will find what they’re looking for.
• Content strategy — what your users will see.
• Service blueprinting — how business will actually deliver value to/for your users.
• Wireframes and wireflows — how users will move through your application to get what they want.
• Mockups & prototypes — what your application will look, feel, and behave like in a much more detailed fashion.

Validation

In validation, you’ll discuss the steps that you took to ensure that users were both receptive of and actually liked the solution you and your team came up with. This will include usability testing and the various sub-types of usability testing (we’ll talk about those below), feedback you got from your users, changes and/or iterations you went through in response to this feedback, versions of your product to showcase process of change, and the final designs that you and your team went with.

• Usability testing — 5-second/impression testing, walkaround testing, critical task testing.
• Feedback — user debriefing & surveying, what did users do, what did they think about the process, and how do they feel about both the process and their associated results?
• Changes/iterations — changes you made to your product based on the information you got from usability testing and feedback that you got from user debriefing & surveying.
• Versions — the various versions of your product that you went through to get to your final product.
• Final designs — the final versions of your designs that represent your finished product; polished, clean, and ready for production.

Outcomes

In outcomes, you’ll talk about key takeaways, what you learned, what worked well, what didn’t work well, and what you’ll do differently in the future.

This can include:

• User outcomes.
• Business outcomes.
• Personal outcomes.
• Key takeaways.
• Learning experiences.
• What you’ll do differently moving forward.

In this section, you’re basically trying to communicate what happened, how everything landed with your users and business, what they got out of it, what you as a designer got out of it, anything that you learned, and how it will positively affect your processes moving forward.

This section is great for any metrics that you have, or any data that you can present to your viewers which can cement their belief in your process and (as selfish as this may seem) lends to your credibility as a designer.

Lastly, you’ll want a few final shots of your product as mockups and a thank you note to make sure your readers feel valued. Don’t be afraid to list your website, portfolio, or other resources for them to check out as well.

Some things to avoid

After all of this, and I know it can be quite a bit, there are a few things that you’ll want to steer clear of to make life easier on yourself when creating your case studies:

1. Anything that you can’t legitimately prove. Talking data, facts, figures, metrics, etc. Make sure for any claims that you make, you have documents ready to back it up.
2. Being too wordy or long-winded. You want to aim for just enough information to be interesting, but not enough to overwhelm the reader. ~200–450 words per section should suffice.
3. Going crazy with the layout. Your layout should be crisp, clean, and professional. For best results, I would recommend doing 1, 2, and 3-column layouts, alternating per-section as-needed. This can help to maintain visual interest, while keeping your content well organized.
4. Not making it scannable. Your case study needs to have good information hierarchy so that people can glean the most important data as fast as possible. Use size, shape, color, pattern, and texture as-needed to accentuate key data for your readers.
5. Making it too hard to find. Whatever you do, don’t bury your case studies. If you chose to do case studies, you want to make them as prevalent as possible on your site or in your portfolio, so that people looking for them can find them quickly and easily.

Why should you even write case studies?

I couldn’t resist quoting this article:

“Creating case studies is like flossing[…]

Everybody knows they should be doing it. Almost nobody does. And when they finally do, it’s a painful, bloody, but oddly rewarding experience that has them vowing to do it again soon.”

To tell you the truth, for the longest time I actually flat-out refused to write case studies because they’re laborious, time-consuming, and I legitimately figured that people wouldn’t read them.

→ I was wrong.

Turns out that case studies are some of the most compelling evidence to your credibility as a UI/UX designer that you can possibly have.

Why? Because they allow you to showcase every single deliverable that a potential client or employer could possibly ask for in the context of solving a legitimate problem.

Now don’t get me wrong, I still hate writing case studies, but I’ve changed my view on them significantly, and will be working on creating more from now on.

Getting it done faster & easier

With all that said, I couldn’t help myself, and in the spirit of saving you hours of soul-crushing layout work, I’ve put together a professional resource just for you that includes:

• A 100% customizable case study Figma template that you can use to create high-impact case studies for your portfolio.

Designed for flexibility, you can share these out as live prototypes with links (they’re set to allow scrolling and will auto-update as you modify your files), or you can export them as PDF’s, PNG’s etc. if you want to send them as standalone files.

It’s only $5, and can help save you a ton of time and effort (talking like a day or two’s worth), and if you’re interested, you can get it right here:

Bringing it all together

To recap, what makes up a high-impact case study?

1. A punchy opening
2. A robust presentation
3. A compelling narrative
4. A tour of deliverables, and
5. Insightful takeaways

Typically, the sections you’ll have include:

• Discovery
• Design
• Validation
• Outcomes

And typically, you’ll want to avoid:

1. Anything that you can’t legitimately prove.
2. Being too wordy or long-winded.
3. Going crazy with the layout.
4. Not making your case study scannable.
5. Making your case studies too hard to find.

Nick Lawrence Design
Website | Portfolio