1 Background

In technical education, students might pursue design and engineering projects in a largely value-neutral manner. However, technical projects, along with the tools and technologies they produce, are not value-neutral. To the contrary, tools and technologies make some goals easier to obtain and others harder, support some human experiences and values but not others, lead to unanticipated value tensions, and so forth. Thus, in general, tools and technologies unavoidably shape human experience. At the same time, when a technology is introduced into society, people and institutions adapt, leading to new practices, norms, and policies. These processes, in turn, lead to new technologies, and so forth, on and on.

Tech Policy: Tools, Technology, and Policy

The case studies work with broad definitions of policy, tool, and technology. From the Oxford English Dictionary:

Policy (noun). A principle or course of action adopted or proposed as desirable, advantageous, or expedient; esp. one formally advocated by a government, political party, etc. (“Policy,” n.d., para. 4)

The case studies, consistent with this definition, take a broad view of policy, which is often linked to a particular setting or context, characterized by natural, social, or technical dimensions. The following are different forms of policy, ranging from the formal and institutional, to the informal and personal:

international laws • local laws • government or industrial regulations • tax systems • medical informed consent • licensing agreements • incentive systems • terms of use • codes of conduct • standards • guidelines and style guides • wilderness travel protocols • sexual consent • family rules • rules among friends (norms) • …

Similarly, the case studies use a broad definition of technology. From the Oxford English Dictionary:

Technology (noun). a. The branch of knowledge dealing with the mechanical arts and applied sciences … ; b. The application of such knowledge for practical purposes … c. The product of such application …(“Technology,” n.d., para. 4)

With this definition, we see that technology is knowledge, which when applied leads to a product, often a tool, artifact, or device, which a person might hold in her hand. Technology also includes the hardware and software that surround the places where human beings are born, dwell, go to school, work, recreate, worship, retire, die, and so forth. The built environment shapes human experience and action. Indeed, the relationship between human beings and technology is deeply interactional, one shaping the other and vice versa:

“We encounter the deep questions of design when we recognize that in designing tools we are designing ways of being.” (Winograd and Flores, 1986, p. xi)

Technology can be expansive infrastructure, which under normal circumstances we take for granted and is often difficult to change, such as the power grid or software foundations needed for the Internet. Often tools work together with infrastructure. Electric cars, for example, to be charged, generally need the power grid. But, millions of electric cars, all seeking power in an uncoordinated manner, might lead to instabilities in the existing infrastructure.

The distinction between “tools” and “technology” is nuanced. Accordingly, we’ll use the phrase tools and technology to refer to the products that result from the application of scientific knowledge. Depending on the context, we will use one word or the other, clarifying the intended meaning when precision is required.

In addition, we will consider policy, also a product of knowledge, to be a special kind of tool, as policies afford or constrain human action in ways that are similar to the effects of a tool or technology. With all tools, technologies, and policies we can ask these kinds of questions:

• Will a human action be constrained or made impossible?
• Will a new human action become possible?
• Will a human action be supported or perhaps amplified?
• How, or in what circumstances, might a tool become harmful, and, in the extreme even become a weapon. What policies might govern inappropriate use or address harms that might reasonably be expected to occur?

Finally, the phrase “tech policy” shows that technologies and policies are often in relation to each other. But, the relationship can be varied and nuanced, as seen in these broad examples:

• Reactive policy-making. After a technology is developed, or likely to be imminently developed, a policy might be designed to reactively prohibit its use for particular purposes. Examples: Prohibitions against fully autonomous weapon systems, limits on how facial recognition technologies can be deployed.
• Proactive policy-making. A policy might be developed proactively to fuel innovation of a technology for particular purposes. Examples: Higher gas mileage targets for vehicle fleets, certification of autonomous drone-flying in remote rural areas.
• Innovative policy-workarounds. Technology might be designed to creatively work around an approved standard of limits and requirements. Examples: Designing high-performance bicycles such that they conform to Olympic regulations, designing investment strategies that avoid taxation, developing design processes that strictly satisfy regulations while leading to more rapid product development.
• Policy-making for technical innovation. Prior to the development of a technology, or contemporaneously, entrepreneurs might lobby for the development of policy favorable to their project. Example: Changing the laws related to pet sitting to pave the way for a new sharing-economy businesses.
• Policy-making as political response. The invention of a new technology might lead to public or corporate demands for a new policy to govern its use. Examples: Use of AI in making hiring decisions, governance of Internet of Things in domestic settings.

