How can I build a diagram that explains how parts of a system relate?

Write one sentence describing what the diagram should help someone understand. That sentence sets the boundary: a diagram of how a library loan is recorded needs different parts from one of the entire library service.

Next, list the parts that matter to that explanation. A part might be a person, component, process, record, or service. In a hypothetical library-loan example, the parts might be Reader, Book Copy, and Loan Record. Leave out details such as opening hours unless they affect the relationship you are explaining.

Consider who will read the diagram and what they already know. Use names and explanations that make sense to that audience. Aim for enough detail to make the connections understandable, not a complete inventory of the system.

For each pair of parts, write a phrase that completes “A relates to B because…” Put that phrase beside the line; an unlabeled line can be interpreted in different ways.

For the hypothetical example:

Reader — borrows — Book Copy Book Copy — is tracked by — Loan Record

Use a plain line when the relationship has no important direction. Use an arrow when direction or sequence matters, and label it with an action or flow, such as “sends request.” Don’t rely on the arrowhead alone to explain the meaning.

Keep visual rules consistent. If shapes represent different kinds of parts, add a small key. Try to avoid crossing lines, and use words or a key to distinguish different connection types rather than relying on color alone.

Include detail only when it helps answer your purpose. A diagram about which parts are connected may not need internal steps or every exception. A diagram about process order should show the steps and their direction. Don’t mix levels of detail unless readers need both; you could make separate diagrams instead.

For each arrow, ask: “Would the reader misunderstand this connection if the arrowhead were removed?” If not, a labeled line may be clearer. If the arrow means “sends,” “depends on,” or “happens before,” keep it and label that meaning.

Ask someone unfamiliar with the system to describe the connections. If they have to guess, improve a label or key. This checks whether the diagram is understandable; it does not establish that the diagram completely or accurately models the real system.

Use this worksheet before drawing:

Purpose: [What should the reader understand?] Audience: [Who will read it, and what do they already know?] Boundary: [What is included and left out?] Parts: [Name each part consistently.] Connections: [Part A] — [relationship phrase] — [Part B] Direction: [Does order or flow matter? If so, which way and why?] Key: [What do shapes, line styles, or arrows mean?] Clarity check: [Can a new reader explain the important connections?]

Filled in for the hypothetical library-loan example:

Purpose: Show which parts are involved in recording a loan. Audience: Staff learning the basic record-keeping flow. Boundary: Include the reader, borrowed copy, and loan record; leave out unrelated services. Parts: Reader; Book Copy; Loan Record. Connections: Reader — borrows — Book Copy; Book Copy — is tracked by — Loan Record. Direction: This simple relationship view does not show a process sequence, so use labeled lines without arrows. Key: Each box is a named part; each labeled line describes a relationship. Clarity check: Ask a new reader what each line means and revise any unclear label.

This is a planning illustration, not a claim about how every library records loans. Adapt it to the system you are explaining.