Customer Communication Meets Design Thinking
Design Thinking is a tool to tackle any problem involving people, their pain, and a brighter future. We put our users first, and let them guide our actions and outcomes. At IBM Kenexa, our product design and support teams collaborated to understand the pain around customer-facing mass communication. Our “users” became our customers and our own internal team as we sought to know what both camps value. Designers are encouraged in IBM to focus on all 6 experiences, with #6 being “Get Support.”
We’ve all had experiences with support teams, whether for better or for worse. Our goal was to find ways to change for the better. Our support team informs customers when system failures occur, and these issues come with frustration from the start.
The Pain — Our Customers
We deal with customers who are stopped in their tracks by a broken system for whatever reason, so the tone we use is crucial to customer satisfaction. We uncovered a few specific areas that led to customer frustration:
- Technical verbiage made the meat of the message tough to decipher
- The difference between emergency and informational communications was unclear
- Content was infrequent, inconsistent, and either too detailed or too vague
- Communications were reactive instead of proactive
All of this lead to a frustrated customer with a poor perception of our ability to solve problems and react. If the customer has too much information, they start to filter things out which could lead to missing important messages that relate to them. If we don’t send enough information, the customer is left feeling in the dark during a frustrating time and doesn’t feel supported by our team. Most of what we uncovered boiled down to hierarchy in our communications. If we could surface the basic details of what relates to them without cognitive load, we could relieve a lot of tension.
These pain points combined to make it nearly impossible for the customer to keep up with the action we take and what applies to them at the end of the day.
The pain of system failure is pretty obvious. There’s also a more lighthearted category of messaging called proactive communications, which contain tips & tricks, new features, events, and teaching to empower the customer to get more from their tools. These communications and efforts weren’t coordinated, leading to overlap, duplication of efforts, and event scheduling mishaps.
The Pain — Our Own Team
Most of the pain involved in our own internal process revolved around time waste and mundane tasks. It took too long to send communications for reasons ranging from the cumbersome process of gathering information to the archaic system in place used to send out those communications. Getting the right information and the approval for that information from the whole team led to more time passing and a drop in content quality at the end of the day. When supporting customers, the last thing we want is time passing without producing messaging to to keep them in the loop on progress.
Design thinking kickoff (Diverse empowered teams)
As with all design thinking workshops, gathering the right team was essential. Our diverse empowered team surfaced unique perspectives to observe our users and our team. We started with a superpowers activity to break the ice, uncover skills, and get to know the personalities of each team member.
Problem definition and stakeholder mapping shed light on the difficulties faced by our own team and our customers. As-is scenarios built empathy for our team’s daily work and our customer’s recurring pain. These specific design thinking activities were crucial for getting everyone on the same page. At the end of the day, we all had stronger knowledge of the whole scope of the process.
We then moved forward inspired by empathy and focusing on user outcomes. To-be vignettes helped us gather ideas about the future, and those ideas got us excited about how things could be. We broke off into two streams to reflect on what we gathered and map out specific actions.
Stream 1 focused on the inside-out process (we discover an issue and communicate it out to customers, walking with them from discovery to solution). We gathered pain points around the customer’s understanding of our progress and their opinions of us.
Stream 2 observed the outside-in process (customers discover issues, and report them to us). This is a tough scenario because we are reacting to what a customer is dealing with, instead of tackling issues before customers are aware. The big focus here was on our internal team process. The quicker we can react to an issue, the more dependable we are in our customer’s eyes.
Solutions (go, make) — Our Customers
Persona definition was key to making something great happen to our communications. We mapped out the personality of the messaging author based on the type of communication. For example, when sharing tips and tricks, the persona is passionate and informative. There’s room to be less formal and more fun to inspire (Dead Poets Society style). But compare that to a reactive emergency communication. Any amount of “fun” will read as making light of a negative situation, and will not be welcome. The persona here is knowledgeable, to the point, and doesn’t use fluff in communication.
To address a large part of our customer’s pain, we redesigned our email templates starting with logical hierarchy. Information was all in one solid chunk with little to no hierarchy, clunky branding, and no real structure. We broke it out into a few main areas starting with an issue indicator in the upper right to show severity at a glance. We also included a summary of the issue, affected areas, and the body of the email spelling out more details.
Finally, we applied color and visual styling to make it clear at a glance how severe of an issue we’re dealing with. Whitespace was also key to craft a template that feels light and easy to consume.
This gave us a starting point to showcase our persona based communications. We are also able to recycle the templates to send along proactive messaging in a more streamlined and organized fashion.
Solutions (go, make) — Our Own Team
Improving the lives and efficiency of our own team members results in a better life for our customers as well. We found several ways to speed up our internal process. One example; when an issue arises, we track how many customers are affected based on thresholds. The thresholds map out at what point an issue needs escalating and communicating. Previously, collecting the total number of customers affected was a manual process. Support team members had to keep track, reach out to other team members, and be on top of things. Our engineering team uses RTC to keep track of issues and related actions, so we came up with a way to create draft issues in RTC. This small change made it easier to keep track of the number of customers affected. It resulted in faster and easier tracking, less work to identify issues that need escalating, and a lot less copy and paste time once an official RTC issue is created.
We brought the whole team together in the beginning which built an understanding of each person’s role. Getting everyone’s roles defined was a huge game changer. Better internal communication means moving from a vague message to crystal clear information, faster.
Co-written and edited by Nate Austin, Carla Hall, and Julianna Ehlers
