Victoria Bieghs

Designing a PartFinder for A System That Doesn’t Fit on a Screen

During my time as a consultant in the e-commerce landscape, I had the opportunity to design a part-finder interface for an industrial spare-parts catalog.

This interface had to represent a physical installation on screen, whether that meant a warehouse, an airport system, or any other kind of hierarchical environment.

Users were not just going to navigate a flat list of products, but move through the structure of the installation itself: areas contain machines, machines contain assemblies, and assemblies contain the individual parts that can ultimately be ordered.

The result is a hierarchy that can easily span five or six levels, sometimes more, and whose shape is neither consistent nor predictable.

Warehouse

└─ Area

└─ Machine

└─ Assembly

└─ Part

The goal of this interface was to help technicians and operators locate the correct spare part within this structure as reliably as possible. In practice, users often already roughly know what they’re looking for. Something broke, and they likely have a SKU or internal reference for the product. The challenge is confirming that it’s actually the correct part for their specific installation.

Because spare parts often look similar and identifiers can change over time, technicians rely heavily on the structural context of the system itself to verify they’ve reached the right component.

This post focuses on the interface side of that work: how do you make a structure like this navigable on the web?

Why Conventional Navigation Patterns Break Down

“No worries,” I thought. This must have already been solved!

Hierarchical navigation isn’t new, file systems have existed for decades. Surely there must be a standard pattern that works for this, right? So I started digging...

I read modern UX articles, browsed through design systems, and checked a lot of popular websites. Surprisingly, none of them seemed to deal well (or at all) with the specific problem I was facing. Eventually I had to start looking further back in time;

UX forum posts with screenshots that look horribly pixelated on my modern monitor. Archived documentation for tools that only still exist on the Wayback Machine. Basically, the places where people had probably already wrestled with deeply nested hierarchies long before modern web applications existed.

And I tried everything. Looked everywhere, and eventually the following design-patterns kept resurfacing;

Tree Views

Tree views were the obvious first candidate. The pattern is familiar: expandable nodes with indentation that shows hierarchy depth. It’s essentially the classic file explorer pattern.

Tree View Navigation Pattern (PatternFly.org)

Unfortunately for me, this pattern works… until it doesn’t.

Actually navigating through this nested soup quickly overwhelms users once the number of nodes grows beyond a handful. When the hierarchy itself becomes unpredictable (or should I say, realistic), the interface starts to feel like it’s fighting you.

One click reveals three children. The next reveals fifty.

The page stretches, content shifts around unexpectedly. The structure stops feeling like a solid structure and starts to resemble a moving target instead...

Drill-Down Navigation

Fine. The first option is rarely the best, but, looking at drill-down navigation patterns instead, revealed the opposite problem. Sure, the page itself stays stable, but the hierarchy gets flattened instead. Each step replaces the previous level rather than expanding it. I can see the items, but I lose sight of where they belong in the larger structure, and with that, I lose confidence that I’m looking at the right component for my installation.

So, both approaches expose hierarchy. Neither of them preserve orientation.

Drilldown Navigation Pattern (PatternFly.org)

At that point it started to feel like none of the standard patterns really solved my problem.

For a moment I was almost ready to accept what many UX blog posts eventually conclude: combining “huge dataset” and “navigation” in the same sentence, inevitably leads to something clunky.

But while researching tree-based navigation patterns, I came across the following article on Medium comparing two approaches: tree structures and Miller columns.

Miller Columns

This interaction model first appeared in early Unix tools, most notably in the NeXTSTEP operating system in the late 1980s. Decades later, the same idea still survives today in macOS Finder’s “column view”.

Miller columns (Wikipedia.org)

It solved exactly the problem I was running into: showing hierarchy without losing orientation.

Each level of the hierarchy appears in its own column. Selecting an item reveals the next level to the right while keeping the previous levels visible. The entire path remains on screen.

Perfect!

Then, I had another look at the data my client sent me. An installation could be seven levels deep, at minimum.

Then, I looked at the e-commerce interface this feature had to live in.

The page layout allowed roughly 1200 pixels of usable width.

