Summary
Payroll managers needed to make adjustments and process accurate payroll, but ITS4 made that work difficult to follow. When processing paused, users could not clearly identify the cause, understand what to do next, or resolve the issue themselves. They contacted support and waited for a completed payroll record to appear.
As Elysium’s sole designer, I worked on redesigning the payroll experience within a broader platform transformation. The design challenge was to make complex work understandable while preserving established configurations and payroll continuity for existing clients.
This story focuses on adjustment complexity, processing visibility, and the safeguards used when clients moved from ITS4 to Elysium.
My Role and Team
I was the sole designer, working with the company owner and two developers. The owner set overall expectations, while I had substantial autonomy to prioritize work, plan sprints, and coordinate developer tasks.
My work across Elysium included research, interaction and visual design, prototypes, annotated specifications, implementation reviews, and pre-release QA. I also supported training and migration. Product decisions were collaborative; technical implementation and calculation validation were team responsibilities.
Problem, Context & Constraints
Payroll could stop without giving users an explanation
Payroll editing involved adding, editing, and deleting earnings, deductions, and garnishments, as well as adding or removing employees from a payroll run. The process was complicated, and users lacked clear feedback when processing encountered an issue.
They could not readily tell whether a calculation error or another blocker had interrupted processing. Without a clear explanation or recovery path, they depended on customer support. Progress and expected completion were also unclear: users started the process and waited for the finished record to appear. Payroll recurrence and scheduling were not available to configure.
The redesign had to account for Puerto Rican labor requirements, existing client configurations, legacy data, and technical dependencies. Kendo UI capabilities also constrained possible interactions.
Goals & Success Criteria
Make important decisions and next actions understandable
The design goals were to clarify adjustment work, make processing status understandable, and help users identify what required attention. Preserving the meaning of existing payroll configurations was essential during the transition.
The project’s usability questions included whether payroll managers could understand the current state, distinguish progress from a blocker, and identify the next action. These are design goals; a payroll-specific usability scorecard remains to be added.
A separate, concrete migration requirement protected calculation continuity: before going live, a client needed at least one complete parallel payroll run, with two preferred for biweekly or semimonthly cycles. Net pay, taxes, benefits, and garnishments had to match legacy or expected manual calculations to the cent.
Understanding the Users
Accurate payroll, on time
Payroll managers created payroll runs, adjusted payroll data, and reviewed it before processing. Their responsibility was broader than editing individual fields: they needed confidence that the payroll was ready and that unresolved issues would not carry through to employee pay.
Administrators maintained configuration, while HR and supervisors contributed employee information, time records, and approvals within the wider platform. Payroll managers depended on the state of that connected work.
Interviews, user shadowing, and support-ticket analysis revealed the original friction. Support requests were particularly useful for understanding where users lost visibility or could no longer proceed independently.
Personas
PAYROLL OPERATIONS
Elena Rivera
Payroll Administrator / Specialist
Runs the pay cycle, from reviewing timecards and exceptions to calculating payroll, correcting errors, finalizing the run, and producing reports. Has full operational access, but cannot approve personal changes.
GOALS
Complete an accurate pay run on time, resolve exceptions early, and hand off changes for independent approval.
FRUSTRATIONS
Repeated data entry, unclear error messages, and late exceptions make corrections slow and increase the risk of missed deadlines.
BEHAVIORS
Checks timecards first, validates earnings and deductions, reviews adjustments, and documents corrections before requesting approval.
TECH COMFORT
Web tools
Reporting
Configuration
“Help me catch and fix the exceptions before I hand the run over for approval.”
PAYROLL OVERSIGHT
Marcus Bennett
Payroll Manager / Supervisor
Reviews and approves payroll before release, handles escalations, and manages off-cycle payments. Can approve high-risk changes and apply overrides within defined limits.
GOALS
Release a verified pay run, resolve escalations quickly, and understand the effect of every high-risk change.
FRUSTRATIONS
Missing change context and buried exceptions make it difficult to distinguish routine corrections from changes that need scrutiny.
BEHAVIORS
Compares run totals, investigates significant variances, checks approval history, and records reasons for overrides.
TECH COMFORT
Web tools
Reporting
Configuration
“Show me what changed, why it changed, and what needs my approval before release.”
FINANCE APPROVAL
Sofia Torres
Payroll Approver (Finance)
Provides final sign-off on payroll totals, funding, and labor costs before payment. Has read-and-approve access only, with no ability to edit payroll data.
GOALS
Confirm funding and labor costs, verify unusual variances, and approve only when the supporting information is clear.
FRUSTRATIONS
Unexplained total changes and incomplete supporting reports delay sign-off and require follow-up with the payroll team.
BEHAVIORS
Reviews totals against the previous period, examines funding requirements, and returns discrepancies to payroll rather than editing them.
TECH COMFORT
Web tools
Reporting
Configuration
“I need to verify the totals and funding, not change the payroll.”
Research Insights
Complexity became harder when the system stopped explaining itself
The research established four related problems:
The central insight was that payroll needed more than refreshed styling. Users needed a legible relationship between their adjustments, processing state, and the next step.
Prioritization and Scope
Preserve essential work while improving clarity
Elysium’s first release retained ITS4’s existing capabilities while introducing the shared interface and platform foundations. Payroll was part of that continuity requirement, rather than a standalone product launched without legacy obligations.
The case study concentrates on adjustment work and processing visibility. Migration validation supports the delivery story, while reporting and ESS remain separate case studies.
Across Elysium, I treated essential task completion as the priority when technical constraints emerged. I worked with developers to find an alternative when a proposed interaction was not feasible; nonessential enhancements could use a simpler flow.
Impact vs effort matrix
A qualitative view of likely user value and implementation effort, based on this case study. These are suggested priorities, not measured scores or a record of the original release order.
Impact / Effort | Lower effort | Higher effort |
|---|---|---|
Higher impact | Quick wins: Show persistent errors with a clear next action. | Major investments: Improve processing visibility and validate legacy migration. |
Lower impact | Nice to have: Simplify helper text for familiar payroll fields. | Deprioritize: Rebuild nonessential payroll interactions before core workflows are stable. |
Information Architecture and Key Flows
Connect preparation, adjustments, and processing
The task model spans creating a payroll, managing participating employees, adjusting earnings/deductions/garnishments, reviewing data, and processing the run. Status and recovery need to remain understandable across that work.
At platform level, centralized setup and one user record replaced fragmented administration. Navigation reflected permissions, and employee scope determined whose information a user could access. These shared foundations also shaped access to payroll tools.
Exploration and Design Decisions
Establish feasibility before refining the interface
My approach across Elysium progressed from sketches to wireframes, high-fidelity designs, and prototypes. I reviewed early workflows and business rules with the owner, followed by full-team wireframe reviews to surface backend dependencies and feasibility constraints.
The three inherited databases and Kendo UI limitations shaped what could be implemented. For essential tasks, I preserved the ability to complete the work while adapting the interaction.
Shared conventions also informed the experience: explicit selection controls for submitted values, editing containers suited to task complexity, and persistent feedback for errors requiring attention.
Testing and Iteration
Separate usability evaluation from calculation validation
Interviews, shadowing, and support-ticket analysis established the original usability problems. Payroll-specific task-test findings and resulting interface changes will complete this part of the story.
In parallel, the implementation team used test payrolls during client transition to validate calculations and migrated data. Discrepancies were traced to data migration, configuration/rules, or system logic. The relevant fix was applied and the complete cycle rerun.
These activities answered different questions: usability evaluation concerns whether people can understand and complete the workflow; parallel payroll validates that financial results match the expected calculations.
Final Experience
A clearer view of payroll work
The final-experience walkthrough will use the available two or three payroll screens to explain the redesigned interaction in concrete terms.
Overview: What the payroll manager sees before starting or resuming work.
Adjustment work: How employee participation, earnings, deductions, and garnishments are managed.
Processing and attention: How the interface communicates progress, exceptions, and the next action.
The first-release walkthrough should focus on core payroll actions, pay-code management, employee participation, status, and notes. File-based payroll creation, scheduling, and calendar views belong to the later-version scope.
Implementation & Delivery
Protect continuity through a careful transition
Every client moved individually through a temporary transition version before going live. The team’s migration guide covered data cleansing/mapping, automated validation, parallel payroll testing, stakeholder acceptance, and post-launch monitoring.
Unresolved calculation discrepancies blocked go-live. After a fix, the team reran the complete payroll cycle until the expected match was achieved.
My contribution focused on setup design, annotated behavior, implementation reviews, design QA, training, and migration support. I determined which identified design-QA issues blocked release; backend calculation checks were part of the team’s technical validation.
This made operational continuity a release requirement rather than assuming that a redesigned interface alone made a client ready to migrate.
Impact & Evidence
Carry critical operations into the shared platform
All clients transitioned to Elysium’s shared product version. For payroll, that transition depended on parallel-run validation and resolution of discrepancies before production cutover.
The first Elysium release preserved existing ITS4 capabilities while introducing the redesigned platform foundations. That is a confirmed delivery outcome. The parallel-payroll standard documents the release safeguard; it is distinct from a measured improvement in usability.
Payroll outcome details to add: Any recorded change in task completion, processing time, support requests, or users’ ability to resolve exceptions. Reporting and ESS metrics remain with their respective case studies.
Reflection & Next Steps
Make the state of the work as clear as the work itself
Payroll illustrates why enterprise redesign is not simply a matter of making dense screens look cleaner. Users need to know what has changed, what the system is doing, what still needs attention, and whether they can safely proceed.
A useful next evaluation would follow an end-to-end payroll scenario: make an adjustment, identify an exception, resolve it, and confirm readiness to continue. That would connect the design goals to observable task performance and complement the calculation safeguards already used in migration.
Part of Elysium at Intechsol. This draft focuses on payroll and its relationship to the broader platform transition. Bracketed details and short completion notes identify the remaining interview topics.
