Information architecture, evolved

The product's navigation had a hidden logic. It made perfect sense internally but was invisible to users. Features were organized around development team ownership and API structure, not around what users were actually trying to accomplish. The result: similar functionality scattered across disconnected areas, inconsistent terminology for the same concepts, and a navigation model that quietly undermined user confidence at every turn.

Fixing it wasn't just an IA problem. It required building a shared understanding of users across engineering, product, and design — and shifting the way the organization thought about how features should be grouped, named, and presented. That meant research, facilitation, and a lot of patient advocacy for the user's perspective.

The first iteration was intentionally bounded. Wholesale reorganization risked disorienting existing users, so the scope was limited to changes that improved the structure without forcing a re-onboarding experience — enough to demonstrate progress, small enough to earn stakeholder confidence for future iterations.

Within those constraints, the changes followed a clear principle: group features by what users are trying to do, not by where they happened to live in the system. A new Observability section brought together analytics and reporting capabilities that had been split across unrelated areas. The Monitors section was expanded to consolidate third-party integrations that serve the same role in a shared workflow. And a restructured Pulsar section used new feature additions as an opportunity to introduce a more coherent sub-navigation.

Enterprise users bring high expectations for precision, for consistency, and for a product that communicates competence through its structure. The third iteration focused on the details that shape that perception: sub-page organization that accurately reflects different data types and configurations, cleaner separation of distinct entity types, and terminology that is consistent and confident across sections.

These weren't dramatic structural changes. But they represent the beginning of a deliberate design voice — one where the architecture itself signals that this is a serious tool for serious use cases.

The fourth iteration commits to a structure built entirely around the DNS configuration process itself. Four categories, each representing a distinct phase of work: establishing a DNS foundation, automating data collection from DNS resources, configuring traffic steering to optimize availability and performance, and analyzing the results. Users can move left to right through a workflow that mirrors how the work actually unfolds.

This version has never been implemented — and may never be. But it represents something important: an architecture where the technical story told through the UI is fully comprehensible. Each layer builds on the last, and the product stops feeling like a system to navigate and starts feeling like a process to follow.