As a young boy I eagerly looked forward to Sunday nights. After dinner and a warm bath, I would sit in front of the television and watch The Muppet Show with my family. As a grade-schooler, it felt as if my family would invite the whole cast of characters into our household - Kermit, Miss Piggy, Fozzy Bear, the Swedish Chef, and Animal, to name a few. However, if any of these characters were really invited over for dinner, I suspect we might prepare each meal differently depending on who was our guest. Being sophisticated and expecting the finer things, Miss Piggy would demand we take out our fine china with fancy place settings. Clearly, we would not serve bacon-wrapped ANYTHING. On the other hand, Animal might have difficulty with foods that could not be cleaned up easily, like grape juice or spaghetti with marinara sauce, and we'd have to use paper plates. As host for this dinner, my family would need to thoughtfully consider each guest before making decisions about the meal we might serve.

Similarly, in the workplace, we need to consider the unique needs and goals of each of the people we ultimately serve: the coworkers, users, buyers (or whomever you consider your customers) of the programs, products, services, or even policies that impact them. Short of involving our customers in every step of our work to influence our business decisions, we can leverage personas. Personas are fictitious, specific, and concrete representations of target customer groups for a product or service that creates a sense of empathy for real customers. They provide an actionable narrative that leverages research, as well as internal understandings.

The Sad Truth

Personas are the result of rigorous research, often a combination of qualitative and quantitative research. There are different types of personas too, depending on the need. Marketing-focused personas help businesses make decisions based on their understanding of their current or future customers. These personas often benefit for-profit companies who seek to make revenue-based decisions for attracting and retaining customers. On the other hand, product-focused personas help businesses make decisions based on the behaviors, needs, and goals of users of their products. These personas benefit companies who produce digital or physical products, informing such things as the product roadmap or features that might best meet the desires of its user base.

Unfortunately, in the product space, these personas are often left collecting dust on the shelf. Why? There are a few common reasons, including:

• Focus on Tech: Technical teams may be so solution-focused that they prioritize their understanding of system roles and permissions rather than taking the time to gain empathy for real people and their usage stories. They may think that it’s not their responsibility to have a deep understanding of their users’ needs and goals.
• Focus on Business Goals: Businesses build roadmaps based on organizational drivers and may not regularly collect or consider customer feedback. They may think that it’s not their responsibility to have a deep understanding of their users’ needs and goals.
• Focus on Delivery: Product teams sometimes rush to a solution before understanding or addressing the right problem. These teams design and develop for themselves, assuming they know what’s best for their users. They may think that it’s not their responsibility to have a deep understanding of their users’ needs and goals.

In my experience, successful teams do not only focus on their own skill sets and individual responsibilities. They share the critical responsibility of knowing who their users are and understanding their unique needs and goals. One design leader I look up to argues that it is the responsibility of everyone on a product team to "embrace regular and frequent exposure to users.​ 2 hours every 6 weeks​." (Jared Spool, User Interface Engineering). While that may be impossible to achieve, it begs the question, when was the last time you observed customers using your product or service?

Getting Started

I sometimes ask clients, "Who is your customer?" Regularly I hear people respond with one name, such as "buyer" or "coworker." The fact is that each of us should be able to identify at least three customers who benefit from our work. So first, we must identify those unique people types that benefit from our product or service. Even if you do not have a research-focused person on your team, you can develop what are called "proto personas," which are hypothesis-based, unvalidated by real users. Take some time to document what you already know - locate background materials stored somewhere. Speak to people in your organization who have interacted with these people. Analyze quantitative data stored in a database somewhere. Or simply recall experiences you've had interacting with these people. While there is no universally accepted format or style to tell this person's story, there are a few things we might include. In fact, after an analysis of various personas created across a community of product teams I work with, I identified some common elements often included:

• Name - May use a real name or something silly and memorable
• Picture - Real or an Avatar
• Location
• Age Range or Experience
• Role or Job Title
• Quote - something notable that succinctly captures the persona's focus
• Goals - The needs and goals this person has when using your product or service
• Pain Points (or Opportunities) - The things that prevent this persona from accomplishing their goals
• Day in the Life - a quick story that exemplifies this person's role and how the use of your product or service fits into the bigger picture of their life

Now once these hypothesis or assumption-based proto personas are developed, it's time to validate them. Set up time to talk to these target users. Ask questions. Really uncover their needs and goals. Be prepared to tell a rich story about these people. The story should not just be about using your product or service. Delve into what makes each persona group unique. The goal is to share each unique story with your team, not just so they have the facts, but so they can make empathy-informed decisions about the product or service.

Real World Uses

