19 min read researching

Information Architecture Principles for Navigation in Technical Infrastructure Products

We're engaged in a major IA redesign effort at Tailscale and as part of that I've been refreshing what we know about information architecture design. Unfortunately, a lot of what I've seen is either too specific to consumer SaaS practice, or is too generic in its approach. I can't find very much at all that specifically targets enterprise or technical infrastructure products, and even less that specifically talks about navigation category design. So this is an attempt to define design principles that govern category design, and articulate the logic for those principles. A minimal design process for category design is also suggested.

The goal of a navigation structure is to construct a stable, legible environment in which people with different goals, roles, and levels of familiarity can orient themselves and compose their own paths through the work. It is not to match how users think, and it is not to surface a single correct set of categories.

The navigation structure is terrain rather than an itinerary: an environment that supports many journeys, which people wayfind through rather than follow. It succeeds when someone diagnosing a failure, someone provisioning access for a new collaborator, and someone assembling evidence for an audit can all find their way around; the structure does not anticipate any of their specific goals, but makes the work domain legible enough to navigate from wherever each of them happens to be standing.

A navigation environment should help people build a mental model of the system with as little effort as possible, and that model should be of things that do not change in the long term. This is a design commitment rather than an empirical claim about cognition. I think it is mistaken and impractical in most contexts to discover a "true" set of user categories exists and that research can surface it. Impractical because it is expensive and time-consuming to produce a statistically valid result and a non-significant result can't be used to make existence claims at a population-scale; mistaken because categories are socially constructed objects, and a category set is mutually constructed so adding/removing/changing a category or its contents affects how a viewer will understand the rest, making the entire claim unstable.

Instead, I propose that the navigation must function as a resource for situated action across a diverse range of use, and that this requirement places specific constraints on how the structure is constructed.

This document assumes the context of technical infrastructure products: systems that are operated rather than merely used, with diverse concurrent users, no single primary workflow, and high-stakes diagnostic journeys. It also assumes shallow navigation hierarchies of two or three levels, which is typical for such products. (If you work for AWS, you have bigger problems with bigger resources to solve them, but that is not most of the audience for this post.)

It might be helpful to review these concepts first before reading the main argument: information scent, berrypicking, situated action, prototype theory.

Organising levels

Before the principles can be applied, a candidate schema needs to be described: what kind of thing is it organised around? Four common organising levels recur across navigation structures, and any proposed schema is built from one of them, or from a mixture.

Objects are the persistent entities in the system: the things that maintain state, that people return to, and that exist independently of any particular use. In an infrastructure product these are the first-class objects that constitute any deployment or instance, and which have long-lived state that users can see. (So this would exclude temporary and transactional objects.)

Activities are what people do: purposeful engagements with the system, tied to a motive. An activity typically targets objects rather than containing them; a single activity may touch several object areas, and a single object serves many activities.

Workflows are sequences of steps: ordered paths through activities and objects toward a defined outcome. A workflow sequences actions on objects.

Solutions are vendor-side bundles: capabilities packaged into named offerings aligned with buyer needs and market positioning. A solution bundles objects and activities into a sellable unit. Unlike the other three levels, this one originates in the vendor's go-to-market structure rather than in the user's work.

The relational structure among these levels matters more than the list itself: activities target objects, workflows sequence actions on objects, and solutions bundle both. The levels stand in asymmetric relationships to one another, and those relationships determine what happens structurally when each is placed at the top of a hierarchy. Which level best satisfies the principles below is a judgement to be made per product and per context, by applying the principles as filters. This document deliberately does not make that judgement; it supplies the criteria by which any candidate, at any of these levels or at ones not listed here, is to be evaluated. 

This is also not an exhaustive list of schema. Consult the literature review section for some other common topic types. 

Category Design Principles

The principles are constraints. Any proposed schema must pass all of them.

1. Structural durability

Categories must be stable across changes to product packaging, naming, and organisational structure. A category that would need to move, merge, or rename after a rebranding, acquisition, or product reorganisation is too tightly coupled to implementation.

Test: Could this category have been named before the current product lineup existed? Would it survive the next repackaging?

2. Non-overlapping top-level categories

Each top-level category claims distinct conceptual territory. In a shallow hierarchy, overlap at the top is unresolvable, because there is no deeper level available to disambiguate. If two categories overlap, an item either lives in both, violating single home, or is arbitrarily assigned to one, requiring the user to guess which.

