Configuration without chaos
Redesigning how HR admins define, govern, and populate the employee directory on ApplaudIQ — an enterprise B2B rewards platform.
Role
User researcher and Product desiginer
Timeline
1 weeks
TL;DR
"ApplaudIQ" is used by HR admins to run their employee rewards programs. Everything in the platform is keyed off employee data. But the way admins defined that data was quietly broken, and the onboarding team was frequently asked by clients to set this up for them. Everytime an employee has to be added an onboarding team expert has to go on a call with a client.
I ran a usability study to see where admins were getting stuck, and three things stood out. The screen was overloaded, setup wasn't self-contained, and errors were punishing. In the bulk upload flow, even a few mistakes could light up the screen with red errors everywhere. That cascade of red created the real problem: fear. Admins stopped trusting themselves to configure things without help.
The common thread: admins didn't feel in control. So instead of fixing each screen individually, I redesigned how the whole employee-management system works so the product carries the dependencies, the setup, and the error-handling, and admins only deal with what matters to them.
The result: admins could configure the platform themselves, and bulk import went from 15+ minutes to under 2 minutes.
Context
ApplaudIQ is The Reward Store's HR-facing platform a global, enterprise-grade product where HR admins manage their company's employee rewards programs. Configuring the employee directory correctly is the first thing every new client has to do, and everything downstream depends on it: routing rules, approval flows, award multipliers, automated rewards, reports, and the org chart all read from employee fields.
The trigger was a clear signal from the field: the onboarding team reported that clients couldn't figure the platform out on their own even after a demo, they needed manual assistance most of the time. A product that needs a human sitting beside every customer isn't finished. I picked it up to find out why.
Context on how we delivered: our team was experimenting with an AI-assisted build workflow — a token-based design system connected through MCP to an AI IDE, so wireframes and specs will be used to build the UI. I directed that process; the design judgment stayed human.
I ran a usability study on the existing configuration experience [~1-hour sessions] with 5 internal users, the audience available to me. I watched where they hesitated, where they made wrong assumptions, and where they gave up.
One limitation: this was a small internal sample. It was enough to find clear, repeatable problems, but I’d validate these findings with real client admins with more access. That feels much more natural than “the audience available to me” and “where they gave up,” while still being honest about the research limitations.
Key findings from our study
Three things stood out, and together they explained why admins were afraid to make changes.
Too much on one screen: Everything competed for attention at once, with little sense of what mattered or where to start.
Setup wasn’t self-contained: To pick something as basic as a department, an admin had to leave the flow, configure it somewhere else, and then find their way back.
Errors punished instead of guided: A single mistake showed up in harsh red. When two or three things went wrong, the screen lit up with errors in a dozen places at once.
The last one was the real problem. The cascade of red didn’t just confuse admins it scared them. They stopped trusting themselves to make changes without help, which meant the onboarding team kept getting pulled in to do it for them.
01 ·
Make configuration intentional
ApplaudIQ runs on employee data, but not every client needs every field. If Date of Birth isn't configured, the client can't use birthday-based automated rewards; the same goes for Joining Date and work-anniversary rewards.
So fields are sorted into three clear tiers instead of a flat wall:
Mandatory, always-on, locked: First Name, Last Name, Company Email. Can be reordered, never renamed, disabled, or made optional.
Enabled by default: Gender, Date of Birth, Joining Date, Department, Team, Designation, Reporting Manager, Dotted Line Manager. On out of the box, but configurable.
Disabled by default: everything else, turned on only when a client needs it.
The onboarding team configures the fields and features relevant to each client (in the internal tool), so unnecessary fields are switched off and the employee form becomes far easier to understand. I also grouped fields into clear sections Personal, Professional, Other and added contextual help where needed.
The result: admins only see what matters to their organisation, instead of having to figure out what 20 different fields are for.
02 ·
Make setup self-contained
Reference data was the next problem. If an admin was adding an employee and typed a department that didn't exist yet, they used to have to leave the flow, configure the department elsewhere, and come back.
So I changed the interaction itself. When a department isn't found, the dropdown offers Add new department they create it right there and continue with the employee they're adding.
The same principle extends to bulk upload. If the uploaded file contains a field that hasn't been configured, the admin gets a Verify step where they can map it to an existing field, create a new field, or fix the configuration and continue. The flow no longer stops just because the system wasn't prepared for the data.
03 ·
Turn errors into decisions
Adding people happens two ways invite individually, or bulk upload and bulk is where errors used to overwhelm. I redesigned it as a four-step flow (Upload → Verify → Review → Done) and, more importantly, changed what errors are.
The old flow dumped every problem on one screen at once department doesn't exist, email already exists, unknown column, invalid value and asked the admin to untangle them all. So instead of treating errors as things to display, I treated them as decisions the admin makes, and split them by where they're best fixed:
Conflicts resolved inline, as a choice. A duplicate (row matches an existing employee on email) offers Skip / Update / Overwrite / Stop. An unconfigured value ("Product Design" isn't a department yet) offers Add or Map to existing.
Data errors handed back in the file. For a datatype mismatch or a missing mandatory field, the fix stays in the file: the offending cell is highlighted red and a new column is added with a plain-language message explaining exactly what's wrong. The admin fixes it in their own spreadsheet and re-uploads the same file no hunting for what was rejected or why.
A clean file skips all of this: Verify just loads and passes straight to Review, which previews exactly what will happen (rows created, updated, skipped, dropped) before anything is committed. The step only demands attention when there's something to attend to.
What started as a configuration problem turned out to be about giving admins control without making them understand the entire system.
The product should know the dependencies. It should tell them what a change affects. And when something doesn't match, it should help them fix it instead of making them figure it out on their own.
Admins shouldn't have to be afraid of configuring the system. The product should carry that weight for them.
Looking back, this project became less about adding controls and more about removing the fear around using them.
Bulk import went from 15+ minutes to under 2 minutes. The flow that previously required the onboarding team to complete it for clients could now be handled by admins themselves.
Configuration moved from demos into the product. Instead of relying on onboarding to explain dependencies and manually configure things, admins could understand and manage the setup themselves.
A dozen inconsistent decisions became one coherent system. The final spec defined the dependency model, field tiers, employee states, and validation rules clearly enough for engineering to build without the back-and-forth that had previously stalled the module.
I reverse-engineered the data model from the UI, when the honest order is the opposite — the model should have come first, the screens second. I got to the right place, but by fixing contradictions I could have avoided by settling the model up front.
I’d also validate with real client admins, not just internal users — the study surfaced the right problems, but external testing would harden the findings.
And I’d push earlier on one open question: whether reference-data lists are owned by each field or shared across the platform. It sounds small but has large consequences (one “Departments” list versus several drifting copies), and deserved a day-one answer.