So, once we bring back a proto persona or a fully validated persona, how can teams make better business decisions by leveraging these artifacts? My encouragement to you would be first to consider the ways you might involve a real person in your day-to-day work cadences. Do you have recurring meetings where you discuss work that will impact your customer? Do you create project artifacts so that other team members have clear expectations about the work they are to produce? Clearly, we cannot invite our users to attend every meeting we attend and read every document produced to align our team. So, how might we creatively represent them, so they have a figurative seat at the table? The diagram here illustrates that we achieve the best solutions when our users are equally represented in our conversations and considered in our business decisions.

So how can we represent them? I offer a few creative options, including:

• Create user stories that replace “user” or “role” with the actual name of your persona, and link to the persona for those who may be unfamiliar with their user types.
• Print out personas and decorate your workspace with them. Better yet, once we return to our offices in person, post personas in communal spaces where they will get views, like lunchrooms or even bathrooms!
• Create a cardboard cutout of each persona and have team members adopt one and take it with them to physical meetings. Or, if virtual, create a digital headshot and have team members sign in 2 times to your web meeting, once as you and once representing one of your personas.
• Create trading cards for a team-building activity or for new employee onboarding. Pass out a stack of trading cards that only represent 1 of many personas. Your job is to talk with other team members and trade so that you end up with a full set.

Now some forty-something years later, as a parent I sometimes slip into the role of a Muppet Show character. While my wife is strong in her impression of Miss Piggy, I do a mean Kermit as well as Swedish Chef impression. With my 5-year-old, my antics are well-received and memorable for her. For my teenage daughters, they are memorable, just for another reason. As I think back to my own best experience using personas, I recall a meeting I had with the development team. Being in the edtech space, I likely created some silly name for this persona like "Edith Educator" or something along those lines. And I remember as the team was negotiating the level of effort required to create a feature, one cantankerous engineer stated matter-of-factly, "This feature would not be delightful enough for Edith, who has to use this capability every day!" I just about fell out of my seat. That is why we create and infuse persona artifacts into the everyday cadence of our teams. Make them representative. Make them memorable. Use them every day.

Pruning, or the selective removal of specific branches or stems, is an important maintenance practice that helps to keep your trees healthy for many years to come. Important reasons to prune mature trees include controlling size, providing clearance for foot traffic or vehicles, removing potentially hazardous branches, and improving appearance. - University of Maryland, College of Agriculture and Natural Resources

I've noticed a concerning trait among product teams I've been a part of. That is, there's a goal to "grow a tree" (i.e., create or improve a product) without taking the time to systematically re-evaluate the heath of the product and prune unhealthy or unhelpful capabilities. These teams continuously build upon a minimal viable product (MVP) so that the product meets the broader needs and goals of its customers (or the business). To use another metaphor, we might start by building a rowboat, and that gets our customers from point A to point B, but it's not good enough. Perhaps it's too slow, so we build a speedboat. But that cannot carry enough customers at one time. So bit by bit we grow our boat until it becomes a cruise liner. This cruise liner has every amenity known to humankind. Music. Food. Activities. Wifi. Window views. But have you checked to see how long it takes for a rowboat or speedboat to change course compared to a cruise liner? We learned just how nimble a container ship can be.

I have a colleague who works in the real estate investing space. He purchases distressed homes at a discount, often from homeowners who have neglected to care for them and upkeep them. Some homes were filled from floor to ceiling by hoarders who refused to purge. Other homes were a Frankenstein-assembly of antiquated and garish upgrades and adornments, fitted on top of previous design decisions. Although my colleague wisely buys homes at a deep discount, he knows the secret sauce for making a profit on his fix and flips: Strip the home of anything unnecessary, start with a good set of bones (and foundation), simplify the design, and modernize the fixtures.

Reasons Businesses Do Not Prune

As professionals who deploy products and services for our customers, how often do we stop and make decisions to prune or simplify? Is the deck stacked against this behavior? A few observations may shed some light on this phenomenon:

• It's not how we're wired – According to a recent Nature article, the authors observed that "people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient."
• It discourages job security – Removing features and capabilities means more people will be upset, and upset customers could threaten my ability to work, right?
• It's not how we're accustomed to working - Developers develop. The creativity is in building code, not destroying it. Removing features might increase technical debt, and technical debt is seen as detrimental to the success of a product development initiative. Further, what would product demos look like when pruning means teams have less to show?
• It's not incentivized - When was the last time you read product release notes that reflected reduction instead of expansion? When do you hear the Steve Jobs of the world host an annual conference boasting of removing or simplifying capabilities? We reward progress. We reward creation.

How Might We Become Pruners?

So, how do we change business behavior to value pruning? I offer a few suggestions, including:

