I’ll research current data on navigation, information architecture, and how internal structures affect user experience before writing.Let me search for the term “Conway’s Law” applied to UX and for cart/conversion abandonment data tied to navigation.I have strong material. Let me write the article now.
The dropdown that maps perfectly onto your departments
Open the main menu on most mid-market B2B websites and you can reverse-engineer the company behind it. Products. Solutions. Services. Resources. About. Each one a little fiefdom, each one owned by a team that fought to get its name on the bar. The marketing director claimed “Resources.” Sales got “Solutions.” Someone in HR insisted “Careers” sit at the top level. The navigation isn’t a map of what your customer wants. It’s a seating chart for your last reorg.
Eric Schmidt put the test bluntly in How Google Works. You should never be able to reverse-engineer a company’s org chart from the design of its product. If you can, something has gone wrong. And on the typical company website, you absolutely can.
This is Conway’s Law, and it has been observed for nearly sixty years. The computer scientist Melvin Conway argued in 1967 that any organisation designing a system is constrained to produce a design that copies the organisation’s own communication structure. Conway’s law describes the link between the communication structure of organisations and the systems they design; his original wording was that organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations. The principle was written about software architecture, but it applies to anything an organisation builds together, and a website is one of the most visible examples. The quality of the customer experience an organisation delivers will inevitably be the product of its organisational design.
The problem is simple to state and expensive to ignore. Your customer does not know your departments exist. They do not care which team owns which page. They arrive with a job to do, and your navigation either helps them do it or quietly sends them somewhere else.
Why internal logic feels obvious to you and opaque to everyone else
Inside the building, the structure makes total sense. Of course “Professional Services” is separate from “Products,” because those are two different P&Ls run by two different VPs. Of course the implementation guides live under “Support” and not “Resources,” because the support team wrote them. Everyone who works there has absorbed this map through years of meetings, so it reads as natural.
To a first-time visitor it reads as noise. They have a completely different mental model, built from the problem they’re trying to solve, not from your internal accounting. Research on information architecture has documented this gap repeatedly. A key driver of IA difficulty is the diversity of mental models across user segments, because professionals, casual users, and domain novices structure the same information differently; without segmented research, structures tend to optimise for one user type at the expense of others. When the people doing the structuring are all insiders, the website optimises for the one mental model that no customer shares: yours.
The cost shows up as failure to find things. The Nielsen Norman Group is direct about it: one of the biggest causes of user failure is when people simply can’t locate things on a website, and the first law of e-commerce design holds that if the user can’t find the product, the user can’t buy the product, so these design flaws are often a site’s biggest profitability problems. Findability has a precise definition worth keeping in mind. Findability is when users can easily find content or functionality that they assume is present in a website. Assume being the operative word. They expect it to be there. Your org chart hid it under a label they would never click.
How bad does it actually get
Worse than most teams believe. The numbers from controlled testing are sobering, and they come from organisations with budgets far larger than yours.
MeasuringU benchmarked US federal government websites in 2024. The average success rate in finding information was only 51%, with some task success rates below 30%. These are sites with enormous resources and millions of users, and roughly half of attempts to find information failed. One participant’s comment captures the lived experience precisely: “Sometimes I cannot find the exact information I am looking for and then I have to contact someone.” That sentence is a navigation failure converted directly into a support ticket. Multiply it across thousands of visitors and you have a cost centre disguised as a website.
E-commerce gives an even harder edge to the data because the failure is measured in lost revenue. When Baymard Institute ran its large-scale product-finding study, test subjects had trouble finding products matching basic criteria such as a sleeping bag for cold weather or a spring jacket, with task completion rates as low as 10 to 30 percent, making it clear that it doesn’t matter how much time you spend on beautiful design and product images if foundational elements such as the category taxonomy aren’t solid. The most damaging finding goes beyond a single lost sale. Baymard noted that a poor taxonomy can cause permanent brand damage, because when test subjects couldn’t find a product type they concluded the site simply didn’t carry those items, leading not only to an immediate lost sale but to future losses, since customers are unlikely to return to a store they don’t expect will stock what they want.
Read that again with your own site in mind. A customer who can’t find your enterprise plan because it’s buried under a label only your sales team uses doesn’t think “poor navigation.” They think “they don’t do that.” Then they leave and don’t come back.
The specific ways org-chart navigation breaks
Labels that are job titles, not customer language
“Solutions” is the classic offender. It means nothing to a buyer because it means everything to the people who chose it. It’s a container the company invented so several teams could share top-level real estate without arguing. The customer scanning your menu for help with a specific problem doesn’t see their problem named, so they keep scanning or they bounce.
The fix is not clever copywriting. It’s research into the words your customers actually use. Information architecture user research seeks to understand how people think about information in order to determine the best ways of organising and labelling content. Card sorting is the standard generative method here, but it has a limit worth respecting. Card sorting produces a similarity matrix, statistical evidence about how users perceive relationships between items, but it does not produce a taxonomy directly; practitioners must interpret that matrix alongside business requirements, content volume, and technical constraints. In other words, the research tells you how customers group things. Turning that into a real menu is a judgement call, and it should be made with the customer’s grouping as the starting point rather than the department’s.
Duplicated and overlapping categories
When two teams both think they own a topic, it shows up in two places under two names, and the customer has to guess which one is real. Baymard found this was once endemic. The past issue of redundant and overlapping categories, which in 2013 affected 68% of sites, has since been largely alleviated, with just 12% of sites still showing category-redundancy issues in the later benchmark. The good news is that this is a solved problem when teams pay attention to it. The bad news is that on many B2B sites, where nobody is testing, the duplication is alive and well because each silo keeps publishing into its own corner.
Over-categorisation that mirrors internal subdivisions
The opposite failure is slicing everything so thin that the broad view disappears. Over-categorisation remained the main taxonomy issue at 54% of e-commerce sites, with Baymard citing Best Buy’s “Point & Shoot Cameras” being split into camera-type sub-categories, making it impossible for users to get a list of all point-and-shoot cameras and forcing them to choose between overly narrow and overlapping sub-categories. This happens when the menu reflects how a product team thinks about its catalogue rather than how a buyer shops it. The buyer wants the broad list. The org chart gives them the internal taxonomy instead.
The homepage as a treaty between departments
The homepage often becomes the place where every team gets a tile. That misreads what the homepage is now for. As more customers arrive from search engines and social links deep inside a site’s hierarchy, the homepage may no longer be the predominant entrance, but it still serves as an escape route and anchor for the category taxonomy, and even customers who use on-site search depend on that taxonomy to infer the available product range. A homepage organised as a peace treaty between departments fails at exactly this job: helping a disoriented visitor understand the shape of what you offer.
Why you can’t see it from the inside
The reason this persists is that the people approving the navigation are the same people who created the org chart. They built the map, so the map looks obvious to them. This is the deeper reading of Conway’s Law that gets quoted less often. Later reflections on Conway’s work, including in the book Team Topologies, raise a pointed question: is there a better design that is not available to us because of our organisation?</
That is the question to sit with. The best possible navigation for your customer may be one your current structure cannot easily produce, because no single team owns it and proposing it means stepping on someone’s territory. The website becomes a negotiated settlement rather than a designed experience. Nobody set out to confuse the customer. Everyone just defended their patch, and the sum of those defences is a menu that serves the building rather than the visitor.
Opinion polling inside the company won’t surface this either. Ask five executives whether the navigation is clear and you’ll get five confident yeses, because all five already know where everything lives. The only way to see the problem is to watch someone who doesn’t.
How to find out whether your navigation is broken
You don’t need a six-month research programme to diagnose this. You need to put your structure in front of real users and measure whether they can complete realistic tasks. The two methods that matter most are cheap and fast.
Tree testing evaluates your structure stripped of visual design. It tests the findability of content within an information architecture by giving users the task of finding a specific area or category within the existing structure and tracking their journey to see how, and if, they reach the destination. Because it isolates the hierarchy from the look of the page, it tells you whether the structure itself is sound. Know its boundary, though. Tree testing evaluates whether a navigational hierarchy supports specific task scenarios; it cannot detect problems with labelling abstraction, metadata, search behaviour, or cross-linking, which sit outside the tree.
First-click testing tells you where people go the moment they’re given a task. The first click is enormously predictive of whether someone will eventually succeed, and watching a series of wrong first clicks pile up on the same menu item is the clearest possible signal that a label is lying to your customers.
The metrics to track are straightforward and the same regardless of method. A standard information-architecture test reports on findability success rate, time to find requested elements, error rate, perceived difficulty of the tasks, first clicks, and the paths users followed. A real-world tree test gives you a feel for what “broken” looks like in those numbers: in one Nielsen Norman Group case study, a company’s overall findability scored just 4 out of 10 across tested tasks, prompting the team to conclude the information architecture could be substantially improved, with a goal of reducing unnecessary sales calls. That last detail matters. Bad navigation doesn’t just lose customers. It pushes work onto your sales and support teams that a clear menu would have absorbed.
Prototype the structure before you commit to the build
Here’s where most redesign projects go wrong. The structure gets decided in a meeting, signed off by the department heads, and then handed to designers who make it beautiful and developers who make it real. By the time anyone tests it with a customer, the architecture is locked, the budget is largely spent, and the politics of changing it are brutal. So it ships, org chart and all.
In our projects, we prototype before we design, and the navigation is the first thing we put in front of real users, not the last. The sequence matters. You test the bones of the thing, the labels and the hierarchy and the paths, while changing them still costs nothing but a few hours of revising a prototype. Using both generative and evaluative methods in an iterative approach to user research is often the best way to ensure an intuitive information architecture. Generate candidate structures from how customers actually group your content, then evaluate whether they can navigate it, then revise, all before a single pixel of final design is committed.
This is also where the politics get easier, not harder. A prototype-first approach turns “whose department gets the top-level slot” from an argument between executives into a question answered by data. When the first-click numbers show that customers expect implementation guides under one label and not another, the conversation stops being about turf and starts being about evidence. The structure your customers can actually use is worth more than the structure that keeps every department happy.
What we see across client projects is that the teams who test structure early ship navigation that survives contact with real users, and the teams who skip it ship their org chart and then spend the next two years patching it with redirects, mega-menus, and ever-larger search boxes that try to compensate for a taxonomy nobody can follow.
What to do this week
Start with a five-minute test of your own honesty. Open your live navigation and, next to each top-level item, write the name of the internal team that owns it. If the menu maps cleanly onto your departments, you have your answer, and your customers have been paying for it.
Then do something a customer would actually do. Pick three real tasks a buyer or user comes to your site to accomplish. Write them as plain goals, not as page names. Hand them to five people who don’t work for you, ideally people in your target market, and watch where they click first and whether they ever get there. Note every wrong first click and every “I’d contact someone” moment. Five users is enough to expose the worst of it, because qualitative IA research reaches saturation, the point at which new participants surface no new structural insights, at much lower sample sizes than quantitative methods.
If those five people stumble, the fix is not to redesign the homepage or add a bigger search bar. It’s to rebuild the structure around customer tasks and test it before you commit to design and development. If you want a second opinion on what your own navigation is really doing to your customers, you can book your free discovery call and we’ll talk through your specific situation.
Your customers will never see your org chart. Make sure they don’t have to navigate it either.
Ready to get started?
