Filtering out the noise to answer the most urgent questions first

Not only did Workday Help become the fastest selling add on in Workday history, it managed to rank as one of the top 5 HR Service Delivery Solutions ahead of ServiceNow, Oracle and SAP both in terms of Vendor Satisfaction and User Experience within its first year. I’m writing this from the present day, so some of the details of the work will be a little hazy.

This case study is going to focus on a small slice of work I did at Workday to provide a way of filtering and prioritising work for case solvers. We didn’t have a huge amount of time, or budget, but we needed to provide people with a way to narrow down large volumes of work to focus on what mattered most to them.

Our objective was shift the focus from showing the last case in, to displaying the most meaningful, relevant, and timely cases. We wanted to move the conversation beyond what was simply technically possible and deliver value that fit into peoples work life.

Accommodating flexibility and personalisation to encourage early advocates to adopt Help

Designing in Enterprise requires meeting the needs of many different people in very different organisations. These people are often awash with tools, with many of our customers already using one or multiple systems to manage employee issues. We didn’t want help to become another destination to check as this would run counter to our goal of reducing the case solvers workload.

Hunches around how case loads were managed

Upon arriving at the queue it was vital on a case level to be able to see the number of cases to get an idea of the workload, but this was a very rough approximation. The actual reality was that each type of case required a different level of time, effort, and expertise to bring to a satisfactory resolution.

Some of the other things we had heard at this point that were important:

1. Case solvers need to be able to see cases assigned to them in order to identify any dependencies (other people/departments, missing information) so they can act accordingly

2. Case solvers need to be able to identify cases that are routed incorrectly so that cases get seen by the right team and employees requests are seen and answered efficiently.

3. What queue the case is in and who has access (Routing determined by Flags, Type, Team etc.)

4. Case solvers need to be able to estimate how long it will take to resolve all their assigned cases so they can manage their workload successfully.

5. Whether they were at risk of running over any service level agreements (SLAs)

6. Who opened the case can be a factor in how they manage their work. Someone who opens a lot of cases – a frequent flyer, will be handled differently to the CEO

Shift in our approach to working together

I was fortunate to work with a great team at Workday. The Help team were always inclusive, kind, and genuinely passionate about doing great work. That said, at this point we had been grinding away ahead of getting out releases and had in some ways become stagnant with developers stuck in a backlog of less than interesting work, and customers dictating terms and features ahead of going live.

In order to mix things up a little, the team agreed to take a couple weeks to try out something a little different and free up the engineers to build and co design some solutions that had yet to be fully defined. This led to some exceptionally quick turnaround times, and allowed us to change our posture with customers who felt they had been actually heard.

Week 1: Customer interviews & workshops

In order to get a better understanding of how our customers were currently using their tooling and managing their day, I set up and conducted a set of 5 interviews over 2 days with the product manager. We wanted to get a walkthrough of a typical day of a case solver managing their queue. I was curious to learn what they liked and disliked about their current systems, get an understanding of what, if any, workarounds they had in place, and to find opportunities for us to capitalise on.

Interrogating our assumptions to design for specificity

On the third day I pored over the recordings and pulled quotes, observations, and ideas for each participant and set up a whiteboard on Miro for a workshop with the cross functional team of product, engineering, and design people.

Everyone attending the session was given "homework" to do ahead of time to review one participant video and pull notes from it into the format above. This allowed them to internalise one perspective before ideating. Ideas were limited to one per question/task with the focus on direct observations and quotes.

Week 2: Building, testing, and deciding on what to keep

We followed Jeff Gothelfs Lean UX canvas to guide the team to work towards potential solutions based on a hypotheses that were then voted on as a group. One idea was to provide a much more information dense view of the case list behind a toggle, with another to provide more exposure on the filters and sorting capabilities. Both ideas were compelling enough that the engineering team agreed to create testable solutions to be evaluated against each other. More so, due to their increased involvement they were switched on and excited about the prospect.

Circling back to the customers from week 1

Rough mocks were quickly co created with engineers and research stepped in to run a number of usability sessions with our customers. Everyone involved was invited to join a session and watch back as customers tried our intended solutions to the problems they had posed last week. We had a clear winner on the Friday which ended up feeding in and becoming productised ahead of the general availability of Workday Help.

Key learnings

“If you’re just using your engineers to code, you’re only getting about half their value.”

– Inspired by Marty Cagan

Embracing a new way of working allowed us to bring in perspectives from people who had felt strongly about the product and desired more ownership. Engineers when included in the design direction tend to be far more engaged with the execution. That our customers too could see change happening in weeks instead of years, which is typical in Enterprise, went a long way towards engaging with them, and building trust.