Format of the Workshop
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.