Test: For any object in the system, can you identify its parent without ambiguity? If two categories could plausibly claim it, the partition is leaking.

3. Sibling coherence

Any set of items sharing a parent is drawn from a single nameable organisational scheme. You do not mix product brands with capability descriptions with domain objects at the same level. Mixing schemes at a single level means that no single information-seeking strategy works across that level.

Test: Can you name, in one phrase, the scheme that unifies all children of a given parent? If not, the parent is holding together items that don't belong together.

4. Category-content coherence

Encountering an unexpected object inside a category should deepen your understanding of the category, not introduce dissonance. Perfect predictability is neither achievable nor necessary, but the relationship between a category and its contents must be legible enough that each encounter reinforces the model rather than requiring memorisation.

Test: Show someone an object they haven't seen before, placed in its proposed category. Does the placement make sense to them after seeing it? "I wouldn't have guessed that, but it makes sense here" is passing. "Why is this here?" is failing.

5. Goal-agnosticism

The structure does not require the user to pick a goal, solution, or workflow before they can locate something. Goals and solutions are realised as paths across categories rather than as containers for them. When a surface can serve multiple goals, it cannot be nested under any one of them.

Test: Take the three most common cross-cutting tasks. Can a user reach the relevant surfaces without first committing to a solution area or workflow?

6. Low prior-knowledge demand

Finding something must not depend on knowing the product's internal boundaries, its packaging, or its taxonomy. Labels carry scent to someone who does this kind of work but has never used this product.

Test: Show the top-level labels to a qualified person who has never seen the product. Can they predict what's behind each one? A label that requires a tooltip or a briefing has failed.

7. One canonical home, no homonyms

Every persistent object has exactly one home in the navigation. The same label never appears twice meaning different things. Cross-cutting views (seeing one object's related records from another object's page, for example) are visibly views rather than competing destinations.

Test: Flatten the nav to a single list of leaf labels with parents stripped. Any duplicate or near-duplicate is a defect.

8. Parsimony

The fewest top-level categories and minimum depth that can hold the domain without distorting it. With only a handful of top-level slots, each slot carries a substantial fraction of the entire schema. Adding a category requires showing that an existing one is too broad for users to scan, not that a new product needs a home.

Test: If someone proposes adding a top-level item, ask what scheme its new siblings share and what evidence shows the existing parent was too broad.

Construction process

The principles constrain what the navigation must not do. The following rough process describes how to proceed: how to build a schema that honours the principles.

Identify the core stable elements that people hold state about. The persistent entities that people return to, and that maintain state across interactions, anchor the environment; they do not change depending on what the user is trying to do.

Group related elements into non-overlapping, exhaustive areas of the work domain. The grouping should partition the full scope of the work: nothing falls outside the schema, and no element is claimed by two areas. Exhaustiveness matters, because an element with no home is a gap in the environment.

Reflect clear category centrality. Each grouping has a recognisable centre, a prototypical member that makes the category legible. If a proposed category has no clear centre, it is probably not a coherent area of work.

Use categories that are stable in the work domain. The areas should be nameable by any practitioner in the domain regardless of which vendor's product they use; they describe the problem domain rather than the product. This is what makes them durable: they survive repackaging because they were never coupled to packaging in the first place. You may wish to test with a representative sample of user types in order to verify this claim.

Support different goals, configurations, and patterns of use. The same set of categories must be navigable by someone doing routine maintenance, someone investigating an incident, and someone configuring a new deployment. The structure succeeds by making the work domain legible enough that each person can compose their own path, rather than by anticipating those paths.

Theory and literature

The principles and construction criteria above are grounded in several intersecting literatures from different traditions. This section maps each theoretical strand to what it supports and what analytical lens it provides. The traditions supply criteria; they do not, individually or collectively, decide which organising level wins for a given product. That judgement is made by applying the principles to candidates.

Information architecture: organisation schemes and labeling systems

The canonical vocabulary comes from Rosenfeld, Morville & Arango's Information Architecture (4th ed., O'Reilly, 2015). They distinguish exact schemes (alphabetical, chronological, geographical) from ambiguous schemes (topical, task-oriented, audience-specific, metaphor-driven, hybrid). Exact schemes serve known-item searching; ambiguous schemes serve browsing and vaguely-defined needs. The key design rule is that siblings within a level share a scheme.

