About:
Internal Benefits is Pluxee's module that connects HR and employees around company perks. The old version was confusing, inconsistent and technically limited. I redesigned it so both roles can find, manage and use benefits without friction.
Category:
UX/UI design
Client:
Pluxee
Year:
2025
Location:
Da Nang, Vietnam and Denpasar, Indonesia
Design framework:
Design Thinking
Tools:
Figma, Pluxee Design System, Dovetail, Teams
The problem:
HR admins hit technical limits every time they published a benefit, and employees got lost in a clunky ordering flow that no longer matched Pluxee's brand. Both leaned on support tickets instead of the tool.
Goal:
Let HR publish and manage benefits without fighting the interface, and let employees discover and order them on their own.
My role:
UX/UI designer owning the redesign end to end: stakeholder interviews, Service Safari, high-fidelity prototyping, moderated testing and dev handoff.
Methods:
•
Stakeholder interviews
•
Service Safari
•
Personas
•
UML flow diagram
•
Collaboration workshop
•
High-fidelity prototyping
•
Hypothesis mapping
•
Moderated usability testing
•
Iterative redesign
•
Dev handoff
Research
Before redesigning anything I needed to see how the module works today for both HR admins and employees, and where it breaks, not guess.
/01
Stakeholder interview
The product manager walked me through how internal benefits are managed today and where the module falls short. We mapped how HR admins publish benefits, how employees order them, and the technical blockers that slow everything down.
The key insight: both admins and employees are blocked by the tool itself, not by a lack of interest in benefits.
/02
Service Safari
Using real tickets from Pluxee's customer service, I walked through the current admin and employee flows step by step. Every broken moment showed up in the tickets long before anyone called it a design problem.
Three critical issues: the admin interface is demanding and technically limited, so HR needs workarounds it shouldn't have to know; the ordering flow has unnecessary steps, so employees drop off; and the visual design no longer reflects Pluxee's brand or UI library.
Collaboration framework
Halfway through, a business analyst challenged the design on cost and personal preference. Instead of debating every screen, I paused the work and redesigned how we collaborate.
/01
Stakeholder workshop
I brought my manager, the business analyst and the product manager into one room to map where collaboration was breaking down: business requirements arriving after designs were signed off, ad-hoc design suggestions without user or business reasoning, and no agreement on who has the final call.
The workshop ended with a simple agreement: each role knows when to step in, what input it brings, and how to challenge ideas without derailing the project.
/02
A repeatable framework
We turned the outcomes into a framework for future projects. Business needs are defined and validated upfront. Design decisions are owned by the UX/UI designer. Feasibility is flagged early by the business analyst, not late. Sign-off happens at clear checkpoints owned by the product manager.
Regular retrospectives let us adjust it in practice. It became a reusable pattern, not a one-off fix.
Define & prototype
The stakeholder brief arrived as a UML diagram. I turned it into one end-to-end flow, then into a high-fidelity prototype.
/01
UML flow diagram
From the UML I mapped every key state and transition for both roles: how benefits are created, edited, published and ordered, including edge cases. Admin and employee flows were mapped in parallel so handoffs stayed consistent, and it became clear which screens were needed, what data each had to show and where validation was critical.
/02
Prototype v1 and v2
I went straight to a high-fidelity prototype built from Pluxee's design system and iterated layout, copy and states with the product manager until it was stable enough to test.
For v2 I simplified it under the new collaboration rules, replacing heavier components such as the stepper with standard Pluxee patterns to reduce implementation risk. The condition was clear: every simplification had to be verified with real users on both sides.
/03
Hypothesis mapping
Stakeholders wrote their own hypotheses directly into the Figma prototype, screen by screen. Do HR admins understand where they are in publishing? How easily can employees find and order a benefit? Can HR work without relying on support? By the time testing started, everyone knew what a good outcome looked like.
Test
Moderated sessions covered both sides of the product: creating a benefit as HR, then ordering it as an employee.
/01
Moderated usability testing
Participants first acted as HR admins creating and publishing a new benefit, then switched to the employee side to find and order it. Three issues recurred: unclear UX copy on both sides, missing navigation banners so people lost track of where they were, and confusion about whether a benefit was live or still a draft. The flows worked in principle; the key states and copy just weren't explicit enough.
/02
Follow-up round
After clarifying publication states, rewriting copy and adding navigation, a second round on the admin side showed people could clearly see whether a benefit was published and moved through with fewer hesitations. Small changes in copy and state visibility had a disproportionately large effect on confidence.
Outcome
One of the first successfully delivered projects of its type inside Pluxee, now in final production testing.
/01
Handoff and collaboration
I walked the external frontend and backend team through the module, interaction patterns and key states, and kept a direct line open so technical questions were answered during implementation, not after launch.
/02
Impact
HR gets a clearer, more stable way to publish and manage benefits, and employees discover and order them with less friction. The collaboration framework was adopted as a pattern for future projects: a decision made once, reused many times.
/03
What I learned
Managing stakeholder conflict is part of design work, not a distraction from it. Pausing to run a workshop and agree a framework saved more time than pushing through an unclear process. The hardest part wasn't the interface, but aligning the people around it.
/04
Next steps
Test the shipped UI with real HR teams and employees, define ROI indicators such as support ticket volume, time to publish and ordering completion rate so impact is measured rather than assumed, and apply the framework to the next internal redesign.
© More works
(WDX®)
digital design
© help centre
(WDX)
clarification
Let’s talk