(From Kim’s 11/16 conference talk at UI21, posted to uie.com’s All You Can Learn section, link here)
As UXers, we are often concerned about stakeholder behavior—which we can shape through our behavior towards them and our project
We want to maximize our influence on their behavior
We need to design our stakeholders’s experience of us:
- Identify “users” and roles in the project
- Understand & design for the org’s context and culture
- Understand & design for them as individuals—where are they in their understanding of design and this project etc
1. Roles
Stakeholder
- Generally not well-defined
- Person who signs off on Jira stories?
- Person with an opinion?
- Doesn’t set up any clear expectations or responsibilities
RACI model
- Responsible for doing the work
- Usually prod/design/dev trio, may include supporting team
- Approves the work/accountable for the outcome
- In reality, usually multiple people—and shared accountability is tricky
- Their feedback is binding
- Consulted because they are experts
- Most “stakeholders” fall under this category
- Their feedback is non-binding
- Informed because understanding the plan is important to their jobs
- Feedback is not necessary
- May try to self-appoint themselves as stakeholders
- Sometimes an O is added for omitted—to avoid bottlenecks in cultures that stress decentralized, org-wide decision making
Kim suggests negotiating this at the project’s kickoff and provides an example:
- The negotiation here often centers around the R and A designations
- Helps to do this as a group effort so it’s more transparent to everyone why and how the designations apply
- You might want to set up the meeting with explicit mention of the decisions to be made at it to make sure the correct people attend
2. Context
The org’s culture
- Values
- How decisions get made
- What process feels ok
- What arguments do we value/how can we be persuasive in this context
- Kim suggests the book Diagnosing and Changing Organizational Culture
- Kim has evolved a competing values framework:
- The Dynamic range refers to type of planning flexibility
- The External range refers to where the org thinks the expertise lies
- Here, External also refers to user interviews/testing etc
This leads to 4 decision styles:
- Adhocracy—dynamic, external
- Values flexibility, external knowledge
- Tends towards a Lean UX approach
- Challenge is that the wheel can get reinvented time after time
- Values white boarding, user feedback, loose processes and constantly changing informal RACI—nothing too structured or “corporate” seeming
- Clan—dynamic, internal
- Values internal expertise and involvement
- Challenge can be that everyone feels like a stakeholder & decisions can get revisited based on who’s at meetings—something of a hive-mind orientation
- Values UX as facilitator (not expert), lots of team involvement, collaboration, consider CAIRO
- Hierarchy—stable, internal
- Values expertise, risk reduction via processes and tools, deliverables and style guides, RACI
- Challenge is that there’s always a bigger boss, decisions can get overruled, your process really needs to be “blessed” by the powers that be
- Market—stable, external
- Values maps and data (think Google)
- Challenge can be the user gets lost to the metrics
- Values rigors & science, quantitative data, risk reduction, RACI for speed
3. Individual behaviors
Stakeholders have limited time, which can lead to:
- Being uninformed or forgetful
- Good to always give a quick recap/update
- Not likely to use your tools (like Jira), so published does not equal communicated. Communication has 2 parts:
- Giving requirements/feedback that aren’t what you need
- You’re going to get unwanted feedback
- Don’t take it personally
- Accept what’s given & find value in it
- Follow up with what you heard & how you responded to it
- Ask for the feedback you do need—be explicit!
- Set up what you hope this design/feature accomplishes, and then focus them on the most valuable feedback
Stakeholders also bring expertise and ideas
- Ego can become involved
- Anxiety about whether you “get it”
Stakeholders are responsible for metrics
- Anxiety can lead to swoop & poop
- Keep stakeholders informed to mitigate this
- Try to manage and anticipate their anxieties—stakeholder interviews can really help suss this out
- They feel heard
- You build relationships, set expectations and start getting buy-in
- You learn critical things
- Ask who the hidden stakeholders are that you don’t know about but who could throw the project off track so you can interview them
- Do this even if you’re in house
- Say “I want to know what you think” and stroke their ego without looking dumb
- Basic questions:
- Further Qs:
- Follow up your interviews by reflecting back your understanding of their goals and needs, and share a plan w opportunities for involvement
Some stakeholders might not “get” the importance of UX design
- They might look at a focus on design as a loss of focus on their area of expertise
- We’ve got the help them see the value:
- Bringing in user testing results, analytics and metrics etc to help bolster denial
Some stakeholders just don’t want to engage via meetings
- Find another way to engage them. Tailor the experience to be more of what they want/expect
Conclusions
Maximize what matters in project plans and arguments:
- Involvement
- Risk reduction & repeatability
- Data & more data
- Quick learning
Focus on getting the feedback you need (while selectively ignoring feedback you don’t)
Prevent & manage stakeholder anxiety via high quality, thought-out interviews
Communicate proactively in the ways that work for your stakeholders
Reflect back that you understand their goals and needs
About Kim (from Twitter): Author of Designing for the Digital Age. Design & product exec. Consultant. Researcher. Designer. Teacher. Wildlife photographer.
