What if we had a method we could use with clients to better understand their stakeholder landscape and that would help us do more effective UX work? What if it was more like a consulting method instead of a design deliverable? Could that help us choose research, design and evaluation methods more effectively so we could have more impact on our projects?

1. MAPPINGMARCH 30, 2014 ● IA SUMMIT
STAKEHOLDER
My name is Gene Smith. This is my seventh or eighth presentation at the IA Summit in the
last 10 years. I’m really grateful and humbled to be part of this year’s program. There’s just
so much great content being shared this weekend.
This talk is about Stakeholder mapping.

2. #stakeholdermapping
#shmap
@gsmith
If you want to tweet about this talk, I will follow the hashtag #stakeholdermapping and look at
your comments and feedback later.
If you want to tweet to me directly, my handle is @gsmith

3. I think it’ll be helpful if I share a couple of details about my company before I get started just
to give you the context our business.
nForm is a UX design firm. We’re located in Edmonton Canada. And we work exclusively
with enterprise clients on large websites and intranets and complex business applications.
We don’t really do things like ecommerce, micro-sites, or consumer facing web apps. That’s
partly a reflection of our location and customer base, as well as some of the choices we’ve
made.
One of the features of our projects is that there are lots of people at the table with competing
and sometimes divergent interests.
And there are usually a few important people who aren't at the table, but who are invested in
whatever product we happen to be working on.
A couple of years a ago I had a moment of clarity.
The realization was that if we better understood the stakeholders on our projects, the
relationships between them, the role they play, their interests, and that sort of thing, we
would have a powerful advantage when it comes to planning and doing our work. A
methodical and comprehensive map of our stakeholders concerns would help us be more
savvy consultants *and* most importantly do better research, design and evaluation work.

4. This moment of clarity was the result of a simple question. It was a cool June afternoon. I
was sitting in a boardroom in Victoria, Canada, with seven others—developers, architects,
account managers, project managers. I was the only UX person.
We were doing a retrospective on an application development project that had just failed. We
had been part of that project, and thankfully we weren't the reason it failed. We were asked
to pull together with a new team to start over.
So as we surveyed the wreckage of this failed project, we started to talk about all the different
people who should've been involved, all the different people who had to approve different
facets of this system, and generally, all the different people who had some kind stake in the
project.
And one guy, a senior guy with a lot of corporate knowledge, asks "so who is the client?"
Photo: https://www.flickr.com/photos/yasminsimpson/11287682726/

5. “Who is the client?”
We all paused.
It's not like we didn't know who signed the contract and the cheques. We all knew that. The
problem was there was a long list of other people who had a material interest in what we were
doing. They weren't the economic or contractual client, but they were clients.
Within two minutes of that question being asked we collectively came up with a list of eight
clients. It was the usual acronym soup.
All of them were the client. And by that I mean all of them were important enough to have
approval—to say yea or nay—to some or all of what we were building.
And some of them had different points of view on what the application needed to be.
We couldn't just walk into this project with the mindset that we were there to advocate for and
design for the end user. That would be naive.

6. We had this whole constellation of stakeholders we needed to accommodate… with our
process, with our deliverables.
This was where the lightbulb started to flicker on for me. Maybe the reason we aren't having
the impact we want on this project is because we haven't adequately surveyed the
stakeholder landscape.
And if you don’t mind me mixing metaphors, we only had a rudimentary map of that
landcape. We didn’t even have a “There be dragons” on it.
Maybe if we had a methodical and comprehensive understanding of that landscape, our
design work would be more effective.

7. What if we had a method we could use with clients
to better understand their stakeholder landscape
and that would help us do more effective UX work?
What if it was more like a consulting method
instead of a design deliverable? Repeatable,
teachable, measurable, provide reliable and unique
insights, offer guidance on strategies.
Could that help us choose research, design and
evaluation methods more effectively so we could
have more impact on our projects?
So I started to ask myself some questions:
What if we had a method we could use with clients to better understand their stakeholder
landscape and that would help us do more effective UX work?
What if it was more like a consulting method instead of a design deliverable? Repeatable,
teachable, measurable, provide reliable and unique insights, offer guidance on strategies.
Could that help us choose research, design and evaluation methods more effectively so we
could have more impact on our projects?