The classic warning against org-chart IA ("don't organise your intranet by department") generalises: any structure that partitions the space by internal ownership imposes the organisation's structure on users, who navigate by the structure of their work rather than by who owns what.

Labeling systems are a distinct component of IA. Labels succeed or fail independently of structure. The discipline of controlled vocabularies directly addresses the homonym problem.

This supports: sibling coherence, non-overlapping categories, no homonyms. It describes why mixing organisational schemes at one level is problematic.

Sources:

The vocabulary problem

Furnas, Landauer, Gomez & Dumais (1987) demonstrated that two people spontaneously choose the same term for the same thing with probability less than 0.20. A label chosen by one designer and treated as the single access point will fail 80–90% of the time. A homonym, the same label with different referents, makes the situation worse than chance, because the user forms a prediction that is actively wrong.

This supports: low prior-knowledge demand, no homonyms. It means that duplicated labels in a nav are a measurable navigation failure, and that labels need to be validated with users rather than negotiated internally.

Sources:

  • Furnas, G.W., Landauer, T.K., Gomez, L.M. & Dumais, S.T. (1987). "The vocabulary problem in human-system communication." Communications of the ACM, 30(11), 964–971. — doi:10.1145/32206.32212

Cognitive Work Analysis and the abstraction hierarchy

Jens Rasmussen's abstraction hierarchy (1985, 1986) and Kim Vicente's Cognitive Work Analysis (1999) were developed for complex sociotechnical systems (process control, aviation, defence) where the work is diagnosis and control rather than shopping. The abstraction hierarchy models a work domain along a means-ends dimension with five levels:

  1. Functional purpose: why the system exists. Too abstract for navigation; it is one thing, not five.
  2. Values and priority measures: criteria for judging performance. Also too abstract; these are evaluative rather than navigational.
  3. Purpose-related functions: what the system does, in terms the work domain recognises independent of any particular product's implementation.
  4. Object-related processes: how specific mechanisms accomplish the above. Too specific for top-level navigation.
  5. Physical form: the actual components, including product names. The most volatile level.

The hierarchy provides a way of asking, of any candidate category, what level of abstraction it occupies, and of predicting its volatility from that position. The higher levels are stable but too abstract to partition; the lowest level is concrete but changes with every implementation decision. Purpose-related functions sit at the level where categories can be simultaneously stable, scent-bearing, and recognisable to anyone in the work domain.

Work Domain Analysis (WDA), the first phase of CWA, is deliberately event-independent and actor-independent. It models the constraints of the domain itself rather than any one workflow or role. This is why WDA-derived structure is durable: it survives repackaging, bundling changes, and acquisitions because it describes the problem domain rather than the product.

Ecological Interface Design (Rasmussen & Vicente, 1989–1992) builds on this: the interface should make the work domain's structure visible so that users can compose their own routes through it, rather than encoding one canonical sequence. The empirical results are clear: progressively adding information from higher levels of abstraction improves performance, and grouping information according to structural means-ends relations outperforms not doing so.

This supports: structural durability, goal-agnosticism. It provides a formal instrument for locating any candidate category on the abstraction dimension and reasoning about its stability from its position.

Sources:

  • Rasmussen, J. (1986). Information Processing and Human-Machine Interaction: An Approach to Cognitive Engineering. North-Holland.
  • Vicente, K.J. (1999). Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Lawrence Erlbaum.
  • Vicente, K.J. & Rasmussen, J. (1992). "Ecological Interface Design: Theoretical Foundations." IEEE Transactions on Systems, Man, and Cybernetics, 22(4), 589–606. — PDF
  • Naikar, N. (2013). Work Domain Analysis: Concepts, Guidelines, and Cases. CRC Press.
  • Read, G.J.M. et al. (2016). "Cognitive work analysis: An influential legacy extending beyond human factors and engineering." Applied Ergonomics, 59, 528–540. — sciencedirect.com
  • Reising, D.V.C. (2000). "The Abstraction Hierarchy and its Extension beyond Process Control." Proceedings of the Human Factors and Ergonomics Society, 44. — sagepub.com

Information foraging and information scent