• Measure the Customer Experience – Create recurring customer feedback loops that map to customer experience touch points. It might mean tracking the number of subscribers and looking for changes after features are released. It may mean collecting satisfaction data about a recently released feature. It could mean tracking usability data such as task completion rates or time to complete a task. You cannot prune your tree if you are not actively monitoring its health.
• Build it into Project Plans – Whether you follow agile or waterfall approaches to development, there should be triggers or milestones where teams can pause, review, and make decisions about what aspects of the product should be simplified. For those who follow agile approaches to development, this reflection activity could occur during the innovation and planning sprint. Or maybe Product Owners could create "simplification" as its own feature, giving teams planned focus on reviewing the product for opportunities to simplify.
• Potential Future Enhancements - Did you know that the act of reduction could be considered an enhancement? Many teams add specific types of stories to their backlog, including targeted work for testing or technical debt. Why not add an "enhancements" story type in the backlog that consistently provides focus for teams to simplify so they can begin to see reduction as its own type of development activity?

Celebrate Simplification

A simplification mindset is hard to adopt. As indicated in the Nature article, perhaps it's not our first instinct. Perhaps it's not behaviorally reinforced. But I remember a time when I was really young being invited to a home that was planned to be bulldozed in order to build a new home. We were given all sorts of tools to choose from for destroying the home, including hammers and pickaxes and told to "have at it" - destroy anything you want. What freedom there was when simply being given permission to destroy, to simplify!

via GIPHY

Have you ever seen those videos where a building is loaded with TNT and after a moment, the building falls to the ground? It is fun and satisfying to watch, isn't it? So how can product teams channel that same feeling, not as a destructive tendency, but as a way to elevate the value that subtraction is just as valuable as addition? I encourage you to add Subtract: The Untapped Science of Less to your reading list, as will I.

Service design is the process of understanding and refining an organization’s people, processes, systems, and policies to improve both the employee experience and, directly and indirectly, the customer’s experience. I communicate to clients a simple 3 step approach to service design including:

Personas -> Journey Maps -> Service Blueprints

In Part 1 we defined customer Personas and in Part 2, stressed that a Journey Map reflects a specific Persona’s experience with an organization. To close out this series on service design, we will discuss what we do with this gained empathy for the customer experience.

Service Blueprinting: Visualizing the Employee Experience

Think back to the pre-COVID days when you could get a reservation at a nice restaurant. Chances are, many “cooks” contributed to your dining experience. From the line cook and sous chef to the executive chef and baker, all of these functions contributed to your culinary experience, for better or for worse.

Yet if we took the role of food critic, our review would reflect our experience in the dining area, not what may or may not have happened in the kitchen. While a journey map reflects the customer view of the “dining room” experience (i.e., what the customer sees), a service blueprint is an artifact that visually describes the “kitchen” - how the people, processes, and physical (or digital) resources ultimately supports a specific journey.

Think of service blueprints as the flip side of the same coin, yet representing the employee experience. So what is this artifact and what do we do with it? A service blueprint provides details about how employees support a specific customer journey. So, what types of information should a good service blueprint include?

A service blueprint recipe of basic ingredients should include:

• Evidence – This represents the physical and digital touchpoints, or focal points for interaction. Following the restaurant scenario, evidence could be a billboard or menu or emailed coupon.
• Customer Actions – A slimmed down representation of the steps, choices, activities, and other actions a customer takes with an organization to reach a particular goal.
• Frontstage Actions (what the customer sees) – A customer does not just act – they interact with you, so this layer should reflect what the customer sees during touchpoints along the journey. Who do they communicate with? What tools do they use to transact with the organization? What is the trigger? What happens next? How is the transaction completed?
• Backstage Actions (unseen steps and activities that support Frontstage) – This is the most important information in this artifact, reflecting the actions taken by employees unseen by the customer (e.g., cook in the kitchen) or a frontstage employee who does something unseen by the customer (e.g., waiter entering order into a touchscreen system)
• Support Processes – This reflects the steps that must take place internally in order to fulfill the customer journey. This typically reflects actions from employees who do not regularly interact with customers.

Service blueprints must be created by pulling frontstage and backstage inputs from real employee accounts and validated through internal research. This research and validation will likely need to traverse functional groups across an organization. Some key benefits of this work and the resulting artifact(s) include:

• Uncover systemic organizational weaknesses and inefficiencies
• Identify opportunities for optimization
• Assign areas of ownership for the experience
• Flatten silos by sharing responsibility for the customer experience
• Helps organizations make decisions that matter

Service design is the process of understanding and refining an organization’s people, processes, systems, and policies to improve both the employee experience and, directly and indirectly, the customer’s experience. I communicate to clients a simple 3 step approach to service design including:

Personas -> Journey Maps -> Service Blueprints

In Part 1 we covered the topic of Personas and the important practice of identifying, defining, and gaining empathy for the specific customers of your products and/or services. Today, in Part 2, we explore the second step of service design, which focuses on customer Journey Mapping.

Journey Mapping: The Voice of the Customer

