Summary
Elysium succeeded ITS4, bringing Main, employee self-service (ESS), and Taxes into a unified platform. As Intechsol’s sole designer, I shaped the experience from research through delivery, training, and migration support. The work preserved established capabilities while replacing client-specific variations with a shared foundation and configurable workflows.
Selected results
Area | Result | Context |
Reporting | Completion 52% → 91%; average task time 14.5 → 5.2 minutes; SUS 51 → 82/100. | Initial n=9; follow-up n=30, including returning users. Completion reflects task attempts. |
ESS document requests | Unaided success 10/22 → 20/22 task attempts. | Four tasks; one separate comprehension target remained unmet. |
Delivery | Every client moved to the shared version. | Common updates across client environments, not one shared database. |
Business context | Approximately fourfold client growth during my tenure. | Firsthand operational recollection, not growth attributable solely to design. |
My Role & Team
Sole designer with product and delivery ownership
Over eight years at Intechsol, I progressed from Sales Assistant—with website, marketing, and user-guide design responsibilities—to UI Designer, Product Designer / Product Owner, and Senior Product Designer. Learning ITS4 exposed inconsistent interfaces, repetitive steps, confusing terminology, and hard-to-find features. I proposed interface improvements and moved into product design.
The tenure includes approximately six months to one year in the initial sales role, not eight full years exclusively redesigning Elysium.
I owned UX/UI, conducted research and testing, and designed configurable experiences. Across Elysium projects, the core team was consistent: me as the sole designer, the company owner, and two developers. The owner set expectations; I had substantial autonomy to prioritize work, plan sprints, and coordinate developer tasks. Broader stakeholders included the system analyst, customer service manager, and account salespeople. Product decisions were collaborative.
My scope extended through annotations, implementation reviews, release QA, migration support, training, and release communications. I determined which identified design-QA issues blocked release.
Scope: Research · UX/UI · Prioritization · Sprint planning · Testing · QA · Training
Platforms: Responsive desktop/tablet platform and separate ESS mobile app
PROBLEM & CONTEXT
Connected data, disconnected experiences
The main software, Employee Self Service, and Taxes had different styles, navigation, and access configurations. Users needing ITS4 and ESS had separate logins. Intechsol employees used Taxes internally on clients’ behalf.
The three databases already exchanged data through synchronization triggers. This was not a routine data-reentry problem: the experience was fragmented, and differences complicated maintenance. Undocumented client customizations created separate versions; database differences could cause errors during updates.
The Central Challenge
On paper, this was a redesign. In practice, it was something far harder: replacing the foundation of a house while people were still living in it.
The old system had accumulated years of structural debt. Modules were architecturally disconnected, data models were inconsistent across the product, and the experience of moving from one area to another felt like switching between different applications entirely. The new system required a fundamentally restructured architecture and a new database design, but existing clients were actively using the old system in production. Nothing could break. No client could be stranded mid-process.
The hardest constraint wasn't technical — it was continuity. Every design decision had to work for the future without abandoning the present."
This shaped everything. New modules could be designed with a clean slate. Legacy modules had to be reimagined within the reality of live data, active users, and migration paths that couldn’t introduce risk. The architecture decisions I made in the first year became the load-bearing walls every subsequent module was built on.
Goals & Success Criteria
Unify first, expand afterward
The directional goals were more clients, including larger companies; better UX; one entry point; and a more complete product. No numerical redesign targets were established.
Common capabilities became the baseline. The team reviewed specific client needs; I designed flexible setup, separating basic/advanced settings and revealing options when relevant.
Three-database dependencies and Kendo UI constrained interactions. For essential tasks, I worked with developers to find alternatives. For nonessential enhancements, I simplified the flow.
The Process
My process connected research, design, delivery, and adoption. I started with client interviews, competitor research, support tickets, and a review of the existing system. I then mapped new features to legacy workflows and worked with the system analyst on the data structure. From there, I turned flows and sketches into wireframes, detailed designs, and instructions for developers. Delivery included release planning with the project manager and testing before launch. User guides, client announcements, and internal training helped people understand and adopt the changes.
Research & Exploration
Understand how the work actually happens
Users included administrators, supervisors, HR, payroll managers, and employees. I analyzed support tickets, met with clients, conducted surveys, and used shadowing. Discovery covered workarounds, payroll exceptions, hiring, reporting, documents, historical records, and migration risks.
A concrete finding: clients approaching a deadline exported two or three reports and merged data themselves rather than wait for custom development. This supported combining existing data, not endlessly adding fixed reports.
I moved from sketches to wireframes, reviewing workflows with the owner. Full-team wireframe reviews identified backend dependencies and feasibility concerns before high-fidelity designs and prototypes.
Shared administration & relevant access
One user, appropriate responsibilities
I centralized module settings and access configuration. One user record supported management and employee responsibilities. Profiles controlled available functions; employee selection controlled the population accessible to each user.
Management users accessed ESS within the shared menu; employee-only users saw ESS navigation without management tools.
Clients gained tax filing/payment visibility, documents, and information submission. Intechsol retained final tax-submission and payment responsibility: transparency did not transfer execution.
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: Standardize labels, feedback, and navigation conventions across modules. | Major investments: Connect legacy workflows through shared patterns while preserving client configurations. |
Lower impact | Nice to have: Polish isolated screens that already support essential tasks. | Deprioritize: Replace every legacy workflow at once rather than deliver in stages. |
Role-specific dashboards
Act now. Monitor. Know. Navigate.
Interviews explored what users checked first, chased, and could not afford to miss. Dashboards separated urgent actions, process status, key numbers, and shortcuts.
An email survey asked users for their top three widgets. A separate priority sort evaluated 24 widgets with 24 participants: six each from supervisor, HR, payroll, and employee roles. Our project rule: 5–6 essential selections supported defaults, 2–4 optional placement, and 0–1 exclusion from that role’s home page.
Supervisors prioritized approvals and coverage; payroll prioritized timecard exceptions. Employees prioritized balances and pending documents/training; task-oriented language informed “My to-dos.” Headcount charts were optional for HR, not universal defaults. HR sub-role differences supported distinct views.
Shared widgets used role-appropriate scope. Users could reorder/hide widgets. Post-launch configuration analysis revealed administrators hiding defaults and supervisors adding an optional widget; we adjusted defaults.
These small samples informed direction. Configuration patterns do not establish improved task performance. Post-launch percentages are omitted because their population/timeframe are unavailable.
Reporting
Guided creation, flexible editing
I designed templates and a three-step wizard:
Choose Subject → Select Columns → Add Filters.
It led into the full editor, where users named reports, dragged categorized fields into place, adjusted filters/sorting, and inspected live data. Engineering supported curated data relationships rather than user-configured database joins.
Timezone conversion and labels clarified time-based data. Individual feature effects were not isolated.
Initial testing: 9 users (3 HR, 4 payroll, 2 supervisors). A separate 30-person card sort informed field organization. Follow-up: 30 users (10 HR, 15 payroll, 5 supervisors), including returning participants.
Measure | Initial | Follow-up |
Task-attempt completion | 52% | 91% |
Average task time | 14.5 min | 5.2 min |
Critical errors/user | 2.8 | 0.2 |
SUS | 51/100 | 82/100 |
Completion rose 39 percentage points; time fell approximately 64%.
Tasks and assistance rules were comparable, but samples differed. These are descriptive comparisons, not a matched-participant study or production-wide outcome. Errors decreased, not disappeared.
Employee Self Service
Explain policies when they matter
HR configured documentation requirements, dynamic vacation groups, capacity limits, and approval routing. Employees struggled with surprise document requirements, day counting, upload timing, and why sick requests entered review.
I surfaced requirements during date selection/extensions, made policy-specific counting visible, clarified upload options/deadlines, and distinguished “Submitted, waiting for document” from approval. A timeline explained progress. Sick-request messaging explained standard review; staffing impact remained visible to approvers without inappropriate employee-facing capacity warnings.
Task | Original | Revised |
Admin configures document rules | 3/5 | 5/5 |
Employee submits three-day sick leave | 3/6 | 6/6 |
Approver reviews missing-document request | 2/5 | 4/5 |
Employee extends sick leave to day three | 2/6 | 5/6 |
Unaided success increased from 10/22 to 20/22 attempts. All four completion targets were met. Ease increased 4.2 → 6.0/7; confidence 3.8 → 5.8/7. Median extension-task time fell 2:40 → 1:55.
Deadline/options comprehension remained 4/6 against a 5/6 target. Subsequent implemented refinements moved the deadline beside upload actions, reduced the day counter, and strengthened waiting-status visibility. No additional measured result is established for those refinements. Detailed approver observations are unavailable; no causal explanation is invented.
Mobile ESS
Shared capabilities, mobile-specific interactions
I designed a separate app with ESS web functionality using mobile components. Home and More anchored bottom navigation; middle destinations adapted to role. Multiple roles used one combined permission-filtered menu, not a switcher.
Testing revealed confusion between a hamburger menu and bottom navigation. I removed the hamburger and consolidated secondary destinations under More. No separate measured navigation improvement is claimed.
Shared standards & Notifications
Consistent behavior, not just styling
I customized Kendo UI’s theme and defined component conventions. Annotations were the main delivery reference, supported by specifications, examples, discussions, and reviews. Rules distinguished immediate settings from form values, selected containers by context/complexity, and kept actionable errors visible.
The supplied component guide is a retrospective reconstruction, not original team documentation. Proposed thresholds and unconfirmed details are not historical evidence.
Delivered notifications covered pending work, expiring credentials/documents, and employee milestones. Authorized users configured recipients, email/app delivery, advance reminders, recurrence, and individual emails or daily digests.
Team-implemented controls limited creator scope, checked recipient permissions at delivery/opening, and excluded sensitive content from external messages. Notification receipt did not grant access. This is reported implementation, not an independent security audit.
Quality & Migration
Protect continuity through change
I logged mismatches with screenshots, affected roles/screens, and intended behavior. Task completion, accuracy, security, compliance, accessibility, and exposure informed my release-blocking decisions; lower-risk issues could be scheduled later.
The team’s migration guide covered cleansing/mapping, automated validation, parallel payroll, acceptance, and monitoring. My contribution was setup design and migration support, not backend validation ownership.
Clients transitioned individually through a temporary version. At least one parallel payroll was required (two preferred for biweekly/semimonthly cycles). Pay, taxes, benefits, and garnishments had to match legacy or expected calculations to the cent. Discrepancies blocked go-live; fixes required a complete rerun.
Every client moved to the shared version, enabling a common update across environments. Maintenance time was not quantified.
Reflection & Next Steps
Design the rules around the experience
Elysium needed to accommodate different policies without maintaining a different product per client. Reporting and ESS evaluation reinforced that flexibility needs explanation. Dashboard customization showed that defaults still needed adjustment after release.
If starting again, I would establish a clearer measurement plan upfront, connecting workflows to task success, support demand, and post-launch behavior, making progress easier to track across releases.
Reflection is an editorial draft for the author’s review, based on the interview rather than an additional historical event.
Performance-review enhancements were planned, not in development or delivered when I left: exception handling, reviewer changes, reopened reviews, disputes, goals, peer feedback, development plans, optional compensation links, and further integrations/reminders. The existing platform notification feature had already shipped.
The lesson I would carry forward: design the rules, feedback, and evaluation around the experience—not just the interface.