8. As I was asking myself these questions, there were some tools in the UX space that were an
inspiration to me:
XPLANE’s empathy map, which I’ve used dozens of times, and does a great job of getting
clients to put themselves in the shoes of different users.

9. Text
TUG’s performance continuums—I’ve used these a few times as well—and they are really
effective at spurring discussion about the nature of the product we’re working on.
So I starting working through ideas—could we develop something simple like empathy maps
or performance continuums, but that would help us and clients decide what to do with
stakeholders early in a project?

10. 1. What’s already been done in the field of
stakeholder mapping
2. What I’ve been thinking about: stakeholder
mapping for complex design projects
3. A method we’ve been testing internally and those
results.
What I’m going to walk you through today is
1. What’s already been done in the field of stakeholder mapping
2. What I’ve been thinking about: stakeholder mapping can be used on complex design
projects
3. A method we’ve been testing internally and those results.
So by no means is this a complete method or set of tools, but this is our first thrust at
creating stakeholder mapping tools specifically for complex design projects.

11. What’s a stakeholder?
But first, let's start with the most important question: what is a stakeholder?
The term has different meanings depending on the context. In business, stakeholders are
typically investors, analysts, customers, board members, perhaps various kinds of advocacy
groups depending on the industry.
In public engagement, stakeholder can mean any kind of individual or community group. In
our UX work we sometimes distinguish between users and stakeholders—though perhaps that
distinction is unnecessary.

12. A party that has an interest in an enterprise or
project
“Any person group or organization that can place a
claim on the organization's attention, resources, or
output, or is affected by that output.” - Bryson, 1995
“Those individuals or groups who depend on the
organization to fulfill their own goals and on whom,
in turn, the organization depends" - Johnson &
Scholes, 2002
Here are three definitions:
A party that has an interest in an enterprise or project
“Any person group or organization that can place a claim on the organization's attention,
resources, or output, or is affected by that output” (Bryson, 1995)
“Those individuals or groups who depend on the organization to fulfill their own goals and on
whom, in turn, the organization depends" (Johnson & Scholes, 2002)
I really like the third definition, since it encompasses the users we usually fret over. But for
the purposes of this talk any of these will do—we are talking about people or groups who
have an interest in what we're doing.

13. What’s Already Been Done
Stakeholder mapping is not a new activity. It's widely used in management consulting, urban
planning, resource management, and public participation activities.
I want to walk you through some of prior work in this area, because I think it's instructive.

14. INTEREST
INFLUENCE
Keep Informed
Manage Closely
Keep Informed
+
Two-way
Communication
Keep Satisfied
One of the first stakeholder analysis tools, developed by Gardner in the 1980s, is called a
power/interest matrix. With this tool you rank stakeholders based on their level of interest
and their level of influence.
One thing I like about this tool is it provides strategic guidance. For example, stakeholders
that are high influence and high interest are to be managed closely.

15. Crowd
PlayerSubjects
INTEREST
INFLUENCE
Context Setter
In a later version of this tool, developed by Eden and Ackermann in the late 1990s, we can see
these groups named. If you’re in the upper right, you’re a “player”
If you’re in the lower right, a “context setter”
One of the challenges for this tool, and any of the others that examine power/influence, is
that power is a hard thing to discuss honestly.
On one project we were involved in, the project manager created a power/interest matrix as a
planning tool. It was included some of the official project documentation and it just so
happened that one executive member was placed in the low influence.
Midway through the project, the project sponsor sees this matrix and objects. She says “he
can’t be listed low influence, what if he sees this?” So he was moved to high influence, and
the effectiveness of the tool was diminished.

16. Another for technique for stakeholder analysis looks at power, legitimacy and urgency.
Stakeholders are classified based on whether they have the power to influence the project or
organization, legitimacy in they eyes of the organization, and the degree to which their claims
or issues call for immediate attention.
Salience is defined as the degree to which the organization prioritizes competing
stakeholders.
This model is also prescriptive; it tells us how to prioritize once we figured out where our
stakeholders fall it tells us how to deal with them.
In that red zone, we have definitive stakeholders.
In those orange petals we have dominant, dependent and dangerous stakeholders.
This tool give us guidance on how to handle each one, and balance their interests and needs.

