Stakeholders, Power, and Voice

By the end of this lesson, you will be able to...

• Map who is exposed to a system, who benefits, who can be harmed, and who can change the rules.

• Distinguish formal decision rights from practical power and from having a voice.

• Choose a participation and escalation path that can change a design instead of merely collecting opinions.

Idea in one sentence: A stakeholder map is useful only when it shows unequal exposure and power, then changes who gets heard, when, and with what authority.

Core Insight

In the previous lesson, a housing-support portal looked correct inside its component diagram. Consider Ana's application: it still failed because the outcome depended on a deadline, a contact channel, a caseworker metric, and an appeal path.

The city now wants to redesign the workflow. The product manager schedules a meeting and invites the people who normally appear in project documents:

• the portal team,
• the department director,
• the casework supervisor,
• and the vendor that sends text messages.

They call the meeting a stakeholder review. No applicants attend. No community organization is paid to participate. Caseworkers who close applications are invited, but they are told that the deadline is a policy question and cannot be discussed.

The team leaves with a polished list of concerns and no changed decision. This is not because the participants are careless. The meeting confused three different questions:

1. Who is affected by the system?
2. Who can influence its behavior?
3. Who has a meaningful way to be heard and obtain repair?

Those groups overlap, but they are not the same. A person can be heavily exposed to a system and have almost no power over it. An infrastructure vendor can have high technical influence while never meeting the people who bear the consequences. A person can be invited to speak and still have no voice if nobody must respond.

The Naive Stakeholder List

A quick stakeholder list often means “the people who bought, built, operate, or approved the product.” It is easy to make, and it is useful for assigning internal tasks. It is not enough for a sociotechnical review.

The narrow list for the housing portal might be:

department director -> product team -> casework supervisor -> messaging vendor

This list treats the system as an organization chart. It leaves out people who wait, depend on the result, absorb the cost of an error, or create informal repair work.

The first repair is to ask four questions about every possible group:

These dimensions prevent a common mistake: treating “stakeholder” as a synonym for “person invited to the meeting.”

Power Is More Than Job Title

Plain meaning:

Power is the ability to shape what the system does, what resources it receives, or what happens when it fails.

In this scenario:

• The director can approve a policy change and allocate staff.
• The product team can change the interface and queue states, but not the legal deadline.
• A caseworker can sometimes repair one application, but cannot change the performance metric.
• An applicant can report harm, but may not be able to delay closure or obtain a human review.
• A community organization may have little formal authority but enough trust and local knowledge to reveal patterns the dashboard misses.

Technical name:

Power is not a single rank. It is distributed across decision rights, resources, expertise, access to evidence, ability to exit, and the ability to make someone respond. A stakeholder with no title can still have leverage. A stakeholder with a title can lack practical control if budgets, contracts, or policy constraints sit elsewhere.

Voice is different again. Voice means that a person or group can communicate relevant experience in a channel that the decision process must consider. Voice becomes meaningful when there is a response obligation: someone records the concern, explains the decision, changes the design, or explains why it will not change.

An open microphone is not automatically voice. It may be only an opportunity to speak.

Build a Stakeholder-Power Map

Start with the decision, not with a generic list of names. The decision here is:

Should the portal automatically close an incomplete application after seven days, and what recovery path should exist?

Now map the groups that experience, shape, or repair that decision.

The map makes two omissions visible. The people most exposed to closure have the least agency. Community organizations have important evidence but no formal authority or compensation. Those are design facts, not just ethical observations.

A Worked Path: From Map to Participation Decision

Suppose the team is choosing among three redesigns:

1. Keep the seven-day closure rule and add a clearer reminder.
2. Add a grace period that caseworkers can grant, with a new status in the queue.
3. Replace automatic closure with a human contact attempt and an appeal route.

The team could ask every stakeholder to vote. That sounds fair, but a vote would hide the asymmetry: the director and vendor can implement changes, while applicants bear the result. Instead, move through the map step by step.

Step 1: Name the decision and the affected outcome

Write the decision in one sentence. “Improve the portal” is too vague. “Decide when an incomplete application closes and how an applicant recovers” identifies the rule, the state transition, and the consequence.

Step 2: Separate evidence from authority

Applicants and community organizations can provide evidence about missed messages, document access, and recovery effort. They do not need to approve the architecture for their evidence to matter.

Policy owners and supervisors hold authority to change deadlines, staffing, and escalation. Their participation must include a response obligation, not just attendance.

Step 3: Match participation to power and exposure

This is a design choice. The team is deciding who supplies evidence, who can challenge the model, who must answer, and who can change the system.

Step 4: Give the voice a route to action

For each concern, record:

concern -> evidence -> decision owner -> response deadline -> changed control or reason for rejection

For example:

