# How to Make a Tree Diagram in Figma (Structure Without Quantity)
_August 27, 2026 · 11 min read · by Systergon_
> A tree is the one hierarchy chart that encodes no quantity at all — it shows what contains what, and nothing else. That is usually the reason to pick it: plenty of hierarchies have no numbers, and forcing one in distorts them. Layout directions, the depth and breadth limits, and the radial variant that trades labels for compactness.
Tags: Figma, Charts, Tree Diagram, Hierarchy, Plugin
URL: https://systergon.com/blog/figma-charts-tree-diagram
---
[Install Figma Charts — it’s free to try →](https://www.figma.com/community/plugin/1345221583582136577/figma-charts) [See the tree gallery →](https://systergon.com/figma-charts/chart-types/tree)

A tree diagram draws a hierarchy as nodes and connecting lines. It is the one member of the hierarchy family that encodes **no quantity at all** — a treemap, a sunburst and an icicle all size their shapes by value, while a tree simply shows what contains what. That sounds like a limitation and is frequently the reason to choose it: plenty of hierarchies have no numbers, and forcing one in distorts them.

![A top-to-bottom tree diagram drawn by ECharts inside the Figma Charts plugin](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-top-down.svg)

_Real plugin output: an ECharts tree captured from the editor. Every chart on this page is the library’s own drawing._

What a tree gives you instead is **layout freedom**. Because nothing is sized by data, the diagram can run in any direction, curve its edges, or wrap into a circle — and each of those choices makes a different kind of hierarchy readable. This page is about picking among them.

## First — get the plugin

Everything below happens inside **Figma Charts**, a Figma plugin. It runs the real JavaScript charting libraries — Google Charts, Highcharts, D3-based Nivo, ApexCharts and Apache ECharts — inside the plugin window, so the node positions on your canvas are the library’s own layout.

[Install Figma Charts from the Figma Community →](https://www.figma.com/community/plugin/1345221583582136577/figma-charts)

Press **⌘/** (**Ctrl /** on Windows), type _Figma Charts_, hit Enter, and pick **Tree** from the category filter. Nine examples — ECharts 7, Highcharts 1, Nivo 1 — and seven of those are the same data in different layouts, which tells you what this chart type is really about.

## Five layouts, and what each is for

![A left-to-right tree drawn by ECharts](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-left-right.svg)

_**Left to right** — the workhorse. Every node gets a full line for its label, deep trees grow down a scrollable page instead of off the sides, and the reading direction matches how people scan text. For anything with long names — file paths, package names, org roles — this is the default worth starting from._

![A radial tree drawn by ECharts](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-radial.svg)

_**Radial** — root at the centre, levels as rings of nodes. It fits considerably more into a square frame than a linear layout and removes the vertical axis that readers translate into seniority or importance. The cost is rotated labels around the outside._

![A tree with polyline edges drawn by ECharts](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-polyline.svg)

_**Polyline edges** — right-angled connectors instead of curves. They read as structure rather than flow, which is the correct signal for a containment hierarchy, and they make it much easier to trace which child belongs to which parent in a dense diagram._

![A treegraph drawn by Highcharts](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-highcharts.svg)

_**Highcharts’ treegraph** — the same idea with node cards and level-by-level styling, and the closest thing in that library to an [org chart](https://systergon.com/blog/figma-charts-org-chart) without using the organization series._

![A tree diagram drawn by Nivo](https://systergon.com/blog/figma-charts-tree-diagram/images/tree-nivo.svg)

_**Nivo’s tree** — the D3 look, with configurable link shapes and node sizing, and per-node colour inheritance. React-only export._

## The absence of quantity is the feature

Three consequences follow from a tree encoding no values, and all three are reasons to use one:

- **Every node is equally visible.** In a treemap, a small leaf is a sliver; in a tree it is the same node as any other. If your hierarchy has one enormous branch and several tiny ones, a tree shows the small ones properly.
- **Structure is exact.** Depth, branching and parentage are unambiguous because they are drawn rather than inferred from nesting or angle.
- **No data preparation is needed.** A hierarchy with no numbers — a menu, a schema, a decision path — can be drawn as it is. Every other hierarchy chart needs values invented for it, and invented values are read as real ones.

The corresponding limitation is exactly what you would expect: **a tree cannot tell you which branch is biggest**. If size matters, add it as a second channel — node size, node colour, or a number in the label — or use a [treemap](https://systergon.com/blog/figma-charts-treemap) and accept that the small branches will vanish.

## Why trees run out of room sideways

The practical limit on a tree diagram is not depth but **breadth**, and the arithmetic is worth knowing before you start.

Each level multiplies. A tree where every node has four children is four nodes at level two, sixteen at level three, sixty-four at level four — and every one of those needs horizontal room for a label. Depth costs you one more row; breadth costs you exponentially more width.

Three ways to manage it, in order of how much they preserve:

**Collapse by default.** Show two levels and let the rest expand on demand. In a static design that means picking the two levels that carry the argument and noting the counts below — “Engineering (14 teams)” rather than fourteen boxes.

**Go radial.** A circular layout has circumference to spend, so it holds substantially more leaves than a linear one in the same frame. The cost is rotated labels.

**Split the tree.** One diagram per top-level branch, each on its own frame. This is almost always more readable than one enormous diagram, and it is the option people try last.

## When a tree is the wrong diagram

**1. The structure is not a tree.** Each node needs exactly one parent. Anything with cross-links — a component used in three places, a person in two teams, a dependency graph — is a [network](https://systergon.com/blog/figma-charts-network-diagram), and forcing it into a tree means duplicating nodes or dropping edges.

**2. You have hundreds of nodes.** Trees grow wide fast: each level multiplies. Past about fifty nodes a static diagram becomes a poster, and the answer is collapsing, filtering or showing two levels with counts.

**3. Proportion is the question.** “Where is the storage going?” is a treemap or icicle question. A tree shows you the folders; it does not show you which one is enormous.

A fourth: **when the diagram is really a flowchart.** Decision trees with conditions on the edges, processes that rejoin, anything with logic on the connections — those want a diagramming tool, not a chart library. A chart tree draws a containment hierarchy and nothing else.

## Building one, step by step

Six screens, start to finish, captured from the plugin.

![The Figma Charts gallery filtered to the Tree category](https://systergon.com/blog/figma-charts-tree-diagram/images/step-gallery.webp)

_**1. Filter to Tree.** Three libraries have it — ECharts with seven layout variants, Highcharts with the treegraph, Nivo with one. Pick by layout, since that is the decision this chart type is really offering._

![The Figma Charts editor with a tree diagram in the preview](https://systergon.com/blog/figma-charts-tree-diagram/images/step-editor.webp)

_**2. The editor.** Live preview above, tabs below. Trees expand in whichever direction they run, so set the frame to match the layout before judging whether the labels fit._

![The hierarchy data editor showing nested nodes for a tree diagram](https://systergon.com/blog/figma-charts-tree-diagram/images/step-data.webp)

_**3. The hierarchy editor.** ECharts trees get the plugin’s tree editor — nested `name / children` nodes, with values optional. This is the one hierarchy chart where leaving the values out is entirely normal._

![The Configuration tab showing tree option groups](https://systergon.com/blog/figma-charts-tree-diagram/images/step-config.webp)

_**4. Configure.** Orientation, edge shape, node symbol and size, label position and per-level styling. Edge shape matters more than it sounds: curves read as flow, right angles read as structure._

![The Export tab showing code export formats](https://systergon.com/blog/figma-charts-tree-diagram/images/step-export.webp)

_**5. Export.** A working component for React, Vue 3, Angular, Svelte or vanilla JavaScript, at the version the plugin rendered with._

![The + SVG and + PNG insert buttons](https://systergon.com/blog/figma-charts-tree-diagram/images/step-insert.webp)

_**6. Insert.** SVG is the point here: nodes, edges and labels all arrive as real Figma layers, so you can swap the node symbols for your own components and keep the computed layout._

## The data shape it needs

A hierarchy of `{ name, children }` — values optional. In ECharts the plugin provides its tree editor for exactly this structure, which is the same editor treemaps and sunbursts use, with the difference that here you can legitimately leave every value blank.

One notable difference from the rest of the hierarchy family: **trees are not marked link-incompatible in the plugin**. Treemaps, sunbursts, circle packing and Sankeys all refuse a linked data source because a connector cannot build their structures from a flat range; the tree registry entry carries no such restriction, which makes it the most connectable of the hierarchy charts here.

Two structural rules, as always for hierarchies: **exactly one root**, and **no cycles**. A second root produces either two diagrams or an error, and a cycle will hang or truncate the layout — and both occur routinely in exported data.

## Library by library

The **Tree** category holds **nine examples**: ECharts 7, Highcharts 1, Nivo 1.

- **ECharts — 7 examples**, and they are mostly the same tree in different orientations: top-down, bottom-up, left-to-right, right-to-left, radial, polyline edges, and multiple trees in one frame. That is the most complete set of layout options in the plugin, and layout is what this chart is about.
- **Highcharts — the treegraph**, with node cards and level styling — effectively an org chart without the organization series. Commercial licence required to ship commercially.
- **Nivo — 1**, with configurable link shapes and node sizing. React-only export.
- **Google Charts and ApexCharts — no tree type.** Google has an org chart in its own library, though none ships in the plugin.

Worth noting where the neighbours are: an [org chart](https://systergon.com/blog/figma-charts-org-chart) is a tree with people in it, and Highcharts files that separately; an [icicle](https://systergon.com/blog/figma-charts-icicle-chart) is a tree with proportional widths; a [sunburst](https://systergon.com/blog/figma-charts-sunburst-chart) is an icicle rolled up. Four chips, one family, and the differences are entirely about whether value is encoded and how.

As always: **design in whichever library your engineers already use**, because the export then matches production exactly. [Choosing the right chart library](https://systergon.com/blog/figma-charts-choosing-the-right-chart-library) covers the trade-offs.

## The chart most worth finishing in Figma

Trees are the type where inserting as SVG and then working on the canvas pays off most, for a specific reason: **the hard part is the layout, and the layout is what the library does well.** Everything else — how a node looks, what it contains, what typography it uses — is a design job that a chart library does adequately and Figma does properly.

The workflow that works:

**Render for position, not for style.** Get the structure right in the plugin with plain nodes, then insert as SVG. You now have every node and edge at mathematically correct positions.

**Swap nodes for components.** Replace the plain shapes with your own node component — avatar, title, status chip, whatever the diagram needs. The positions are already correct, so this is a swap rather than a layout exercise.

**Keep the edges, restyle them.** The connectors are vector paths; changing weight, colour or dash is trivial and their geometry is already solved.

The result is a diagram with an algorithm’s layout and a designer’s components, which is exactly what most real org charts, taxonomies and architecture diagrams need and what neither tool produces alone.

## Styling it well

**Right-angled edges for containment, curves for flow.** A tree of things that belong to other things should use orthogonal connectors; curves belong to diagrams where something moves along the edge.

**Keep node sizes equal unless size means something.** Varying node size is a free channel — team size, file size, importance — and an accidental variation reads as a claim.

**Two levels of type, no more.** Name and, if needed, one qualifier in a lighter grey. A third line doubles the node width and halves how much tree fits.

**Colour by level or by branch, and pick one.** Level colouring makes depth readable at a glance; branch colouring makes lineage readable. Doing both produces a diagram where colour means two things.

**Give the deepest level room.** Trees are usually cramped where they are deepest, which is where the labels are also longest. Design the frame around the worst case rather than the root.

For type and colour, bind them to your design system rather than picking by hand — covered in [Your chart, your design system](https://systergon.com/blog/figma-charts-design-system-colors-typography-tokens).

## Edge shape is a signal, not a style

Chart libraries offer several connector shapes and treat the choice as decoration. It is not — readers infer different relationships from different edges.

**Orthogonal (right-angled)** edges read as containment and structure. They also make a dense tree far easier to trace, because the vertical segments align into columns and the eye can follow one down. This is the correct default for hierarchies.

**Curved (bezier)** edges read as flow or movement — appropriate for something travelling along the connection, misleading for a taxonomy where nothing moves anywhere.

**Straight diagonal** edges are the most compact and the hardest to trace, because several of them converging on one parent form a fan that is difficult to disentangle at a glance.

One practical note: whichever you choose, **keep the edge weight below the node weight**. The nodes are the content; connectors drawn at equal strength turn the diagram into a lattice with labels attached.

## Reading it well — and the ways it misleads

**Position implies rank.** Readers read top as senior, left as first and depth as distance from importance. In a taxonomy none of that is true, and a note or a non-vertical layout is the fix.

**Branch width looks like weight.** A parent with twelve children occupies more space than one with two, so it reads as bigger — when it may simply be more finely subdivided.

**Missing levels flatten silently.** Data that skips a level attaches nodes further up, making a parent look like it has more direct children than it does. Validate the tree before publishing.

**Equal nodes suggest equal things.** A tree draws a leaf and a major branch identically; nothing on the diagram says one contains ten thousand items and the other contains three.

**Layout is not data.** Which child is drawn leftmost is usually source order. Sort deliberately — alphabetically, by size, by importance — because readers will infer meaning from the order either way.

## Where tree diagrams are the standard tool

Four cases, all sharing a property: the hierarchy has no natural quantity, or the quantities are beside the point.

**Information architecture.** Site maps, navigation structures, content taxonomies. The question is what sits under what, and the pages have no size worth encoding — which is precisely when the other hierarchy charts have nothing to draw with.

**Schemas and data models.** Nested object structures, configuration trees, API response shapes. Left-to-right with polyline edges is close to how developers already read these in a tool.

**Decision documentation.** Not decision trees with logic on the edges — those are flowcharts — but the record of how a set of options was subdivided. Trees show the shape of the reasoning.

**Organisation structure.** Which is an [org chart](https://systergon.com/blog/figma-charts-org-chart) and is filed separately in this plugin, but is drawn by the same layout algorithms — ECharts’ tree examples are frequently the better starting point for one, because they offer the layouts the organization series does not.

## Accessibility

**Keep the text as text.** Inserting as SVG brings node labels in as real text layers, which makes the diagram searchable and readable by assistive technology — and for a chart whose content _is_ its labels, that is the whole accessibility story.

**Do not encode meaning in node colour alone.** Status, type or level shown only as a hue needs a label or a shape as well.

**Watch the edge contrast.** Connectors are usually the lightest element and they carry the structure; too light and the hierarchy dissolves into a scatter of labels.

**Give it a text equivalent.** The Export tab’s **Copy Alt Text**, **Copy Data Table** and **Set Node Desc** produce a description, a table of the underlying rows and a description written onto the Figma node. An indented list is a near-perfect textual equivalent of a tree, which is not true of most chart types.

## Common questions

### What is the difference between a tree diagram and a treemap?

A treemap encodes value as area and nests rectangles; a tree encodes no value at all and draws nodes with connecting lines. Use the treemap when sizes matter, the tree when structure matters and small branches must stay visible.

### Which libraries can draw a tree?

ECharts (7 examples, covering every orientation plus radial and polyline edges), Highcharts (the treegraph) and Nivo (1). Google Charts and ApexCharts have no tree type in the plugin.

### What layout should I use?

Left-to-right for long labels and deep hierarchies — it is the most practical default. Radial when you need to fit a lot into a square frame and want to avoid the seniority reading. Top-down when the hierarchy genuinely is about authority.

### Can a tree show quantities?

Not structurally, and that is the point — but you can add them as a second channel: node size, node colour or a number in the label. If quantity is the main question, an icicle or treemap encodes it properly.

### Can it handle a node with two parents?

No. A tree requires exactly one parent per node; anything with cross-links is a network diagram. Duplicating the node in two places is the common bodge and it silently double-counts.

### How many nodes can one hold?

Around fifty in a static diagram before it becomes a poster. Beyond that, show two levels with counts, filter to a subtree, or make it collapsible — in which case the deliverable is a prototype rather than a chart.

### Can a tree use live data?

Uniquely among the hierarchy charts here, the tree registry carries no link restriction — unlike treemaps, sunbursts and circle packing, which the plugin refuses to bind because a connector cannot build their structures from a flat range.

### Should the edges be curved or right-angled?

Right-angled for hierarchies. Orthogonal connectors read as containment and align into columns the eye can follow; curves read as flow, which is the wrong signal when nothing moves along the connection. Keep the edge weight below the node weight either way.

### Does the chart stay editable in Figma?

Insert as **SVG** and every node, edge and label is a real layer — which makes this the chart most worth finishing on the canvas: keep the algorithm’s layout, swap the nodes for your own components. Insert as **PNG** for a flat image at twice the pixel density.

## Where to start

Open the plugin, filter to Tree, and try the same hierarchy in three orientations — top-down, left-to-right and radial. The right answer is usually obvious within seconds and depends entirely on your label lengths and depth, which is the practical reason ECharts ships seven variants of one chart rather than one variant of seven.

[Install Figma Charts — it’s free to try →](https://www.figma.com/community/plugin/1345221583582136577/figma-charts) [Browse all 45 chart types →](https://systergon.com/figma-charts/chart-types)