Pirolli & Card's information foraging theory (1999) models navigation as a foraging problem. Users are "informavores" who follow scent gradients, evaluating proximal cues (labels, links, icons) to predict the value of what lies behind them. A label succeeds when it predicts what is behind it before the user clicks. A label with zero scent is a dead end in the foraging model regardless of what lies behind it.

The claim is: navigation is an adaptive optimisation process, and users continuously weigh the cost of pursuing a path against the expected information gain. Internal codenames and packaging jargon carry no scent to anyone who has not been briefed, meaning the foraging process stalls.

This supports: low prior-knowledge demand. It means that scent is a property of the label relative to the user's existing knowledge, not of the label in isolation. Labels drawn from the work domain carry scent to anyone who does the work; labels drawn from the product carry scent only to people who already know the product.

Sources:

  • Pirolli, P. & Card, S.K. (1999). "Information Foraging." Psychological Review, 106(4), 643–675.
  • Pirolli, P. & Card, S.K. (1995). "Information foraging in information access environments." Proceedings of CHI '95, 51–58.
  • Pirolli, P. (2007). Information Foraging: A Theory of Adaptive Interaction with Information. Oxford University Press.
  • Spool, J.M., Perfetti, C. & Brittan, D. (2004). Designing for the Scent of Information. User Interface Engineering.
  • Nielsen Norman Group (2024). "Information Foraging: A Theory of How People Navigate on the Web." — nngroup.com/articles/information-foraging

Anomalous State of Knowledge

Belkin's ASK model (1980, 1982) addresses the most important design case: the user who does not yet know what they need. An information need arises from a recognised gap in knowledge, but the user is unable to specify precisely what would resolve it.

An example: in operated infrastructure, the dominant high-stakes journey is "something is broken and I don't yet know what." A user in that state cannot self-route by committing to a category that presupposes a diagnosis, because reaching that diagnosis is the thing they are trying to do.

This supports: goal-agnosticism, low prior-knowledge demand. It means that any structure demanding commitment before orientation inverts the actual sequence of diagnostic work. The environment must be navigable by someone who arrives with an anomaly rather than a plan.

Sources:

  • Belkin, N.J. (1980). "Anomalous States of Knowledge as a Basis for Information Retrieval." Canadian Journal of Information Science, 5, 133–143.
  • Belkin, N.J., Oddy, R.N. & Brooks, H.M. (1982). "ASK for information retrieval: Part I. Background and theory." Journal of Documentation, 38(2), 61–71. — researchgate.net

Berrypicking

Bates (1989) demonstrated that information seeking is not a linear process with a single query and a single result set. Users collect information bit by bit, using a range of sources and techniques (citation chasing, area scanning, browsing), and their query evolves as each piece of information reshapes their understanding of the need.

This supports: goal-agnosticism. It means that a structure forcing goal-commitment at the top level will be wrong by the time the user has gathered enough information to know what they actually need. In diagnostic work, each thing inspected reshapes the query and points toward the next thing to inspect; the environment needs to support traversal across areas as understanding develops.

Sources:

  • Bates, M.J. (1989). "The design of browsing and berrypicking techniques for the online search interface." Online Review, 13(5), 407–424. — semanticscholar.org
  • Bates, M.J. (2002). "Toward an Integrated Model of Information Seeking and Searching." New Review of Information Behaviour Research, 3, 1–15.

Situated action

Suchman's Plans and Situated Actions (1987) argues that plans are resources for action, not determinants of it. People adapt their behaviour as they interact with their surroundings; new information, unexpected events, and shifting understanding all reshape what happens next. Plans provide orientation, but they do not fully determine the course of action.

This supports: the core framing directly. It is the primary warrant for treating the navigation as an environment for flexible navigation rather than a representation of a canonical sequence. A structure that encodes one prescribed path will fail everyone who improvises, and in an operations tool that is everyone after their first session. The structure makes the work domain legible; the user composes the route. For a product with no primary workflow, a kit of parts used differently by different people, this is the fundamental design condition — the product is valuable to users precisely because it under-constrains their behaviour. Designing categories around your beliefs about how (an imagined) they organise their work domain runs counter to that benefit.

Sources:

  • Suchman, L.A. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press.
  • Suchman, L.A. (2007). Human-Machine Reconfigurations: Plans and Situated Actions (2nd ed.). Cambridge University Press.

Activity theory