Once upon a time, I fathered a wonderful girl who, at this time of writing, is four years old. My daughter’s favorite Disney movie is Cinderella. If we flash-forward to the ending of the story, Prince Charming wants to marry the unidentified maiden he met at the Grand Ball. Unfortunately, she leaves in haste before he learns her name. His only clue to her identity is that she leaves behind one glass slipper. The next day, the King sets the Duke on a mission to have the slipper fitted on every girl in the Kingdom. And of course, when the Duke places it on Cinderella’s foot, it fits perfectly!

Too often organizations focus on creating great products and services in a one-size-fits-all approach. That is, we take the time to create a great product (e.g., glass slipper) but we do not thoughtfully consider the unique customer needs and goals – will it fit? We often, like the Duke, try to forcefully stuff oversized feet into a dainty glass slipper. We seek to solve the problem rather than to first understand or reframe the problem.

You will create innovative solutions if you first develop a deep understanding of your target customers (see Part 1 – Personas). Note that I use the plural “customers” because your solution should never be one-size fits all. In fact, one way to gain empathy for your customers is by developing a customer journey map.

A customer journey map is a visual artifact representing the customer’s perspective of what their experience is like with you, the organization. This does not reflect the organization’s perspective. Rather, it is what I call an “empathy artifact” – a tool to reflect the voice of the customer. Empathy artifacts lead to businesses solving the right problem the right way, significantly increasing their return on investment for upfront costs.

Here are the basic ingredients of a good journey map:

1. Context – Set the context by addressing:
   • Persona – Which type of customer is represented? Be as specific as possible.
   • Time – Does the visual represent one customer interaction with the organization or does it reflect all touchpoints over an extended period of time?
   • Goals – Why does this customer want to engage with your organization?
2. Journey – The core content of this artifact should reflect a persona’s:
   • Milestones – what are key chronological events that represent a persona’s interaction with the organization?
   • Doing, thinking, feeling – What activities or motivations does this persona have when interacting with the business? Are these interactions positive or negative?
   • Touchpoints – How does this persona interact with the organization? Email? Phone? In-person? Desktop? Mobile?
3. Opportunity – Organizations can leverage this artifact for advantage by identifying:
   • Pain Points – Where in the journey are there problem spots, as identified by the customer?
   • Opportunities – Where can businesses find areas of the journey to improve, or even create new products or services that can address opportunities highlighted by their customer?
   • Ownership - Your customer does not care about your org chart, so their experience may traverse multiple parts of your organization. Use this artifact with problem solvers and leadership to identify areas of focus and people willing to take on the challenge.

Although we haven’t addressed how a journey map is constructed, it should go without saying that if you’ve created it without any customer research, input, and validation activities, you’ve done it wrong! A good journey map should act as the customer voice when the organization makes decisions that will impact its customers. Think of this artifact as your “Fairy Godmother” that can help usher in a fairy-tale ending for your organization.

Service design is the process of understanding and refining an organization’s people, processes, systems, and policies to improve both the employee experience and, directly and indirectly, the customer’s experience. I communicate to clients a simple 3 step approach to service design including:

• Persona – Identify, define, and prioritize the customer types impacted by an organization's products, services, and policies;
• Journey Map (customer viewpoint) – Research, document, and validate the persona’s experience (journey) with the organization over time and touchpoints; and
• Service Blueprint (business viewpoint) – Document how the organization currently supports the customer journeys and use these artifacts to identify opportunities to improve the customer experience by creating new or improving upon existing products, services, and policies.

Personas: What and Why

Today we focus on personas, artifacts that are a fictitious, specific, and concrete representations of a target customer group for a product, experience, or policy. Personas provide an actionable narrative that leverages both qualitative and qualitative research. First and foremost, a well-crafted persona allows the business to gain greater empathy for the customers who will benefit from the initiative.

Personas are artifacts created early in a project when teams are gaining a better understanding of the problem they are looking to solve and the people (customers) who are impacted by a new or improved product or service. The recommendation is that employees spend 2 hours every six weeks observing their customers as they use their products and services; this cannot always happen. HCD, as a philosophy, argues that understanding informs solutions, but many times businesses rush to a solution and make risky assumptions in a one-size-fits-all approach.

Rather than making business decisions based only on what is viable or feasible to the organization, a well-crafted persona allows organizations to inform their decisions based on what is desirable to their customers. For personas to be useful artifacts, please do not treat them as an unchangeable fact. Instead, personas tell the story of a customer type based on what the organization knows now, which could be subject to change the more they learn about and involve their customers in the process. Further, useful personas should not be customer stories or pretty pictures that collect dust on a shelf somewhere. Smart teams may create trading cards or full-size cardboard cutouts, whatever it takes to channel the customer perspective across levels within an organization making business decisions that impact these key stakeholders.