Back to all ArticlesAnd what designers get wrong when working with data-heavy products
The uncomfortable truth
Most navigation design fails.
Not because designers lack skills.
But because they solve the wrong problem.
They focus on:
- menus
- labels
- grouping
Instead of asking a more fundamental question:
What is the structure of the system I’m designing for?
The real problem is not navigation
In simple products, navigation is about access.
In complex systems, it’s about understanding.
Users don’t struggle because they can’t click something.
They struggle because:
- they don’t understand how the system is organized
- they don’t know where they are
- they don’t see how things connect
And no amount of “clean UI” will fix that.
Feature-based navigation is the biggest mistake
Most systems grow like this:
- new feature → new item in navigation
- new module → new section
- new requirement → another layer
Over time, navigation becomes:
👉 a list of everything the system can do
👉 instead of a model of how the system works
And that’s where everything starts to break.
What happens when navigation is wrong
You don’t just get a messy menu.
You get:
- slower workflows
- higher cognitive load
- poor onboarding
- constant confusion
- expensive redesigns later
Because navigation is not a surface problem.
It’s structural.
Designing navigation as a system
In data-dense environments, navigation must do something very specific:
support work without interrupting it
That changes everything.
1. Navigation should reflect system logic
Not features.
Not teams.
Not backend structure.
👉 system logic
If users move through:
- assets → execution → results
Navigation should reflect that.
2. Not everything should be equally visible
One of the biggest UX myths:
“Everything should be easy to access”
No.
Everything should be:
- where it makes sense
- when it makes sense
3. Navigation is not one component
In complex systems, navigation is a layered system:
- top navigation → control & awareness
- side navigation → structure & domains
- context navigation → local actions
Treating it as one thing is a mistake.
A different approach
In my recent work on a data-dense system,
navigation was not designed as UI.
It was designed as:
a representation of the system architecture
That meant:
- separating domains instead of features
- mapping system lifecycle
- defining responsibilities of each layer
- ensuring scalability from day one
This approach becomes much clearer when applied to a real system.
👉 Here’s a breakdown of how I structured side navigation for a complex, data-heavy product:
https://zofiaszuca.com/project/designing-side-navigation-for-complex-systems
The shift designers need to make
If you’re designing for complex systems:
Stop asking:
- “Where should this go?”
Start asking:
- “What part of the system is this?”
Final thought
Navigation is not about helping users find things.
It’s about helping them understand the system they’re working in.
And once they understand it —
they move faster than any UI could ever make them.
🔗 Want to see how this works in practice?
If you're working on a complex product and navigation keeps breaking as you scale —
this might help:
