Why you should do UX workshops with customer support
A crazy-fast shortcut to uncovering your product’s top usability issues
Before I made the transition to UX, I was a client services consultant at an identity verification company. Every day, I was on the phone speaking with new clients and legacy clients, assisting their development teams with integrating our API, troubleshooting issues, and configuring the software business rules to fit their needs. As a result, I built a healthy mental repertoire of business, user, and consumer needs, goals, pains and a thorough familiarity with the product suite: its most powerful yet unused features, its most misunderstood features, the workarounds to handle the plethora of edge cases that pop up from nowhere.
In short, I was on the front lines with users every day.
Inadvertently, this experience became one of my most powerful assets in my UX skill set. When I plunged into UX, I was met with the harsh reality that sometimes, you simply cannot get direct access to users. At CareerBuilder, I worked on a benefits admin system and with the mentorship of Tim Ward, I learned to take my time understanding the user’s process before even touching wireframes. I cold-called some of the client support people who helped clients set up and troubleshoot the system and thoroughly interviewed them on their process. In just a few calls, I became the team subject matter expert on benefits enrollment.
When I started at CINC, I did a basic UX Audit of the current product and while I made some general best practice observations, I wanted to lift the hood and uncover all of the usability issues quickly.
So I put together a UX workshop and did an open invite to the client support team.
This accomplished 2 things: we were able to unearth usability problems we didn’t even know were problems and we built a bridge between departments, facilitating collaboration between support and product.
How I Structured the Workshop
Set-up: What You’ll Need
If the product is big and complex, focus on maybe one or two areas for the workshop. Print out as many screenshots as you can of those areas. You’ll also need sticky notes, scotch tape, and your laptop. The participants do not have to bring theirs. Also, it would be good to institute a “no-email policy” or leave out laptops altogether. However, since support people have to respond to inquiries immediately, I would communicate that there will be short breaks to do so. In short, make sure your participants participate! I also invited my product manager and head developer to sit in these workshops as an observer so they can hear the feedback directly. Having them take notes individually will not only help free you to facilitate the workshop, but it will also be helpful to get different perspectives. What a product manager may find noteworthy may be different from a developer’s! Try to find a large conference room where people can get up and move around.
Format of the Workshop
Intro
Since most client support people have not been exposed to the behind-the-scenes work in Product, it’s good to have a little intro where you will explain what the workshop’s agenda and what the goals are. I like to reassure my client support folks that:
- There are no wrong answers
- You can put up duplicate issues, i.e. don’t’ worry if someone else already voiced the same problem because that tells us that it’s a problem for multiple people
I tell the participants that they will each have 20 minutes to write down:
- any usability problems on the sticky notes that they experience themselves,
- problems they get calls about,
- areas where most users get stuck,
- areas where people get confused,
- areas where users make errors
One issue per sticky note, and place the sticky note next to the element on the screen you’re talking about. I also let them know that at the end, we will go through the issues as a group and discuss and elaborate, so they won’t need to write long explanations on the sticky notes.
Sticky Note time
I then Google “20 minute timer” and put on some lo-fi chillhop. I do that to create a relaxed atmosphere so people don’t feel awkward from the prolonged silence. Whenever I see a person hesitate to put something up, I encourage them to put it up and remind them that there are no wrong or stupid answers.
Once the 20 minutes pass, I examine the screens posted up on the wall and quickly glance through the sticky notes for anything that isn’t self-explanatory to me. Once I see a topic, I point to it and ask the team to explain it to me and drill into the reason and history behind that feature. I don’t ask the team about each and every little thing because I want to make the most of my time with them — after all, they have to get back to the desks and tend to users via phone and email.
After the Workshop
Once the workshop is over, I take photos of all the screenshot printouts and the sticky notes and upload them to my computer. I also create a Slack channel with the participants of the workshop so that I can ask the group about any other sticky note we didn’t get to discuss in time. This allows me to continue that relationship with the group and now, I have a “council” of support folks who can help answer my questions.
Going through the photos I uploaded, I then integrate the points made by the support team into my UX Audit and include the use cases and problems they brought up. If available, I also include any direct feedback from users into the UX Audit as well so that we have a document that centralizes all of these usability problems. This will be helpful during the ideation phase as you can reference the problems you need to solve. This document can guide your user testing and help validate whether or not your solutions solve these problems effectively. I personally use Keynote to create this document but you can use Illustrator, InDesign, or any other program that can export a PDF of the audit.
Why is this effective?
This exercise helped me to quickly collect insight and problems that end users face on a daily basis. Also, remember that the client support team are also users of the system, as they have to configure software via admin panels and settings pages. Another benefit to this exercises is that it builds a relationship between departments and client support reps feel heard and involved.
As you create your prototypes, I recommend shooting them over to the new Slack channel for feedback and input and keep them updated on the progress. When you get buy-in from others outside the Product team, it strengthens the case for your solution.
Things to keep in mind
Discussions can become very fast-paced, so make sure you have a good notetaker(s) who can document it.
Also, while client support can provide great insight into users, remember that they aren’t the user. Support reps also tend to be power users of the system who want a wide array of configurations since they run into a myriad of use cases. They would not be the best group to determine what features or configurability to cut because to them, everything seems necessary. Also, don’t expect support reps to have solutions of their own. Support reps who have worked in the role for several years most likely can’t see any other way the system could be designed. Don’t use this as a substitute for direct user research unless you absolutely cannot gain access to users.
Make it a win-win scenario
And of course, you may run into a few support reps who feel threatened by what you’re doing — after all, if you make the system easier for end users, what will the support rep do?
When I was a support rep, I really enjoyed solving some of the bigger problems my clients ran into. I enjoyed helping my clients develop strategies or configuring the system to fulfill their business needs. It was much more stimulating to me to analyze trends and use creative thinking to make the software work for my clients. However, my day was littered with calls and emails about basic questions about the interface: where to log in, how to add a user, how to export a report — all things that could be resolved with a user-friendly UI. Context-switching between the big strategy stuff and the small annoying interface questions drained my mental energy. The reality is that software will always require human support on some level. Think about how frustrating it is when you need help and you only run into FAQ pages that don’t cover your unique case or limited chatbots that can’t process your issue. I make it a priority to assure my colleagues in the support department that by clearing out the smaller support calls, they can focus on more interesting big-picture problems to tackle. Not only is it more interesting, but it’s also more beneficial for their career development.
Building the bridge between support and UX is a win-win for everyone.
Special thanks to Arielle Coambes and Ying Yao for editing this article! And bonus thanks to Sophia V. Prater for convincing me to write this after my UX Hustle Podcast interview on the subject!
