Draw a Forest and Mycelium System
Use a forest cross-section when people can see your products but cannot see why they become stronger together.
Draw the visible offers as mushroom caps. Draw shared capabilities as mycelium below ground. Connect them only when you can name the value that flows through the connection.
The result should help someone answer three questions:
- What promise can I see?
- What shared capability keeps that promise?
- What evidence would prove the connection is useful?
When the metaphor earns its place
Use it when:
- several products, services, teams, or ventures have distinct identities;
- shared technology, knowledge, standards, relationships, or operations support more than one visible offer;
- people mistake the visible offer for the whole system;
- the next decision depends on strengthening a connection, not adding another box.
Do not use it for a simple hierarchy or sequence. Use a tree for hierarchy and a flow for sequence. The forest is for one system with two interdependent layers.
Build the picture
1. Name each cap by its promise
Write what a person can choose, use, or appreciate. Avoid internal project names unless the audience already knows them.
Good: Help a team see its operating system
Weak: Frontend application
Caps may look different. Their distinct expression is useful. The shared layer should not force every cap to become a clone.
2. Name each mycelium node by capability
Write what the system can reliably do more than once. Examples include:
- shared language;
- identity and consent;
- reusable interaction;
- evidence capture;
- governed intelligent action;
- fulfilment and support.
A library, platform, or team is not yet a capability. Name the useful power it provides.
3. Make every strand a claim
Label each connection with the value it carries. Then ask what receipt would support the claim.
| Cap promise | Shared capability | Connection claim | Possible receipt |
|---|---|---|---|
| Help a team understand a system | Shared visual language | People interpret symbols consistently | A cold reader explains the picture without coaching |
| Deliver a new service quickly | Reusable interaction | Proven interface patterns reduce rebuilding | A second service imports the pattern unchanged |
| Improve the next decision | Evidence capture | Outcomes return as learning | A later decision cites the recorded result |
Remove any strand you cannot explain. A dense web without named value hides the system instead of revealing it.
4. Choose one growth edge
Do not finish with “improve the ecosystem.” Choose one bounded move:
- connect one cap to an existing capability;
- strengthen one weak receipt;
- extract one repeated capability from a cap;
- stop maintaining one connection that no longer creates value.
Coach at the learner's edge
The picture is a scaffold, not an authority.
Start from what the learner can already identify alone. Then offer the smallest move just beyond that independent state.
| Learning state | Coach prompt | Support |
|---|---|---|
| Can name the visible offers | “Which promise matters now?” | Point to one cap |
| Can name one promise | “What keeps it true more than once?” | Trace one strand |
| Can identify shared capability | “What receipt supports this connection?” | Offer the claim–receipt table |
| Can test a connection | “Which edge should grow next?” | Fade the scaffold and let the learner choose |
This is the Zone of Proximal Development in practice: the task is reachable with support but not yet routine alone. A more knowledgeable other may be a person, team, worked example, or interactive guide. Its authority is limited to the gap it can help close.
Support should fade. The transfer test is simple: can the learner draw a different system, defend its connections, and choose a growth edge without the original guide?
Check the result
A useful forest diagram passes when:
- a cold reader distinguishes visible promises from shared capability;
- every strand carries a named value claim;
- important meaning remains available without color or spatial position;
- the equivalent text is as useful as the picture;
- the learner can choose one next action;
- the metaphor can be removed after it teaches the underlying relationship.
The diagram is a working hypothesis until observed use supports its claims. It does not prove that a shared capability is healthy merely because a line was drawn.
Practise
Take one system you know. Limit yourself to three caps, five mycelium nodes, and seven strands.
For each strand, complete this sentence:
[Capability] helps [promise] by [named value]. I would believe this connection is useful when [receipt].
Remove one weak strand. Circle one growth edge. Ask another person to explain the picture before you explain it to them.
Context
- depends-on Design Language — use semantic visual rules so the metaphor remains readable and portable.
- applies-to Systems Thinking — use the picture to expose relationships, not to replace evidence.
- uses How to Audit a Page — test legibility, access, and responsive behavior in the rendered surface.
Questions
Which connection would matter even if the mushroom cap changed its brand?
- What can the learner already identify without support?
- Which one connection is just beyond their current understanding?
- What receipt would change your mind about that connection?
- Next question: can the learner transfer the method to a different system without the original picture?