Kaptelinin & Nardi's Acting with Technology (2006) and Engeström's expansive learning framework provide a hierarchical model of human activity:

  • Activity: tied to a motive, the enduring purpose
  • Action: tied to a goal, a conscious objective
  • Operation: tied to conditions; automatic, contextual execution

The hierarchy is an analytical instrument for any proposed category: does it correspond to a level in the structure of human doing, and if so, which one? Categories that correspond to no level in the hierarchy are imposed on the user's activity from outside it. The levels also differ in stability: activities, tied to enduring motives, are more stable than individual goals or tasks, which bears directly on which level of description yields durable categories.

Norman's "Human-Centered Design Considered Harmful" (2005) makes a related argument: activity-centred design takes the whole activity and its context as the unit of analysis rather than individual screen-by-screen task flows, and tools are understood through the activity they serve. This disciplines any task-oriented position away from a literal task list and toward the broader structure of work.

This supports: structural durability, goal-agnosticism. It provides the vocabulary for locating candidate categories in the hierarchy of doing, and for predicting their stability from the level they occupy.

Sources:

  • Kaptelinin, V. & Nardi, B. (2006). Acting with Technology: Activity Theory and Interaction Design. MIT Press. — mitpress.mit.edu/9780262513319
  • Engeström, Y. (1987). Learning by Expanding: An Activity-Theoretical Approach to Developmental Research. Orienta-Konsultit.
  • Norman, D.A. (2005). "Human-Centered Design Considered Harmful." Interactions, 12(4), 14–19. — jnd.org
  • Norman, D.A. (2006). "Logic Versus Usage: The Case for Activity-Centered Design." Interactions, 13(6). — jnd.org

Object-Oriented UX

Sophia Prater's OOUX (2015) argues that design should identify the core objects in a system, the persistent entities users interact with, before defining actions or flows. Objects have structure, instances, and purpose; actions and flows are then defined in relation to them.

OOUX contributes as an analytical method rather than as a cognitive claim: it makes the object level of a system explicit and inspectable, whatever role that level ends up playing in the final structure. Its central observation about the relational structure of systems, that flows traverse objects rather than containing them, is descriptive, and it explains a common failure mode of purely task-organised structures: the same persistent entity ends up duplicated across multiple task containers, because multiple tasks need it.

The ORCA process (Objects, Relationships, Calls-to-action, Attributes) provides a practical method for identifying the objects, mapping their relationships, and making the object layer of a system explicit before structural decisions are made.

This supports: one canonical home, non-overlapping categories. It supplies a documented method for surfacing the persistent entities of a system and their relationships, which any schema, at whatever organising level, must account for.

Sources:

Usage-Centered Design

Constantine & Lockwood's Software for Use (1999) provides a formal method for deriving navigation structure from work analysis. The process runs: user roles → essential use cases (task cases) → interaction contexts (abstract prototypes) → navigation map.

Essential use cases (task cases) are stripped of implementation detail; they describe user intention and system responsibility in the abstract, independent of any particular interface. The navigation map models the interrelationships among distinct interaction contexts. This is a construction method: it does not discover categories, it builds a structure that can hold the range of essential use cases.

Constantine's 2006 "Activity Modeling" paper extends this with activity theory, integrating the activity hierarchy (activity → action → operation) with usage-centred models.

This supports: sibling coherence, goal-agnosticism, and the construction criteria. It means that the derivation chain from work analysis to navigation structure is documented and repeatable (essential use cases → interaction contexts → navigation map), and it provides a defensible answer to "how did you get these categories."

Sources:

  • Constantine, L.L. & Lockwood, L.A.D. (1999). Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley.
  • Constantine, L.L. & Lockwood, L.A.D. (2002). "Usage-Centered Engineering for Web Applications." IEEE Software, 19(2). — researchgate.net
  • Constantine, L.L. (2006). "Activity Modeling: Toward a Pragmatic Integration of Activity Theory with Usage-Centered Design." — researchgate.net

Contextual Design

Beyer & Holtzblatt's Contextual Design (1998; 2nd ed. 2005; 3rd ed. 2016) derives system structure from consolidated models of field data. The User Environment Design (UED) is a "floor plan" of the system: focus areas, functions within each area, and navigation links between them, all derived from sequence models, flow models, and cultural models.