The key point is that engineering processes can be strengthened by considering both technical requirements and policy requirements within design processes.

Learning Objectives

Given this introduction to policy, tools, and technology, the overarching learning aim for the case studies is:

To develop student’s knowledge and skills for how technology and policy go hand-in-hand, with each shaping the other.

This learning aim is met by positioning students to design solutions to carefully crafted design prompts. The prompts are framed so that students engage both policy and technical elements within a particular theme.

In each case study, students are guided through a design process drawing on four common methods from value sensitive design (Friedman, Hendry, & Borning, 2017; Friedman & Hendry, 2019). After developing experience with a case study, students should be able to adapt and incorporate these methods into their own projects.

The case studies are “modular” and are intended to be incorporated into technical classes, that is, classes where students are learning to design and implement solutions to information or engineering problems. Students learn to ask and engage such questions as:

• What is the sociotechnical context in which a target technology will be used?
• Who are the direct and indirect stakeholders of the target technology?
• What values might stakeholders hold and what values might be implicated by the target technology?
• What value tensions emerge and how might they be addressed?
• What policy elements exist, or might be invented, in a sociotechnical context?
• How might those policy elements afford or constrain technical features and development?
• How might the policy elements and technological features work together to meet engineering and/or policy requirements?

To engage the above questions and to develop familiarity of these concepts, students learn to employ specific methods from value sensitive design.

Case Study Format and Instructor Notes

Going beyond analysis and critique, the case studies are design-oriented, that is, students are positioned to design solutions to problems and to critically reflect on the sociotechnical context. Each of the case studies comprise the following:

1. Background material, which introduces the sociotechnical context and some key tech policy questions.
2. Suggested design process, which introduces the design situation and presents students with a broad problem and then presents a series of steps that scaffold students’ engagement with the design situation.
3. Reflective prompts and exercises, which prompt students to critically reflect on process and outcomes of the case study.

In addition, each case study includes instructor notes and a bibliography.

BASE FORMAT. The case studies are presented with the assumption that they will be delivered as a 110-minute class activity. That said, the case studies are intended to be revised for different pedagogical settings and goals. They have been used in these settings, among others:

• A single activity in a 50-minute class (150 first and second year undergraduate students in Informatics)
• A single 3-hour studio project (newly admitted graduate students in a professional masters degree)
• A 5-hour project, begun in class and completed outside of class (150 first and second year undergraduate students in Informatics)
• A 10-15 hour project, completed over two 3-hour studio sessions and outside-class work (fourth year undergraduate students in Informatics).

PEDAGOGICAL COMMITMENTS. The case studies make the following broad pedagogical commitments:

• Action, then reflection. Following Donald Schön’s theory of professional practice, the case studies prompt students to design and to then reflect on their process and products (Schön, 1990). To address the intentional ambiguity of the problem brief, students find and frame their own specific problem, often prior to fully understanding the issues that underlie the problem brief. Students’ understanding of the problem develops by solving it. Then, in the process of engaging the problem, and at the end, students are prompted to critically reflect on their work.
• Work concretely. Students develop a concrete solution, with both technical and policy requirements. The solution is typically represented through a written scenario along with sketches and idea maps.
• Exposure to method, not depth. The case studies introduce methods and ways of thinking about tech policy, largely through stakeholders and values. The emphasis is on exposing students to multiple methods linked together in simplified a design process rather than focusing in-depth on a single method.
• Progress, not perfection. Students work with incomplete information and within a simplified process. Seeking to avoid the paralyzing effects of “perfection,” and following value sensitive design, the case studies prompt students to make meaningful progress.

INSTRUCTOR NEEDS. For instructors, the case studies are intended to be responsive to a variety of educational settings and formats, as follows:

• Adaptability. The format for the case studies is flexible and general. Instructors might focus on particular topics or extend the case studies in new directions. Instructors, in addition, might use or appropriate the format to represent new or emerging topics in tech policy.
• Depth. The case studies rest on research base that might motivate and catalyze a sustained research and design project. The case studies offer theoretical constructs and provide a body of examples.
• Simplicity. The case studies are reviewable in about 30 minutes and are structured so that they can be readily revised.
• Topical appeal. The case studies are crafted to be of interest to a broad spectrum of learners. While the topics are of immediate public interest, the underlying issues are likely to be with us for many years to come.