A school introduces an AI tool to help teachers notice students who may need support. The team calls the design “fair” because the model’s error rate is similar across several groups. A teacher asks whether students can challenge an alert. A parent asks who sees it. A student asks whether being flagged will follow them into another class. These are not peripheral concerns added after accuracy testing. They reveal different values embedded in the way the system makes predictions, shares them and gives people power to respond.
Value-Sensitive Design, or VSD, is a framework for bringing human values into the design of technology through connected conceptual, empirical and technical investigations. It asks what matters to people affected by a system, how those concerns appear in context, and how particular design choices support or obstruct them. This Concepts entry explains the framework’s mechanism and boundaries. The separate Methods & Measures entry on measuring value-sensitive design asks how to evaluate whether a project actually carried out its stated commitments.
Values enter through decisions, not labels
A value such as privacy can sound clear until a design team must decide who may access an alert, for how long and under what conditions. Autonomy can mean a student’s ability to understand a recommendation, a teacher’s discretion to override it, or a parent’s right to contest a record. Fairness can concern error distribution, participation in setting a policy, or the consequences of false alarms. Naming a value does not resolve these questions. VSD works by making the question visible early enough that a design decision can still change.
Friedman and colleagues describe VSD as an approach that considers human values throughout technology design rather than adding an ethical checklist at the end. Their framework joins conceptual investigation, empirical investigation and technical investigation in an iterative process. Conceptual work asks what a value means and whose interests count. Empirical work asks how people experience a system and its possible effects. Technical work asks what a system’s properties make possible or difficult. The layers inform one another: a classroom interview can change the value definition, while a prototype can reveal an impact no one anticipated during the first meeting.
The mechanism is not mysterious. Design decisions allocate permissions, information, defaults, timing and the ability to appeal. A notification that reaches one role but not another changes who can act. A default retention period changes who can be exposed later. A confidence display can reveal uncertainty or conceal it. The design makes some behaviors easier and others harder. VSD asks teams to examine those consequences as expressions of values rather than as neutral implementation details.
Friedman and Hendry call for moral and technical imagination in this work. Moral imagination helps people consider lives and effects beyond the immediate user story. Technical imagination asks what could be built differently. Neither is enough alone. A team may understand a harm but lack a way to alter the system, or may have a clever feature that addresses the wrong concern. VSD is valuable when these forms of reasoning meet in a concrete alternative that can be tested with affected people.
Conceptual investigation: what is at stake?
The first step is to identify direct and indirect stakeholders. The direct user of the school tool may be a teacher. Students are the people classified, and families may be affected by decisions that follow. Administrators, support staff and future teachers may also encounter the records. A focus only on the person clicking the interface would miss much of the ethical situation. The set of stakeholders is not fixed forever; it should be revised when a new use or consequence appears.
Conceptual investigation then asks what values mean in this setting. Privacy could concern limiting data collection, giving students notice, restricting sharing, or allowing deletion. Accountability could mean identifying who made a decision and what evidence was considered. Dignity could concern the language of a flag and whether a student is treated as a problem rather than as a person with context. These meanings need not collapse into one slogan. A value definition should be specific enough to guide an observable design choice.
Values may conflict. A system could show an alert to more people to improve timely support, while increasing exposure of sensitive information. It could keep records to audit bias, while prolonging privacy risk. The conflict should be documented rather than hidden behind a statement that all values were satisfied. Borning and Muller argue that VSD should be cautious about lists of supposedly universal values and should give stronger voice to participants and researchers’ own positions. This critique matters because the first version of a value map often reflects the team that had the power to draw it.
Conceptual work is not a vote in which the largest group automatically wins. Some stakeholders face greater exposure to harm while having less organizational influence. A student may not be able to refuse the system, and a teacher may not be able to alter the policy that governs it. The ethical question includes who can challenge a definition and who can change a decision. VSD can surface such power differences, but it cannot solve them through vocabulary alone.
Empirical investigation: learn from lived use
Once a team has a provisional value map, it needs to learn how the setting actually works. Interviews, observations, participatory workshops, surveys and prototype studies can reveal routines and consequences that designers did not imagine. A teacher may explain that an alert arrives during a lesson when there is no time to review it. A student may reveal that asking for help in front of classmates feels exposing. A parent may describe how an earlier label affected later expectations. Empirical work gives situated content to abstract values.
Empirical investigation should include people who are affected but not easily reached through the product’s ordinary user channel. Indirect stakeholders may not have accounts or seats in a planning meeting. A design team that interviews only paying clients can mistake institutional preference for the full set of human values. Participation also requires care: merely inviting someone to a workshop does not transfer decision-making power. People need to know which choices remain open, how their input will be used and what happens when the team disagrees.
Methods have limits. A small interview sample can reveal important possibilities but not how frequent each experience is. A survey can estimate reported preferences among its respondents but may miss what happens in practice. A prototype test can show how people use a feature in a limited setting, not all its long-term consequences. VSD does not eliminate those research limits. It makes them part of the design conversation, so a confident technical decision is not built on a thin reading of the people it affects.
Empirical work may challenge the original moral framing. The team might assume that students want every model explanation in technical detail, then learn that they first need to know who sees an alert and how to correct a mistake. That finding does not make technical explanation unimportant; it changes its place in the design. Iteration is the mechanism by which observed experience revises the problem statement, not merely a repeated round of polishing a feature that was already decided.
Technical investigation: values become system properties
Technical investigation examines the artifact itself. Which data fields are collected? Who can access them? Are alerts reversible? Can a false flag be corrected without leaving a permanent trace? How is uncertainty shown? What happens when the system fails? These questions connect ethical claims to architecture and interface behavior. A team that discusses privacy without considering logging and retention has not yet asked the technical question. A team that discusses autonomy without considering override and appeal has left the claim unfinished.
Technical work can be proactive, building a feature to support a value, or reactive, examining an existing system’s properties and redesigning them. In the school example, a proactive choice might separate a private support suggestion from an official record. A reactive investigation might discover that a dashboard exposes student labels to staff who do not need them, then narrow access. Each choice has tradeoffs. An audit trail might improve accountability while increasing retention. The design must specify which harm it addresses, what new risk it creates and how those effects will be checked.
Gerdes and Frandsen’s review of VSD technical investigations found that this part of the tripartite framework is often less developed than its conceptual or empirical discussion. Their sample of 54 theoretical and applied studies is evidence about a published literature, not a census of every product. Still, it sharpens the practical lesson: a workshop, value list or stakeholder map is not the same as a changed technical property. A value-sensitive project should be able to trace an important concern to a requirement, design alternative and implemented decision.
The technical mechanism is not a promise that code can solve politics. A system’s rules may be constrained by procurement, law, staffing, incentives and organizational authority. A developer can create an appeal button, but the institution must assign someone to review appeals fairly. A model may provide uncertainty estimates, but users need time and permission to act on them. VSD therefore concerns socio-technical systems: the artifact and the human arrangements that make it consequential.
Why iteration matters more than a linear checklist
The three investigations are often drawn as separate categories, but the most important learning can happen between them. Conceptual analysis proposes that contestability matters. Empirical research finds that students avoid contesting alerts because they fear being seen as uncooperative. Technical investigation reveals that the only appeal route is hidden in an administrator’s menu. The design team then revises both the value definition and the interface. A linear process that completes “ethics” before development would miss this feedback.
Winkler and Spiekermann reviewed methodological practices in VSD projects and identified gaps in how the full tripartite and iterative method was reported and enacted. The review does not show that iteration always produces better outcomes; it shows that claimed VSD practice and documented method can diverge. That gap is important for a design team: if the value analysis never changes a design decision, or if the artifact never leads the team to revisit a value tension, iteration may exist only in a diagram.
Feedback must also include the period after deployment. Users may find a new workaround, administrators may expand the system’s purpose, and data collected for support may later be used for discipline. A VSD project that stops at launch cannot observe all downstream changes. It can, however, design channels for contestation, monitoring and revision. Such channels are not evidence that the system is ethical. They are mechanisms that allow new evidence to alter it.
Sometimes the best revision is not a feature. A team might conclude that a proposed classification is too unreliable or that the institution lacks a fair appeal process. Delaying or declining deployment can be a value-sensitive choice. VSD is often described as a method for improving technology, but its principles should also permit a reasoned decision that a particular technology does not belong in a given setting.
AI systems expose additional tensions
AI projects make VSD especially demanding because model behavior can change with training data, prompts, updates and use patterns. A value such as fairness cannot be assigned to the model in the abstract. It must be examined across who provides data, who receives predictions, who can inspect errors and who bears consequences. A value such as autonomy may concern whether users understand an AI suggestion, whether they can reject it, and whether the surrounding institution respects that rejection.
Sadek, Calvo and Mougenot’s critical review of value-sensitive AI design processes examines comprehensiveness, guidance and methodological value-sensitivity. It shows why a process can mention responsible AI while offering little practical direction for discovering values or changing design. It does not establish that following one preferred framework guarantees fair outcomes. Its contribution is a set of criteria for asking whether design processes meaningfully support the work they claim to support.
Generative systems create a further distinction between intended design and emergent interaction. A team may design an assistant to be supportive, yet users may interpret it as an authority or companion. An automated summary may save time while making a contested judgment look settled. The value-sensitive question is not simply whether the model passes a performance benchmark. It is how the system positions people to question, override or understand its output, and whose interpretation of the interaction receives priority.
AI systems also make ownership of tradeoffs harder to see. A product team may rely on a third-party model, a school may choose its own policies, and a teacher may act on a recommendation. Each actor controls some choices and not others. VSD needs a trace of responsibility across that chain. Without it, “human values” becomes a broad aspiration that no one is empowered to implement.
What the evidence does not show
The cited sources do not show that using VSD automatically makes a technology ethical, safe, fair or beneficial. A value list is not evidence that stakeholders were heard. A workshop is not evidence that participants shaped a decision. A feature that embodies one value can compromise another. Published reviews identify method gaps in their samples but cannot prove that every unpublished project has the same weaknesses.
VSD does not supply a universal ranking of values. Privacy, accountability, dignity, autonomy and welfare can conflict, and different affected groups can reasonably interpret them differently. The framework helps surface and investigate these tensions; it cannot make a moral disagreement disappear. It also cannot replace legal duties, clinical judgment, democratic governance or the organizational authority needed to change a product’s use.
The evidence does not establish a single score for “value sensitivity,” a guarantee of downstream outcomes or a way to infer ethics from documentation alone. A project may be well documented and still harm people. Another may be poorly documented yet contain a useful design choice. To assess a claim that VSD improved an outcome, one must examine what changed, whose experience changed and what alternative explanations remain. That assessment belongs to the separate methods entry and to context-specific evaluation.
Using the framework without overclaiming
A practical VSD conversation can begin with four questions: Who is affected, including people who never touch the interface? Which values are at stake, and what do they mean here? Which design choices distribute benefits, burdens and control? What evidence would make us revise those choices? These questions are an Institute synthesis of the cited framework and critiques, not a certified scoring tool. They are useful because each directs attention to a possible decision.
Return to the school tool. Similar error rates are relevant, but they do not answer who sees an alert, how a student challenges it, or whether the label follows them. A value-sensitive process might alter access controls, design a clear correction route, delay a deployment or reconsider the purpose of the tool. It might also discover disagreements it cannot settle alone and bring them to the institution that has authority over policy. In that sense VSD is a disciplined way to connect ethical concern to design and governance, while remaining honest about what design can and cannot do.
Related Learning Hub entries
Research references
- Friedman, B., Kahn, P. H., Jr., & Borning, A. (2008). Value sensitive design and information systems. In K. E. Himma & H. T. Tavani (Eds.), The Handbook of Information and Computer Ethics. Wiley. View source
- Friedman, B., & Hendry, D. G. (2019). Value Sensitive Design: Shaping Technology with Moral Imagination. MIT Press. View source
- Borning, A., & Muller, M. (2012). Next steps for value sensitive design. Proceedings of CHI 2012. View source
- Winkler, T., & Spiekermann, S. (2021). Twenty years of value sensitive design: A review of methodological practices in VSD projects. Ethics and Information Technology, 23, 17–21. View source
- Gerdes, A., & Frandsen, T. F. (2023). A systematic review of almost three decades of value sensitive design (VSD): What happened to the technical investigations? Ethics and Information Technology, 25, 26. View source
- Sadek, M., Calvo, R. A., & Mougenot, C. (2024). Designing value-sensitive AI: A critical review and recommendations for socio-technical design processes. AI and Ethics, 4, 949–967. View source