OneAsure Portal: UX Case Study

Context

Four portals, four logins, one HR team

HR professionals at mid-to-large enterprises ran their day across four separate Asure portals, for time and attendance, benefits, payroll and HR, each with its own login, logic and quirks. Administrators made errors. Employees gave up on self-service. The sales team struggled to demo a product that looked a decade old.

I was one of four designers on the project, working with eight developers and a project manager over six months. I owned the research, the information architecture and the presentation of design rationale to stakeholders.

The Problem

The ask was a refresh. The problem was trust.

The brief came from sales: make it look modern. The interviews said something else. Users had stopped trusting the system, and several described avoiding tasks entirely because the process felt too risky. Consolidating four products into one without losing the complexity enterprise clients actually needed was the real work, and it had to happen before any visual change could land.

HCM platforms audited

12

user interviews

16

usability tests

24

design iterations

8

Decisions

Four calls I made, and what I turned down

1. 01

   Reframe the brief from a refresh to a consolidation

   The request was a visual refresh so sales could demo the product. After 16 interviews the real finding was that users had lost trust in the system: four portals, four logins, four sets of rules, and admins avoiding tasks that felt risky. I brought that back to stakeholders as a sequencing argument: structure first, then visuals, or the refresh would put a new coat of paint on the same fragmentation.

   Rejected: Shipping the refresh first to unblock sales. It would have hit the date and left every structural complaint in place.

2. 02

   One entry point, then modular navigation

   Single sign-on was the most requested and least contested change, so it anchored the new IA. Behind it, I designed navigation that surfaces only the modules a client has purchased. Enterprise customers buy different subsets of the suite, and showing everyone everything was a large part of why the product felt bloated.

   Rejected: A universal navigation with disabled items for unpurchased modules. Consistent for us, confusing for a customer who never bought Payroll.

3. 03

   Make admin-side risk visible in real time

   Admins had no signal when employees changed sensitive information, and the errors that followed were expensive to reverse. I designed a notification layer for those events, tested it across three rounds, and cut it back twice when the first versions buried the important changes in noise.

   Rejected: A daily digest. Simpler to build, and useless for the changes that needed a same-hour response.

4. 04

   Modernize the visual language, but after the structure

   The floppy-disk save icon was a near-universal complaint, and the sales team could not demo the old UI with confidence. I updated iconography, type hierarchy and component patterns across all modules once the IA was settled, so the credibility gain landed on a product that also worked.

   Rejected: Doing this first. See decision one.

The Product

The Pay module, as shipped

The Benefits module is the interactive prototype at the top of this page. Pay was the second module to move into the consolidated product. Both prototypes are the whole portal: the navigation moves between Home, Time, Pay, Benefits and More, the way one login replaced four.

Testing

24 tests, 8 iterations, and what they caught

Each round surfaced friction I hadn't anticipated: edge cases in the notification flow, labels that made sense to designers and confused admins, navigation that worked on desktop and broke on small screens. The notification system below went through three of those rounds before it stopped burying the changes that mattered.

Outcome

One product, fewer support tickets, and a sales team that could demo it

Four portals and four logins consolidated into one product with consistent patterns. After launch, support reported fewer tickets, admins reported fewer errors, and the sales team gained a product it could demo. These are qualitative signals, not baselined metrics. Built on 16 interviews and 24 usability tests across 8 iterations over six months.

Administrators also reported faster onboarding, and enterprise prospects engaged with demos again. Not having a baseline for any of this is the first thing I'd change (below).

What I Learned

Stakeholder alignment is a design skill

1. 01

   Stakeholder alignment is a design skill, not something that happens after the design work. Translating UX decisions into business language, anticipating objections before they derailed progress, and building shared ownership of the design direction were as important as anything made in Figma.

2. 02

   Sequencing matters. On a project this complex, the order in which you tackle problems is critical. Fixing visual design before addressing structural issues would have been the wrong call. Starting with research before wireframes kept the team from solving the wrong problem.

Hindsight

What I'd do differently

1. 01

   Instrument the portal before launch. I have qualitative evidence that admin errors dropped and onboarding got faster; I should have baselined both so I could state the numbers, not just the direction.

2. 02

   Push the single sign-on decision earlier. It was the most requested change and the least contested; sequencing it first would have bought goodwill for the harder IA changes.