Senior UX Designer

Payroll is traditionally processed on a schedule; companies pay their employees weekly, biweekly, or on some other regular interval. When an employee abruptly resigns or management wants to give everyone a holiday bonus, payroll practitioners typically use an off-cycle. Off-cycles are so called because they occur outside the normal schedule or cycle of regular payroll.

For Lifion, the next generation HCM product from ADP, the ability to process both types of payroll — regular and off-cycle — was cumbersome and immature. Of primary concern, the only way to pay many employees the same holiday bonus was do it one by one in a wildly inefficient procedure. Secondly, the experience of working with an off-cycle was entirely different than that of regular payroll. And lastly, both types of payroll utilized a slow and brittle legacy payroll engine to do the actual calculations. Moving forward, payroll needed to be flexible by supporting a new modern payroll engine in addition to the legacy engine.

As the primary designer on the core payroll team, I worked alongside a senior product owner to define these challenges and then model and design a path forward. Ultimately, I collaborated with several engineering teams in an agile environment over the course of several months to implement our approach.

Modeling a Path Forward

Initially, the project was framed around addressing the most immediate and painful shortcoming within payroll — the inability to use an off-cycle to pay many employees at once. Hoping to achieve further clarity, I brought together payroll designers and product owners for a problem framing workshop.

From the workshop, it became clear that there was a broader opportunity to address more fundamental issues in payroll. Specifically, we could design a unified system to handle both off-cycles and regular payroll as well as integrate both modern and legacy payroll engines.

Unified payroll model

Model suggesting similar processes for regular and off-cycle payrolls.

By organizing these ideas into a model, I sought to illustrate how a regular payroll was functionally similar to an off-cycle. I hypothesized that we could deliver a consistent and more intuitive experience to payroll practitioners and that it would be easier to maintain and extend as the product grew.

Designing Structure

Using the model as a shared reference point, I moved into design. My initial task was to lay out an appropriate interface and navigation. This meant organizing the experience into a few key screens using components from the design system.

Early structure idea

Early idea showing how payroll practitioners might proceed from a payroll index (top left) to setup (top right) to inputs (bottom left) and then to results (bottom right).

Throughout much of the product, navigation is generally thought of as a mix of horizontal and vertical tabs. This, however, has its drawbacks. Vertical tabs, for example, narrow the main content area thereby limiting the data visible in a table. To address this, I explored several alternatives, including a concept where tabs or views could be selected from a dedicated modal. With this approach, tables could be wider and payroll practitioners could search from an expanded list of views and descriptions.

Earnings index

Selecting change view opens a dedicated modal.

Change view modal

View descriptions help clarify complex terms.

During remote moderated testing, payroll practitioners responded positively to this concept and were better able to distinguish between similar views. However, due to development constraints, we ultimately moved forward with the more traditional tabbed approach.

Beyond Tables

Tables and filters are everywhere in payroll. They are an efficient means of manipulating large amounts of data, not to mention payroll practitioners essentially live in Excel. That said, because every cell is treated uniformly, tables often fail to convey hierarchy.

Recognizing this, custom sections were more appropriate for the Run payroll index screen. Prominence was given to important amounts like employee count and pay date as well as values like gross pay and net pay which made choosing and comparing payrolls easier.

Run payroll index

Payroll practitioners can either access an existing payroll or start a new one.

Deeper within the experience, spreadsheet-like tables made more sense, particularly for cases that required searching, filtering, and editing data. To accommodate space constraints, summary tables linked to detailed tables, providing a more robust view when needed.

Repeating Patterns

In the final designs, special attention was devoted to transparency, flexibility, and extensibility. This primarily meant including metric tiles — blocks with totals — in multiple locations based on context and feasibility. While basic in their execution, metric tiles address issues of scale, allowing payroll practitioner to quickly assess magnitudes and confirm accuracy. Metric tiles could also be extended to accommodate a broad range of summary data and interactions. Similarly, tooltips and interactive panels were critical to providing more detailed information without over complicating the design.

Off-cycle payroll using the legacy payroll engine

For payrolls using the legacy payroll engine, metrics were shown on each tab based on available data.

Off-cycle payroll using the modern payroll engine

For payrolls using the modern payroll engine, metrics were shown in the header as totals did not require calculation.


Interactive elements offer additional information and functionality.

Manage earnings

Detailed tables allow payroll practitioners to edit data directly.

In the end, I collaborated closely with multiple engineering teams to realize this unified approach to payroll. In 2020, our efforts in payroll were recognized as a “Top HR Product” by Human Resource Executive, and we continue to build upon our original foundation.

Looking Back

Framing is essential. In my experience, product success — does the product address real needs and will it be used as intended — hinges on how it’s framed. In this case, the project was pitched narrowly, focusing on obvious pain points and near term benefits. Accepting this outright would have yielded a solution likely to fall apart as priorities shifted. Instead, spending time upfront with the right people, reflecting on the bigger picture, and ensuring that we really understood each other was crucial to producing something of long term value.

Focus on structure. In fast paced environments, designers are often expected to focus on the interface and turn around usable solutions quickly. For this project, given its size and complexity, that would have been a mistake. Developing a model and solidifying things like navigation and layout first allowed us to move forward while also accommodating uncertainty. Decisions as to what fields to capture or columns to show could shift without dramatically impacting the overall design.

Challenge constraints. The more time you spend with a product or design system, the more you consciously and unconsciously conform to constraints as they’re perceived. That said, constraints are meant to be challenged. Exploring multiple directions, some feasible, some not, created a sense of excitement, a culture of innovation necessary to build something new in a complex space.