Loyalty Platform Customer Service (Call Center) Application
For this project, I was figuratively thrown onto a moving train, as the development team had already been working on API development for quite some time, without any involvement from the UX team (nobody had been assigned to the project yet). Almost immediately, I got word that the scrum master was itching to get wireframes from me in less than a week. OK, let’s negotiate! “I’ll have SOMETHING for you within a week," I told her. "I’m not sure yet what it will be, but I will definitely have something.” I had to call a timeout – hey, let’s slow down a minute and think about what we’re doing, not just start building something so we can meet a deadline. That response wasn’t necessarily well received, but I asked the team to trust me.
I had to do some learning fast, since I really didn’t know much about our call center or their needs for this “customer service app.” My first step was to make friends with the call center supervisor; we immediately began discussing some of their high-level needs, and she even pulled another supervisor and a trainer to join the discussion – it was great collaboration right off the bat!
Once I got the high-level overview, I set up appointments to talk with, and observe, a few customer service reps to get an idea of their workflow and to see how they used the legacy systems that we were replacing.
Some of my early notes from the initial user research phase.
In the meantime, I had been trying to make sense of an existing “user flow,” given to me by the business analyst; it was really just a rather confusing site map that didn’t even tell the whole story of how the call center reps actually worked, despite the fact that it was fairly comprehensive. My intent was to analyze and map out the users’ process, then simplify everything before digging back into the complexity.
Another challenge I faced was that this project was not only a rewrite of legacy systems, it was also the merging of multiple systems, with the goal of making it flexible for all clients to use going forward. I was especially conscious of call center reps being very accustomed to using the legacy systems as-is, so I wanted to make sure a drastic change wouldn’t disrupt their work lives; therefore, I wanted to bring everyone along on the journey of designing and building a new product, making sure we were all on the same page.
Once I started meeting with the call center reps, their workflow came into sharper focus. Based on my research to this point, I started doing some card sorting, with the intent of rolling up all of the granular tasks into bigger buckets, ultimately coming up with a very basic, sketched-out outline and task flow. This was the “something” that I delivered to the team (per the scrum master’s wishes) within the first week! However, I cautioned that there was a caveat – this flow wasn’t validated with the users yet.
The high-level flow, however, boiled down to "choose a program, find a program participant, authenticate that participant, manage the participant's account, disposition the call, and end the call.
I worked through this flow with the supervisory team, and continued iterating on it over the next day or so, firming it up a bit and getting to more detail.
Once the flow was in a good place, I sketched out a high-level paper prototype of the actual application screens, and scheduled some guerrilla testing sessions with a few of the call center reps. This round of testing validated the overall flow, but also uncovered some relatively minor changes that needed to be made, and even brought up a few hard questions for the call center team. Working through that, I was able to forge ahead with creating digital and interactive (yet still low-fidelity) wireframes as I moved from paper and pencil into Axure.
Iterative sketches that led to the initial paper prototype.
Preliminary paper prototype that was used to validate the call center reps' workflow.
In this next round of usability testing, I took call center reps through their task flow with the aforementioned higher fidelity wireframes, to see how it fit with their existing mental models. Finding that we were, overall, still heading in the right direction, there were also some "gotchas" that we came across.
The following video clips from the usability testing sessions highlight the moments where we discovered such problems as a lack of clarity around global notifications vs. program-specific notifications, a need to have more participant information persistent in the header that is always in view (we had previously made an intentional decision to remove most of this, in the interest of decluttering the design, but also based on user feedback during initial research), and the need to allow agents to disposition each call more than once (initial research indicated that a call could only be dispositioned once).
For this round of testing, I had worked up to the point of having full-fledged interactive wireframes with mock data, so I was able to simulate customer phone calls with the call center reps. These testing sessions uncovered more “gotchas,” but also validated a lot of good things happening in the design.
Some excerpts from this round of testing:
Discovering that the lock/unlock switch doesn't work as planned.
The beginning of a larger discussion around how summarizing (saving multiples) and ending the call would be handled.
At this point, after making some more adjustments based on the third round of testing, I was comfortable enough that we were on the right path that I started working on some visual design (in parallel with continuing to flesh out the wireframes deeper into the application), starting with the login page, then the client/program selection page, then the participant authentication page, etc. This allowed us to get the front-end developers started on creating the UI. We would soon have something to show the stakeholders!
The entire journey from being thrown on the moving train to the beginning of sprint 1 was just a few weeks, but we sure did a lot of discovery and ideation in that short period of time! Another important item to note is that the stakeholders and project team began to see the value in slowing down upfront, doing user research and usability testing, in order to ultimately speed up the delivery of the product.
Screenshots of the production-ready UI.