Another topic that cyclically appears throughout the Design blogs and publications dedicated to Design is centered around writing effective Case Studies. And that of course is tied with the effectiveness of having substantial and meaningful portfolios, ones that explain a process and not just an output of a process (or even gratuitous UI/Visual Design exercises which are substantiated by thinly defined problem statements, which in reality end up not solving any problems whatsoever, and even raise questions if those same concepts can even be delivered and implemented properly). As is the case with Portfolios, when it comes to Case Studies, the essence of what makes one effective is the convergence of three aspects: content/substance, organization and support materials. Also, if I may volunteer this tidbit of recommendation, while showcasing what Human Centered Design principles and philosophy is always a nicety, and provides additional lauds/kudos for Professor Don Norman and for many of his peers, it’s not necessary to explain at length what they are. Chances are, if your readers are not familiar with this topic, you can always link it to an article located within NNG or the Interaction Design Foundation, where your readers can actually get the information from its actual source.

Introduction — Before starting the Case Study itself, and much like a newspaper article, create a lead/introduction to what you’re about to showcase. That means, indicate and succinctly describe the Organization you were working with, the players on your team, the duration of the engagement (that spans the duration of the case study itself), the methodology you used, and even optionally, some of the tools you utilized during the process (depending of course on how granular you want to be). Just as importantly, contextualize if you’re writing about something that is an actual product or feature, as opposed to something that is just a concept, or an Academic endeavor. Having read through countless case studies, it’s always something that is not entirely clear: is this case study about something that is actually a live product or just an abstract concept. It’s not about the merit of one versus the other, it’s about getting a sense of collaboration, integration and fit to market efforts.

Document the Problem — Much like Human Centered Design epitomizes, “Understand and Address the Core Problem”. Which means, when writing a case study, be sure to clarify what is it that you and your team set out to do and solve for. Oh and why were you all choosing to do that particular endeavor and not something else. Documenting the assessment of a problem, illustrates the actual genesis of a product or feature or even redesign effort. It may be due to the identification of an opportunity (which in itself, can come from a discussion with a client), or because metrics are indicating shopping cart abandonment or issues with onboarding, or even because new competitors are emerging and following a thorough market research, senior leadership decides to revisit the product offering. Whatever is the case, knowing that prompt, the particular trigger, helps readers understand the journey that is going to unfold in front of them. Another recommendation: usually statements such as “we looked in the market and found an opportunity” or “we identified a gap”, can be somewhat generic and vague. Remember that broad statements can typically lack depth of data to substantiate them, and always consider that any Product Design Endeavor is a considerable investment, therefore anchoring your statements in facts goes a long way.

Explain the Process & Milestones — Which typically means, a continuation of what you indicated and prefaced in your introduction. If you use a Lean Product Design process, briefly explain what motivated that application, and what techniques you utilized in order to apply it. If you use FAST (Focus, Attendance, Summarization, Translation), with proxies for users, also explain the reason for doing so. Remember, the goal is not having case studies that read like a formula or a recipe. The goal is to have a narrative, a story which properly illustrates what you and your team members and partners on that journey actually did and why. Be sure to detail how you crafted your Research endeavors, keeping in mind to explain who were you solving the problem for (staple 2 of HCI, People centered, and not technology centered). Indicate the types of research that were applied in order to justify the decisions that were made. That includes detailing aspects surrounding the types of research that were used, which can include Ethnographic studies, Customer Interviews, Surveys, Analytics (or Metrics), Tree Testing, A/B Testing, Desirability Studies, among others, anything that demonstrates interaction with users and just as importantly, what was done with the information from those interactions and engagements. Document Workshops, cadences of those workshops, and how the solution became crystalized, either through the identification of patterns, expectations, opportunities, market reconnaissance, and how that eventually morphed into a flow (or journeys), and its evolution to eventually becoming something users responded to (HCD principle 3, Use an Activity centered systems approach). And of course, document the artifacts created throughout the process. Sketches (and at this point, actually document sketches, not random cryptic scribbles that represent nothing), wireframes (yes, these are needed and do make sense, particularly as you expand interactions from the early validation efforts which were done with sketches), and UI driven prototypes, in summary, succinctly document anything and everything which substantiates the different layers of testing that were done with users (HCD principle 4, Rapid Iterations of Prototypes and Testing). Artifacts aren’t of course the goal of a case study, but illustrate it perfectly, bringing to focus the milestones and activities that were developed during the process itself. And finally detail the process of handoff and communication with Development Teams. Illustrate the quality control process, and how the process of Story Writing, of documenting iterations, issues, actually occurred, and how involved the Design Team was on that part of the journey itself.

Measuring Outputs & Statuses — Many of the case studies I’ve been reading usually end their journey with a conclusion, usually under the guise of “My Learnings” or “My Takeaways”. And typically those translate into some lessons that illustrate how the application of the process enabled the Designer to learn more about the industry and how to facilitate collaboration with peers. While that is a commendable aspect, ultimately it is not coherent with the narrative the Case Study sets in motion. Remember that when the introduction to the case study was made, you as the author, clearly indicated that there was a focus on understanding opportunities, market gaps, possible friction with existing solutions, and the list goes on. The point being: the process of either crafting a new product or feature, or redesigning something, is costly and lengthy. Therefore there are Key Performance Indicators that the Business expects to be met. Which can translate into sales volumes, account creation, market reach, whatever those KPIs may be. Document these clearly, indicating the impact that the solution translates to the Organization, to Users/Clients and to the team itself. While the learnings one brings from these situations are invaluable, Case Studies should primarily have a component of being factual representations of a process, one that returns outputs and measurable value. Include post launch research endeavors, voice of the customer data, anything that further cements the solution that was brought forth.

Case Studies are very much like synthesizing a research endeavor in itself. You have to analyze an entire process and summarize it in a way that is illustrative, without being excessively detailed. These studies also serve a point of demonstrating a Designer’s point of view when communicating, highlighting one’s capacity to be succinct, efficient and also pepper the content with just enough detail to keep the reader invested. Case studies don’t need to be 50 pages long, since that defeats the process of summarizing a process. They should capture one’s attention, and just like a story well told, take us on a journey.

I’ll conclude this brief article with a quote from Steve Jobs on the topic of storytelling:

“The most powerful person in the world is the storyteller. The storyteller sets the vision, values and agenda of an entire generation that is to come.”