This supports: structural durability, sibling coherence, and the construction criteria. It means that there is a documented method for bridging "we understand the work" to "here is the nav," with every design decision traceable to observable field data.

Sources:

  • Beyer, H. & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann.
  • Holtzblatt, K. & Beyer, H. (2016). Contextual Design: Design for Life (2nd ed.). Morgan Kaufmann.
  • Holtzblatt, K., Wendell, J.B. & Wood, S. (2005). Rapid Contextual Design. Morgan Kaufmann.

Prototype theory and categorisation

Rosch's prototype theory (1978) explains why some groupings feel natural and others feel arbitrary. Categories are cognitively real when their members share high cue validity: a clustering of features that makes the category recognisable and its prototype identifiable. Basic-level categories (e.g., "chair" rather than "furniture" or "kitchen chair") are the level of abstraction people naturally use: specific enough to be informative, general enough to be broadly applicable.

This supports: sibling coherence, and the construction criterion on category centrality. It means that siblings drawn from different organisational schemes share no cue validity; the parent category cannot form a prototype because its children do not resemble each other. It also explains why superordinate labels tend to fail as navigation categories (too abstract, since nearly everything is arguably a member) while basic-level labels work (specific enough to have clear members, general enough to be stable across roles). When a proposed category has no clear central member, it is probably not a coherent grouping.

Sources:

  • Rosch, E. (1978). "Principles of Categorization." In Rosch, E. & Lloyd, B.B. (Eds.), Cognition and Categorization. Lawrence Erlbaum, 27–48. — PDF
  • Rosch, E., Mervis, C.B., Gray, W.D., Johnson, D.M. & Boyes-Braem, P. (1976). "Basic objects in natural categories." Cognitive Psychology, 8, 382–439.

Classification as infrastructure

Bowker & Star's Sorting Things Out (1999) examines how classification systems are infrastructure that encode institutional commitments. Every classification generates residual categories for whatever does not fit the system's assumptions. A proposed nav schema is never neutral: it encodes who owns what, what gets visibility, and what gets relegated to "Other" or "Settings."

This supports: structural durability, sibling coherence. It provides the analytical move of asking, of any pressure on the schema, whose commitments it encodes: the user's work domain, or the institution's ownership, launch visibility, and go-to-market structure. Institutional commitments are legitimate concerns, but they are concerns about the institution and not the product; it is better to keep these separate, lest you unleash Conway's curse.

Sources:

  • Bowker, G.C. & Star, S.L. (1999). Sorting Things Out: Classification and Its Consequences. MIT Press.

Depth/breadth and menu design

The breadth/depth literature addresses parsimony directly. Broader-and-shallower hierarchies outperform narrower-and-deeper ones when the categories are discriminable. When categories are not discriminable, when the user cannot predict which path leads where, breadth becomes a scanning problem rather than a navigation aid.

This supports: parsimony, sibling coherence. It means that parsimony and coherence are load-bearing together. Parsimonious but incoherent yields a short list of confusing items; coherent but sprawling yields a clean taxonomy nobody can hold in their head. Every level of hierarchy is a prediction the user has to make before seeing what is inside.

Sources:

  • Larson, K. & Czerwinski, M. (1998). "Web Page Design: Implications of Memory, Structure and Scent for Information Retrieval." Proceedings of CHI '98.
  • Norman, K. (1991). The Psychology of Menu Selection: Designing Cognitive Control at the Human/Computer Interface. Ablex.
  • Kiger, J. (1984). "The depth/breadth tradeoff in the design of menu-driven interfaces." International Journal of Man-Machine Studies, 20, 201–213.

Cross-product navigation in multi-product SaaS

For practical pattern guidance beyond the theoretical literature, several recent practitioner sources address the specific problem of navigation across product portfolios:

  • Pencil & Paper (2022). "Navigation UX Best Practices for SaaS Products." — pencilandpaper.io — Distinguishes object-oriented, task-oriented, and workflow-based navigation patterns, with cases.
  • Lollypop Design (2025). "Designing Your SaaS Navigation Menu for Maximum Discoverability." — lollypop.design — Object-oriented vs. workflow-based navigation.
  • LogRocket (2026). "Cross-product navigation is broken — here's how to fix it." — blog.logrocket.com — Shared IA and governance for multi-product platforms.
Arvind Venkataramani

Arvind Venkataramani