Pay Equity Analysis
Project Summary
Details
Nov 2023 - Jul 2024
Design Lead
Browser-based web app
Figma and Figjam
Distributed team
Background
Pay equity is about identifying statistically significant pay gaps that discriminate against protected classes (women and “minorities,” aka people of color). The field of pay equity has previously been dominated by legal consultants because of its focus on compliance, but when Syndio was founded in 2017, it was the first to productive the offering, transforming weeks of meetings and endless PDF reports to a visual analysis delivered directly to customers.
I joined Syndio in early 2023 as an in-house product designer dedicated to their flagship product, PayEQ, which identifies and explains pay gaps and suggests a budget for remediation. To date, Syndio has helped countless customers put millions of dollars directly into the pockets of underpaid employees.
The Business Case
To help guide customers through the pay equity process, Syndio offers a software package and a team of experts. However, this service leans heavily on people power to provide consulting, with the software fading into the background. The group detail page is one of the most heavily used analysis pages, but it’s difficult for customers to interact with themselves. Our goal as a company is to lead with software as a service. By making the UI more intuitive, we can make our service more efficient and less manual, ultimately meeting our business goals.
The truth is, I know almost nothing about statistics. But learning just enough to understand what matters to domain experts is one of my favorite parts of being a designer.
Research and Design
We started with a wish list
Syndio launched its flagship product PayEQ about 5 years ago. While some aspects of the product have been updated, most of it has remained the same and slowly become outdated, especially the group detail page.
The group detail page is a critical part of the analysis because in order to analyze pay, employees need to be organized into groups where they do substantially similar work. This creates a more optimal framework by which to determine if they are being paid fairly.
To be honest, even without subject domain expertise, I could tell this page was an inefficient use of space when I first laid eyes on it. The feedback confirmed that this was an issue with customers and our domain experts. Specifically, the information that people need, such as the impacted side of the comparison and the p-value, is difficult to access. The information that is visible on screen is either not important, or presented in a convoluted way.
I reviewed all the existing feedback on the page and created a prioritized list of changes to jumpstart design.
Design iterations and stakeholder feedback
We had a few distinct goals going into this redesign: make the UI more clear and understandable, prioritize important information, integrate the new design system, and keep the redesign to a manageable scope of work. I worked with the design team, product manager, and internal stakeholders to create designs and continuously iterate based on feedback.
I incorporated key design system patterns to modernize the UI and surface important information. Specifically, I replaced the various charts and numbers scattered throughout the page with a stats bar at the top, which presented key population stats and group information.
I moved analytical components, such as the group status, p-value, average comp, and average gap, to an informational card. Whereas previously the page lacked a visual hero, I worked with the design team to use visual patterns from our platform to create a design that would draw the eye to the most important component - the comparison status (red, yellow, green). This status was ultimately the symbol that could result on a litigation case and motivated the use of remediation budgets.
To make better use of space and simplify the UI, I redesigned the controls (which are labels that you apply to the analysis) to only display applied controls on the page, and moved editing to a different menu. We cleaned up the page by removing extraneous information.
The group detail page also includes various different states: including pay equity statuses, pre- and post-budget states, and errors and settings changes. I created specific designs to account for the different states, and this created the final package that our PM referenced to write the epics.
This design process was very transparent from the start. The design team, product squad, and various internal stakeholders were involved during every step. Thankfully, this helped create buy-in for the project ultimately a final design that everyone felt satisfied with. One of our domain experts said, “I didn’t even know I needed this until I saw it.”
Our squad is always working on multiple ongoing projects, so we had only one front-end engineer assigned to this project. Thankfully, he’s nearly unstoppable, and our small but mighty team was able to pull it off.
Implementaion
Design QA support
I worked with the front-end engineer and QA tester on our squad to review the development of UI updates and helped test for accessibility. We were able to build key components such as the stats bar, the controls menu, and tooltips to be keyboard accessible shareable components that we could use for future projects.
Statistical model scenarios and corner cases
We work in the squad model at our company, with each squad focusing on a different product. Not to brag, but our squad has the best QA tester in the company. She is renowned for knowing the product inside out, nothing gets passed her. And as we started to implement the redesign, she brought up multiple issues with me.
Employee counts
The problem: The employee counts in the group are confusing because while the group has a total headcount (e.g. 100 employees) each comparison actually has a different headcount (e.g. Men vs. Women has 95, White vs. Black has 70, White vs. Hispanic has 55). These different comparison headcounts are currently not displayed to the user.
There are also many reasons why an employee might be dropped from the comparison, such as if they have missing data, missing comp, or if the user ignored them. Some but not all of these reasons are displayed to the user.
The solution: I added two new stats to the stats bar - “Included,” which shows the total headcount of the specific comparison, and “Omitted,” which shows the number of employees that have been dropped from the comparison. I also added a tooltip next to “Omitted” that explains the various reasons why an employee might be dropped.
Small groups
The problem: We have a concept called small groups, which is a label that groups are given if the headcount is too small to determine a statistical analysis with confidence. There are multiple types of small groups, to the point where it’s actually kind of ridiculous. It could be a small group if there are less than 30 people total, or if one side of the comparison has less than 10 people. There is a user setting that can change the threshold from 10 to 5 people. Sometimes, it could turn into a small group if too many controls are applied and the number of columns (controls) exceeds the number of rows (employees).
We show the user if it’s a small group, but the messaging is not always clear, and some scenarios require different types of messaging. Internally, not everyone at Syndio could keep track of all these different scenarios, and we needed to communicate them clearly to the squad so we could account for them all in the implementation.
Solution: I created a matrix chart to identify all the different small group scenarios. After reviewing and editing this chart with the QA tester (twice) I created designs for each scenario based on the chart.
To be honest, I’ve regularly had friction with QA testers. In many ways, they are the opposite of designers - instead of imagining possibilities, their job is to confirm the expected behavior and make sure nothing deviates from that. However, I found working with the QA tester on these scenarios made the design process very rewarding. It helped elevate the design and improve the UI, helping us meet our project goals. And while I created the small group chart to preserve my own sanity, it turned out to be so effective that even a domain expert asked me for a copy.
Reflection
I have been part of many UI redesign projects, some enjoyable, some horrifying. Out of all of them, this has probably been my most successful redesign. Not only was the process collaborative and iterative, but we were able to see it through implementation and release it to customers. Here are some things I learned in the process:
- Domain expertise should be a guiding light for enterprise software
- Don’t be afraid of complexity
- QA is your friend, not your enemy
