Global navigation redesign
Pluxee runs five products on one account: Pluxee Portal, NGM, Personal Account, Pluxee Search and Cafeteria. Each had grown its own navigation. The seams were showing. I redesigned it into one shared model, validated it with real users, and handed off a pattern the whole ecosystem could inherit.
Year:
2025
Location:
Prague, Czech Republic
Design framework:
Design Thinking
Tools:
Figma, Pluxee Design System, Dovetail, Maze, Teams
3D Hover Component
Connect a frame to the component.
Research
Define
Ideate
Outcome
The problem:
Five products, five different navigations. Users switching between Pluxee Portal, NGM and Personal Account were losing their bearings, because the sidebar told them different things in different places. The tell was in support: "switching between companies and systems" kept coming back as a friction point, and nobody on the product side could point to a single source of truth for how it should work.
Goal:
Design one navigation model that works across every Pluxee product, makes the difference between switching system and switching company obvious, and can be inherited by future products without redesigning from scratch.
My role:
UX/UI Designer owning the navigation redesign end to end. Stakeholder alignment, information architecture, high-fidelity prototyping, two research rounds, and the handoff pattern that the design system now ships.
Methods:
Stakeholder interviews
Hypothesis setting
High-fidelity prototyping in Figma
Moderated qualitative research
Unmoderated A/B preference testing
Design system pattern handoff
Empathize
Before drawing anything, I needed the four stakeholders on one definition of the problem. I also needed to understand what was going on underneath the UI, not just on top of it.
/01
Stakeholder
interviews
The redesign was commissioned by four stakeholders from across Pluxee: Petra Tothová, Jan Gillern, Radomír Jurečka and Filip Bouček. I ran a discovery conversation with each one. Every stakeholder brought a different lens (product, operations, engineering, business), and the overlap between them became the brief. The common thread: they all described the same friction but in different words. That told me the problem was real and systemic, not a matter of taste.
/02
Business Analyst alignment
I then ran a dedicated session with the project's Business Analyst to map the technical reality underneath the navigation. Which systems share a session. When a user's role actually changes. What "switch company" and "switch system" really do in the backend. This session shaped the whole design. The two actions look similar in the UI but do very different things under the hood. That mismatch was the root cause of everything I'd later see in testing.
Define
Stakeholder discovery told me what people said the problem was. The Business Analyst session told me what was actually broken. Put together, they reframed the brief.
/01
The core structural principle
The navigation problem wasn't visual. It was conceptual. Two different actions had been forced into the same control, and no amount of styling would fix it. So before I opened Figma, I committed to a single structural principle that would drive every screen: the left sidebar is for navigating within a system, the top-right is for moving across systems. One place for "where am I going inside this product", another for "which product am I in". Every variant, test and handoff that followed was built on that separation.
Validate
The navigation problem wasn't visual. It was conceptual. Two different actions had been forced into the same control, and no amount of styling would fix it. So before I opened Figma, I committed to a single structural principle that would drive every screen: the left sidebar is for navigating within a system, the top right is for moving across systems. One place for "where am I going inside this product", another for "which product am I in". Every variant, test and handoff that followed was built on that separation.
/01
The core structural principle
The navigation problem wasn't visual. It was conceptual. Two different actions had been forced into the same control, and no amount of styling would fix it. So before I opened Figma, I committed to a single structural principle that would drive every screen: the left sidebar is for navigating within a system, the top-right is for moving across systems. One place for "where am I going inside this product", another for "which product am I in". Every variant, test and handoff that followed was built on that separation.
Ideate
Ideation ran in two beats. One upfront, to commit to the unified model. One later, when moderated testing flagged the switcher still needed work.
/01
One model, two switcher placements
I presented the final design during a grooming session and provided detailed behavioral specifications. This ensured the new stepper component was properly prepared and integrated into our broader design system.
/02
Product launch & results
The first beat was straightforward. If the structural split was correct, the navigation just needed to express it consistently across all five products: one sidebar system, one cross-system switcher, shared by Portal, NGM, Personal Account, Search and Cafeteria.
The second beat came after the first round of testing. My hunch was that the switcher belonged in the top-right, where web apps conventionally put account and workspace controls. But a hunch isn't a reason to ship. So I designed two parallel placements to the same fidelity: Variant A with the switcher inside the left sidebar, Variant B with the switcher in the top-right. Identical everywhere else. Designing both rather than pre-picking meant the team wasn't being asked to rubber-stamp my preference. They were choosing between two real options.
Prototype
With the structural decision made and the initial solution direction set, I went straight to high fidelity. The Pluxee Design System was mature enough to carry a realistic prototype, and I needed stakeholders and respondents reacting to something that looked like production, not a sketch.
/01
High-fidelity prototyping
I skipped wireframes and built the full cross-product journey directly in the design system: Pluxee Portal, NGM, Personal Account, Pluxee Search, Cafeteria Employee and Cafeteria Admin. Working at fidelity from day one meant any visual or interactive decision I made was already aligned with what engineering would build. No second translation step later.
Test
Testing ran in two rounds. Moderated first, to see whether the unified model worked end to end across systems and roles. Unmoderated second, to isolate the preference between the two switcher placements.
/01
Setup and hypotheses
Before the moderated sessions, I went back to the stakeholders and the Business Analyst to turn our suspicions into testable hypotheses, so every task in the script had a clear reason to exist.
H1. Users will confuse switching the system with switching the company.
H2. The current placement of the system switcher is not discoverable on first attempt.
H3. Terminology inside the sidebar (Pluxee Search, Manual point loading) reads ambiguously.
H4. Moving Administration into the main left navigation will be seen as an improvement, not a regression.
/02
Moderated sessions
9 respondents · 19 tasks · 8 of 9 completed
Sessions were run online with HR and HR Assistant users from companies ranging from 20 to 28,000+ employees. Recorded and synthesised in Dovetail.
/03
Signals that changed the design
Cafeteria, Pluxee Search and Administration all passed. The friction concentrated exactly where the stakeholder conversations predicted it would: at the switch between systems.
Pluxee Portal. 4 of 9 only completed the system switch on a second attempt (H1 and H2 confirmed). One respondent ended the session early.
R1: "I had to search for where it was. I hesitated for a while."
Pluxee Search. 3 of 8 read the name as a site-wide search, not a product (H3 confirmed).
R2: "If I wanted to search for something in my personal account, I'd go to Pluxee Search."
"Manual point loading." Flagged as misleading (H3 confirmed).
Administration in the left nav. 2 of 8 volunteered, unprompted, that the new placement was an improvement (H4 confirmed).
R4: "Administration is better now than it used to be."
The signal was clear. The split between left sidebar and top-right switcher was sound. The rest of the sidebar worked. But the cross-system switcher in Pluxee Portal and Personal Account still wasn't discoverable enough. That's where ideation returned before a second round of testing.
/04
Unmoderated A/B validation
14 respondents · 2 tasks · 14 of 14 completed
I shipped both variants to Maze with the same target group, same tasks, and a preference vote plus an open-ended "why" at the end. The unmoderated format stripped out moderator bias and turned the preference question into a clean signal.
8 of 12 chose the top-right (Variant B).
"It's more intuitive. Having the switcher in the top-right is how most web apps do it."
3 of 12 chose the left sidebar (Variant A).
"It suits me that I see everything in one column and just switch where I need."
1 of 12 had no preference.
"Anything where switching lives in the same place is simpler and doesn't confuse users."
Two thirds of respondents confirmed the hunch. That was enough to commit.
Delivery
The final model consolidates five navigations into one pattern, owned by the design system so future products inherit it for free.
/01
Final navigation model and handoff
Left sidebar holds within-system navigation only: menu, sections, Administration (which tested well and stayed). Top-right holds the system switcher, separated visually and spatially from any "switch company" action so the two are no longer confused. "Pluxee Search" and "Manual point loading" were renamed. I packaged the whole thing as a component pattern in the Pluxee Design System, documented states and behaviours, and handed it to engineering with a mapped component inventory.
/02
Research presentation
Alongside the pattern, I delivered a research presentation to the four commissioning stakeholders and the wider product team. It walked through the methodology, the hypotheses and how each one resolved, the findings broken down per product, and the prioritised recommendations coming out of both research rounds. The goal wasn't just to share results. It was to leave the team with a document they could refer back to when future navigation questions come up, so the reasoning behind the pattern travels with it.
Outcome
/01
Impact
Pluxee now has one navigation model instead of five, backed by 23 respondents across two research rounds. Future products inside the ecosystem inherit the pattern from the design system without re-running the discovery work. For the teams that shipped it, the riskiest interaction (cross-system switching) is now the one with the cleanest test data behind it.
/02
What I learned
The most useful thing I did on this project wasn't a design move. It was an information architecture decision made in a conversation with a Business Analyst before I opened
Figma: the split between within-system and across-system navigation. Separating the two research formats was the second. Moderated for does it work, unmoderated for which one do they want. Mixing them would have given me two weak signals instead of two strong ones. And designing two variants instead of defending one gave the team a decision to make, not an opinion to accept.
/03
Next Steps
Ship the top-right switcher in Pluxee Portal first, where the friction was highest. Retest the same tasks after release to confirm the prototype's gains hold in production. Roll the pattern into any new Pluxee product from day one through the design system.ShareContentpd
