Case study
Rethinking navigation for a growing, multi-product platform
Interfaces are reconstructed to respect client confidentiality.
The context
A platform growing faster than its architecture could support.
As Waterplan grew, so did the number of customers, products, and features. What started as a shared platform was evolving into a much more complex ecosystem, with customers asking for increasingly tailored experiences.
The existing architecture hadn’t been designed for that level of growth or flexibility.
Growth and personalization were platform-level challenges that drove several initiatives across the product. This case study focuses on one of them: navigation and information architecture.
The problem
One platform couldn’t keep working the same way for everyone.
Customers wanted Waterplan to feel more like their own environment — from terminology and branding to how information, metrics, and formulas were presented.
At the same time, new products and features were constantly being introduced, and the existing navigation was running out of room.
Every new request meant figuring out where things could fit, often adding complexity to both the user experience and development.
Navigation was where both pressures became most visible.
Why it was hard
How do you make one platform feel like many, without building a different product for every customer?
The UX challenge went beyond reorganizing a sidebar. We needed an architecture that could accommodate more products, support different customer configurations, and remain intuitive regardless of how each organization used the platform.
The difficult part was finding the right balance between a consistent product experience and the flexibility customers expected.
My role
Growth and personalization shaped several initiatives across the platform. I focused on rethinking Waterplan’s navigation and information architecture to support a more flexible, scalable platform.
My focus was understanding how the growing number of modules, customer-specific configurations, and workflows could coexist within a single experience.
That meant reconsidering how the platform was organized, how users moved between products, and how the interface could accommodate different needs without becoming increasingly complex.
The decisions that shaped the product
-
Build for growth, not just the next feature
- Decision
- Create a navigation architecture that could accommodate new products and capabilities.
- Over
- Continuously adapting the existing menu to fit each new request.
The previous structure was reaching its limits, making every addition harder to integrate.
-
Make room for customer-specific experiences
- Decision
- Design a shared navigation framework that could support different customer configurations.
- Over
- Maintaining one rigid experience or creating separate interfaces for individual customers.
Customers needed flexibility, but the product still needed a consistent foundation that Design and Engineering could maintain.
-
Separate the platform structure from its presentation
- Decision
- Define which parts of the navigation could vary per customer — terminology, branding, and other configurable elements — without changing its underlying logic.
- Over
- Treating every customization request as a separate navigation problem.
A flexible platform needed to accommodate customer differences without fragmenting the overall experience.
The evolution
A platform running out of room
New products, features, and customer requests were pushing the existing navigation beyond its original limits.
Rethinking the architecture
Reorganizing the platform around a more scalable structure that could support multiple products and different customer needs.
One platform, more flexibility
Creating a shared navigation experience capable of accommodating growth and customer-specific configurations.
Outcome
A more flexible foundation for a growing platform.
I helped reshape Waterplan’s navigation and information architecture around a more scalable model — moving away from constantly finding space for new features toward a structure designed to accommodate multiple products and customer-specific needs.
Lessons learned
Scalability starts with architecture.
A design that works for today’s product can become a limitation as new capabilities and customers are introduced.
Flexibility needs structure.
Customization only works sustainably when there’s a consistent foundation underneath it.
Design decisions create technical consequences.
Information architecture isn’t just about where things appear on screen. It directly affects how easily a product can evolve.
