Surf
Ocean
Freedom
Experience
Internal reporting modul
Internal Reporting is Pluxee's reporting module
used by HR teams to track how employees use their benefits.
For years, every report had to be prepared manually
by an internal team. We changed that.
Year:
2025
Location:
Prague, Czech Republic
Design process:
Lean UX
Tools:
Figma, Pluxee Design System, Dovetail, Teams
My role:
UX/UI Designer
Research
Define
Test
Delivery
Validating the Friction
Project overview
Internal reporting is Pluxee's reporting module used by HR teams to track how employees use their benefits. For years, every report had to be prepared manually by an internal team. We changed that.
Hypothesis:
HR specialists weren't unable to work with their data because the data wasn't there. They were blocked because the tool didn't exist. Every report had to go through an internal team — creating delays and unnecessary dependency on Pluxee's customer service.
Goal:
To design a self-service reporting module that allows HR teams to create, filter, export and manage their own benefit reports — without contacting Pluxee support.
My role:
UX/UI Designer leading the end-to-end design of the reporting module — from stakeholder interviews and personas through high-fidelity prototyping, moderated research and dev handoff.
Methods:
Stakeholder interview
Requirements analysis
Personas
How Might We
Jobs to be Done
High-fidelity prototyping
Moderated user research
Usability testing Prototype iteration
Dev handoff
Understanding the current reality
Research
Before designing anything, I needed to understand why reporting felt slow and dependent for HR teams. By talking to product managers and mapping how reports were requested and delivered, I could see where the current process was breaking down.
Stakholder interview
Two product managers walked me through how HR clients request and receive reports today.
I ran two stakeholder interviews to clarify goals and current pain points. We mapped the real reporting flow, from client request to final Excel export, and noted where work is slow, manual or blocked by internal teams.
"We are planning a complete redesign of the corporate reporting module. Previously, we prepared them for the clients ourselves, but now we want to give clients a tool that allows them to easily create them themselves. The module should be visually modern, technically stable, and above all, user-friendly."
— Jan Gillern, Product manager
"From an HR perspective, we need the new system to allow easy orientation in the utilization of benefits across teams while also saving time. Exports and reports primarily serve HR specialists, and therefore it is important that they are well-structured, easily filterable, and quickly accessible"
— Simona Kuldová, Product manager
The key insight: data exists, but HR teams can’t access it without asking someone inside Pluxee.
Current process mapping
I mapped how a single reporting request travels through Pluxee today, from HR to final export.
Using input from stakeholders, I sketched the current “As‑is” reporting flow: HR sends a request, internal teams prepare custom exports, and results go back by email. The map made bottlenecks visible repeated manual steps, long waits between handoffs, and no way for HR to reuse or tweak existing reports.
Tool benchmarking
I mapped how a single reporting request travels through Pluxee today, from HR to final export.
I looked at several HR and analytics tools to see how they structure reports, expose filters and offer export options. This helped me avoid reinventing basic patterns and focus on gaps specific to Pluxee, like multi‑team reporting and recurring exports.
What we confirmed and changed
Learnings
With a working prototype, I watched where HR specialists hesitated and used usability tests to confirm what worked and what needed to change.
Prototype notes
I tracked the moments where users slowed down or got confused in the reporting flow.
During early prototype sessions, I noted every hesitation: unclear report types, hidden filters, or export options users didn’t notice. These notes turned into lightweight hypotheses about what people would or wouldn’t understand.
Usability testing
I ran task‑based tests with HR specialists using realistic reporting scenarios.
I asked participants to create and export specific reports, then observed where they got stuck. The tests confirmed which ideas worked — like keeping key filters always visible and revealed what to change, such as labels that users consistently misread.
Updated hypotheses
After each round, I captured what we had confirmed and which assumptions we needed to rethink.
From the tests, I summarised a few clear statements, for example: “Users understand the difference between saved and ad‑hoc reports” or “Users overlook export options when they sit in a secondary menu.” These learnings guided the next design iteration and helped the team align on what to keep, fix or drop.
Turning insights into a flow
Design
Based on the research and learnings, I explored how a self‑service reporting flow could work for HR specialists inside Pluxee.
User flows
I mapped a simple end‑to‑end flow from creating a report to exporting it.
Using the current process and test learnings, I sketched a new flow: pick a report, set filters, preview, then export. This helped me remove redundant steps from the old process and keep all critical decisions in one clear path for HR specialists.
Wireframes
I translated the flow into simple screens without visual styling.
I created low‑fidelity wireframes to test layout ideas: where filters live, how results are displayed, and where export actions sit. Keeping things rough made it easy to move sections around and align with product on what each screen must do before polishing the UI.
High‑fidelity prototype
I rebuilt the reporting flow using Pluxee’s design system components.
Once the layout worked, I moved to a high‑fidelity prototype with real data, Pluxee typography and components. This made it realistic enough for stakeholders and HR specialists to judge whether the reporting tool feels trustworthy and ready for everyday use.
Turning insights into a flow
Test
I ran usability tests with HR specialists to see how well the new reporting flow works on real tasks.
Usability sessions
I asked HR specialists to complete real reporting tasks in the prototype.
In short, task‑based sessions, participants created and exported reports they would normally request from Pluxee. I watched where they hesitated, missed an action or asked for help, and captured their comments on clarity and speed.
Key changes after testing
I adjusted copy, hierarchy and actions based on what users actually did.
The tests led to a few focused changes: clearer report labels, always‑visible key filters, and more prominent export actions. Each change directly addressed a moment where users got stuck or misunderstood the interface.
The project conclusion
Outcome
The final reporting concept gives HR specialists a self‑service way to create and export reports without waiting for manual help from Pluxee teams.
Takeways
The project showed that even a small, focused UX effort can unblock an internal process that had grown around manual work and one‑off Excel exports. For the first time, stakeholders aligned on a shared picture of what “good” reporting should look like.
Impact:
The new flow reduces the number of ad‑hoc report requests and makes standard reports something HR teams can run themselves. Product and development now have a concrete, tested pattern they can reuse for future internal tools.
What I learned:
Designing internal tools is as much about changing habits as changing UI. I learned how important it is to involve development early and to frame every design decision in terms of implementation cost and support load.
Next Steps
Roll out the new reporting flow to a pilot group of HR clients and track how often they still ask for manual exports.
Further research: Rerun usability testing with the shipped version to see whether improved reporting actually reduces time spent on manual requests and follow‑up questions.
