Product development at Digitec Galaxus
Rethinking product filters
How we modernized product discovery at Digitec Galaxus from a left-hand checkbox column into a responsive pill and dialog system.
Loading article…
Product development at Digitec Galaxus
How we modernized product discovery at Digitec Galaxus from a left-hand checkbox column into a responsive pill and dialog system.
Loading article…
I'm based in Neustadt a.d. Weinstraße, Germany, and prefer remote work.
Product filters are one of those features users only notice when they do not work well. With millions of products, thousands of categories and very different product types, filters become central navigation.
My biggest topics were state management, routing behavior, browser back, mobile dialog navigation, scroll locking and a clean separation between search state and UI state.
Digitec and Galaxus had a strong focus on structured product data from early on. Products were not only described with title, price and image, but enriched with many technical and domain-specific attributes.
Someone looking for a TV might filter by screen size, panel technology, ports or energy efficiency. Someone looking for a sofa cares more about material, color, width or style. That data foundation was both an opportunity and a challenge.
I worked as a full-stack engineer in the team responsible for rebuilding the product filters. My focus was close to product and frontend implementation: interaction model, state management, URL and routing behavior, browser-back logic and mobile specifics such as scroll locking and focus management.
This was not a solo project. We worked closely as a team and with UX. Many decisions emerged iteratively from research, mockups, tests, discussions and technical evaluation.
The old filtering solution was classic desktop e-commerce: filters in a left column next to the product list. Many experienced Digitec users knew that column very well. At the same time, the concept was hitting limits: too little room for complex filters and no direct translation to mobile.
UX context: Left-hand filters are established, but with many options they can overwhelm users and disappear into banner blindness. A horizontal filter bar keeps attention closer to the results and creates more room for complex interactions.
The central design decision was to move filters out of the left column and place them above the product list. Instead of long checkbox lists, filters became compact pills. Clicking a pill opened a dialog with available options.
The biggest technical challenge was deciding which state belongs where: search state, URL state, UI state, temporary dialog selection and platform-specific behavior. Not every state belongs in the URL, but everything that changes results must stay traceable and reload-stable.
We chose a decoupled model: while a filter dialog is open, the product list updates dynamically, but the URL commit happens only when the dialog closes. This keeps browser history clean and makes the mobile back button close the dialog instead of undoing local intermediate steps.
On desktop, filter dialogs behave like compact overlays. On mobile, a filter dialog is almost its own view: full screen, its own scroll locking, focus management and a clear browser-back expectation.
Scroll locking on mobile was much more complex than it looks from the outside. Viewport heights, address bars, touch scrolling and overscroll differ significantly between mobile browsers.
For numeric values such as price, screen size or minimum age, checkbox lists are a poor fit. We needed range sliders. Elasticsearch aggregations allowed Galaxus to know how many products existed in each value range.
A price filter becomes more than an input. It becomes a small data visualization. Users can see whether a target range is realistic or whether they are filtering into an empty area.
The new filter solution was not better in every dimension. For some power users, the old left column initially felt faster because many options were directly visible. The redesign hit a nerve and triggered community discussion.
For me, this was a good example of why product ideas need iteration and why some features should be removed again when real usage does not justify the maintenance cost.