Three Structure Diagrams
Functional structure, information structure, product structure — draw each separately. Don't mash them together.
Before writing requirements, draw three tree diagrams: functional structure, information structure, and product structure. The order can't be reversed, and mashing them into one makes no sense to anyone.
What you'll run into:
- You draw one big diagram with features and fields all crammed in, then can't read it yourself
- Discussion with developers goes nowhere because the diagram has no objects or fields
- You jump straight into a prototype, then scrap it halfway, stuck in details
What each diagram does
| Diagram | It answers | What to draw | Main use |
|---|---|---|---|
| Functional structure | What feature modules exist and how they divide | Tree of function names, 2–3 levels | Scope the requirements, align the design thinking |
| Information structure | What information each business object holds | Objects as roots, fields as branches | Reference for the developer's data model |
| Product structure | How functions and information land on pages | Page frames plus what each page carries | Stand in for prototype review, guide the prototype |
The product structure isn't a simple overlay of the first two — a real product design step sits between them. Its value is the low cost: moving a feature's position means moving one node, not redrawing a prototype. Information architecture is exactly this — the structural design of a shared information environment so information stays findable and usable; these three diagrams are how you practice it in a product. ia
How to draw each one
Functional structure. Abstract the key nodes and operations from business flows, group them into modules, and name features as verb plus noun — "export statement." Two hard constraints: five to nine modules, two to three levels. Exceed them and the problem isn't the drawing; the feature scope needs trimming.
Information structure. Abstract objects from the business, work out which fields describe each one, then add the fields the business needs. Its most common mistake is listing information page by page. It should survey the whole information system from above, by object — the same user object's information appears on many pages, but is drawn only once.
Product structure. Build on the first two, classify and layer the functions, abstract a product framework, and annotate each node with what that page shows. No interaction details — that's the next step. Once this diagram is drawn, the prototype is half done: every page's content is annotated, and drawing the prototype is just turning it into a visual. It's also the most skipped diagram — it looks like one more drawing, but it actually saves the most expensive round of rework.
How many to draw if you're solo
Drawing all three is the safest, but a solo builder can choose based on project complexity.
- For a small tool: the information structure is enough. There are only a few features, but if you get the objects and fields wrong, everything downstream feels off.
- With multiple roles or business lines: you need all three. Feature ownership and permission boundaries have to be drawn clearly first.
- Mostly content display: functional plus product structure. The data model is usually simple; the focus is on organization.
- If you only draw one: pick the information structure. It's the only one that forces a database rebuild if you get it wrong — the other two are much cheaper to change.
The form doesn't matter. A mind map, indented text, an AI-generated Mermaid snippet — all fine. Their value is in forcing you to think the relationships through, not in the deliverable itself, which is also why they can replace a prototype for review: changing a node takes seconds; revising a prototype takes half a day.