Microsoft Design – Medium | Cheryl Platz

An improv-inspired framework for better customer understanding and better product design

User experience designers are most likely to thrive when we can tell our customers’ stories compellingly. We are constantly defending the importance of costly features and investments by connecting our stakeholders to the real impact those changes would have on our customers.

But in many cases, just saying “This will help customers” is comically inadequate to get the job done. We must create an environment where our stakeholders can truly empathize with our customers, their pain points, and how our solution can improve customer moods and lives. Unless your audience is full of empaths, context and detail usually lead to better, more engaging story.

And yet, few of us got into UX because we wanted to write novels or screenplays — being faced with building that engagement and empathy in our stakeholders is a daunting task. Serendipitously, I’ve found that my time in improvisational theater has been a critical part of my design toolbox over the years.

Building Blocks of Story

At Unexpected Productions, when I teach improv to beginning students, our curriculum is focused largely on exploring the building blocks of a good improvised scene. We have a shorthand for these building blocks: CROW, which is an acronym for Character, Relationship, Objective, and Where.

The more developed these elements become, the more compelling the resulting scene. Not every good scene nails all four of these components, but it never hurts to double down in any category.

Let’s say we have a scene where two people are standing and talking about chocolate. Fine, and perhaps even funny.

• Perhaps one of the characters chooses to display some low-status nervous behaviors physically. Things become a little more interesting thanks to this characterization choice: what’s going on here?
• We may discover the relationship between these two characters when they refer to each other by name (Eddie, the nervous boy, and Sarah): perhaps these two people aren’t strangers but friends. Why, then, is one of them so nervous?
• By a passing comment about “4th period class”, and later interaction with an invisible locker, we discover the where of the scene: it takes place in a school hallway.
• And at some point, the audience discovers Eddie’s objective: to ask Sarah to a school dance for the first time. The conversation about chocolates is their way of building up to the subject.

By establishing CROW during the scene, it goes from a simple conversation to a story worth telling. Improvisors train to do this instinctively with just a few seconds notice.

CROW: Not just a talkative bird or a Game of Thrones plot device. Remember Character, Relationship, Objective and Where to help your storytelling and design skills take flight.

Heightened need for context

But what does this have to do with user experience? For the better part of a decade, user experience designers focused primarily on the craft of building interactive PC-based experiences. We could easily assume our customers were sitting down at a computer somewhere, and that their objectives were compatible with sitting at that device for extended periods of time.

In 2006, with the arrival of the iPhone, things began to change drastically. No longer could we assume a customer was sitting comfortably, or that they had plenty of time. Suddenly, the customer’s story in the moment becomes much more important. Where are they? What is their objective? Who’s around them? And how do they respond to the world around them?

The challenge has become more pointed in recent years. Not only are our customers not sitting at a PC — they might not even be in eyeshot of a screen at all. With a wider range of potential customer needs, objectives, and contexts, the storyteller’s burden on designers becomes even greater.

Applying CROW to UX

So let’s deconstruct CROW again, but in terms of user experience. What parts of your story apply to each of these building blocks, and how can you tease CROW out of your scenarios?

Character

I appreciate the definition of characterization I found in The Improv Handbook while preparing for my first teaching assignment. They divided the concept of character into three components:

• Characterization: Physical traits, mannerisms, and habits. These tend not to change over time.
• Attitude: Emotions and options regarding other stimuli — other people, objects, or situations.
• Choices: The actions we take. But when actions are taken without a clear “Why” based on attitude, characterization, or other event, we see that choice as ‘out of character’.

When we look at our customers through these lenses, a few helpful UX-related questions emerge.

• Do our customers have any physical mannerisms or limitations that would change how they use our experience? This question is tied to accessibility.
• Does this customer persona have well-defined attitudes towards any part of our experience, or the situation our experience compliments? What is their emotional state when approaching our product?

Remember to consider the many characterizations that your customers exhibit. What are their attitudes? Common habits and preferences? How do they express their individuality, and is your product a part of that expression?

Relationship

This is perhaps the most challenging story building block to translate to UX, partially because the nature of the relationships in our stories is often harder to describe.

In improv scenes, relationships usually manifest via the shorthand of names. Two characters who refer to each other by name are not strangers. But the relationship is also a key to emotional reactions — the closer we are to someone (or something), the more likely we are to get emotional about it.

In user experience, the relationships we may have to explore broaden. Examine your scenarios and try to define the web of relationships surrounding your product!

• Human to device relationship: How long has your customer owned the device they’re using? Is it shared? Do they own it? Is it expensive and treasured, or cheap and disposable? Does the customer anthropomorphize the device in any way? Did they name it?
• Human to business relationship: Does your customer deal with you directly, or through a third party? Did they get to choose to work with you, or are they locked in due to monopoly or limited choice? What are their expectations of you in this situation?
• Human to human relationship: In some cases, your product may be used by multiple people, perhaps at the same time — what is their relationship to each other? Do they trust each other?

The human-to-device relationship between a person and their phone is complex, and not without emotion. Have they anthropomorphized it? Named it? How do they feel about their device when they open your app?

If relationships are key to emotion in storytelling, so too are these relationships key to the elusive emotional state of “delight” in our products. If we simply satisfy the requirements, our customers are satisfied. If we deeply understand the relationships at play and honor those expectations, we are on the road to delight.

Objective

The design industry has specialized in identifying customer objectives for years, so this part of CROW should hopefully come naturally. Still, in the face of passionate defense of a particular feature or product, it can be easy to lose sight of the “why” behind our customers’ engagement with our products.

