Somewhere at the intersection of ‘in-depth understanding’, ‘longitudinal data’, and ‘mixed-methods research’ lies an underused approach: case study research. It’s where you weave various sources of data together into a narrative, creating a rich and detailed story about What Happened. And perhaps What Didn’t Happen.

I think case studies are an almost guaranteed route to valuable insights, especially in complex and time-intensive user journeys.

In the social and health sciences, as well as many other domains, case studies are an established research approach. I’m purposely opting for the term ‘research approach’ here, because there doesn’t seem to be much agreement about whether case studies are a method, a methodology, or something else altogether. Regardless, the definitions these domains use are largely applicable to the world of UX and product development too. Take, for example, this definition from a book about nursing research:

[A case study is] an intensive, systematic investigation of a single individual, group, community or some other unit […] within its real-life context […]. Typically a case study involves one or several cases that are studied over time using multiple data-gathering methods.

Nursing research: theory and practice (1988) by Nancy Fugate Woods and Marci Catanzaro

Perhaps unsurprisingly, given what I’ve previously written about visualising linear analytics data, non-linear analytics data, and messy journeys, I’m drawn to approaches that involve developing a rich picture of a small number of users. Case studies are just that.

I’ll attempt to convey what makes case studies so compelling as a researcher.

Context

In academic publishing, where I currently work, the ‘end-to-end journey’ usually starts with an author submitting a manuscript to a journal. Provided it passes various quality control checks, the journey eventually ends with the work getting published. In the best case scenario, this can take several months. Some publishing journeys take years. During that time, the authors often use many different services, created and maintained by many different teams. Behind the scenes, the number of systems and people involved is even greater. When everything goes well, it is a mammoth of a process to map. When something doesn’t go well, unravelling the reasons why can be quite the task.

Through quantitative data, we occasionally identify an area in this journey that we want to understand better, for whatever reason. The complexity created by the combination of systems, teams, policies, research domains, countries, and the sheer number of people involved sometimes warrants a case study.

Phases of a case study

1. Case selection

The core concept of a case study is to investigate one case (or a very small number of cases) in great detail. In my context that usually means looking at one user’s journey from beginning to end, either retrospectively or while it’s partially underway. How we select a user to focus on varies, and depends on the aim of the study. The starting point can be a support query, a comment made in a survey response, the characteristics of their journey, or anything else that indicates the user has experience with the part of the journey we are investigating. And then it all depends on whether the user is willing to take part, because a case study without their input is unlikely to be as fruitful.

2. Data collection

Once I know which user’s journey to study, the data collection can start. In order to know where data might live, I first dissect the journey and identify which teams and systems may have been involved. Some of these systems I might have access to myself, but most require the relevant specialists (product teams, customer support, finance, etc.). I’ll contact these people, explain what we’re doing and provide the information that allows them to check if they do indeed have data – like the manuscript number. While this may sound time-consuming (and it is), this process is essential for understanding the journey and who needs to be involved in the later phases of the case study: we’re mapping the stakeholders and systems against the journey.

Some data is likely much easier to gather than other data, but I usually attempt to collect the data in a somewhat coherent order:

• Key facts of the case: identifiers, dates of events, status changes, etc.
• Names of systems and people that may have data on the case
• Any available system or log data
• Communication data: emails, support queries, internal communication
• Any media files such as photos, videos, screenshots
• Any observational data
• Internal perspective: interview(s) with main stakeholders, using the data collected so far to guide the interview
• User’s perspective: interview(s) with user, again using the data collected so far to guide the interview

A convenient aspect of retrospective case studies and case studies of journeys-in-progress is that you don’t need to wait for the user to progress through the journey for data to come in: at least part of it should be readily available. This means it can be a relatively fast process.

3. Reconstruction

Next follows the most disorientating and challenging part of any case study: wading through the (overwhelming amount of) data and reconstructing what happened. This may involve organising data along a timeline, or sorting the data by system, team, or communication channel – whatever helps piece together the overall story. This phase is highly immersive, it’s where you need to connect the dots between system data, communication, observations, interview comments, and any other sources of data. It’s best done collaboratively, both to improve the analysis and to avoid getting lost in the data.

The use of multiple methods and multiple sources as forms of triangulation makes case study findings not only more comprehensive but also more complicated, because so many perspectives are represented.

Case study research (2003) by Patricia A. Hays in Foundations for Research, Routledge.

Once a rough picture is starting to emerge, further interrogation of the data is required. Depending on the nature of the study, this could include:

• Where are the gaps? What is missing?
• What are the key events?
• Where does the data contradict?
• Where could/should things have gone differently?

4. Narration

Once the reconstruction is starting to make sense and it feels like a story is coming together, I consider how to document and narrate it. The volume and richness of data often means it isn’t sensible to share the full timeline of events, instead a clear and convincing (pseudonymised/anonymised!) summary narrative is needed to make others understand the sequence of the events.

For a recent case study, I opted for a heavily annotated journey map: the key facts on a timeline in the middle, the user’s perspective on those events to one side of the timeline, and the organisation’s perspective on those same events to the other side. A case study triptych, if you will, to highlight the contrast between the user’s experience and the internal perspective on these same events.

Where appropriate, it may also be helpful and fair to provide both internal stakeholders and the user an opportunity to respond and add to the narrative. A more collaborative version of journalism’s ‘right of reply’. The intent is to understand and, ultimately, to figure out where to improve – not to point fingers.

5. Reflection/Action

And finally, time to bring together all the relevant people to do a debrief. What happened? What can we learn? What should we investigate further? What can we change? Who will act?

In my context, the duration and complexity of the journey means the stakeholders often only know their own part of the journey in great detail. A case study is an opportunity for everyone to step outside of their organisational silos and reflect on how the various components have worked, or not worked, to result in this experience.

By zooming in on one user, everyone gets to zoom out and see the bigger picture.

In my experience, the learnings from case studies can go far beyond identifying pain points in the journey. Case studies often reveal deeper insights about the interactions between the people and systems, and they raise more strategic questions about the workings of the organisation. A microcosm.

Mystery

As a researcher, case studies are probably as close to ‘doing an investigation’ as it gets. Collaboratively piecing together a complex puzzle. To me, they are challenging and endlessly interesting.

All of this to say: if you’re working on a time-intensive and/or complex journey, I’d strongly recommend doing more case studies. They can uncover a wealth of insights that are very difficult to get to using other research approaches. And for a little while, you get to feel like you’re solving a mystery.