Business Views
Case Study
2023-2025
My Focus Area
-
Workday analytics suite has several key area. My primary focus has been on Core Reporting, specifically within Business View (Data Model), which sits alongside tools like the Report Writer (Composite, Advanced, Matrix), Office Connect, and future initiatives like Reporting Hub and Discovery Board.
Due to the broad scope of the project and confidentiality considerations, only a selected portion of the design work is presented in this case study
Problem Space
-
Business Views was created to address two major challenges:
1. Obscure Data Model
Workday’s data model is vast, with over 1000 distinct business objects (each representing an individual component of a data source.). Each of these containing hundreds of individual fields. Unsurprisingly, it's hard to find the data you are looking for without extensive knowledge in Workday.
An example of WD’s obscure data mode—In the case of the Worker Business Object, over 2500 delivered fields. The customer then add their own fields for their own specific needs.
2. Disconnected Data
Workday's data is not well connected and you cannot easily show data from two different sources in the same data table. This is critical in Financial planning. You can solve for this by manually defining the connections at Report building time. But this requires complex and costly implementation as it needs to be done ad-hoc for each report. Even with this manual workaround, many use cases are impossible inside the platform.
This is an example of a disconnected data—despite the “integrated backbone” strategy, Workday’s architecture treats each Business Object (e.g., Projects, Plan Lines, Journal Lines) in isolation, limiting the ability to combine data across sources.
So... how do we make data more easily
discoverable & understandable?
Business Views Vision
Enables users to blend and curate multiple Workday delivered data sources to create a data source that better meets their needs. The published data is also called Business View (BV).
Expanding Problem Space
To give you an example, a contract specialist needs an end to end view of all the activity generated for a specific Supplier Contract. Such as purchase orders and receipts.
In Workday that means pulling data from 7 different Business Objects, which is incredibly difficult and costly. So, whilst the data our user needs does sit within Workday, in order to bring it together into a single view it’s far simpler to extract it for use on another platform.
Business Value
Reduce cost and training hours to create reports
Faster to author reports
Increase in customers’ adoption in the Financial area
Kick off: User types & Project Status
-
The initial Business View data configuration experience—developed without design involvement—was built for Workday App Developers and focused on two key Financial (FIN) domains: Procure to Pay (P2P) and Grants & Projects, within the XO framework. However, the broader business goal was to design the experience for Data Admin customers, enabling them to customize tenanted Business Views.
*Prism Interactive Data Prep (IDP) is data preparation and analytics platform. It’s a tool to bring in external data, prepare it alongside Workday data, and create rich, interactive analytics all within Workday’s secure environment.
Design advocated for a clear distinction between the customer experience and the App Developer experience. This was because we know our customers are not well versed in our data model and find it difficult to navigate. They’re not sure what path to take but they know the destination. When it comes to configuring data they are in more of a discovery mode. Our app devs, on the other hand, have extensive knowledge of the Workday data model and the relationships between objects. When it comes to building a View, the exact path to take has been prescribed for them in requirements.
For the customer configuration of Business View, we agreed to proceed with a React spike. Most importantly, we advocated for leveraging the same user patterns as Prism Interactive Data Prep (IDP) to ensure a seamless and consistent user experience.
UX Focus: The Bucket of work to address
-
As a first step, and with guidance from another designer who served as the Design Architect on the project—I created my own roadmap, outlining where UX could and should add value.
I took a step back to look at the bigger picture and organized the key UX questions into distinct focus areas: Data Management and Data Analysis.
Design/PM Deliverables & KRs
-
As the next step to answer the key Business View questions. At the leadership level, there was ongoing debate about whether BV’s customer configuration experience should differ from the App Dev experience (built in XO). To move forward, we needed to secure leadership buy-in to justify the investment in dedicated dev resources. As a result of that we had to define a high-level design and product direction to establish a clear vision for where BV should go next.
Together we PM we decided to…
Deliver a visionary storyboard that illustrate the end-to-end experience—from Business View Admin configuration to business self-service analysis —leveraging Business View Data Visualization to drive insights and decision-making.
This wouldn’t just inform the future product strategy roadmap; it would also help define our analysis tooling, such as Discovery Board. Additionally, it would establish the MVP approach for implementing custom Business View.
UX Approach: Conducting Workshop
-
I conducted a 2-day workshop with Workday Implementers, Partner Consultants, cross-functional PMs/UX managements, Technical Writer, and a UX Architect to help shape the design direction and the storyboard as well as to answer all of those key BV questions.
The goal of the workshop—on day 1 we aimed to align the team on the problem space, user needs, and key opportunities. And day 2 dedicated to two breakout discussions. Breakout room1 on BV data management/modeling layer and breakout room2 was focus on the data analysis improvements for Business Views.
Workshop Synthesis: Key Takeaways
_
Data Management Layer
Tool flexibility/Ubiquity: Works across all Workday reporting and analysis tools. Integrates with existing functions (e.g., calc fields, dated prompts).
Finability: Quick, clear data selection with no confusion. Easy BV discovery with no redundancies. Workday suggests the best BV and drafts insights. Structured, clear query formulation.
Structured & Automated Binning: Clear understanding of time bins and hierarchy (Day, Period, Quarter, Year). Automatic or easy numeric date binning for efficiency. Supports date grouping by quarter/month with hierarchy integration.
Editable & standardize calculated metrics: Frequently used calculations should be integrated into BVs. Users should write formulas directly on data sources.
Clear Naming, Purpose & Usability
Data Analysis layer
AI/ML/Chatbot assistant incorporation: In 5 years, users can ask NLQ questions from anywhere in Workday and receive reports/visualizations (vizzes). Users unfamiliar with data structures will rely on NLQ to generate answers from BVs.
Embedded Analytics: Analytics should be integrated within Projects, Tasks, and operational Workday pages to surface relevant insights. Storyboards should illustrate how embedded analytics function across Hubs, Custom Dashboards, and Tasks (XO Reports lack customization).
Guided & Interactive Analysis: Pre-defined analytics provide structured insights, but users should be able to switch to ad hoc analysis (slicing/dicing, filtering, editing) as needed.
Workshop Key Takeaways: Shaping the Storyboard
-
After synthesizing the workshop findings, it became clear that we needed to incorporate AI/ML technologies into our story and vision. However, we had to determine the right balance between what’s feasible today and what’s the best approach for future. Ultimately, we landed on a well-balanced approach that blends human interaction with AI to be incorporated.
High-level User Flow
-
Before working on the storyboard, I began by mapping out a high-level user flow to outline the overall process—from Workday configuration of Business View to consumption and exploratory analysis of Business View data. This flow served as a guiding framework for our storyboard, ensuring clarity in how users interact with and derive insights from Business View.
Storyboarding
-
I used storyboarding technique to tell a compelling story of how these two experiences, the BV configuration and analysis can be connected, demonstrating a specific use case/scenario.
The story features the creation of a fully customized BV that serves as a data source for a visualization, delivering data-driven insights. It unfolds across 3 main chapters.
Design in collaboration with Anna Chi
Chapter Breakdown
-
Chapter 1 highlights: Custom Business View Creation
In this first chapter, we focus on creating a Custom Business View that aligns with Prism IDP’s user experience. Users begin by selecting a base data source or component—essentially a metadata business object created by App Dev—from the Component Views library. This includes enhanced FIN area categorization capabilities to improve data discovery and usability.
Another capability that we showcased was to initiate analysis directly from the Business View View page, making the transition from configuration to exploration more intuitive and efficient.
Chapter 2 highlights: create & embed a viz using business views
In this chapter we illustrated how the new BV would be used to create report and analysis. We’ve reimagined data source organization with Workday’s ML-driven recommendations, making it easier to find the right data.
Users can browse an intuitively structured field list, where metrics and binned dates are pre-defined in the BV data model.
Plus, we’re enabling embedded Discovery Board visualizations within stakeholders’ natural workspaces, to make sure insights are seamlessly integrated into their daily workflows.
Chapter 3 highlights: EXPLORATORY analysis on business views viz
Chapter 3 is all about Expanding Analysis with AI & NLQ: Users can seamlessly create a new Discovery Board from an embedded visualization for deeper analysis.
We also incorporated, Workday’s AI assistant and Natural Language Query (NLQ), so they can further explore Business View data, and uncover additional insights effortlessly
Define MVP: where to focus to get the most value
-
After presenting the storyboard that articulated the future vision and strategy for Business Views to leadership, we successfully secured engineering resources and received valuable feedback—enabling us to kick off work on Custom Business Views, the primary goal of our team. Partnering with my PM, we began mapping out our current understanding and identifying the next steps needed to keep the project moving forward.
Meanwhile, the teams focused on the analysis layer were also able to define their own roadmap to support Business Views within the tooling—specifically enabling integration with Discovery Boards.
Prism IDP Pattern Review
-
Now that we were confident in maintaining a consistent data transformation experience with Prism IDP, I partnered with the PM and a development scrum manager to review IDP UI patterns. Our goal was to better understand:
Which functionalities need to be removed or disabled for Business Views (BV)
Which concepts are uniquely relevant to BV that we need be to separately working on
I have intentionally omitted confidential data here.
*Prism Interactive Data Prep (IDP) is a Workday data preparation and analytics platform. It’s a tool to bring in external data, prepare it alongside Workday data, and create rich, interactive analytics all within Workday’s secure environment.
MVP requirements
-
We started with the high-level user flow, which we had previously used for the storyboard, to help define the MVP requirements for Custom Business Views.
Due to a tight deadline and limited engineering resources for the MVP, we decided to focus on only the most essential, bare-bones functionality—leveraging existing capabilities already implemented for the App Dev experience or available in Prism IDP. New ideas generated from the workshop synthesis and storyboard were prioritized for future releases. Therefore, integrating Business Views with the Prism IDP *Data Catalog was considered too heavy a lift for the MVP.
As a result, Product and Engineering aligned on a hybrid approach that leverages both XO and React frameworks. This means certain pages, like the Business Views homepage (which displays the list of BV data)—will be built as XO page/task, while the rest of the data transformation experience will mimic Prism IDP and be developed using React.
I have intentionally omitted confidential data here.
*Data Catalog is a centralized library or inventory of all available data sources—both Workday-delivered and external that are ingested into Prism for analysis.
Introducing Business Views
-
Business Views empowers organizations with a business-oriented data experience, where complex data becomes accessible to those who need it, when they need it.
By seamlessly blending and transforming data into an understandable format, Business Views accelerates informed decision making and enables organizations to unlock the full potential of their data.
Design Details
-
Due to the broad scope of the project and confidentiality considerations, only a selected portion of the design work is presented in this case study.
1. Create
Business View CATALOG
I began by designing the Business View homepage using the XO framework, as agreed upon with the team. We decided to make this page a centralized library that displays all Business Views—both in-progress and those marked as "Enabled for Analysis." It enables users to easily view, edit, or create new Business Views directly within the catalog.
Import Stage
Import is the first step in the data transformation process, where users select a component or metadata business object as the base data source for their Business View and begin transforming the data for analysis. They can then specify a name and description for the data source, providing context and clarity for better understanding data.
2. Edit Transformation
Edit Transformation:
Once the data component is imported, the user enters the data transformation stage— a critical step in preparing and shaping data for analysis. This is where users define how raw data should be cleaned, structured, and transformed to ensure it's ready for reporting and downstream analytics.
Hop Join Design
Unlike the “Join” and “Union” stages, which have well-defined meanings in SQL language, “Hop Join” is a Workday-specific concept that is unique to Business Views and not available in Prism. It is used when there are object graph relationships between Business Objects. This join type hops across multiple Business Objects/data sources to retrieve a field.
An alternative approach is to manually define the relationship at report-building time. However, this would be extremely complex and requires deep expertise in the underlying data structure. For this reason, we've decided to enable this capability in the data model layer to simplify the experience and make it more accessible for report authors.
Example Use case:
If a user wants to create a report based on the Journal Line object and include information like the Supplier Address, they must first hop through the Supplier Invoice Line object to access the Supplier field. From there, they can retrieve the final field—Supplier Address—from the Supplier business object.
Another Example Use Case:
A single Business Object can have many dependencies. For example, in the case of the Worker Business Object, there might be over 100 possible paths to reach the Worker’s Address field. This makes it extremely difficult for customers—especially those who aren't familiar with the Workday data model.
Hop Join Existing Alternative: Business View App Dev Experience
To start, I explored the existing alternative approach implemented for the Business View App Dev Experience in XO.
Here are the key pain points I identified:
Visual Representation: Hop Join is all bout defining the “path” to the final destination field and paths should appear as clear, linear connections. The current zigzag-like design is confusing and hard to follow.
User Interaction: The experience requires too many clicks and manual inputs, making it inefficient and tedious.
Source Organization: The logic behind reordering sources is unclear and useless as the order of the sources/fields don’t matter.
Hop Join Design ideations
Option #1:
User inputs the final destination field in the search area, and the search result comes back with the list of possible path suggestions between the Primary Business Object and the final destination field.
Option #2:
The system suggests the closest matching path based on the user’s input from the prompt questions, minimizing the number of options presented.
Option #3:
The user will manually input a sequence of required fields to get to the destination field.
Final Design Flow
Together with the PM and engineering team, we evaluated the pros and cons of each option. Options #1 and #2 were considered the most optimal from a design perspective but were deemed too costly and complex to implement—particularly due to integration challenges with the AI framework—so they were deferred for future releases.
As a result, Product and Engineering aligned on the last iteration (option #3), as it was the most cost-effective and feasible solution to implement within MVP timelines. While this solution only partially addresses the problem, users still need to manually define the path to reach the final field—it serves as an improved version of the original Hop Join experience developed by App Dev.
The goal of the updated design was to make it visually easier to understand the navigation path and how to hop between Business Objects. Users begin at the source and explore relationships step by step, with preselected Business Objects included to streamline the process and improve usability.
Final Hope Join Micro Interaction
3. Enable for Analysis
The final step, after adding stages and applying data transformations, is enabling the data for analysis. In Prism, before publishing a dataset, the security configuration defaults to a predefined security domain. However, for Business Views, we wanted this to be an explicit and required step in the process to ensure clarity and control for users. With that in mind, we decided to leverage the existing security configuration UI pattern, as customers were already familiar with it and had experienced no usability issues in the past.
End-to-End Interactive Prototype
-
Next Step: Usability Validation
-
With support from our research team, we began recruiting users and planning usability validation for the Custom Business View MVP features—Join, Union, Hop Join, and Filter. We decided to start with testing Hop Join, as it introduced a new concept within the data model configuration.
Together with the PMs, we drafted key questions we aimed to answer through user testing. To ground the research in a real-world scenario, we selected a financial use case: retrieving the Journal Line Posted Date and Time for a Billable Transaction—a common multi-hop use case.
Currently, report authors must manually build this logic into their reports using the "Look Up Related Value" function. While technically possible, it’s a tedious and unintuitive process that we’re aiming to simplify through the new design.
Plan & Outcome:
User Type: Prism users comfortable creating data sources and Look up Related Value (LRV) or calculation fields in Workday
Recruiting Plan: Use 3 of the internal or external roles
Outcome:
Validate the usability of the experience
Inform the MVP requirements
Get feedback to inform improvements to the feature
Reflection
-
Complex & Technical Challenge
One of the most technical projects I’ve worked on, involving a deep structural data model and broad product impact.Communication Was Key
Proactive, ongoing communication ensured progress and clarity.Early Alignment Through Workshops
A discovery workshop helped align the team on goals, user needs, and opportunities across teamsLeading Through Ambiguity
Strengthened my ability to navigate complexity and advocate for users.