Applicants miss reminders after changing numbers
-> 18 of 30 sampled cases had an inactive contact number
-> policy owner and service supervisor
-> response before the next launch review
-> add a contact-change path and pause closure until one human attempt

The system does not need to accept every request. It does need to make the decision and its owner visible. That is the difference between participation and a listening exercise.

What Performative Consultation Looks Like

Consultation becomes performative when the process displays inclusion without moving authority or changing the decision. Common signals include:

• feedback is requested after the deadline, metric, or contract is already fixed;
• only people with time, transport, language access, or organizational confidence can attend;
• the team collects quotes but publishes no response or decision log;
• a representative is treated as proof that an entire group has been heard;
• the burden of proposing a solution is placed on people who already bear the harm;
• “we heard you” is reported as an outcome even when no control changed.

The correction is not to promise total consensus. It is to define the smallest decision that the participation can still change. If nothing can change, say that before inviting people and do not label the meeting co-design.

Trade-offs and Limits

The central trade-off is clear: broader participation improves evidence, legitimacy, and the chance of finding hidden failure paths, but it costs time, money, translation, accessibility work, and coordination. Paying community participants may reduce short-term delivery speed while improving the quality of the model.

Participation does not eliminate disagreement. Applicants may want a longer grace period, caseworkers may need a bounded queue, and policy owners may face statutory deadlines. A stakeholder map cannot decide that conflict by itself.

It also cannot prove that every affected group has been found. People who avoid the system, cannot access it, or fear retaliation may be absent from the data. The boundary signal is therefore important: if exposure is high but agency and voice are low, treat the map as incomplete and add a discovery or appeal path before claiming legitimacy.

Common Confusions

Confusion: The buyer is the primary stakeholder

Why it is tempting: the buyer funds the system and signs the contract.

Better model: funding creates decision rights, not exclusive moral or operational relevance. People who receive the output, bear the risk, or repair failures belong in the map even when they never chose the system.

Confusion: Every stakeholder should have equal power

Why it is tempting: equal treatment sounds like fairness.

Better model: equal respect does not mean equal authority. Make asymmetries explicit, then give high-exposure groups stronger evidence, representation, protection, or appeal where the decision requires it.

Confusion: More feedback means more voice

Why it is tempting: surveys and comment boxes produce visible activity.

Better model: voice needs a channel, a response obligation, and a path to change or a reasoned rejection. Count changed decisions and repaired failures, not only responses collected.

Check Your Understanding

Check: The portal team invites ten successful applicants to a usability test. Nobody who had an application closed is invited. What is the main problem?

Think first, then reveal.

Answer: The sample overrepresents low-harm outcomes. People with the highest exposure to closure are missing, so the team may optimize convenience while failing to see recovery costs.

Check: A community organization can publish a report that embarrasses the department, but it cannot change the deadline or reopen a case. Does it have power?

Think first, then reveal.

Answer: It has informal agenda-setting and evidence power, but little direct decision power. The map should record both kinds instead of reducing power to job title.

Practice: Make the Map Change a Decision

Choose a real or realistic system: a school enrollment portal, workplace scheduling tool, benefits chatbot, or tenant-maintenance app. Pick one decision the system makes or structures.

Create a one-page review with:

1. the decision and outcome under review;
2. at least six stakeholder groups, including one group that is affected but not a regular user;
3. exposure, benefit or harm, practical agency, formal decision rights, and voice risk for each group;
4. one missing voice and the reason it is likely missing;
5. a participation move with a response deadline and named decision owner;
6. one change, one reasoned rejection, and one appeal or repair path.

Use this rubric:

• Boundary: the map includes people, rules, resources, and consequences, not only product roles.
• Asymmetry: exposure and power are shown separately; no one is treated as equally positioned by default.
• Action: participation can still change a concrete control, launch decision, metric, or repair path.
• Evidence: each important claim has a trace, interview, observation, or explicit uncertainty.
• Limits: the review names costs, missing groups, and what remains unresolved.

Resources

• [BOOK] Design Justice - Focus on who is centered, who participates, and how design processes redistribute power.
• [ARTICLE] Value Sensitive Design - Use the stakeholder and value investigation as a complement to the power map.
• [ARTICLE] Participatory Design - Compare participation as a design activity with consultation as information gathering.
• [BOOK] The Alignment Problem - Use its cases to notice what happens when system objectives and human interests diverge.

Key Takeaways

• Start with the decision and outcome, then map exposure, benefit or harm, agency, decision rights, and voice.
• Power includes control of rules, resources, evidence, exit, and response—not only organizational rank.
• A person can be invited to speak without having meaningful voice.
• Participation is useful when it can change a named decision or produce a reasoned rejection and repair path.
• Broader participation costs time and coordination, but a fast decision with missing high-exposure voices can create larger repair work later.