A screen list lies. I found a whole feature I didn't know we shipped.

Ask anyone for their product's information architecture and you get a list of screens. Dashboard, invoices, invoice detail, settings. It looks complete. I trusted ours for a long time. Then I built the same map a different way, and it handed me a screen I had genuinely never seen.

A screen list tells you the rooms exist. It says nothing about the fact that "invoice detail" is really seven screens in a trench coat, one for each state the invoice can be in. It says nothing about the screens that only exist for one kind of user. And it says nothing about how you get from one place to another, which is most of what a product actually is. A list gives you the nouns. The product is mostly verbs, and the list quietly throws them away.

So I stopped listing screens and drew a graph

Instead of screens we modelled entities, the things the product is about. Nodes, the actual surfaces. States, because that one invoice screen is really seven. And edges, the moves between them. It's heavier than a list, but heavy in the way the real product is heavy. You stop getting ambushed by the error state nobody drew, because the graph makes you name it before you can pretend it isn't there.

Where the map came from, and the screen I'd never seen

The part I didn't expect was where the honest version came from. Not the running app. The code.

We first tried building it by crawling the live product, clicking through and writing down what we found. A crawl only ever sees what it happens to reach. It misses whatever's behind a permission it doesn't have, whatever state it didn't know how to trigger, whatever route nothing linked to on the day it ran. When we derived the same map straight from the code instead, it turned up a stack of routes the crawl had missed, and one of them was a whole feature sitting in our product that none of us had thought about in months. I was a little embarrassed. I'm meant to know our product.

The rule that keeps it honest

Code and reality don't always agree, and that gap is the interesting part. The code is what could exist. Production is what does. Something can be alive in the code and dead in the product, or busy in the product and already being deleted out of the code.

So the rule we settled on, and the one I'd hand anyone doing this, is that absence of observation is not absence in production. Your analytics never catching a state doesn't mean nobody hits it. Maybe it's rare. Maybe you're just not measuring it. So you don't delete the thing you didn't see. You annotate it. Code says it's here, we didn't catch it live, here's what we know.

The moment you start deleting everything you didn't personally witness, you stop mapping the product and start mapping your own instrumentation. Which is a much smaller and sadder thing to be the owner of.

---

Part of a series on building an AI collaborator for our design team at Xflow. Each post stands on its own.