PayEQ

The problem

Syndio's flagship product PayEQ pairs software with a team of experts who walk customers through pay equity analysis. It launched five years ago, and most of the product has been updated since. One page had quietly fallen behind though: the group detail page. This is where employees are organized into groups that do substantially similar work, which forms the basis for any pay comparison.

The deeper problem was a posture shift: the service was carrying more weight than the software, and the group detail page (one of the most-used pages in the analysis flow) was difficult for customers to navigate themselves. The opportunity was to make the UI intuitive enough that customers could lead with the software. That would be better for them, and better for our software-as-a-service model.

Even without deep statistical domain expertise, the inefficiency of the page jumped out the first time I sat with it. The customer feedback we'd been collecting confirmed it: the things people actually needed (the impacted side of the comparison, the p-value) were hard to find, while a lot of what was on screen wasn't load-bearing.

The designer and I went through the existing feedback together and prioritized a list of changes to jumpstart the redesign.

The redesign converged on three structural moves: a stats bar pinned to the top, an info card that led with the comparison status (red / yellow / green) and surfaced the p-value plus the adjusted and unadjusted gaps, and a controls panel that showed only applied controls inline (editing moved into a dedicated menu).

The info card carried the most narrative weight. The comparison status is the symbol that drives whether a remediation budget gets allocated. Sometimes it's the symbol behind a litigation case. We worked through several Figma directions; I flagged where high-fidelity treatments would balloon the render cost on dense tables, and we converged on a treatment that gave the status the visual hierarchy it needed without breaking performance.

The controls panel was the cleanup pass. Editing-in-place sounds simple, but with five active controls it cluttered the page. Pulling editing into a dedicated menu let us treat the controls panel as a read-mostly summary, which matched how customers actually used it.

The page renders in more states than the happy path suggests: different pay-equity statuses, pre- and post-budget views, error states, and settings-change cascades. The designer and I worked through these together. She sketched the variants, I traced what each one meant in the component tree, and we iterated until every branch in code had a corresponding design. Our PM then referenced the final package to write the epics.

The process was transparent throughout. Design, product squad, and the internal stakeholders were in the room at every step. That kept buy-in high and pulled us toward a final design everyone could stand behind. One of our domain experts said, "I didn't even know I needed this until I saw it."

Building the UI Components

I leveraged React 19 + TypeScript to build the components. Bundling was done through webpack. State was handled through Redux and RTK Query. Routing done through React Router v5. Testing done through Jest + React Testing Library. Playwright for E2E testing. Styling done through SCSS.

I built the major new pieces (stats bar, controls menu, tooltips) as keyboard-accessible, design-system-ready components so they could be reused on future projects. This was a major point of emphasis. As a growing midsize startup, building reusable components is key.

Corner case: Small groups

The problem. Syndio has a concept called small groups. Groups where the headcount is too small for the statistical model to land with confidence. The triggering conditions are deceptively dense: a group can be "small" if it has fewer than 30 employees total, or if one side of the comparison has fewer than 10 (5, on some configurations), or if applied controls push the column count above the row count. The legacy UI told customers when a group was small but couldn't communicate which kind, and internally not everyone on the team could keep all the triggering conditions straight.

The solution. The designer mapped every small-group scenario into a matrix chart. She and the QA tester refined it (twice), then she designed a UI variant for each cell. I leaned on the matrix heavily on the engineering side. Every cell needed a clean branch in code, with the right copy and the right downstream behavior (some small groups are budgetable, others aren't; some surface a status, others don't).

I've shipped a lot of UI revamps. This one stood out: the process was transparent from research through release, and we got to see it land in the hands of customers who had been asking for it for years. A few things I'll carry forward:

• Domain expertise is the guiding light for enterprise software. The customers and our internal SMEs knew the math better than I ever would. Designing alongside them, not for them, kept us honest.
• Don't be afraid of complexity. The small-group scenarios had real branches that mattered. Compressing any of them would have made the product worse.
• Strong QA partnership is rare; cultivate it. Most teams treat QA as a gate at the end. The level of collaboration we had, with QA shaping the design by surfacing edge cases before the first PR, is unusual and worth replicating.