Storytelling is a key tool of design. At its simplest, a story is people doing stuff to achieve goals. For example, a classic storyline is boy meets girl, boy loses girl, boy gets girl back. The boy and the girl are the people, the stuff they do is meet, break-up, and get back together. And the goal is finding true love. In enterprise design, stories are often not so simple.

Basic elements of a design story

Enterprise design stories

Unlike consumer design, where the buyer and user are usually the same person, enterprise design focuses on companies with multiple stakeholders. These stakeholders have interconnected and sometimes conflicting goals and pain points. For example, the CTO of a company might buy software that is cost-efficient, while the hands-on users find it difficult to use and prefer other software they find easier. However, management stakeholders are often directing hands-on users, setting their goals, and measuring their results. And there are often multiple hands-on user roles working together in task flows to achieve the larger company objectives. Our enterprise design stories need to tie all these layers together.

Stories like a layer cake — yum!

At VMware Design, our multi-layered stories are structured a bit like a layer cake — my favorite food! At the center are hands-on user stories, where we show how people interact with our products to achieve business goals. Along with hands-on user stories are technology stories where we show how we leverage technical know-how to simplify and improve the user stories. But while the user and technology stories are central, they are not where we start.

We start with the customer story — the organizational level story with stakeholders seeking to create value for their company. It is here that goals and pain points are driving the search for a solution. It’s like the buttercream filling that holds the user and technology layers together.

The customer story layers

What’s the recipe?

While every multi-layered design story (like every cake) is unique, there is a recipe for making it. Our recipe is to start with user research, choose an important customer problem, identify the stakeholders and hands-on users and their goals, then ideate on solutions. Like any good design thinking process, we consider technical possibilities (what’s feasible) and sustainable business models (what’s viable) — but we’re looking for innovations that tell a desirable story.

The multi-layer story creation process

Customer goals — the buttercream filling

For example, one of our stories starts with stakeholders looking for flexible infrastructure options. The IT Director is worried about aging datacenters and the CIO wants to start using public cloud. The CFO is concerned about managing costs between on-prem and the cloud. While the VP of App Development wants to move to DevOps, containers, and continuous delivery in modern app frameworks. The stakeholders make these their organizational goals.But having a goal is not enough, they need a solution and a plan for getting there.

Example of stakeholder goals and pain points

The hands-on users are tasked with identifying and building the solution. The IT Architect starts with the organizational goals while also listening to the pain points of the hands-on users. The Virtual Infrastructure Admin spends too much time upgrading on-premise software. The Security Admin needs new technologies to address modern security threats. The Developer just wants access to a Kubernetes cluster and does not care where the infrastructure is running. All of these hands-on user concerns need to be part of the solution.

Example of hands-on user goals and pain points

Measuring success

At the end of the day, the measure of success is not whether the hands-on developers or admins are using their favorite tools. The real measure of success is whether the company can deliver new services quickly and is achieving its goals in the marketplace. Our multi-layered stories tie the hands-on user activities back to those organizational measures of success.

One more layer — the market story

But wait — there’s one more layer to the cake (did I mention I like lots of layers in my cake? It improves the frosting to cake ratio!). The final layer is the market story — where we are in the market today, the change we want to make, and how this solution helps that change. This is not putting VMware’s interest before the customer’s; it’s about ensuring that those interests are aligned so we can deliver what they want while running a successful business.

The VMware market story layer

Aligning our market and customer stories

For example, the company above needs to create a new application in the cloud quickly. They run their current data centers on-premises with VMware software, but it can take months to get new hardware for a project and they don’t have that time. They could start new on a public cloud platform, but then they need to educate teams on the new platform and change their operations. They don’t have time for that either. Luckily, VMware’s market story is closely aligned with their goals.

VMware is the dominant virtualization platform for on-premise applications, but VMware wants to expand their market to the public cloud. The VMware vision is for a hybrid cloud where customers can easily move workloads back and forth from on-premise to the public cloud. Customers can provision new infrastructure in the cloud in minutes while maintaining operational consistency with on-premise applications. They can do this with seamless networking that is private and secure. In this market story, VMware’s interests and the customer’s interests are perfectly aligned.

Everybody gets a slice!

So, our multi-layered design stories align our hands-on user tasks with our technology solutions, with customer stakeholder goals, and with VMware’s market direction. It’s a sweet story that not only looks delicious but tastes great and everyone gets a slice! I usually take two or more! Wait, maybe that’s just at birthdays. And holidays. And Wednesdays. You get the picture.

Write the script

Now that we know the ingredients of our multi-layered story, let’s talk about the steps of the recipe. Our storytelling starts with a script. The users and stakeholders are our cast of characters. The organizational goals and pain points set the stage and create the dramatic tension. The users’ goals animate their motivations and their pain points provide the obstacles that they must overcome in their journeys. However, this is not noir fiction, we don’t make them suffer. We tell a story where the hero wins in the end — the hands-on users are the heroes and they achieve both their personal goals and the organizational goals by cleverly leveraging our technology and processes.

The following shows the outline of a script for VMware Cloud on AWS Outposts — a new service offering combining VMware software on AWS hardware delivered on-premises.

Example of scenes in a storyboard script

Visualize the script in a storyboard

Our scripts are often simple text documents that describe a series of scenes that can then be visualized in a storyboard. By moving from text to pictures we start to introduce the objects and actions that users interact with. We show which users are interacting with one another and the results of their actions. The early scenes always illustrate the stakeholders and their goals. That’s followed by scenes where hands-on users learn about our solutions and choose to try them. The storyboard will show how they quickly move from learn to try and from try to buy and eventually to grow their use of our solution to meet more of their goals.

Example of a storyboard visualization

Embody the story in an interactive prototype

The last step in our recipe is to realize the story as an interactive prototype. This is usually pretty high fidelity, but often a narrow path that follows the storyboard — not a prototype that would allow for a lot of exploration. We are more focused on how compelling the story is as a concept for our customers — do they see themselves in the characters? Do they believe that they will be able to follow the same path and accomplish their own goals?

Example of an interactive prototype

Judging the cake — “Yum?”

The prototype is also an important tool for telling the story to our internal stakeholders. Does it show a technological solution that we can deliver? Does it show our ability to sell the solution to our customers and grow our business? Does it show the change we want to make in the market? It’s like presenting our finished cake to the expert chefs for judging — how does it look? How does it taste?

The answer is not always “Yum!” Every level of these stories is likely to be iterated — from the target stakeholders and their goals, to the possible technology, to the marketing messages, to the hands-on users and their interactions. We try to make the story real so we can eventually reach alignment, but the chefs do a lot of experimenting to make a delicious story cake.

Multi-disciplinary story team

So, who are the chefs? It’s not just the design team. The story team includes multiple disciplines, including product management to help with the customer and market research, marketing to help with the stakeholder goals and product positioning, and multiple types of technical architects to help with ideation on technical solutions and feasibility.

Multi-disciplinary story team

The last crumbs — leading with design

The VMware Design team’s use of multi-layered stories has enabled us to make user experience the guiding light on new product development. Not only are multi-layered stories one of the design team’s key goals for 2019, but executives, product management, and engineering are all looking to tell the story first — from the stakeholder and hands-on user perspective — and then figure out the plan to deliver the story. It’s a process that gives us the information we need for good design while also bringing together our internal stakeholders on a shared vision for our products. It’s like we can have our cake and eat it too ; )