Surf
Ocean
Freedom
Experience
Redesigning Internal Benefits Module
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 finally find, manage and use benefits without friction.
Year:
2025
Location:
DaNang/Vietnam, Denpasar/Indonesia
Design framework:
Design Thinking
Tools:
Figma, Pluxee Design System, Dovetail, Teams
3D Hover Component
Connect a frame to the component.
Research
Define
Test
Delivery
The problem:
Managing internal benefits was painful for both sides. HR admins hit technical limitations every time they tried to publish a new benefit, and employees got lost in a clunky ordering flow that looked nothing like Pluxee's current brand. Both roles ended up leaning on support tickets instead of using the tool.
Goal:
Redesign the internal benefits module so HR can publish and manage benefits without fighting the interface, and employees can discover and order them independently, without needing help from support.
My role:
UX/UI Designer owning the end-to-end redesign. From stakeholder interviews, personas, and Service Safari, through high-fidelity prototyping, moderated usability 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 understand how the internal benefits module works today for both HR admins and employees. I started with the product manager to get the internal picture, then cross-referenced what they said with real support data. The point was to find where the current experience breaks, not to guess.
/01
Stakeholder interview
The product manager walked me through how internal benefits are managed today and where the module falls short. Using an initial framing method, we clarified goals, constraints, and current pain points. We mapped how HR admins publish benefits, how employees order them, and the technical blockers that slow the whole process 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 line, I walked through the current admin and employee flows step by step. Each broken moment in the interface showed up in the tickets first, long before anyone called it a "design problem."
The Safari confirmed three critical issues:
Admin interface is demanding and technically limited. Managing benefits requires workarounds that HR shouldn't need to know.
The ordering flow has unnecessary steps. Employees drop off before finishing.
Visual design is out of date. It no longer reflects Pluxee's current brand or UI library.
Collaboration
framework
Halfway through the project, a business analyst entered the process and challenged the design based on cost and personal preference. Instead of debating every screen, I paused the work and redesigned how we collaborate. Requirements, design decisions, and feasibility all needed clearer ownership before the project could move forward.
/01
Stakeholder workshop
I brought my manager, the business analyst, and the product manager into one room to reset the process. Together we mapped where our collaboration was breaking down.
Late business requirements. Specs arriving after designs were already signed off.
Ad-hoc design suggestions. Changes proposed without clear user or business reasoning.
Unclear ownership. No agreement on who has the final call on what.
The workshop ended with a simple agreement: each role knows when to step in, what input they bring, and how to challenge ideas without derailing the project.
/02
Collaboration framework
and retrospective
We turned the workshop outcomes into a simple, repeatable 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.
I set up regular retrospectives so we could see how the framework worked in practice and adjust it together. The framework became a reusable pattern for future projects, not just a one-off fix for this module.
Define
With the user groups and main problems clear, I translated the stakeholder specification and UML diagram into a single end-to-end flow. This became the backbone for the first high-fidelity prototype of the internal benefits module.
/01
UML flow diagram
The stakeholder brief arrived with a detailed UML diagram instead of a text specification. Using the UML, I mapped all key states and transitions for both HR admins and employees.
End-to-end coverage. How benefits are created, edited, published, and ordered, including edge cases.
Admin and employee side. Both flows mapped in parallel so handoffs between roles stayed consistent.
Screen-level clarity. Which screens I needed, what data they had to show, and where validation was critical.
Prototype
After resetting the collaboration framework, I updated the prototype to reflect new constraints while keeping the experience coherent for admins and employees. At the same time, I pulled stakeholders into the hypothesis-writing process so everyone knew what we wanted to learn from testing.
/01
High-fidelity prototype v1
I skipped low-fidelity wireframes entirely and went straight to a high-fidelity prototype using Pluxee's design system. Based on the UML and brief, I composed the first version of the interface directly in Figma with existing Pluxee components. Together with the product manager, we iterated on layout, copy, and states until the prototype was stable enough to test with real users.
/02
Updated prototype v2
I simplified the first prototype based on input from the business analyst and our new collaboration rules. To reduce implementation risk, I removed heavier components such as the stepper, replacing them with standard patterns from the Pluxee UI library.
The compromise was clear. Any simplification had to be verified with real users on both sides of the product, both HR admins managing benefits and employees ordering them.
/03
Hypothesis mapping
I asked stakeholders to write their own hypotheses directly into the Figma prototype. For each key screen, we captured what needed to be confirmed or disproved.
Clarity of the admin flow. Do HR admins understand where they are in the publishing process?
Employee ordering. How easily can employees find and order a benefit?
Self-service. Can HR work without relying on support?
This shared hypothesis board aligned expectations around research and made test results easier to translate into concrete design changes. By the time testing started, everyone knew what a "good" outcome looked like.
Test
With a stable prototype and shared hypotheses, I ran moderated usability sessions that covered both sides of the product. Creating a benefit as HR, and ordering it as an employee.
/01
Moderated usability testing
Participants completed two scripted scenarios. They first acted as HR admins creating and publishing a new benefit, then switched to the employee side and tried to find and order that same benefit.
The sessions revealed three recurring issues.
Unclear UX copy. Terminology confused participants on both sides.
Missing navigation banners. Users lost track of where they were in the flow.
Confusion around publication state. Was the benefit live, or still in draft?
The flows worked in principle. The key states and copy just weren't explicit enough for confident use.
/02
Follow-up research round
After fixing the main issues, I ran a second, focused round of moderated testing on the admin side. I clarified publication states, improved UX copy, and added navigation elements.
The follow-up study showed that admins could now clearly see whether a benefit was published or not and moved through the process with fewer hesitations. Small changes in copy and state visibility had a disproportionately large impact on how confident admins felt using the module.
Delivery
Once the prototype was validated with two research rounds, I handed it over to the external development team and stayed involved to support implementation.
/01
Dev handoff and ongoing collaboration
I presented the prototype and research findings to the external dev team and set up direct communication lines. During a joint session, I walked frontend and backend through the module, interaction patterns, and key states. We clarified the behaviour of complex components and defined how to handle edge cases.
By keeping direct contact open, we could validate technical questions quickly and plan iterations during implementation instead of after launch.
Outcome
The internal benefits module moved into final production testing as one of the first successfully delivered projects of this type inside Pluxee. Three things came out of the work: a validated prototype, a collaboration framework adopted across teams, and a clearer relationship between design, business, and development.
/01
Impact
The redesigned module gives HR a clearer, more stable way to publish and manage benefits, while employees can discover and order them with less friction. Equally important, the collaboration framework we created during the project was adopted as a pattern for future projects. A design decision made once, reused many times.
/02
What I learned
Managing stakeholder conflict is part of design work, not a distraction from it. Pausing the project to run a workshop and set a framework saved more time than pushing through with an unclear process would have. Designing internal tools is as much about changing habits as changing UI. The hardest part wasn't the interface itself, but aligning the people around it.
/03
Next steps
The work continues beyond handoff.
Production monitoring. Prepare another round of moderated testing with the shipped UI and track how HR teams and employees actually use the module in production.
Measurable impact. Define ROI indicators against the redesign (support ticket volume, time-to-publish, ordering completion rate) so impact can be measured, not assumed.
Reuse the framework. Apply the collaboration framework to the next internal redesign and refine it further based on what works.