Expanding the max-width wasn’t an option for several reasons. And serving users seven or more columns that are barely a hundred pixels wide each, then shipping it as a “new feature that will improve your workflow”, is just downright evil. Plus, making the columns appear horizontally on click was exactly the flaw I had already rejected in drill-down navigation...

So, the behaviour was right, but the layout wasn’t.

Compressing a Horizontal System into a Vertical One

I kept searching for alternatives that might fit my use-case better. But, the Miller column approach really felt like it was the right one.

Fine then.

If the hierarchy couldn’t expand sideways, the only remaining option was to make it expand downward.

But, simply stacking levels vertically would recreate the same problems I had already rejected before: long, unstable lists that constantly shift around as new content appears, forcing users to search for where the interface changed.

So instead of copying the Miller column layout directly, I kept its underlying behaviour and adapted it to work inside a single column;

Production Screenshot – Installed Base Explorer (dummied data)

When a user selects an area or zone in the installation, the selected location moves to the top of the column and its direct children appear immediately underneath it.

This ensures the next step always appears in a predictable position. So, instead of scanning the page to figure out what changed, users can keep their focus in one place while the hierarchy progresses around it.

Once I had a way to preserve orientation, another problem immediately surfaced: some of these nodes simply contained far too many children.
Some nodes contain only a handful, others contain hundreds.

Showing everything at once would technically be accurate, but practically unusable. At the same time, hiding too much would destroy trust and make navigation unnecessarily tedious for users who need to move through the system quickly...

So, the solution was to reveal data in controlled batches.

Top-level locations expand more generously, because users often scan them to orient themselves. Deeper levels, where navigation becomes more precise, load in smaller, consistent groups that always fit within the viewport.

This keeps the structure explorable without overwhelming the user, and ensures that moving deeper always feels like moving forward. Not like opening Pandora’s box.

Two Synchronized Representations of the Same System

The structural Miller-inspired column I created is optimized for navigation speed. It’s compact, predictable, and works well for users who already know the hierarchy and can move through it using identifiers alone.

But, hierarchy by itself often isn’t enough. Especially in physical systems, recognition plays an equally important role. Users often rely on visual confirmation; a machine name, an image, or a familiar label, to verify they’ve reached the correct location or assembly.

To support that, the main content area presents the same selection as visual cards. These show images, descriptive names (all of which the user can edit), and details associated with each element.

Both views represent the same underlying hierarchy;

The column provides structure and navigation.
The cards provide context and confirmation.

They remain synchronised at all times, so moving through one immediately updates the other.

Installed Base Explorer – Component Cards synchronized with hierarchy navigation

Orientation Must Be Reinforced Relentlessly

In hierarchies like this, losing your position isn’t a minor inconvenience.

It breaks the entire interaction flow.

If users can’t immediately tell where they are, they stop trusting the structure. Momentum disappears and is instead replaced by hesitation. So, orientation must be reinforced continuously, and in multiple ways at once.

The breadcrumb provides the full structural path, allowing users to step backward without resetting their progress. The page title states the current location in plain language, confirming that the structural identifier matches the physical system they expect.

At the same time, the column highlights the active branch while the visual cards mirror the same selection in a more descriptive form.

None of these elements are complex individually. But together they eliminate ambiguity. At any moment, users can see where they are, how they got there, and what exists around them.

Just as importantly, the system makes exploration safe. Moving into the wrong branch doesn’t reset the interface or discard progress. Users can step back one level at a time, adjust their path, and continue without friction.

That safety is what makes the hierarchy usable at scale.

Installed Base Explorer – Hierarchical Navigation (production UI)

The Result

What emerged isn’t a standard Miller column implementation. It doesn’t attempt to visualize the entire hierarchy at once. Instead, it reveals the structure progressively, in place, without disorienting or overwhelming the user.

And in a system where the hierarchy is the product, that difference matters.

The interface itself was only one part of the problem. None of this would have worked without reconstructing the underlying hierarchy from raw system data.

That reconstruction introduced its own challenges, particularly around inconsistent identifiers and implicit relationships in the source data. I plan to write about that process separately.