Surf
Ocean
Freedom
Experience
Internal benefits
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:
Prague, Czech Republic
Design process:
Design Thinking
Tools:
Figma, Pluxee Design System, Dovetail, Teams
My role:
UX/UI Designer
Research
Define
Test
Delivery
Validating the Friction
Project overview
HR admins and employees struggled to work with the internal benefits module because it was confusing, inconsistent and technically limited. Both roles were blocked by the tool — from publishing benefits to actually ordering them — creating friction and extra workload for HR.
Goal:
To redesign the internal benefits module so that HR can easily publish and manage benefits, and employees can discover and order them on their own — without needing help from support.
My role:
UX/UI Designer leading the end‑to‑end redesign of the internal benefits module — from stakeholder interviews, personas and Service Safari, through high‑fidelity prototyping, moderated usability testing and dev handoff.
Methods:
Stakeholder interview
Personas
Service Safari
UML flow diagram
Collaboration workshop
Collaboration framework & retrospectives
High‑fidelity prototyping
Hypothesis mapping
Moderated usability testing
Iterative redesign
Dev handoff
Understanding how benefits work today
Research
Before redesigning anything, I needed to understand how the internal benefits module works today for both HR and employees. By talking to the product manager and looking at real support data, I could see where the current experience was breaking down.
Stakholder interview
The product manager walked me through how internal benefits are managed today and where the module falls short.
I ran a structured stakeholder interview using an initial framing method to clarify goals, constraints and current pain points. We mapped how HR admins publish benefits, how employees order them, and where the process is slow, confusing or blocked by technical limitations.
The key insight: both admins and employees are blocked by the tool itself — not by a lack of interest in benefits.
Service Safari
I analysed the existing benefits module using real tickets from Pluxee's customer service line.
Using data from the support team, I walked through the current admin and employee flows step by step. The Safari confirmed three issues: managing benefits in the admin interface is demanding and technically limited, the ordering flow contains unnecessary steps, and the visual design no longer reflects Pluxee's current brand and UI library
Redesigning how we collaborate
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 on requirements, design decisions and feasibility.
Stakeholder workshop
I brought my manager, the business analyst and the product manager into one room to reset the process.
During the workshop, we mapped where our process was breaking: late business requirements, ad‑hoc design suggestions and unclear ownership of decisions. Together we defined when each role should step in, what input they bring, and how to challenge ideas without derailing the project.
Collaboration framework
& retrospectives
We turned the workshop outcomes into a simple, repeatable framework for future projects.
We agreed that business needs are defined and validated upfront, design decisions are owned by me as the UX/UI designer, and the business analyst flags feasibility early instead of late. The product manager signs off at clear checkpoints. 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.
Translating into strukcture
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.
UML flow diagram
The stakeholder brief included a detailed UML diagram instead of just a text specification.
Using the UML, I mapped all key states and transitions for both HR admins and employees. It showed how benefits are created, edited, published and ordered, including edge cases. This structure guided which screens I needed, what data they had to show and where validation was critical.
High‑fidelity prototype v1
I skipped low‑fidelity wireframes 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 be tested with real users.
Designing what weŕe ready to test
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 we knew exactly what we wanted to learn from testing.
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, and replaced 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 — HR admins managing benefits and employees ordering them
The second prototype balanced technical constraints with a realistic, testable experience.
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, how easily employees can find and order a benefit, and whether HR can work without relying on support. This shared hypothesis board aligned expectations around research and made the test results easier to translate into concrete design changes.
By the time testing started, everyone knew what a “good” outcome looked like.
Seeing how admins and employees really use it
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.
Moderated usability testing
Participants completed two scripted scenarios – first as HR admins, then as employees ordering a benefit
In the first scenario, participants played the role of HR managers creating and publishing a new internal benefit. In the second, they switched to the employee side and tried to find and order that benefit. The sessions revealed unclear UX copy, missing navigation banners and confusion around whether a benefit was already published or still in draft.
The flows worked in principle, but key states and copy weren’t explicit enough for confident use.
Follow‑up research round
After fixing the main issues, I ran a second, focused round of moderated testing on the admin side.
Based on the first findings, 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 move through the process with fewer hesitations, improving overall flow and confidence.
Small changes in copy and state visibility had a disproportionately large impact on how confident admins felt using the module.
From validated prototype to implementation
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.
Dev handoff & 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 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.
what changed for pluxee
Outcome
The internal benefits module moved into final production testing as one of the first successfully delivered projects of this type inside Pluxee.
Next Steps
Prepare another round of moderated testing with the shipped UI, monitor how HR teams and employees use the module in production, and apply the collaboration framework to the next internal redesign.
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. The collaboration framework we created was adopted as a pattern for future projects.
What I learned:
I learned that managing stakeholder conflict is part of design work. Pausing the project to run a workshop and set a framework saved more time than pushing through with an unclear process.
