top of page

Optimization Dashboard

AI/ML Design, Data Dashboard UX, User Research, 2024

Background and Challenge

Workday's Business Process Framework is the engine that supports every Workday application. From hiring a candidate, to  requesting leave of absence, to changing pay preferences, Workday customers interact with business processes everyday.

 

But how is a Workday administrator meant to check on the health of their business processes when their company has up to 300 active business processes? If they are hearing from various sources that their business process is taking too long or malfunctioning, how are they meant to effectively analyze the problem, optimize the process through a solution, and then measure the success of that solution?

​

These are the questions my project team asked ourselves throughout this 6-month long project. In addition I asked myself, "how might we create a supporting tool that will empower users to quickly and effectively analyze, optimize, and measure their existing business processes?"

Optimization Dashboard

The Team

  • 2 UX Designers (I acted as Lead UX Designer)

  • 2 Product Managers (1 lead and 1 supporting)

  • 1 Engineering Lead

  • 1 Functional Architect

  • 1 Data Analyst

On-ramp & Kickoff

Admittedly, I had very little knowledge as to what a business process was or how the Workday Business Process Framework functioned when I started this project. Thus, I spent the weeks leading up to my first kickoff meeting with the project team researching on my own, and utilizing 1:1s with my various team members to understand the customer experience. Here's what I did:

​

  • Met with the lead product manager to get a high-level understanding of the project timeline and expectation.​

​

  • Scheduled multiple 1:1s with the functional architect, who worked on the initial concept of the project, to walk through the current customer experience and learn about the technical functionality of the Business Process Framework. In these 1:1s I verified a user journey I had put together and we did some whiteboard brainstorming. This was an integral part of my project on-ramp.​

​

  • Met with the data analyst to get their perspective on current user problems as well as view real customer data to interpret on my own.

​

  • Experimented with various low-fidelity wireframes. I chose one set of wireframes to introduce to the product team in our first project kickoff meeting. My main intention was to validate whether or not I was understanding the project goals and technical functionality.

Kickoff Wireframe 1
Kickoff Wireframe 2
Kickoff Wireframe 3

Building Blocks

After the design kickoff of this project, it became clear to me how large this tool needed to be. Even as an MVP, the dashboard required many functionalities. I felt nervous to lead the charge on such a project as I was the single designer assigned to the project at the time. Thankfully, my previous experience designing software enabled me to view the product holistically, rather than feature-by-feature.

​

I quickly made the decision to start by building out the "shell" or "frame" of the tool. I wanted to ensure that I designed the tool to be scalable and easy to navigate. I also wanted to ensure thaas the product grows past my design handoff in the years to come, I would be setting the next designer up for success. 

​

For the purpose of scalability, I decided to store main functionalities of the tool inside of tabs at the top of the page. Additionally, I added a filter to the right of the screen for users to quickly sort and organize the data on each screen.

Tab Design
Filter Design

My product team was happy with this shell, however, I realized that splitting the main functionalities of the tool into tabs forced the user into a binary, having to choose which feature to utilize first, second, and so on. My goal was to lead the user through a holistic experience, not force them to make decisions. This prompted me to change the tabs to a more granular function, rather than an integral product feature. 

My goal was to lead the user through a holistic experience, not force them to make decisions

Gathering User Feedback

My favorite part of this project was that I got to take advantage of a rare opportunity: I had the absolute privilege of presenting to a focus group of Workday partners and customers, a Design Partner Group or DPG, every month throughout the project, to get direct user feedback. My monthly hour-long sessions with the DPG consisted of showing various "in-progress" feature designs that had been prototyped in Figma, and asking the group open-ended questions to get qualitative feedback. These DPG sessions were imperative to the success of the end product as well as the iterative nature of the design cycle.

​

For my first session with the DPG, a little more than one month into the project I prepared a full end-to-end prototype that demonstrated an ideal version of how the full product could function. This prototype included a filter, tabular navigation from different product areas, and two different views for the data dashboard (graph and table). The prototype also included what I like to refer to as the Insight Inspector- a deep dive into an individual business process, each of its steps, and its health. 

Mockup of data graph dashboard for the 1st DPG session
Mockup of "Insight Inspector" for the 1st DPG session

Along with the mockups, I prompted the DPG group, typically a group of about 20 international Workday customers split up into two sessions throughout each month, with research questions. For the first session, I asked the group to rate how valuable the the graph view (pictured above) is to their organization on a scale of 1-5 (5 being very valuable). The overwhelming response was a rating of 3-4, the graph and the data was valuable but would be even more so if it was shareable via a downloadable PDF file and if there was a way to view industry benchmarking on the graph. â€‹

​

By the last DPG session, I presented a mockup of a graph view that included industry benchmark data, and a download button at the top right corner of the graph. This time around, I asked the DPG to rate the graph again on a scale of 1-5, and the overwhelming responses jumped up to a 5. When asked why they rated the graph a 5, they reiterated that the benchmarking is immensely valuable as the ability that they can download that data to present to their CFOs and leadership. My product team and I continued to iterate on the product over the next 2 months to reach our final product.

Mockup of the graph view for 2nd DPG session

AI Recommendations

Although we had validation that a visualization of the business process data was valuable to Workday customers, the product team and I knew that we wanted to make the data actionable. We wanted to answer the inevitable user question, "what now?" and we knew that brining in AI was the next step.  When a user is told by the tool that their business process is falling behind, for example taking 34% longer than the industry average,  it's crucial that the tool also identify why the user's business process is exceeding the benchmark and present recommendations for fixing it. 

Buisness Process breakdown with an AI-generated report

We wanted to answer 
the inevitable user question, "what now?" and we knew that bringing in AI was the next step.

At this point in the project, the excitement that this product was coming to fruition and gaining support from users had spread throughout various internal organizations throughout Workday. We had gained a large viewership from company leadership. Myself and my team knew that we needed an additional UX Designer to help design the last piece of the project- a "home" that would utilize machine learning to summarize the most important data a customer would need from the tool.

​

While I continued on design for the main tool, my fellow designer friend from another internal Workday organization, began creating mockups for the home page of the tool. This designer wasn't granted the time to dive into business process research to better understand the full functionality of the tool, so he created a fantastic generalized experience that encompassed the basic user needs that we had learned throughout the DPG sessions. Afterwards, the designer handed off designs to me, where I edited the copy and data visualizations to model a more realistic view.

Home page

Conclusion and Learnings

The designs for this project became public when a clickable prototype (made in Figma by yours truly) was presented to more than 1000 customers at Workday's largest annual conference, Workday Rising. The presentation incited a ripple effect of excitement for both external customers, as well as internal teams. Since the presentation, we have seen a significant spike in customer interest in the product and are overwhelmed with customers who would like to sign up for the tool's early adopter program. I continue to work with the development team to implement designs and advocate for users. 

​

This was one of the largest projects I have worked on to date and I learned more than I could hope for. Number one is that UX designers are an amazing strategic product partner. UX can and should be brought in during the early stages of product ideation to center users. Second, the use of a DPG is such an amazing resource for user testing. The privilege of getting in-progress user feedback was invaluable. Lastly, this project broke down so many layers of imposter syndrome for me and taught me, more than anything, that I can do anything. 

bottom of page