I get it: your developers barely read the Asana tickets you assign them, your boss is too busy dealing with big-picture problems, and your sales team doesn’t seem to care about the product. So, why would anyone read the great UX case study that you shared on Slack?

And it’s frustrating because if they just read them and listened to the key points, they’d learn something. They’d appreciate design more. They might even give you more resources. Since 2019, I’ve been publishing UX case studies. A lot of the articles that have been shared, but never read, have been mine.

In the next few minutes, I’ll explain exactly why your whole team should care about UX. I’ll also give you a few tips I’ve learned from working with some of the best product teams in the world, about how to actually get your team to pay attention. There are no cheat codes, just hard-learned lessons.

Why is a UX case study interesting?

‍

You love Uxcel (I do too, for the record, and they have a great case study template), but if you can’t get your boss to read an article, they’re definitely not going to engage in the brilliant courses here. So, what is a UX case study?

Well, it’s usually a story of a product. Someone takes a complicated scenario or a user journey and breaks down:

  • The likely impacts of a design decision
  • Why those impacts can be positive or negative
  • How to improve the outcome with some clever UX

You see, you’re not teaching someone how to design; you’re teaching them why design matters. It’s like the first step to converting them to UX believers (after which, you should try and get them to come along to a live event).

They’re interesting to read because, in 10 minutes, you can get really deep on a very specific design feature, flaw, strategy, or impact. Then, if it’s a good case study, you can take the learnings away and apply them to your own product or service.

Who should read them?

In my experience, everyone. I’ve worked with some of the best product teams in the world, and people always ask me what the key differences are. Well, one thing I’ve noticed is that everyone in the entire product team cares about the user experience. They might not care about pixels, they might not ever log in to Figma, or they might not even understand what design tokens are. But they care.

With Built for Mars, I’ve run experiments on product teams with hundreds of employees and watched as that fire in my belly (for UX) transcends job roles. It’s infectious to care about what you ship.

  • Developers notice inconsistencies between Figma and their designs before sending it to QA. They also start problem-solving designs themselves (because not every page is always designed for every screen in Figma).
  • QA testers are liberated by having psychology and best practices to lean on. No longer are things “working” or “broken”. They can be “kind of working, but feels horrible”. UX gives them a way to describe that “horrible”.
  • Leadership teams can start to put resources into their user experience without focusing on pixels or the design cost. It’s hard to justify spending £100k on “design” because you imagine your website. It’s easier to spend £100k to “delight and retain customers”.
  • Designers get better. We thrive off this stuff. We’re all constantly learning.

Here’s the kicker that most people miss: your team is usually blind to your product. They’ve seen it hundreds of times. They understand every inch. But, by showing them examples that aren’t of your product, you can trigger part of their brain that has been switched off.

Context is the key to getting your team to read them

The key is contextualizing the benefit that they’ll directly receive. I’ll use one of my own as an example: a case study on Trello. Now, “read this UX case study on Trello” doesn’t sound very interesting, does it? Why? Because you’re not building a Trello competitor.

Why would anybody waste their time reading a long article about Trello if they’re not building something like Trello? The internet is full of good content that I’ve not read. So, they skim it and lazily reply that it sounds interesting. Or they leave it on an open tab and forget about it. Either way, you didn’t contextualize why it was beneficial.

Instead, imagine a message like this:

“This article about Trello is very similar to our onboarding. I think there are a few things here we should consider copying because it might be why our activation rate is so low for that new feature”.

To be clear, that’s not a message to copy and paste for any case study, but I’m trying to demonstrate a point: people need context. Busy people need context and a predicted outcome. Even better if you can bundle it with some internal analytics:

“I checked our analytics, and the activation rate for that new feature is only 24%. I found this article, which is very similar to our onboarding. I think there are a few things here we should consider copying because it might be why our activation rate is so low for that new feature”.

Notice that I didn’t even mention Trello; Trello isn’t important anymore. Nobody cares if it’s Trello, Airbnb, or Yahoo. What matters to the wider team is the impact on the business. But that sounds like a lot of work for me. It’s some work, but it’s such an asymmetric reward.

  • More resources for UX (both functionally and to learn)
  • More appreciation for UX challenges
  • More team awareness of UX and prioritization of initiatives

Uxcel helps you become a better designer, but great case studies can help everyone around you understand why your designs are better. I publish free case studies every month, but this same logic applies to any great case study in any industry, topic, or language.

‍