It’s not you, it’s hierarchy
How I demoted my tree diagrams.
It’s 9:03 a.m. I join a Zoom meeting titled “Team Structure Alignment — Attendance Required,” the type of meeting title commonly reserved for nightmares. As soon as I join HR appears in one tile, smiling like this is definitely covered in their onboarding. It isn’t. We’re here today to demote a sentient diagram.
Long story short: afew years ago a lightning bolt totally hit a Texas data center while someone had Lucidchart open, and a Information Architecture Tree Diagram (our old reliable sitemap buddy) woke up, and has been with us ever since.
The I.A.Tree drops into the meeting late– connection lines crinkled and nodes misaligned.
“I’ve been up all night reorganizing the course pages. The client added three new ‘top-level categories’ that are actually just filters. The homepage has eight parents now. And someone renamed one of my root nodes ‘Global Navigation 2.’ Wait… why is HR here?”
I take a breath. “This is going to be a hard conversation.”
A couple of I.A. diagrams’ boxes squeeze into near triangles — making a kind of squint. “If this is about course registration prerequisites again, that’s not my job. I’m an architecture diagram, not an interactivity diagram. Or a… relationship diagram. Or whatever new kind of diagram you design kids are using to cosplay as engineers now.”
I glance at HR’s tiny Zoom window. I’m sure the HR lady is doing the same to me.
“Exactly,” I say. “You’re great at hierarchy, I.A. Diagram. But we keep asking you to model things that aren’t just parents and children. We need our go to diagram to show shared data, reusable components, relationships that shift when users interact or when the system changes over time — and you keep telling us doing those things aren’t your job.”
The Tree folds a few of his far off branches in what I think is supposed to be a sort of cross armed pout. “Because it’s not my job! You want to show relationships that move? That’s a state diagram. You want to show dependencies? That’s a system map. I’m an architecture diagram, I only should have to show where content lives.”
“Right,” I say. “But we need to show cardinality now — how many relationships exist, how things multiply or overlap as systems evolve.”
The Tree bristles. “Cardinality? Who the hell do you think you are — the Pope?”
To be fair, the Tree isn’t malicious — just absolutely certain about where its job ends.
“Okay,” I say, “let’s walk through this again. A course can have multiple instructors across different semesters — how do we show that with you?”
“I don’t,” the Tree says flatly. “That’s not my job.”
“What about courses that fulfill multiple degree requirements?”
“Still not my job.”
“Okay… and prerequisites that reference other courses?”
“Definitely not my job.”
“Students registered across multiple sections — sometimes cross-listed — how would you handle that?”
“I wouldn’t. Sounds like somebody else’s problem.”
“Whose problem?”
“Maybe a flowchart. Maybe, I don’t know, ask an engineer.
Every time relationships appear, the Tree punts: put it in a flowchart, an entity relationship diagram, or “engineering will figure it out.” But in 2025 UX, structure is part of the designer’s job: we’re expected to map persistent objects, cardinality, reuse, role-based access, and system constraints — well before anyone writes code.
We need a diagram that can carry that weight.
A horrible realization crosses the Tree Diagram’s root node where it’s face would have been, “am I Being… Fired?”
HR unmutes, voice gentle and corporate: “I.A. Tree Diagram, you’ve been a huge part of this team’s documentation. Your impact on navigation and hierarchy has been — ”
I.A. Tree freezes. “You’re firing me.”
“No,” I say quickly. “Not firing. Demoting. You’re no longer our primary structural diagram. You’ll still be critical to how we design navigation and be used every time we create content hierarchy. But the product design team is promoting class diagrams to our go to diagram.”
He stares. A few nodes detach.
“Class diagrams? That’s full-on UML. Why not sell your guitar, buy Magic cards, and rock a fanny pack while you’re at it?”
“Look,” I say. “We’re not role-playing engineers. We’re trying to plan out and communicate how the product actually fits together — that’s like the definition of design work. Class diagrams show objects, attributes, and relationships — cleanly. That’s what we need.”
Why class diagrams need a promotion in design teams
As design literacy spreads beyond traditional “Product Designer” titles — Forbes notes that 92% of leaders now expect employees to have some level of design skill — Those of us who pay the mortgage with our design skills need to bring value that goes well beyond making and explaining interface-level decisions. The old approach — classifying information monolithically and statically — no longer fits the realities of today’s complex, high-stakes digital products.
The Nielsen Norman Group recently published a great piece called The Future-Proof Designer, arguing that today’s best product designers aren’t just defining how a product looks from state to state at launch — they’re also creating the kinds of diagrams and doing the type of work that helps cross-functional teams solve complex problems together.
An information architecture tree diagram, for example, is like trying to survey a river by taking a single snapshot. It’s useful for orientation, but no longer the tool we need to deliver what’s expected of us now — showing how systems connect, and evolve.
Class diagrams are different from I.A. trees because they let us:
- Define what exists (objects/classes),
- Specify what they contain (attributes),
- Show how they relate (associations with cardinality),
- Capture inheritance/extension (when needed),
If you want a “how to make class diagram” resource go watch Lucidchart’s excellent, short intro to class diagrams on YouTube.
Example
A tree diagram can show hierarchy beautifully — parent, child, sibling. It can even make an unruly architecture look organized (if only at a glance). A tree diagram does have its place — especially early in the design cycle. As the Nielsen Norman Group points out in their article “Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories”, tree testing is ideal before you build page layouts or visual design: it lets you “test multiple IA options … without any design, coding, or content development” to see which structure works best. But a tree assumes that every object has one clear parent and that relationships flow neatly downward. That’s a comforting fiction, but fiction isn’t’ what’s needed when making critical decisions about the design of a system.
For an example let’s think of a course registration product for a university. If the design team was required to wireframe out this system we’d need to diagram at a minimum to represent :
- A Student can register for many Courses (and vice versa).
- Each Course may be taught by multiple Instructors.
- Courses can have Prerequisites (other Courses).
- Some Courses fulfill Degree Requirements.
- Courses are offered in specific Semesters.
What’s the Problem Starting With a Tree Diagram?
If I took this problem and made a tree diagram out of it — well it would look like this, and how the hell could I go back to my desk and start sketching a wire frame from this spaghetti? But more importantly it can’t identify design flaws early, something class diagrams are explicitly designed to do, as noted in Archimetric’s “The Importance of Class Diagrams in Software Development.”
There’s no clear canonical “object.” Are these course instances or just labels? What on this diagram represents an actual, screen-level piece of information — and what’s simply a class definition? Cardinality is either invisible or misleading. Are there many instances of a node, or just one? Tree diagram you drive me crazy!
How and Why I’d Use A “Designerly Class Diagram Instead”
I’d treat each category as its own “designerly class,” separating the information and interactivity into distinct conceptual objects, then map how they work together to create value for the user. That diagram would look something like this (although honestly most of the time I just sketch it on my iPad)
As a designer, I know which input methods users are most familiar with when interacting with these properties. I know where they’ll likely look for the information needed to complete each task. What I don’t instinctively know is how all these pieces of information work together — as a system, as a product. It’s too complex to hold in my head while I’m working. That’s what the diagram is for: not just to share how the system works with others, but to free up mental space so I can actually solve problems.
“I’m Architecture, Not Interactivity”
Back on Zoom, the I.A. Tree digs in:“I show where things go. Someone else can say how they connect.”
“That’s the crux,” I say. “In 2025, structure isn’t just ‘where stuff goes.’ It’s what the stuff is and how it relates, across roles and contexts. If our documentation can’t carry that, engineering inherits ambiguity — and users inherit weirdness.”
He grumbles, a grizzled veteran tone. “In my day, we mapped a whole site with a sharpie, a few sticky notes, and a dream. And it worked.”
“It did — for brochureware and early apps. Today we’re designing systems.”
He eyes me. “So we’re… opening the relationship?”
“We’re building an ensemble, not a monarchy,” I reply.
The HR lady nods, proud of us all while the Tree goes quiet, then mutes. The tile turns gray. I hear what can only be described as a leafy sniffle. When he reappears, he looks smaller. “Okay,” he says. “I’m not the lead anymore. That… stings. But if you need a three-tier menu with mobile fallbacks — ”
“You’re our first call,” I say.
He lifts a branch. “And don’t draw those class diagrams like code. Keep them human. We all need to read them — no curly braces, OK?”
“We will.”
He sighs — a wind-through-leaves sound. “All right. Just… make sure my pension vests.”
HR: “We’ll, uh, look into that.”
We end the call. And for the first time in a long time, I don’t feel compelled to invent a new dashed-gold-double-legend line on a I.A. Tree diagram just to explain the structure underneath our design.
Acknowledgments
The Polar Bear Book — Information Architecture for the World Wide Web by Peter Morville and Louis Rosenfeld — has been hugely influential in how I think about structure, systems, and the evolving role of design literacy in product teams.
Morville, Peter, and Louis Rosenfeld. Information Architecture for the World Wide Web: Designing Large-Scale Web Sites. 4th ed., O’Reilly Media, 2015.
It’s not you, it’s hierarchy was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More