17. Another technique from the natural resource management world is called a conflict analysis
matrix. I’ve seen this extended to look at interactions between different stakeholders.
This example shows the departments of a hospital and the matrix tells us how close or far
they should be from one another, and the reason.
For example,
* Wards and Intensive care = Undesirable because of noise levels
* Pharmacy and Outpatient Clinics = Very important because of convenience
Again, it’s a bit prescriptive.
In some cases, these methods were developed decades ago. While I think they are still
relevant in many ways, I also think the kind of work we do might require something different.
Obviously, as soon as we’re talking about digital products and services are very different from
natural resources.

18. Scarcity: no scarcity of digital assets
Scale: global audiences mean sheer numbers of
stakeholders can be huge
UX Role: we actively advocate for stakeholders
groups.
Let’s talk about some of the differences I’ve obversed.
Scarcity - when we talk about digital products and services, we aren’t faced with the issue of
scarcity that we are in the physical world. Think of a fishery. It can only support so many
fishermen, and feed so many people. There’s no reason a website couldn’t serve every single
stakeholder group, no matter how obscure or remote, simple because there’s never going to
be a shortage of web. Or code.
With digital products we deal with scarcity of time, resources and attention.
Scale: many digital products and services are accessible to a global audience. The sheer
numbers of potential stakeholders can be huge.
These two things, sheer numbers and no scarcity, are kind of interesting when you put them
together.
Role of UX Practitioners. We are not outside the organization, we are in the middle. In many
ways our job is to represent less-known stakeholders and more powerful.
E.g. in the salience model we could think of our role as making the concerns of marginalized
stakeholders more legitimate and urgent in the eyes of the organization.
In any case, all of this is to say that perhaps the old methods of stakeholder analysis are not
enough and we need to look for something new.

19. PETER CHECKLAND
The place I chose to look was called soft systems methodology, and it’s a branch of systems
thinking that looks focuses on designing systems that learn.
Interestingly the guy who came up with Soft Systems methodology, Peter Checkland, is a peer
of Eden and Ackerman who wrote about the power/interest matrix. Checkland and Jim
Scholes wrote a book about soft systems methodology (Soft Systems Methodology in Action),
and if you remember Scholes is one of the authors of the third stakeholder definition I gave
earlier.
There’s a symbiotic relationship between some of the people thinking about stakeholder
mapping and the thinking behind soft systems methodology. That’s all I’m going to say
about that.
One characteristic of these thinkers is that they tend to look broadly and inclusively at
systems and stakeholders. That’s what I’m going to do too.
Photo: https://www.flickr.com/photos/naughton/6960122636/

20. C
A
T
W
O
E
Customers
Actors
Transformation
Worldview
Owners
Environment
The particular method I’m going to talk about is loosely based on an idea from soft systems
methodology called CATWOE.
CATWOE is an acronym that stands for customers, actors, transformation, worldview, owners
and environment. The idea is that interactions between these six elements can be used to
create a rich picture of complex systems.

21. Stakeholder Elicitation & Classification
Stakeholder Mapping
Pattern Analysis
Developing Design Strategies
As I started to think about how we could apply CATWOE to stakeholder analysis, I started
imagine a four step process that answered some of the questions I’d been asking myself.
Step 1: Stakeholder Elicitation & Classification - How do we identify many of the stakeholders
specifically?
Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful fidelity?
Step 3: Pattern Analysis - What insights can we glean from these maps?
Step 4: Design Strategies - How can our stakeholder maps guide strategy?
I’m going to show you how we are working through this four-step process. As I said before,
this is not complete method. At this stage, we are just probing this space to see what’s
interesting.

22. Stakeholder Elicitation
One thing I’ve noticed over the years is that people tend to talk about stakeholder groups
quite generally. There are citizens and advocacy groups and industry. There are off-hand
categories like internal and external. Years ago when I worked in communications we would
often call our stakeholders just “stakeholders” – one big catch-all bucket for everyone who
had an interest. In hindsight that was probably both lazy and risky.
But in our consulting work I’ve noticed that these groups are so large and homogenized and
frankly poorly defined that important or even just interesting details are missed. They are
laced with unspoken assumptions.
Sometimes when we’re planning user research we’ll talk with a client about who we should be
interviewing, and they’ll toss out these generic groups. And you really have to work to get
them to be specific, and inclusive. And if we aren’t familiar with the domain, it’s easy to miss
an important stakeholder, which comes back to bite us later.
This was the easiest one to solve. We designed a workshop activity around eliciting a large
number of stakeholders.

