Dayforce Pay Run Management Dashboard
Dayforce is a comprehensive human capital management (HCM) system that covers the entire employee lifecycle including HR, payroll, benefits, talent management, workforce management, and services. The system is fully integrated as a full suite offering, making it simple for departments manage their workforce without needing to use multiple systems. Whether a customer is a small local business to a global enterprise, the software enables them to ensure their organization is healthy and maintained.
Problem Space
Payroll is the main revenue driver for Dayforce. Many of our customers only use our payroll feature set and integrate with other HCM products. It has the most usage of all the feature areas, specifically our pay run management feature which is used to setup and pay employees each pay period.
However, the feature area is running on technology 8 years out of date leading to a slew of issues. It is extremely expensive for our team to support in the current state and it inflates as the number of employees managed increases. The system could not support larger volumes of data. There were situations where if more than 10,000 employees needed data to be calculated, the system would crash or slow to a crawl.
Working through the pay run management as part of the payroll process, is one that has remained stagnate throughout the entire market requiring extensive manual efforts. These manual efforts take time and as one could imagine become more burdensome as the number of employees increase. The experience itself is complex and difficult to navigate as temporary fix on top of temporary fix compounded, like duct taping a leaking pipe multiple times over the years. 71% of payroll support tickets are questions about how to do or find something in the experience.
All the problems mentioned came to a head as Dayforce made a customer commitment to a large global enterprise who would need to support over 500,000 employees. The commitment was set 2 years out, which meant we needed to do 8 years worth of work in less than 2 to ensure proper testing could be done.
However, the feature area is running on technology 8 years out of date leading to a slew of issues. It is extremely expensive for our team to support in the current state and it inflates as the number of employees managed increases. The system could not support larger volumes of data. There were situations where if more than 10,000 employees needed data to be calculated, the system would crash or slow to a crawl.
Working through the pay run management as part of the payroll process, is one that has remained stagnate throughout the entire market requiring extensive manual efforts. These manual efforts take time and as one could imagine become more burdensome as the number of employees increase. The experience itself is complex and difficult to navigate as temporary fix on top of temporary fix compounded, like duct taping a leaking pipe multiple times over the years. 71% of payroll support tickets are questions about how to do or find something in the experience.
All the problems mentioned came to a head as Dayforce made a customer commitment to a large global enterprise who would need to support over 500,000 employees. The commitment was set 2 years out, which meant we needed to do 8 years worth of work in less than 2 to ensure proper testing could be done.
High Level Objectives & Strategy
At first, leadership wanted the entire payroll feature set to be reworked. However, doing so would take far more time and effort resulting in not meeting the customer commitment timeline. I worked with the product team to identify the primary areas of payroll the customer would be using and frequenting the most. We were able to determine that about 90% of their usage would be within the pay run management feature set within the payroll module. It just so happened that pay run management was the largest area in payroll so it made the most sense to start there.
Our plan was to have the majority of the team work on pay run management and get additional supporting teams from other departments to fit in the others in their own backlog before the commit date as those features did not require a lot of existing knowledge and were far smaller.
I worked with the team to define key objectives to guide the entire initiative. There were many aspects to address within the pay run management feature set, so we needed principles to ground and unify the team.
Our plan was to have the majority of the team work on pay run management and get additional supporting teams from other departments to fit in the others in their own backlog before the commit date as those features did not require a lot of existing knowledge and were far smaller.
I worked with the team to define key objectives to guide the entire initiative. There were many aspects to address within the pay run management feature set, so we needed principles to ground and unify the team.
- Accessible: ensure the feature meets WCAG 2.1 standards
- Reduce manual efforts: Reduce the number of steps and clicks for the user to achieve what they set out to do
- Scalable: Ensure the feature scales for large and small data sets, small to enterprise businesses, and from local to global cases
- Simplification: Ensure the feature is easy to navigate with clear paths for action; focusing on what the user needs when they need it.
Secondary Objective Note
|
I was brought in to lead the team and come up with a strategy for development to ensure all the work was completed in time. There was not a lot of experience on the design team and the product and engineering did not work with design previously. With this initiative there were multiple facets for myself to work on;
|
|
HIGH LEVEL OBJECTIVE
How might we clearly indicate where the user should focus their attention and what sequence of actions should be taken while navigating a pay run?
Project Objectives
As the lead, I decided it would be best if I tackle the main navigation and anchor point since that would be the anchor for the other experiences. This would help me coordinate the other designers easier since their work would need to coincide with my own. We defined several goals and success metrics for the project;
- Reduce support calls & tickets
- Reduce task completion time
- Reduce number of clicks to complete tasks and navigate
- Increase the NPS score
- High engagement on new shortcut navigation points
Research
To kick off the initiative, I employed a process I had used previous but adapted it based on Dayforce procedures. This helped our engineering and product team members gain a clear understanding how the work would proceed. Initially, we wanted to conduct multiple methods of research to understand the processes within payroll and the users that use them. The methods were as follow;
|
User Testing
We user tested the existing experience to see where the primary pain points were. We had them complete several tasks and observed when they got lost, had difficulty, and how long it took them to complete. We asked follow-up questions to understand what stood out as the most difficult and complex Review Customer Support Tickets & Feedback
Dayforce already had a repository of feedback via a product called AHA! Where customers can leave feedback and feature suggestions. We were able to isolate all customer input related to payroll and even was able to get more granular such as navigating the module. |
User interviews
We conducted our first round of interviews with various members of our own internal payroll team as well as our managed services team, which provides a service to do payroll on behalf of our customers. Since our managed services team worked with so many customers, they were able to provide us with a plethora of use cases and scenarios that arise. Our next round of interviews focused on our customers and customers of competitors to ensure we not only understand the cases within our own product but also overall use cases and pain points across the industry. The main focus of these interviews were to identify the steps involved in processing a pay run. |
We conducted a co-creation exercise during the ideation phase of work that combined several other research methods. I will discuss this exercise after discussing the key findings and initial ideation
Key Findings
Our research uncovered much about our users and cases. In this section I will highlight the most important findings that directly impacted our project. To start, we were able to map out the general pay run process;
Manually laborious: Each step requires manual intervention; to adding pay, auditing amounts, and correcting errors. Even simple things such as checking for errors and recalculating an employee's pay require the user to go to an action and click it to perform these actions that in many modern platforms are automated and are things people generally do not even think about.
Cumbersome steps: As mentioned above, things expected to be automated require manual intervention. For example; users have to manual recalculate the entire pay run (which could be 1,000s) just to do a few employee's pay. Another example is a validation step that check the pay run for errors. It will not show any errors until this process is manually run and it can only be triggered at the second last step; meaning if there are errors that require changes, the user will need to redo all the previous steps.
Nested navigation: There are tabs within tabs that have more tabs. Each are sprawled all over without a clear information architecture. The key information needed for admins to complete their tasks is sprinkled between these tabs, meaning they have to go to each one and grab it. Many stated "it's just part of the norm" or "I am use to it".
Cumbersome steps: As mentioned above, things expected to be automated require manual intervention. For example; users have to manual recalculate the entire pay run (which could be 1,000s) just to do a few employee's pay. Another example is a validation step that check the pay run for errors. It will not show any errors until this process is manually run and it can only be triggered at the second last step; meaning if there are errors that require changes, the user will need to redo all the previous steps.
Nested navigation: There are tabs within tabs that have more tabs. Each are sprawled all over without a clear information architecture. The key information needed for admins to complete their tasks is sprinkled between these tabs, meaning they have to go to each one and grab it. Many stated "it's just part of the norm" or "I am use to it".
HOW MIGHT WE
How might we streamline the committing process via an actionable centralized location for pay runs?
Payroll Personas
There were multiple personas we considered, but we kept the focus on the one affected the most by this problem space.
Payroll Admin & Specialist Persona (Photo by Han Myung-Gu/WireImage/Getty Images)
|
Goals
|
Needs
|
Pain Points
|
|
Jobs-to-be-Done
When a payroll admin opens a pay run for the first time,
they want to get a high level overview of the run
So they can understand what is happening at a glance and check accuracy
When a payroll admin opens a pay run to audit it, they want to see significant variances from previous pay runs across hours, earnings, and deductions So they spend less time auditing and address the differences.
When a payroll admin is ready to commit a pay run, they want to see if there are any issues preventing employees from being committed So they can address them or move them to an off-cycle pay run
When a payroll admin opens a pay run to audit it, they want to see significant variances from previous pay runs across hours, earnings, and deductions So they spend less time auditing and address the differences.
When a payroll admin is ready to commit a pay run, they want to see if there are any issues preventing employees from being committed So they can address them or move them to an off-cycle pay run
Current Experience User Tests
Our user tests along with our existing feedback and support tickets painted a picture of the usability issues with the existing experience.
EXPLICIT PROBLEMS
- Pay Run management is on the same level of hierarchy as viewing all pay runs at once causing confusion and inconsistent
- Pay Run management shows all actions and viewing options at once, making it quite complex to understand
- The majority of the screen real estate is taken up by nested tabs, actions, and filters leaving about 30% available for actual contents to view
- Everything happens on a singular screen; panels, dynamic tabs, and other frames clutter the interface
- Opening a Pay Run goes to the Preview tab and doesn’t help give the user a sense of what is going on or directs them what they should focus on or do
- Action bar mixes actions with filters and navigation elements making it difficult to discern what does what
- The user needs to manually recalculate and save each time something is changed which is time consuming
- All the steps are manual requiring load time after each since it is processing all the data in the run at once rather than increments when the user needs things to be loaded
- Many of the displays and steps are only slightly different from one another making it difficult to identify when something has changed a as result of a user's action
Existing Info Architecture
Here is a screenshot of the existing info architecture with callouts for potential opportunities to simplify, remove, and automate.
Solutioning
There were a number of constraints that we need to consider when solutioning as briefly mentioned in the objectives section. Below is an expanded list of constraints and our development strategy to accommodate as such;
- Tight Timeline: 8 years of work needed to be condensed into less than 2 for the customer commitment
- Resourcing Limited: Our design, product, and engineering teams were not very large. Even if we hired more, it would take a considerable amount of time to onboard and ramp up as the product space is dense and takes time to comprehend
- Re-architecture Backend First: The entire backend calculation system needed to be revamped, so the majority of our engineering team’s time would be allocated there
- Design System Early Stages: Our design system and accessibility teams were in their infancy. Many components needed for our project were not done and accessibility documentation guidelines still needed to be defined.
High Level Scope
Automation: I would work with the engineering and product team to determine what aspects of the process we can automate with the new revamped backend to improve completion time and reduce manual clicks.
High Level Nav: I would redesign the high level navigation to each of the pages rather than the nested tabs within pay run management. I needed to ensure it was modular and flexible to accommodate what ever the other designers came up with for the projects. I did not want to limit them, rather encourage them to do what would be the best experience for our users.
Dashboard: I would design a landing dashboard to give a high level overview that is easy to scan at a glance. I wanted to ensure the dashboard data reflected the user needs and the data potentially shown on other pages my other designer’s were working on. The idea was to seamlessly connected between pages to get more granular details, improving the navigation and investigation processes.
Beyond Scope: There were further iterations of the dashboard we agreed to do beyond the MVP shown below. We also agreed that 2 follow-up projects will be undertaken by myself; reimagine the pay run processing steps & improved error handling
High Level Nav: I would redesign the high level navigation to each of the pages rather than the nested tabs within pay run management. I needed to ensure it was modular and flexible to accommodate what ever the other designers came up with for the projects. I did not want to limit them, rather encourage them to do what would be the best experience for our users.
Dashboard: I would design a landing dashboard to give a high level overview that is easy to scan at a glance. I wanted to ensure the dashboard data reflected the user needs and the data potentially shown on other pages my other designer’s were working on. The idea was to seamlessly connected between pages to get more granular details, improving the navigation and investigation processes.
Beyond Scope: There were further iterations of the dashboard we agreed to do beyond the MVP shown below. We also agreed that 2 follow-up projects will be undertaken by myself; reimagine the pay run processing steps & improved error handling
Info Architecture
Generally I do not start with UI. I usually map out the flow or info architecture so product and engineering can be part of the initial conversations for alignment as it is all text based. I mapped out what were determined would be the ideal structure.
Sketching
After having the IA reviewed and tweaked. I started sketching ideas for the dashboard and navigation. I can produce sketches a lot faster rather any digital media. I find my ideas can be more free form on paper. I referenced different dashboards and navigations across industries to generate ideas.
One of the great strengths of sketches is their low fidelity makes them feel less concrete. When you show someone high fidelity mock ups, they start to hyper focus on data, styling, and the amount of changes present in the idea. People are afraid of change, especially in an industry that is use to older legacy experiences. To reduce their fear and anxiety, I use sketches to gather input from stakeholders and customers. They generally let their guards down when looking at drawings because they know this is not the final product, so they can be relaxed and candid.
One of the great strengths of sketches is their low fidelity makes them feel less concrete. When you show someone high fidelity mock ups, they start to hyper focus on data, styling, and the amount of changes present in the idea. People are afraid of change, especially in an industry that is use to older legacy experiences. To reduce their fear and anxiety, I use sketches to gather input from stakeholders and customers. They generally let their guards down when looking at drawings because they know this is not the final product, so they can be relaxed and candid.
|
|
Wireframing & Exploration
After sketches were in a comfortable spot. I grey-boxed a potential structure that mapped the existing experience over top of it. This was to help see how different patterns could work and facilitate discussions with product, engineering, and other stakeholders.
|
|
I started wire framing based on the sketches and grey-boxes. The first thing I focused on was the navigation and action structure as those would be the base that would not change. Then I started to experiment with different widget styles to display the data the users would need. I experimented with a variety of data sets and visualizations.
Co-creation Exercise
We had a number of widgets to work with, but we need a way to refine and narrow down which ones to use. We decided to do a co-creation exercise with customers using the widgets I designed. Participants would drag widgets on to an empty dashboard to build their own optimal board. First users would select from a data set and then they could select a variant that differed slightly from one another in data and visualization. The exercise combines stack ranking and card sorting methods into this collaborative exercise.
EXERCISE GOALS
- Determine which data sets were the most useful
- Determine the widget sequence based on significance and importance
- Determine best visualization format to clearly communicate data at a glance
We ranked and scored all the data sets and widgets across participants. We based the scoring on whether they added a widget to the dashboard and how high on the board they placed it. The end result helped narrow down which data sets and widgets would be the most impactful.
Following the exercise results and findings, I made several further iterations. Each iteration was reviewed with product, engineering, team designers, and most importantly our customers.
Final Mocks & User Flow
As mentioned, we handed off the final wireframes for the UI development to begin which gave myself and the other designers on my team time to refine the components with the design system team, complete and standardize accessibility annotations with the accessibility team, and produce the final high fidelity mock ups. Below, I will be showing the final mock ups instead of the wireframes.
Automation
Calculating, saving, and validating would occur automatically to reduce manual efforts and save time. Rather than the system trying to manage the entire pay run data set, it is chunked out into smaller pieces when the user needs it. As a result, the system is less burdened ensuring any of the processes do not time out or slow down.
In addition, we were able to remove all the save, calculate, and validate buttons and pay run process steps. Errors would show up immediately, data would be saved right away, and each employee would calculate would start as soon as new data is received. Note we would inform the user when there were any updates from these automatic processes via an indicator in the page header stating when it was last updated.
In addition, we were able to remove all the save, calculate, and validate buttons and pay run process steps. Errors would show up immediately, data would be saved right away, and each employee would calculate would start as soon as new data is received. Note we would inform the user when there were any updates from these automatic processes via an indicator in the page header stating when it was last updated.
Navigation
As shown in the iterations above, we went with a sub / side navigation for several reasons;
- Make use of horizontal space instead of adding to vertical space impacting content visibility
- Scalable for multiple navigation options including nested navigation options if needed
- Replace the nesting tabs
The user can expand and collapse the nav to make more room for contents horizontally. I collaborated with our design system and accessibility teams to ensure the pattern would be scalable across the organization. Since I had experience leading a design system in the past, I knew how to document the component so it was ready for others to use.
Dashboard
The dashboard itself is made up of multiple widgets and a page header. The page header hosts the actions the user can perform affecting the entire pay run and the rest of the actions a user needs/wants to perform would be relegated to their associated pages rather than showing every action, everywhere, all at once.
The widgets themselves were designed to be modular and flexible employing a card style that safely contains and segments the data in each so they may have the opportunity to shift and, in future iterations, be configured by the user. Each widget provides data at a glance for easy reviewing and understanding. I defined how each card would reconfigure based on responsiveness and data availability.
Each widget would provide an option to see detail views from other existing pages within the pay run. Think of it like shortcuts with particular tasks in mind for our user's investigations. I collaborated with the other designers working on these other pages to define the scenarios, data sets needed to display, and filters to refine the data sets.
I will go through each widget explaining what they are used, what they help the user accomplish, and rationale for visualizations.
I will go through each widget explaining what they are used, what they help the user accomplish, and rationale for visualizations.
Calculation Status Widget
The calculation status widget shows the amount of employees in each status step in the pay run. Payroll admins need to where all the employees are at before they can progress the pay run to the next step. The "See all" button navigates the user to the "Preview Employee" page listing all the employees in the pay run sorted by calculation status.
Each status is clickable, navigating to the Preview employee page listing all employees with said calculation status. Each status helps payroll admins decide what course of actions they may take. For example; when employees are calculated, they can safely review and audit those employees because they know their data will not change. Another example is if there are employees blocked, they can see who is blocked, why, and make the appropriate corrections.
I decided to use a pie chart to represent the statuses because it quickly communicates how each status compares to one another in relation to the whole (all employees in the pay run). The user could hover over each segment to see a tooltip explaining it. To accommodate different accessibility needs, I also included the full list of statuses represented in the pie chart below it and their associated percentages of employees.
The calculation status widget shows the amount of employees in each status step in the pay run. Payroll admins need to where all the employees are at before they can progress the pay run to the next step. The "See all" button navigates the user to the "Preview Employee" page listing all the employees in the pay run sorted by calculation status.
Each status is clickable, navigating to the Preview employee page listing all employees with said calculation status. Each status helps payroll admins decide what course of actions they may take. For example; when employees are calculated, they can safely review and audit those employees because they know their data will not change. Another example is if there are employees blocked, they can see who is blocked, why, and make the appropriate corrections.
I decided to use a pie chart to represent the statuses because it quickly communicates how each status compares to one another in relation to the whole (all employees in the pay run). The user could hover over each segment to see a tooltip explaining it. To accommodate different accessibility needs, I also included the full list of statuses represented in the pie chart below it and their associated percentages of employees.
Issues Widget
The issues widget shows the number of errors and/or warnings in the pay run broken down by category. Payroll admins need to ensure the pay run is error free before committing. The "See all" button navigates the user to the Issues page listing all the issues in the pay run (note, depending on the tab on the widget, the See all could bring them to the Issues page error tab or warning tab). The user could also click each category which would navigate them to the "Issues" page filtering the list of issues to that particular category.
I grouped the issues into categories for several reasons. First and foremost, it was easier for giving a high level view instead of just showing all the issues or just the total number. Secondly, it helps streamline fixing the issues. Admins, would usually go one by one fixing them, making them jump back and forth to multiple pages. If the know there are multiple errors on one page, it would save them time fixing them all at once. Thirdly, it helps delegate efforts. If they know there are a lot of issues from a particular page, they can plan ahead of time and assign multiple people to resolving particular issues. Also there may be team members with expertise in particular areas they can call on to address a subset of issues.
I decided to use progression bars because the goal is to progress through the issues reducing the number to 0. It was important to view each category separately instead of aggregate so the filled part represented the amount of issue per category and the entire length of the progression bar represented the total number of issues. Note, if there were no issues, the widget would have an empty state indicating as such.
The issues widget shows the number of errors and/or warnings in the pay run broken down by category. Payroll admins need to ensure the pay run is error free before committing. The "See all" button navigates the user to the Issues page listing all the issues in the pay run (note, depending on the tab on the widget, the See all could bring them to the Issues page error tab or warning tab). The user could also click each category which would navigate them to the "Issues" page filtering the list of issues to that particular category.
I grouped the issues into categories for several reasons. First and foremost, it was easier for giving a high level view instead of just showing all the issues or just the total number. Secondly, it helps streamline fixing the issues. Admins, would usually go one by one fixing them, making them jump back and forth to multiple pages. If the know there are multiple errors on one page, it would save them time fixing them all at once. Thirdly, it helps delegate efforts. If they know there are a lot of issues from a particular page, they can plan ahead of time and assign multiple people to resolving particular issues. Also there may be team members with expertise in particular areas they can call on to address a subset of issues.
I decided to use progression bars because the goal is to progress through the issues reducing the number to 0. It was important to view each category separately instead of aggregate so the filled part represented the amount of issue per category and the entire length of the progression bar represented the total number of issues. Note, if there were no issues, the widget would have an empty state indicating as such.
Variance Widgets
The variance widgets show the percent and amount of variance within each category (earnings, deductions, and taxes) compared to the previous pay period. Payroll admins need to ensure all totals per category are correct; if any had variances they needed to see if they are reasonable and make adjustments if they were not. Clicking each card navigates the user to the Preview Summary page breaking down all the codes making up the total amount of the category.
I decided to include the variance percentage and the actual amount because both are needed to determine if something is not accurate. For example; a large amount may not mean anything because an enterprise organization always deals with big numbers. What the admin needs to know is this large amount within their threshold for deviation. A large percent would indicate that the deviation is significant paired with the amount. Another example for the opposite is say a percent is drastically different, like 200%. But the amount went from $20 to $60. For smaller organizations, values are not as big so percent changes may overexaggerate the change.
I decided to separate each category into individual cards since each were equally significant. They did not have a lot of data to communicate but what was there needed to be readily available by just scanning the dashboard. I used the arrow to indicate the direction of the variance as the element to catch the viewers eye and rest on the small data set.
The variance widgets show the percent and amount of variance within each category (earnings, deductions, and taxes) compared to the previous pay period. Payroll admins need to ensure all totals per category are correct; if any had variances they needed to see if they are reasonable and make adjustments if they were not. Clicking each card navigates the user to the Preview Summary page breaking down all the codes making up the total amount of the category.
I decided to include the variance percentage and the actual amount because both are needed to determine if something is not accurate. For example; a large amount may not mean anything because an enterprise organization always deals with big numbers. What the admin needs to know is this large amount within their threshold for deviation. A large percent would indicate that the deviation is significant paired with the amount. Another example for the opposite is say a percent is drastically different, like 200%. But the amount went from $20 to $60. For smaller organizations, values are not as big so percent changes may overexaggerate the change.
I decided to separate each category into individual cards since each were equally significant. They did not have a lot of data to communicate but what was there needed to be readily available by just scanning the dashboard. I used the arrow to indicate the direction of the variance as the element to catch the viewers eye and rest on the small data set.
Employee Variance Widget
The employee variance widgets shows employee with amounts over the acceptable threshold per category (earnings, deductions, and taxes) compared to the previous pay period. Similar to the variance widget above, expect more of a narrower focus instead of totals of all employees. Payroll admins need to ensure all employees have the correct pay, taxes, and deductions; any variances would need to be justified or corrected. Clicking the "See all" navigates the user to the Preview Employee page listing all the employees with a net pay variance sorted highest to lowest. The user could click each employee to open the employee panel to display their details to investigate further as well.
I listed the employees with the highest variances as they are the employees with the biggest problems. I sorted the list by the net pay because admins focus on it first and then look at the taxes and deductions. I included the employee's statuses and pay classes as they could serve as hints as to why pay it off. For example; a part timer would likely make less than full timer.
I decided to use a table since there were multiple data variables that could not be displayed with a visualization easily nor able to consume at a glance.
The employee variance widgets shows employee with amounts over the acceptable threshold per category (earnings, deductions, and taxes) compared to the previous pay period. Similar to the variance widget above, expect more of a narrower focus instead of totals of all employees. Payroll admins need to ensure all employees have the correct pay, taxes, and deductions; any variances would need to be justified or corrected. Clicking the "See all" navigates the user to the Preview Employee page listing all the employees with a net pay variance sorted highest to lowest. The user could click each employee to open the employee panel to display their details to investigate further as well.
I listed the employees with the highest variances as they are the employees with the biggest problems. I sorted the list by the net pay because admins focus on it first and then look at the taxes and deductions. I included the employee's statuses and pay classes as they could serve as hints as to why pay it off. For example; a part timer would likely make less than full timer.
I decided to use a table since there were multiple data variables that could not be displayed with a visualization easily nor able to consume at a glance.
New Hires & Termination Widgets
The new hire & termination widgets show exactly what their names imply; both show the total number of hires and terminations in the current pay period and how it changed from the previous period. Payroll admins always need to review new hires and terminations to ensure their pay is correct. Clicking the "See all" on either widget navigates the user to the Preview Employee page pre-filtered to show all new hires or terminated employees. The user could also click each employee to open the employee panel to display their details to investigate further.
New hires and terminations usually have variable pay impacting the the variance of the totals indicated in previous widgets. Payroll admins usually check new hires and terminations first when variances are present so having widgets that allow them to investigate immediately was very benficial. I included the most recent hires and terminations with their pay because payroll admins generally receive numerous questions from new hires and people terminated about their pay. Making them and the widget front and center makes it easier for them to get access to the info they need to answer any employee questions.
I decided to use a radial progression wheel as I thought it was the best way to represent the change in hire and termination numbers. It also allowed for additional context to be added within the middle of the wheel, reinforcing the context of the contents and the wheel.
The new hire & termination widgets show exactly what their names imply; both show the total number of hires and terminations in the current pay period and how it changed from the previous period. Payroll admins always need to review new hires and terminations to ensure their pay is correct. Clicking the "See all" on either widget navigates the user to the Preview Employee page pre-filtered to show all new hires or terminated employees. The user could also click each employee to open the employee panel to display their details to investigate further.
New hires and terminations usually have variable pay impacting the the variance of the totals indicated in previous widgets. Payroll admins usually check new hires and terminations first when variances are present so having widgets that allow them to investigate immediately was very benficial. I included the most recent hires and terminations with their pay because payroll admins generally receive numerous questions from new hires and people terminated about their pay. Making them and the widget front and center makes it easier for them to get access to the info they need to answer any employee questions.
I decided to use a radial progression wheel as I thought it was the best way to represent the change in hire and termination numbers. It also allowed for additional context to be added within the middle of the wheel, reinforcing the context of the contents and the wheel.
Data Entry Widgets
The data entry widgets show the total number of entries and their total dollar amounts (earnings, deductions, and taxes) for all the data entry areas. The second widget shows the latest of the quick entries. Payroll admins need to ensure the total dollar amounts for entries balance out equaling what was expected according to their filings. Clicking the "See all" on either widget navigates the user to the Data Entries page sorted by the most recent to oldest entries. The user could also click the data entry area labels (earnings, deductions, and taxes) to jump immediately to their corresponding pages.
These widgets were the least important of the widgets, but as mentioned they were helpful to review the data entries entered. There were situations where mistakes or even fraud would be found among entries; an extra zero added to an entry here and there. While this would show up in the total variances, an admin would need to conduct an investigation as to why the values were off. Being able to quickly review the most recent entries and total dollar amounts makes their investigation easier.
I decided to use a data table similar to the employee variance widget due to the amount of data that needed to be communicated at a glance without making it too cumbersome of a visualization.
The data entry widgets show the total number of entries and their total dollar amounts (earnings, deductions, and taxes) for all the data entry areas. The second widget shows the latest of the quick entries. Payroll admins need to ensure the total dollar amounts for entries balance out equaling what was expected according to their filings. Clicking the "See all" on either widget navigates the user to the Data Entries page sorted by the most recent to oldest entries. The user could also click the data entry area labels (earnings, deductions, and taxes) to jump immediately to their corresponding pages.
These widgets were the least important of the widgets, but as mentioned they were helpful to review the data entries entered. There were situations where mistakes or even fraud would be found among entries; an extra zero added to an entry here and there. While this would show up in the total variances, an admin would need to conduct an investigation as to why the values were off. Being able to quickly review the most recent entries and total dollar amounts makes their investigation easier.
I decided to use a data table similar to the employee variance widget due to the amount of data that needed to be communicated at a glance without making it too cumbersome of a visualization.
Future
Future iterations of the dashboard were planned but postponed for later. We planned to allow users to customize the dashboard; reconfiguring the widgets as well as the data sets within them. In addition, we wanted to reconfigure the dashboard according to the phase of the pay run. For example; when the pay run is locked payroll admins are ready to audit so what if all the widgets changed to be what they need to review.
Beyond the dashboard itself, I was working on the issue page revamping how Dayforce handles errors; defining the pattern, content template, and what is classified as an error. I also was working on reimagining the pay run steps to be more inline with what admins are doing and need to do while working on a pay run.
Due to NDA, I cannot discuss these addition iterations and projects indepth until they are officially released. Thank you for taking the time reading my case study and making it through all that content :P
Beyond the dashboard itself, I was working on the issue page revamping how Dayforce handles errors; defining the pattern, content template, and what is classified as an error. I also was working on reimagining the pay run steps to be more inline with what admins are doing and need to do while working on a pay run.
Due to NDA, I cannot discuss these addition iterations and projects indepth until they are officially released. Thank you for taking the time reading my case study and making it through all that content :P