This entry is part of the Chart Index, the reference library for the Chart Design Field Guide.

A force-directed network graph is the visualisation of a graph — nodes connected by edges — laid out by a physics simulation. Nodes repel each other; edges act as springs pulling connected nodes together; the layout settles when forces balance. The resulting picture reveals clusters, hubs, bridges, and isolation in a way no other form does.

The form is uniquely suited to exploring relational data. Where a hierarchy has a treemap and a flow has a Sankey, an arbitrary graph has no natural layout, so the force simulation finds one that respects the connectivity. The output is often beautiful — but the beauty is incidental; the layout is the data structure made visible.

What it is

A network graph maps entities to nodes (circles, dots) and relationships to edges (lines between nodes). The positions of the nodes are computed by a force-directed simulation: nodes repel each other (typically by an inverse-square law), edges pull connected nodes together (Hooke's law spring), and the layout converges to a low-energy configuration. Node size can encode a quantitative attribute (centrality, degree); edge thickness can encode a relationship strength.

The hero chart above is a co-authorship network: thirty researchers in four labs, an edge for every pair who have published together. The simulation was never told about the labs, but it finds them — each lab settles into its own clump, because its members are linked to one another and to few outsiders. The big nodes at the heart of each clump are the lab heads; the long edges that cross between clumps are the bridges, and the statisticians are on most of them. Randomise the node sizes and link lengths and the whole graph re-settles: the clumps hold, the exact positions do not, which is the honest thing about a force layout.

When to use it

Network graphs are the right choice when:

  • The data is inherently relational and the relationships do not fit a tree or a flow.
  • The reader's question is "what is the structure of this network? where are the clusters, hubs, bridges?"
  • The graph has fewer than ~200 nodes for a static, readable display.
  • The audience is comfortable with graph thinking or willing to be guided through it.
  • The chart is exploratory or editorial — not operational.

When not to use it

  • Hierarchical data. Use a tree, treemap, or sunburst. Force layouts on hierarchies look beautiful but lose the parent–child semantics.
  • Very large graphs. Above a few hundred nodes, the diagram becomes a hairball with no usable structure. Use clustering, sampling, or matrix-based representations.
  • Precise quantitative reading. Position in a force-directed layout is approximate; spatial distances are not literal data values.
  • When the graph is mostly disconnected. A force layout of many isolated subgraphs is a chart of separate clouds — better as small multiples or a matrix.

Design principles

Make clusters perceptible

If clusters exist — a community-detection pass has found them, or the data carries a natural grouping — use one colour per cluster. The colour anchors the eye to the cluster identity even as nodes shift during the simulation. Without it, the cluster structure has to be inferred from spatial position alone, and position in a force layout is only ever approximate.

Three teams, coloured: the structure is instant
Sixteen people in three teams, with edges for who works with whom. The simulation pulls each team into its own clump; colour confirms it, and the two grey-linked bridges between teams stand out because the colours change across them.
The same graph in one colour: the clumps are there, the teams are not
Identical nodes and edges with no group encoding. The layout still separates the three clumps, but the reader has to decide for themselves where one team ends and the next begins, and the bridges no longer announce themselves.

Choose node size encoding deliberately

If all nodes have the same size, the chart shows pure connectivity. If you size by degree (number of connections) or by another centrality measure, you encode importance — but you also influence layout because larger nodes push others away further. Match the size encoding to the question.

Every node the same size: connectivity alone
The three teams with node size removed. The hubs are still findable — they are the nodes with the most edges — but the reader has to count. Uniform sizing is the right choice when the question is purely about who is connected to whom.

Know when it becomes a hairball

The force layout has a ceiling. Past a few hundred nodes, or past a density where most nodes touch most others, the springs and charges cancel into a uniform blob: the hairball. No amount of colour or labelling rescues it. Filter the edges to the strongest, collapse the clusters into super-nodes, or switch to an adjacency matrix.

Eighty nodes, two hundred edges: the hairball
A random graph at the density where the form fails. The simulation converges, the nodes settle into a disc, and there is nothing to read — every node is a few hops from every other and no region is distinguishable from the rest.

Label only key nodes

Hundreds of node labels turn a force-directed graph into a wall of text. Label the high-degree nodes, the named entities the reader will care about, and a few outliers. The hero and the team figures above print a label only on nodes at least sixteen pixels across — the hubs — and leave the rest to the tooltip. The unlabelled nodes have meaning by their position and connectivity.

Use edge weight sparingly

Edge thickness can encode relationship strength. With many edges, varying thicknesses produce a tangle of varying ribbons. For graphs with weighted edges, consider thresholding (only edges above some weight), or render thickness only for the top-N most important.

Settle the layout before rendering

A force simulation that has not converged produces a chaotic-looking chart. Run the simulation to convergence — the figures here use 200 ticks — then render the static result. Animated layouts are fun but unstable for editorial use, and a reader should never see nodes still drifting.

Provide alt views for precision

A force-directed graph is for understanding shape. For precise relationships, pair it with an adjacency matrix or a sorted list of edges. The graph answers what does this network look like?; the matrix answers what is the exact relationship between A and B?

Be cautious with arrows

For directed graphs, edges need arrowheads. With many edges, arrowheads add clutter; with few, they add clarity. If most edges are undirected, drop the arrows and note the direction explicitly for the few that matter.

Anatomy

The composition of a force-directed network
An anatomical guide

A network graph's anatomy is nodes and edges, plus a layout. The layout is the data structure made spatial; the colour, size, and labels add encoding dimensions. Restraint in all three (label only the named, size only the important, colour only the cluster) makes the structure read clearly.

  • Heatmap — the adjacency matrix: the same data as a colour-coded grid. Less visually compelling, more precise.
  • Chord diagram — for all-to-all relationships within a single set.
  • Arc diagram — relationships shown as arcs above a linear arrangement.
  • Tree — for strictly hierarchical relationships.
  • Sankey diagram — for directional flows in a multi-stage process.

Reading list

  • Fruchterman, T. & Reingold, E. (1991). Graph Drawing by Force-Directed Placement. The foundational algorithm.
  • Bostock, M., Ogievetsky, V. & Heer, J. (2011). D³: Data-Driven Documents. The library whose force layout became the web standard.
  • Munzner, T. (2014). Visualization Analysis and Design. The taxonomy of network visualisation tasks, and when a matrix beats a node–link diagram.
  • Ghoniem, M., Fekete, J.-D. & Castagliola, P. (2004). A Comparison of the Readability of Graphs Using Node-Link and Matrix-Based Representations. The evidence for the hairball threshold.