23. Stakeholder Elicitation & Classification
Stakeholder Mapping
Pattern Analysis
Developing Design Strategies
As I started to think about how we could apply CATWOE to stakeholder analysis, I started
imagine a four step process that answered some of the questions I’d been asking myself.
Step 1: Stakeholder Elicitation & Classification - How do we identify many of the stakeholders
specifically?
Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful fidelity?
Step 3: Pattern Analysis - What insights can we glean from these maps?
Step 4: Design Strategies - How can our stakeholder maps guide strategy?
I’m going to show you how we are working through this four-step process. As I said before,
this is not complete method. At this stage, we are just probing this space to see what’s
interesting.

24. Held a workshop with six people from the client
organization.
Working alone, participants were asked to list
specific stakeholders for 10 - 15 minutes.
Team of six generated 140 stakeholder names.
We assembled a knowledgeable group of employees from across the organization. These are
people who were working close to the coalface, so they could take a front-line perspective
and a management perspective.
The instructions were simple:
•
Working alone for 10 – 15 minutes write down one stakeholder per post-it note
•
If it’s an individual, write their title or role
•
Instead of generic group names give you must give specific examples.
An example of a generic group name might be “industry” or “lobby groups.” So instead of
just industry you might get “large manufacturers” and “manufacturers associations”, and from
there you might get individual company names or association names.
The facilitation technique I used is to read each post-it note before I place it on the wall, ask
if every understands what it means and if it’s specific enough, and if not I send it back to the
table to be broken down further.
I ran one of these workshops a few weeks ago. We had six people over two hours come up
with about 140 specific stakeholders--with very little duplication. Now this is a large public-
sector organization with a challenging business, so they may have more stakeholders than
most.
The next step was to divide them into customers, actors and owners. If you remember, these
are the three roles from our CATWOE model I shared earlier.

25. Customers use the product or receive the results
of the project; the end users, direct and indirect.
Actors work to create and maintain the project
and product.
Owners own the system or product or own
processes impacted by the project, and can
inhibit/enhance the success of the project.
For the purposes of this exercise, here’s how we defined customers, actors and owners.
-
Customers use the system; the end users, direct and indirect.
-
Actors work to create and maintain the system.
-
Owners own the system or product or own processes impacted by the system, and can
inhibit/enhance the success of the project.
This step generated even more names. We ended with about 180 in total.
As you’d expect, once we divided our stakeholders up we had a lot of customers, and fewer
actors and owners.
Then we could start to group our customers. This was challenging, we were battling the
group’s natural inclination to use their historic stakeholder groupings OR their organizational
structure.
Working together, we subdivided the customers group into five: users, internal and external
service providers, and internal and external overseers. From there we were able to identify
four interesting (but rough) sub-groups of users. And then we ran out of time.
But we got great feedback from the participants, who had a chance to experience the breadth
and complexity of the stakeholder landscape. And that apprecitation came from seeing it in
detail.
In the future I would allow two days for this kind of workshop.
So, we have 180 stakeholder names. What do we do with them?

26. Stakeholder Mapping
Here’s what we think is next.
Continuing with the CATWOE framework, I thought it would be interesting to look at the
environment and worldview of each stakeholder.

27. Customers
Actors
Transformation
Worldview
Owners
Environment
Just a side note, the term worldview has some baggage for me. So I’m going to substitute
“expectations” for “worldview.” I think “expectations” is a bit more expansive in its meaning,
and that suits my purposes here.
In particular, I thought it might be interesting to see if we could map the expectations and
environment of various stakeholder groups.
To do this I asked my senior team members to retrospectively look at projects they worked on
over the past year. Collectively we did 5 projects.
They were instructed to divide their stakeholders into three groups: customers, actors and
owners.
They were asked to list the objectives of their project.
And they were given instructions on how to assess expectations and environment for each
stakeholder. This was strictly a gut-feel exercise.