For designers, the O in CROW should serve as a reminder to doublecheck our assumptions. What have we defined as our customer’s objective? Is that truly their end goal, or simply a sentence written to get the customer to our feature?

In many cases, our hardware or software solution is part of a much larger objective and our goal should simply be to contribute to that goal while minimizing friction along the way.

For example — when setting a timer on Alexa, a customer’s objective is rarely simply “I want to set a timer.” Often, it’s “I want to cook dinner without burning my house down.” (Oh, is that just me?) When this objective is extended, we start to see that same cook might need multiple timers at once: one for the potatoes, one for the turkey. Hence, when the feature shipped supporting a single timer, customers started writing in begging for multiple timer support. The single timer satisfied a single goal but not the customer’s overall objective.

I see this loss of objective all the time in software development:

Marketing: We want to make the Subscribe to Newsletter link more prominent to increase engagement.
Design: OK, but what’s the customer objective?
Marketing: To subscribe to the newsletter.
Design: No, but WHY would they want to subscribe? You haven’t explained that here.

Just increasing the size of elements or their prominence on a page won’t create quality engagement. If your feature isn’t supporting a genuine customer objective, engagement is meaningless. Sure, maybe more folks will click on that link — but if they don’t know why, they probably won’t share their email address in the next step.

In this situation, the next move is to examine your customers’ objectives to see whether the newsletter can genuinely and transparently contribute to those objectives. Your customer is looking to save money? Can the newsletter help them do that? Your customer needs to be on the cutting edge? Can the newsletter give them the information they need to be seen as a thought leader? If you’re not solving a customer problem or helping them achieve an objective, your product or feature will not thrive.

We can’t lose sight of our customers’ objectives. They’re not trying to turn a dial or browse a website — they’re trying to make music or find a store location. When we lose sight of objective, our “solutions” become self-serving.

It is when we lose sight of customer objectives that we risk totally failing our customers. Autoplay videos on social media sites are fairly controversial and widely derided. Why? In part because a common customer objective when visiting a social media site is “discreetly take a break or pass time in environments not conducive to sound.” Or in other words, a common objective is “Stay connected to people I care about during my workday without getting in trouble.” In other cases, autoplay videos fail because a different customer persona seeks to minimize their data plan usage.

Where

Last but not least, we come to environmental considerations. Human factors engineers are well-versed in considering the impact of our physical environment on our interactions. User experience designers have, until recently, largely been able to take environment for granted. Phones, tablets, and hands-free UI now open us up to a dizzying array of possibility.

Contextual inquiry is an excellent research tool to help us define and understand the where, and it’s often a lost art. We don’t know what we don’t know about a customer environment until we see it ourselves.

And even when we believe we understand an environment well — a kitchen, a living room- it’s still our job to remind our stakeholders that our customers may have divided attention, and that the decision making metrics we applied to websites don’t necessarily apply for apps or hands-free experiences.

On paper, improvisors would seem to have this story building block fairly easy. Limited only by our imaginations, wouldn’t it be easy to paint an environment for our scenes? But in reality, I find this is by far the hardest skill to learn for my improv students. Even when we do establish an environment, we usually do it verbally. It is very hard for the adult mind to project an imaginary environment onto a real one.

This challenge has real implications for us as UX storytellers. As a designer on Alexa, I had to rely heavily on storyboards to help my stakeholders visualize the “where” of my stories. It’s one thing to say “the device is in the kitchen while the family eats.” It’s another thing to draw the Echo, half-blocked by a kitchen counter and appliances, where the LED light ring can barely be seen.

To define your “where”, ask questions you’d normally observe at a contextual inquiry:

• Is it a public or private space?
• Is it usually noisy or quiet?
• Where is the device located? Is it fixed or mobile? Does it need to be near a charger?
• Is a conversation, or a device that makes sound, socially acceptable?
• What is your customer holding? Are they multitasking?
• Where is your customer looking? Do they see the device at all times?

Once you understand the answers to these questions, find your pain points. Your job is now to draw attention to those pain points, and to help your stakeholders somehow visualize the “where” in their own minds.

Environment and context matter in product design. Are you designing a mobile app? Will your customers have reliable internet where they’re going? In automotive design, parking lots and garages were a real problem. Define your environments clearly to see future problems.

Story as shared understanding

Now that we’ve explored CROW (can you remember the four components?) in the context of user experience, the next step is accepting that you won’t always need or use all four building blocks. Some scenes are compelling without all four building blocks well defined. However, weakness in one area should be mitigated with strength of understanding in another.

In many ways, CROW is simply a new lens to reframe our existing understanding of our customers. Most designers get at elements of all four building blocks on major projects.

But CROW is not just important for our understanding of our customers and products — CROW is critical when telling stories to our stakeholders. When pitching new projects at Amazon, any one of my storyboards could be taken out of context. I needed to ensure each storyboard hit enough CROW to be compelling in its own right.

By ensuring our design stories provide CROW, we avoid making too many assumptions about our stakeholders’ understanding of a problem. And a strong design story gives us all a strong shared context for collaborative decision making.

What story will you tell?

Cheryl Platz is currently Design Lead for Azure Portal and Marketplaces at Microsoft. Her recent career as a designer and storyteller includes time on Amazon’s Alexa, Cortana, and Windows Automotive.

Cheryl is also a veteran improvisational actress, with over a dozen years of professional experience on stages around the world. As a 9-year veteran member of the Unexpected Productions performing ensemble, she also teaches improv with their well-respected improv school at a variety of levels.

Catching CROW: Storytelling for UX Design was originally published in Microsoft Design on Medium, where people are continuing the conversation by highlighting and responding to this story.