01 / UNDERSTAND
What is an ecosystem map?
An ecosystem map represents the people, organisations and systems around a service, together with the exchanges connecting them. Its focus is how the wider arrangement makes an experience possible, including relationships outside the organisation delivering it.
A Stakeholder Map helps identify relevant actors and their interests. An ecosystem map goes further into what passes between them: information, resources, money, authority or support. Neither diagram proves that a relationship works as intended.
Why use Ecosystem Map?
A service problem can sit between organisations rather than within a single interface. Making exchanges explicit helps a team see where somebody must coordinate, translate or compensate for a gap. It also reveals dependencies that a project boundary can otherwise hide.
When to use it
USE IT WHEN
A service depends on several organisations whose responsibilities are unclear.
A proposed change may shift effort or risk to another actor.
The team needs to understand a coordination problem before redesigning a touchpoint.
When to choose another method
Use Customer Journey Map to follow one person’s experience through time.
Use Service Blueprint to examine the operational delivery of a defined service.
Use User Interviews when the connections on the map are mostly assumptions.
What you’ll need
Define the situation, geographic or organisational boundary and time period. Bring interviews, service documents and accounts from more than one side of an exchange. Include informal helpers where relevant. Decide which sensitive relationships should be anonymised before sharing the map outside the research team.
What the method needs
Keep the elements that help answer your question and support a decision.
The situation included and what remains outside this version.
People, organisations or systems with distinct roles.
What moves between actors, in which direction and under what conditions.
What one actor needs another to provide or permit.
The source and confidence behind each important connection.
Missing, contested or fragile relationships that deserve investigation.
02 / PUT IT INTO PRACTICE
How to create an ecosystem map
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Set the question
Name the decision the map should support. Avoid mapping an entire sector without a purpose.
Ask who must coordinate a repair before deciding how requests should be routed.
02
Identify the actors
Record roles rather than mixing individual names, departments and whole industries at random.
Separate the landlord, repair contractor and resident where their responsibilities differ.
03
Trace exchanges
Draw directional connections and label the actual thing exchanged. Add a legend for different types.
A repair authorisation is different from a notification that work is complete.
04
Check both ends
Compare the sender’s description with the receiver’s experience. Mark disagreement visibly.
Sent does not necessarily mean received, understood or acted upon.
05
Look for vulnerable dependencies
Find exchanges that rely on one person, an undocumented rule or repeated chasing.
Ask what happens when the usual coordinator is unavailable.
06
Select a next investigation
Choose a consequential connection and define what evidence or agreement is missing.
Confirm who can authorise urgent work before designing a faster request form.
Example: coordinating a rented home repair
Fictional scenario: a resident reports a leak to a housing provider. The provider authorises a contractor, while the resident arranges access. A neighbour sometimes holds the key. The map shows different exchanges: the report, spending permission, appointment information and physical access.
The contractor sees a confirmed visit, but the resident has only received a proposed time. The neighbour’s availability is assumed. A connection that looked complete therefore depends on two unconfirmed arrangements.
The team would examine how an appointment becomes confirmed and who handles a failed handover. The design opportunity may be a shared confirmation rule rather than another message. These events are invented to demonstrate the mapping logic, not findings from a housing study.
03 / BELOW THE SURFACE
Below the surface: coordination has an owner, even when nobody names one
A line can conceal the work required to keep a relationship functioning.
EXCHANGE
What actually passes between actors?
Name the object, direction and conditions.
RECOVERY
Who repairs a failed exchange?
Make hidden coordination work visible.
POWER
Can that person change the arrangement?
Separate responsibility from authority.
The resident may be carrying information between organisations because their systems do not connect. Drawing a single line from provider to contractor erases that work. Ask who repairs the exchange when it fails.
Add a short recovery annotation to critical connections: who notices a problem, who follows up and who bears the delay? This is an editorial extension for this guide, not a separate established mapping framework.
A proposed integration may remove visible friction while concentrating responsibility in somebody with little authority. Compare the ordinary exchange with its breakdown before recommending a redesign. The map becomes more useful when it exposes that difference rather than simply becoming more complete.
Ecosystem Map companion worksheet
The original two page worksheet provides a relationship map and an exchange review. Use the first page to locate actors and the second to document a dependency, evidence and recovery responsibilities. Redraw the network when the boundary changes.
Practical tips
Label relationships with concrete exchanges.
Check an important connection with people on both sides.
Common mistakes
Treating every line as an equally reliable relationship.
Leaving informal coordination outside the picture.
Confusing a complete diagram with an agreed operating model.
What you’ll get
A focused account of how the service depends on its surroundings. Carry one unresolved exchange into research or operational design, with an owner and a clear question.