Designing tools nobody had asked for
PRACTISE 4
Most of the projects I've worked on at Pluxee have been about fixing something users already complain about. This one was different. HR specialists weren't complaining about the reporting tool, because the reporting tool didn't exist. They just emailed support every time they needed a report and waited.
The work was figuring out what a self-service version should look like, and whether HR specialists would actually use it once they had the option.
Speculative
Futurism
Design challenge
IKEA
The brief
Pluxee's HR clients use the platform to manage employee benefits. Whenever they needed a report on benefit usage across teams, they sent a request to an internal Pluxee team, who pulled the data, formatted it manually, and emailed back an Excel file. Slow on both sides. The brief was to design a self-service module that would let HR teams build, filter, and export their own reports.
Two product managers framed the goal slightly differently in stakeholder interviews. Jan wanted a redesign that was visually modern, technically stable, and user-friendly. Simona, closer to actual HR users, wanted something well-structured, easily filterable, and quickly accessible. Same product, two emphases. I wrote both down because I wanted to make sure the final design served the second one without breaking the first.
Mapping what already happened
Before designing anything, I mapped the current "as-is" reporting flow. Doing this on paper made the bottlenecks obvious in a way that just talking about them didn't. Repeated database queries, manual formatting, long handoffs, and at the end of all that, a static file that couldn't be reused.
The data existed. The tool didn't. That was the entire problem.
I benchmarked a handful of HR and analytics tools to see how they handled complex data, filters, and exports. The point wasn't to copy any of them, it was to avoid reinventing patterns that already had answers.
The genuine gaps I found were multi-team reporting, recurring automated exports, and saved custom views. Those went into the design.
Skipping wireframes
I didn't do low-fidelity wireframes on this project. Normally I would, but Pluxee already had a mature design system, and the business specification was clear enough that going straight to high-fidelity was faster than building two layers. I prototyped the full module in Figma using the existing component library.
Before testing with users, I reviewed the prototype with both product managers and we left comments directly on the file. Those comments became the test hypotheses. Would users miss the date filters? Was "Legislative" a confusing term? Was the export path obvious? Cheap, fast, and it meant the usability test had a clear scoring rubric instead of vague impressions.
Testing with the real users
I ran ten moderated sessions with HR specialists. Real ones, the actual end users, not proxies. Every session was recorded and transcribed in Dovetail.
The hypotheses turned out to be roughly right. Users did miss collapsed filters. "Legislative" was indeed confusing nobody knew what it meant. Several participants asked colleagues for guidance during the test, which told me something about their relationship with the product, they were used to feeling dependent on someone else for reports, and that learned helplessness carried over even into a session where help wasn't supposed to be available.
The empathy map made one pattern clear. The dominant feeling wasn't frustration with the interface. It was anxiety about doing something wrong, deleting data accidentally, picking the wrong filter, missing a step. That changed how I iterated.
Iteration
I pulled the most-used filters out of secondary menus and put them where users could see them immediately. Renamed the confusing terms in plain language. Made destructive actions visibly distinct from harmless ones. The follow-up test hit 100% task success.
What I learned
Designing internal tools is as much about changing habits as changing UI. The HR specialists I tested with weren't fighting the prototype, they were fighting years of muscle memory that said "ask Pluxee for the report." A clean interface alone wouldn't fix that. The product team will need to actively reduce ad-hoc support requests for the new flow to take hold.
The other lesson, less glamorous: skipping wireframes when the design system supports it saves real time. Not always the right call, but on this project it was the right call.
