Lately, I’ve seen more and more talk about the importance of something referred to as “storytelling” in the designer’s career. For whatever reason, the rate at which I see and hear (e.g., on social media, the increase in Medium headlines, IRL discussions) mentions of its importance appear to be increasing.
Interestingly, when reflecting on my seven years as a designer, I cannot recall any discussion about this concept (as applied to design) prior to the last year. There could be many explanations for this, however: faulty memory on my part, being largely limited in my socializing until about last year, something specific to my more recent social circles, or that this might not simply be a clear case of frequency illusion. It’s hard to say. What’s more, I don’t even have proof that the rate of discussion concerning “storytelling” is actually increasing in design circles, more generally.
So, I don’t know, it’s possible this discussion is best explained by something else, and it’s actually not as trendy as I perceive it to be. Regardless, it’s possible that you’ve noticed this uptick in discussion around this topic, too. For me, it feels like this topic has suddenly grown in popularity in professional design circles — this is similar to other topics, including design systems, design tokens, and others. I don’t have a fundamental problem with trends, but I do often feel that more scholastic trends in design can be misleading. I’d like to explain what I mean.
What’s “storytelling”?
For those who don’t know what I might be referring to, let me provide some context: there’s been a lot of discussion about the importance of “storytelling” in design, with assertions like “good case studies tell a story.” There are numerous articles concerning this topic, making these same assertions. A search of storytelling design case studies returns numerous results. Coming in at the very first result, there’s this one, from Indeed, which explains:
…I’m a believer in looking at a case study like a story, especially when it comes to UX disciplines. A good story needs a plot, characters, and a conflict (user pain-points, anyone?) It also requires a beginning, a middle, and an end. When the storyteller leaves these things out, it’s harder for the reader (the hiring manager) to follow along. It’s difficult to understand where the project started, why it happened in the first place, and what the outcome was.
I do think it is an exaggeration to say that good case studies require “characters,” a “plot,” and so on. Nonetheless, I think this is largely a set of assertions I otherwise agree with. But, in most advice that I see, there’s a real focus on how to talk about one’s work — how to fancifully describe things, how to tweak exact word choices, how to develop a narrative arc, etc. While I agree these things can be important, I don’t think any of that should be as high priority as other matters. Consider the following:
1. Wordsmithing only goes so far
I don’t mean to suggest that there’s no effective (or ineffective) way to talk about one’s work — certainly, if one were to jump right into some feature work without first explaining what it is one is even about to show, the interview panel is likely to be extremely confused and, ultimately, bored and checked out. But consider that other human beings are also capable of the very same reasoning that you possess. This is to say that that those of us on your panel will notice when your work is not actually very interesting or complex — no matter how fancifully you talk about it.
The highest priority for you should be to acquire interesting work. As a professional, you’re incentivized to seek more and more challenging work to add to your experience. If you, as a designer, only have website redesigns, or implausible prompts from your program, or small improvements that were not particularly demanding from your job or summer internship, then this is a problem that “storytelling” cannot fix. Your first order of business is to find good, hard, and honest work to do.
If you have a formulaic case study (e.g., “problem statement,” followed by a “persona,” then some Google Forms research, some “competitive analysis,” etc. — you know what I’m talking about), you’re going to have a problem getting leads, but also landing any of ones you do get. You cannot use fanciful language to plug a plausibility-shaped hole in your work.
Never fear: if your design program/current job is not a source of difficult and interesting work, there is a solution: you can actually generate your own work on your own! If one is so inclined, feel free to read an article wherein I describe how to do this, here:
If one should like, one may also consider another article that is pertinent:
The priority should always be to find some good work (or make it yourself), and then just tell the truth — rather than a story. Formulaic case studies are neither interesting nor truthful, so they aren’t going to help you. You need some good source material: a real piece of software that actually makes sense. Then — and only then — would it make sense to tweak one’s language and delivery while explaining what happened. But not a moment before. You won’t be able to wordsmith your way into technical roles.
2. Simple communication is best
You’re just recounting some events of a product or feature you built, or almost built — this is mostly in a chronological fashion. Don’t concern oneself with what “storytelling” is or isn’t, though, or how to be “good” or “bad” at it. Don’t overthink this! Just explain what happened while you were building some software — where it started, where you got involved, what you did (specifically), and what happened in the end (if applicable, as it’s possible it’s still in development, etc.). They have to have basic information about the product before you dive into it.
Consider that people probably will not know what you are working on, what company you’re at, what that product you’re working on even is, or why someone would use or buy it. When recounting the events of a product or feature you worked on, explain it all as if you were explaining it to a loved one. Explain — with clarity and specificity — what the company is, what the product does, what you were hired to do at the company (“I build enterprise tooling for our customers advertising on this social media app”), what your team on the product does (unless you’re working at a small company, there are going to be many product teams, so be sure to talk about the focus of yours, specifically). If, for example, your mom doesn’t get it and still has questions, so, too, will your panel.
For this reason, you should default to simple communication. There are many stories that are intentionally overly fanciful and complicated (see: much of the fantasy/young adult genre). You don’t get points for using ten dollar words. Just speak plainly, explain necessary context quickly, get people on board, and then talk about what you did — specifically. The entire objective of a case study is so that people understand what you are talking about. If people do not understand, then you’re probably not getting the job.
“Storytelling” sounds really cool, but what you’re doing is just using human language to recount some situation you were in to random people who don’t really know who you are, or what your team/company is. Luckily, you’ve been recounting your experiences to friends, family, colleagues, and etc., your entire life, so you have this in the bag. There’s no special sauce here, you’re just explaining something that happened to you, something that you did — you got this!
3. Pass the vibe check
I don’t know about all this stuff about how “every good story has a villain” and “narrative arcs” — I’m sure this way of thinking is popular for a reason. That said, I am pretty boring, so I just prefer to recount events as they happened — I think people appreciate plain, simple language and sincerity. This doesn’t mean one has put people to sleep, though.
For example, I sometimes crack jokes about something funny or unexpected that happened during my recounting of events. I try to keep people entertained — ideally get some chuckles out of my audience. Notice that comedians tend to recount simple events, and then come in for the kill with an unexpected twist. They do this in a matter of minutes — sometimes seconds. The way I see it, if I’m going to spend the next (at least) thirty minutes explaining something to my panel that they don’t intrinsically care about, I figure it should be worth their while. I should simultaneously inform and entertain.
To put this another way, I am a big fan of hospitality, so I like to think of this as if I have some buddies over at my place. There is an unspoken expectation that I provide good hospitality to any guests: put them at ease, provide good food, a good climate, comfort, good vibes, etc. So just be pleasant. Make it so that your panel choosing to “come over” to your “house” (your lineup of work, in this case) is worth their while. Make sure they come away feeling good about you, as an individual, and that they had a good time getting to know you.
I can imagine that telling a fanciful story can make one more likable, which is cool, but one doesn’t have to make villains and characters and so on to be seen as likable (I think). Just pass the vibe check in whatever way feels good to you.
4. Case studies, historically, are highly technical
You might have heard about medical case studies — this is probably from where the concept derives, and where designers borrowed it from.
Medical case studies tend to be extremely dry, and start with summarizing the important context about the patient (age, sex, aggravating conditions, etc.) before jumping in to their specific diagnosis. Here’s a short example, from John Hopkins, of a case study of two patients, where the analyst explores differential diagnoses and the follow-up for patient treatment. Notice that all information provided in these two studies exist to give context needed to understand the final diagnosis, and follow-up information about treatment.
But case studies have existed for a long time — they have been mainstays in our species. Here’s an example of one from 1600 BCE:
CASE 25. A DISLOCATED JAWBONE (9, 2–6)
TITLE
Practices for a dislocation in his jaw.
EXAMINATION AND PROGNOSIS
If you treat a man with a dislocation in his jaw, and you find his mouth open and unable to close, you have to put your thumb under the end of the rami of the jaw inside his mouth, with your two forefingers under his chin. Then you push them into their place. Then you say about him: “One who has a dislocation of his jaw: an ailment I will handle.”
TREATMENT
You have to bandage him with alum and honey every day until he gets well.
Excerpted from The Art of Medicine in Egypt. Copyright © 2005 by The Metropolitan Museum of Art. New York. Reprinted by permission.
To give an example of a contemporary case study exploring the improvement of carpal tunnel via surgeon, a surgeon describes on video his work (if you, like me, are squeamish, the ending will terrify you, so avert your eyes!):
Case studies are common in medicine, particularly among surgeons, and providers who work in extremely complex disease and other conditions.
Case studies can also be found throughout the history in psychiatry and psychology, too. In this case, psychotherapist Andrew Hortz describes a thorny case he worked on, writing:
A few years ago, I provided psychotherapy to a 20-year-old White female college student whom we’ll call ‘Amanda.’ She had regular conflicts with her parents. She was irritable, unfocused, and depressed — and had little energy for much outside of surfing the web and brooding in her room. She smoked pot regularly. She had friends, but felt socially isolated. At first, our sessions focused on her depression…
He goes on to describe what, to him, was a case “riddled with pitfalls,” but one in which, nonetheless, he did end up finding a diagnosis that fit her. He has advice for how people like Amanda can grow, improve, and become more psychologically resilient, and how he helped her. In this particular case, there can be lessons learned that bubble up even to society-level concerns — this is what has made it such an interesting read (to me, anyway).
But medicine and psychology are not the only places where case studies occur. Certainly, they occur in law enforcement — post mortems are done to study particularly effectively closed cases, or particularly poorly handled ones. These can be highly revealing internally, and help enforcement learn how to be more effective, and learn from all kinds of cases. Throughout history in the States, the FBI, CIA, and local enforcement have been reported to build and share case studies internally to improve their policing, for example.
As you’ve seen, there are many case studies across many industries. They are often used to share industry knowledge and learnings with other professionals, as is in the case of medicine, psychology, and law enforcement.
But design case studies are different — these are used as sales material to acquire customers. Agencies make these, too — any individual or company selling professional services wants to demonstrate their domain-specific knowledge, and convince would-be customers that they are a provider worth buying from. With this being said, your case studies are being used as sales material, and so the extreme detail seen in the case studies of surgeons may not be appropriate (as they mainly exist to help other professionals learn practical skills and gather information from complex cases). That said, the main themes are still there: describe your patient (your company and product), explain their symptoms (describe the status quo, or what is currently going wrong), go into detail about how you specifically addressed their ailment (talk about the exact design(s) you worked on to address the stated concerns), and then describe how the patient responded to treatment (describe any evidence you might have that your product worked or, if none are available, how you might adjudicate that).
Where possible, I will always propose sincerity and plain language. In case studies, I would suggest those same principles. While I can understand and appreciate the usage of “storytelling” as an analogy to help others understand the importance of having some engaging and compelling content to show interview panelists, I would still recommend staying focused on content of one’s words, precision, craft, simple and easy-to-follow language and reasoning, and friendliness. I don’t know that there’s much else to it. I can understand that indexing on “stories” can be helpful,— I do — but I wonder if one wouldn’t simply be better served by saying what’s (in my view) actually underneath it all: good work, explained simply and sincerely, and perhaps with some enthusiasm. As long as one focuses on good, interesting work, I think there is not a need for heroes and final bosses.
