Sitemap

For a long time a product's structure lived only in the heads of the people building it. Screens arrived as mockups, one at a time, and each one was fine on its own — but there was no way to see at a glance how they connected.

The gap surfaces the moment someone asks where a new feature goes. Ask where notification settings belong and you get three answers: under the profile, under settings, under workspace settings. Three people are picturing three different structures, and with no drawing there's nothing to settle the question against. So it gets decided by whoever argues loudest that day, and six months later the product has team management inside settings and another settings page inside team management.

A sitemap pulls the structure out of people's heads and onto paper. Writing it down doesn't make the decisions, but it makes visible where decisions are waiting. A branch that takes five clicks to reach, a level with nineteen items lined up side by side, a pile of leftovers gathered under a label called "other" — all three jump out of the drawing and none of them travel well in conversation.

Six things belong on the page.

1. A root. One entry screen sits at the top. When the logged-out product and the logged-in product are genuinely different, draw two roots. Forcing both onto one root leaves nobody able to tell which screen belongs to which state.
2. Levels. Below the root come top-level sections, then the sections under those. Aim for three or four levels. Past five, reaching a destination takes five clicks, and in a drawing that branch visibly stretches farther down than everything around it.
3. What each screen carries: the name users will see, a number marking its place, who is allowed to open it, and whether it exists today or still has to be built. Number them to match the levels — 1, 1.1, 1.1.2. With numbers in place, a screen whose name is still undecided can still be pointed at in a meeting.
4. Connecting lines. Parent-to-child relationships get drawn as lines. Some screen always turns out to belong under two branches; when that happens, pick one primary location and draw the rest as dashed lines. Two solid lines turn a tree into a web, and engineering is then left unable to settle on one address for the screen.
5. Entry markers. Separate the screens reachable from a menu from the ones reachable only by link. Every product has a few places like a document opened only through a share link, and without the marker those screens vanish when someone builds the navigation.
6. What stays off the page. Anything that isn't a screen: confirmation dialogs, notices that appear and fade, tab switches within one screen. Include those and the node count triples while the large structure disappears. That work belongs to a user flow, which maps the path and branch points someone passes through to finish a task.

Once it's drawn, check the balance between width and depth. Five to seven items per level, three levels deep, is the rule of thumb most teams land on.

The person who draws it is the person deciding the structure. At Pagedeck, Noa draws and Mia reviews. Drawing it alone always misses a screen, so the draft goes to engineering and sales once each, to confirm nothing they rely on is absent.

Four groups read it.

1. Engineers. It's the complete list of screens to build and the input to the address design. Level structure often becomes the URL structure directly, so moving a level moves an address with it.
2. Designers. Which screens need mockups falls straight out of this list. Twenty screens on the page and twelve mockups in hand means eight are missing.
3. Testers. Comparing what was built against the drawing turns up the screens that never got made. It also surfaces screens that exist but can't be reached from any path.
4. New joiners. It's the fastest way to understand the whole product — quicker than opening screens one by one.

Update it only when the large structure changes. Touch it every release and maintaining it becomes a job of its own. Give it one owner, who edits when a branch is added, removed, or renamed. The naming itself is the work of labeling, but which branch a name belongs to gets checked here.

"Before we add this, let's open the sitemap. We need to decide what it goes under."

Place the new screen on the structure rather than beside it.

"Everything under 3.2 is five levels deep now. That branch is much deeper than the rest."

Pointing at a branch that stretches farther down than its neighbors.

"It's on the sitemap but I can't find it in the menu."

The structure has a slot for it; the entry point was never built.

When Pagedeck prepared permission controls for enterprise accounts, Noa opened the drawing again. The question was where six new screens should attach. Putting them under settings would push settings to twelve items; putting them under the workspace would mix personal settings with team settings.

Laid out on the page, it turned out settings already held three team-related items. Noa grouped those three with the six new screens into a new branch called team management and left settings holding only what belongs to an individual. Depth grew by one level while the items on a single level dropped from twelve to six.

The most common mistake is treating it as a draw-once document. Structure doesn't change often, so the assumption is natural enough. But branches grow as features do, and within six months the drawing and the product disagree. A stale drawing is worse than no drawing: without one, people go open the screens to check, whereas a wrong one gets trusted, built against, and walked back later.

The second is assuming shallower is always better. One click beats three clicks, which sounds obviously true. Flatten a level, though, and its items move up to join the one above, and twenty of them end up in a row. People stall longer over twenty choices than over an extra click — Hick's law, that more options make a decision slower, applies right here. Depth and width trade against each other, and which way to lean depends on the name users arrive looking for, an answer that comes out of settling the taxonomy.