Understanding Case Studies in Product Design, Template Much?

Introducing, Case Study

These past few months was a rather interesting time for me, as I was asked to help co-lecture for “Kampus Merdeka” on the topic of UX Design, and also it was hiring season too at the company where I spearhead as their Head of Product Design; I had open slots for product designers, writers, and researchers! One thing in common between those two “events” was case study. It’s an interesting topic as it was one of the key factor of getting hired in our field.

Being able to see the process of a student trying to understand and create a case study, to seeing an actual case study from a candidate, got me thinking that what they’re doing is starting to become a template. Now I’m not saying that it’s a bad thing for it to turn into a template (after all, that’s the way they were taught in regards of the whole “design thinking” framework), but it’s a bit concerning that it seems a lot of them still sees it from a surface level and can’t actually connect the dots between each stage/process. Most of them understands what each stage is about, but don’t really understand that actually each stage effects the next stage. So let’s have a look on those stages briefly and break it down one by one, and see where things usually go wrong, how to actually complete those stages, and finally how they’d actually connect!

Empathise

In short, this is the part where we generate hypothesis of a problem, and validates whether it’s actually a problem or not. It sounds quite simple, just need to analyse the possible problems that someone might have, then ask them whether it’s a real problem or not, sounds easy, right? Wrong.

In order to validate whether it’s a valid problem or not, first we need to really ask the right questions. This is where most people get it wrong, they prepare and ask a bunch of useless irrelevant questions to their respondents without thinking whether the answers will be beneficial or not, and not asking deep enough to find the root cause, just scratching the surface. How do we fix this? For a start, we need to remember the 5 whys methods, which is to drill down the question in order to find the root cause by simply asking 5 “why” for each hypothesis. Another thing that we can do is simulate answering our own questions and analyse whether the answers that we get can contribute to our research or will only become noise. If it’s useless, ask something else.

Define

Now that we’ve gathered (hopefully) the right informations that we need from the previous stage, it’s time to analyse and synthesise them.

What do we use for this stage? The most frequent artefacts used are affinity map, followed by customer profile/segment from value proposition canvas; where we can group the pains & gains, and most importantly the job to be done. By the end of this stage, we can then end it with a How Might We [jobs to be done] question.

Ideate

We’ve identified the pains & gains, and their job to be done, naturally the next stage would be creating the pain relievers (to release the pain), gain creators (to elevate the gain that’s already in place), and finally the product/services (to get the job done). In other words, creating a value proposition. Now there’s a lot of methods on how to ideate which I won’t cover in this post, but the key is to always check whether your pain reliever really answers the pain, and same goes to the gain creators and product/services.

Prototype & Test

You might wonder why I grouped prototype & test in one section; The reason behind this is quite simple, but sometimes when thought separately it becomes a problem, specially when your test scenarios isn’t aligned with the prototype that you’ve prepared.

What I usually do when I’m on this stage is to actually think of what I want to test, to who I want to test this, how I’m going to test it, and finally what prototype I’ll need to prepare to test it; I don’t normally create a prototype before finalising how the test (or research) will be conducted. This is just like what we did on the Empathise stage, in which we need to make sure we need to prepare the right question. In this case, get your testing scenarios straight, then focus on creating prototypes for those scenarios.

tl;dr

Validate the problem by asking the right question; analyse the pain, gain, and jobs to be done; ideate solution that acts as pain reliever & gain creators; finally validate your solution by testing the prototype.

Now, back to the previous statement regarding “template”; It’s great to have structure as it gives clarity. Just make sure to have all the dots connected correctly, don’t contradict one stage over the other.

Cheers!