# Stakeholder Map

## Overview

Understanding who is involved in or influenced by a service is essential for human-centred design. The Stakeholder Map helps teams see the bigger picture—by mapping out the people, groups, and organisations that interact with or affect the service experience.

This visual tool supports planning for discovery research, communication, and later phases of co-design. It helps clarify who should be engaged when: whether during interviews, testing, feedback, or alignment.

The map uses three concentric circles:

* Centre: your **end-users**
* Middle: actors with **direct interaction** with users (e.g. front-line staff, help desk)
* Outer: actors with **indirect influence** (e.g. policymakers, IT teams, regulators)

{% embed url="<https://docs.google.com/presentation/d/1xl5vo7NNwAcHRwnZrn3LLKmVD-P9VGUJ2dGXh1QDSLQ/edit?usp=sharing>" %}
[Open in Google Slides](https://docs.google.com/presentation/d/1xl5vo7NNwAcHRwnZrn3LLKmVD-P9VGUJ2dGXh1QDSLQ/edit?usp=sharing)
{% endembed %}

{% hint style="info" %}
**⏱️ Time:** 30–45 minutes

👫 **Participants:** Core team (3–5 people), ideally with someone from service operations

🛠️ **Materials:** Stakeholder map template (printed or digital) or blank sheet (A3), markers, sticky notes
{% endhint %}

## Input

Before completing this canvas, ensure you have completed the following step:

{% content-ref url="/pages/7afK8CiAQ1DpqChZLbb5" %}
[Service Challenge](/publicservicebooster/design-steps/1-scope-what-challenge-are-we-addressing/service-challenge.md)
{% endcontent-ref %}

## Context

Use this tool during the early planning stage of your discovery research. It is especially useful after initially defining your service challenge, to help decide who you need to speak with and who should be involved later in the process.

## Recipe

{% stepper %}
{% step %}

#### List down users and providers

Use [service challenge canvas](/publicservicebooster/design-steps/1-scope-what-challenge-are-we-addressing/service-challenge.md) to list down users and providers involved in the service your team will focus on. Add more if you come up with any other stakeholders.
{% endstep %}

{% step %}

#### Map the ecosystem

* In the centre: write your **end-users** (specific groups, not just "the public")
* First ring: actors who **interact directly** with users (e.g. clerks, support staff, contractors)
* Outer ring: actors who **influence** the service but may not meet users (e.g. legal teams, procurement, other departments)
  {% endstep %}

{% step %}

#### Add detail (optional)

* Use colours or labels to show roles (e.g. internal/external, high/low influence)
* You can also represent relationship strength (e.g. frequent vs rare contact)
  {% endstep %}

{% step %}

#### Define engagement approach

Mark on the map:

* Who will you **interview** or observe during discovery
* Who should be **informed** regularly
* Who you will **consult** on early ideas
* Who needs to **approve** or support prototyping
  {% endstep %}
  {% endstepper %}

## Results <a href="#results" id="results"></a>

A shared visual reference of all key stakeholders related to your service. The map helps guide:

* Discovery research recruitment
* Communication and alignment strategies
* Planning for later co-design or prototyping steps

## Tips

* Don’t stop at “the usual suspects”—include those who are often left out but may hold valuable insight.
* Consider both **organisational structure** and **real-world influence**—they’re not always the same.
* Be specific: “back office staff handling incomplete forms” is more useful than “internal team”.
* Revisit and update your map as your understanding evolves.

***

### [Share Your Experience](https://padlet.com/opsi/innovation-booster-collaboration-lmuadp5wornnbo86)

We'd love to hear how you're using this tool! Please share your examples and feedback to inspire others and help improve the Booster. Submit your example today and be part of our community.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://oecd-public-service-innovation-b.gitbook.io/publicservicebooster/design-steps/2-engage-who-are-we-designing-for/stakeholder-map.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.