28. Is their environment more ready or less ready for
the project to be a success?
Are their expectations about the project higher
or lower than what's outlined in the project
objectives?
There were two questions they had to answer:
-
Is their environment more ready or less ready than what is required for the project to be a
success?
-
Are their expectations about the project higher or lower than what's outlined in the
project objectives?

29. Environment
Physical
Financial
Technological
Legal
Organizational
Expectations
Project
Team
Sponsor
World at Large
Zeitgeist
And I asked them to use VERY broad definitions for environment and expectations.
•
Environment encompasses physical, financial, technological, organizational and legal
constraints. Basically everything but the “inner life” of that stakeholder.
•
Expectations covered the stakeholders beliefs about the project, the team, the project
sponsor, the world at large, the zeitgeist.
You might you think that's funny, but if you’re working on an Intranet and people believe that
"social networking will change our industry" then that's going to have a substantial impact on
your project.

30. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Actors
Customers
Owners
They were asked to place each stakeholder on a matrix with Expectations on the horizontal
axis (like so) and environment on the vertical axis (like this).
•
On the right we have higher expectations, and on the left we have lower expectations.
•
At the top we have more ready environment, and at the bottom we have less ready
environment.
And finally they were asked to colour-code their stakeholder groups: green for customers,
blue for actors, red for owners.
As you can imagine, this was a challenging and problematic exercise, I’ll summarize the
challenges in a minute. First I want to walk you through the maps

31. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#1

32. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#2

33. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#3

34. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#4

35. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#5

36. Here are al 5. What do we see?
I wasn’t expecting such a variety of patterns. For all the projects, stakeholders cluster in
different areas.
So I said there were challenges.
First, everyone struggled with the broad definitions of these two categories. In particular,
environment is a big tent and some people felt it was important to distinguish between
organizational readiness—willingness to change, leadership, psychological readiness--and
other factors like physical location or resources. Let's face it: organizational issues are much
harder to overcome than technological ones.
Second, in some cases we only had second-hand information about stakeholder groups. So
we were projecting on their behalf.
Third, sometimes it's hard to designate people as only customers, actors and owners.
Finally, some people weren't sure this could be done early in the project—at least not on our
own. Most of these maps capture a year or more of hard-won knowledge. And if you recall,
one of the goals was to do this kind of mapping early we could make our projects more
effective. So it's really not useful at the end of the project.
I added a new symbol to clarify some of differences between stakeholder groups: an open
circle for stakeholders inside the client organization, a closed circle for those outside the
client organization.

37. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#1

38. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#2

39. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#3

40. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#4

41. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#5

43. Pattern Analysis
Let's continue to explore that hunch a bit. If we could do this early, is it possible that we could
develop different—ideally, more effective--design strategies based on the patterns we see?
How do we make sense of these patterns?
One question we asked is could this tool be used to identify stakeholders that might be a risk
to our success?

44. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
Let’s focus on a couple of areas of our matrix. In particular, the corners.
The corners are places where we might find risk.

45. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
We think owners with high expectations and low environmental readiness may pose a risk.
And in particular, this risk is greater when those owners are struggling with organizational
challenges. Why?
May not be able to change their environment to enable success.
Or they may not be aware there’s a problem.
So do any of our projects have owners clustered in this area?

46. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#1
Sure--it’s project #1.
The designer who’s working on this told me that in the context of this project “it’s possible
for us to do good work and still utterly fail.”

47. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
Next we might look at customers with low expectations and high readiness. Why are these
people a risk? Couple of possible scenarios.
In the case of consumer-facing product maybe these are people in danger of switching to a
competitor.
For enterprise software, these may be critics who undermine your efforts, but they may also
be defectors. The groups who “go rogue” and develop their own system.

48. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#1
As it turned out that same project, #1, also fits this pattern.
So at this point we’re getting scared.

49. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
Third, we thought there would be a problem when we simultaneously see owners with low
expectations/low environmental readiness, and customers with high expectations/high
readiness.
In this case the owners act like anchor, keeping customers from achieveing their goals. And if
the situation is not addressed, we can imagine a deep rift as the project fails to address either
of these groups effectively.

50. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#3
We have a project that fits this pattern too.
In this case, some customers wanted to move forward quickly with a solution (and were
ready).
The owners couldn’t move as quickly, that was the reality of their environment. That was
partly technical and partly attitude.
The next question is, how do we move people from their positions? This question is the
essence of step 4 - design strategies.

51. Design Strategies
As I had this conversation with my team, the picture that emerged was that the design
artifacts themselves were incidental. What was important was the way the stakeholders were
engaged in the design process.
This could mean participating in user research, service modeling or co-design workshops or
something like that. Having them involved in some activities that reveal the gap between
where they are and where they need to be.
Those are hard things. Not the design activities themselves, but to get the right people into
the room with the right mindset.
So my hunch that we would be able to use this stakeholder mapping method to help us
choose design methods hasn’t really played out.
But what emerged was maybe a bit more interesting.

52. Positioning our work with owners
Advocating for access to important stakeholders
Empowering designers to ask challenging questions
Choreographing design reviews
Enabling stakeholder participation in design & research
We think that stakeholder mapping may be able to help us do more strategic things:
-
positioning our work with owners
-
advocating for access to stakeholders
-
empowering designers to ask challenging questions
-
choreographing design reviews to engage the right people
-
enabling for stakeholder participation in design and research
These aren’t strictly UX design activities, but they set the stage for success later.
There’s a term for these kinds of activities:

53. Groundwork
Groundwork, something that is done early that makes success possible later.
When I think back to that boardroom in Victoria I realize that we ended up doing a lot of
groundwork, even though it wasn’t part of our formal process.
Our formal design process revolved around Iterative prototyping
But behind the scenes we were advocating for regular design reviews with stakeholders, and
unfettered access to people with critical knowledge of business process, and multiple rounds
of usability testing.
SO maybe the biggest win for this method is that it enables more effective groundwork. And
seeing the stakeholder landscape early can help us pick the right battles.

54. Descriptive Prescriptive
Personas
Experience
M
aps
W
irefram
es
Pow
er/InterestM
atrix
Salience
M
odel
I want to make a larger point here about UX practice.
When it comes to UX deliverables we can imagine a continuum from descriptive to
prescriptive.
So many of our deliverables are focused on understanding and explaining users or systems
and, I think, fall to the left end of that continuum. Things like personas or experience maps
or wireframes.
We don't have many deliverables that impose a predefined framework or rules on our clients.
But you’ll notice that a lot of the examples of stakeholder mapping I showed at the beginning
of the talk fall to the right end of the continuum. After you’ve mapped your stakeholders,
these frameworks tell you how to approach them. They recommend specific strategies for
dealing with them.
And this is where I’m trying to land with our stakeholder mapping method.
I know I sometimes resist these methods because they’re reductive--they seem to
oversimplify things. As IAs and UX designers, we love the details.
I remember talking with a colleague, attending poster night at her first IA Summit, and she
noted that the elaborate diagrams with a baroque level of detail... these are like catnip for IAs.
They were drawn to them and really absorbed in the details, almost getting high off the little
boxes and arrows.
And maybe that’s why we abhor these 2x2 matrices. They seem so coarse and
unsophisticated.

55. Prescriptive methods make
for good groundwork.
These prescriptive methods make for good groundwork, because they tell the organization
how to behave. Remember our challenge is not about whether wireframes or a prototype are
better, it’s about access and empowerment of the design team.
So a method that a) analyzes stakeholder relationships, and b) says to the client “to address
this particular stakeholder arrangement you must do X” could help us be more effective
designers.

56. What’s Next?
So what’s next for this method?
Connecting the stakeholder elicitation workshop directly into the mapping exercise, probably
using a survey tool of some kind. That would allow for greater participation in this method.
More work on pattern analysis, probably done through more project retrospectives.
More work on identifying groundwork approaches to address particular risks.
TO SUM UP
Stakeholder mapping it’s a real thing.
We looked at some things that have been done. We thought there might be room for
something new.
We tried something.
It kind of worked, we learned a few things.
We will continue to apply it, with more rigour, to give us a strategic advantage on projects.
We would love your feedback, positive or negative.
If you want to try this, I have 20 print outs of the worksheet and instructions we used here at
the front.

57. @gsmith @nform

58. THANKS!