P4.01.1Value-sensitive designdesignresearch

Name the values and stakeholders involved before designing

Aliases: VSD · stakeholder analysis · value analysis

What it is

Value-sensitive design (VSD) treats "whose values does this product touch" as an input on par with functional requirements, enumerated at the concept stage. Values are anything that can be harmed: autonomy, privacy, safety, fairness, dignity, accessibility, trust. Stakeholders fall into three classes: direct (paying users), indirect (people affected without using the product — applicants scored by an algorithm they have no account for, family members swept up by a shared device's sensors, pedestrians recorded by dashcams), and excluded (people who cannot use the product at all because of device, language, disability, or connectivity constraints). The deliverable is not a slogan but a roster: which features could enhance or damage which values, falling on whom.

Why it happens

Values and stakeholders do not enter the design view on their own, because product problem statements are framed by whoever pays and whoever counts as the typical user. Indirect stakeholders appear in no dataset; unnamed, they do not exist. And an unnamed value can only surface as vague "the experience feels off," which cannot argue against metrics like retention or conversion that have names and dashboards. The roster turns the unnamed into something pointable-at: once a decision is identified as harming "an applicant's chance to contest a score," it stops being an optimization and becomes a trade-off that requires justification. Naming also assigns responsibility — what is not listed has no owner.

Studying it

VSD prescribes a tripartite investigation: conceptual analysis of the values at stake and their relations; empirical studies (interviews, observation, diary studies) of how different stakeholders actually experience those values; and technical investigation of how system properties (defaults, data models, notification policy) support or undermine them. Stakeholders are enumerated via stakeholder analysis and ranked by influence and affectedness. Methodological cautions: direct users are the easiest to recruit and the least complete sample; indirect stakeholders are often reachable only through community organizations and intermediaries. Value checklists are culturally bounded — entering a new market means re-enumerating, not translating, the list.

Where it stops holding

Value enumeration cannot be neutral: which values get listed is itself a judgment, and the boundaries of "safety" or "autonomy" differ across cultural traditions. The roster also does not adjudicate conflicts — identification makes a conflict visible, but the trade-off remains a separate decision. During exploratory phases with unstable direction, exhaustive enumeration costs more than it returns; scope to known high-risk surfaces (data collection, automated decisions, features for minors) and complete the list once direction settles.

Applying it

  • Fix two tables into the concept-review template: a value table (values touched, plausible harms) and a stakeholder table (direct / indirect / excluded, each with a contact channel).
  • Assign a named owner to every indirect stakeholder to speak for them at reviews; a stakeholder without an owner is effectively unregistered.
  • Make exclusion an explicit question: what device, language, ability, and connectivity does the feature assume, and what happens when one is missing?
  • Verify: sample three shipped features and check whether their value/stakeholder tables would have predicted the controversies that actually arrived; add missed categories to the template.

Related

  • Same group: P4.01.2 Record value conflicts instead of avoiding them · P4.01.3 Technical choices carry value judgments
  • Adjacent: P4.06 Participatory design · O1 Privacy principles
  • Search terms: value-sensitive design · stakeholder analysis · indirect stakeholders

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/P4.01.1