Social Impact Statements:

Engaging Public Participation in Information Technology Design

Ben Shneiderman* and Anne Rose

Human Computer Interaction Laboratory
Center for Automation Research,
Department of Computer Science* &
Institute for System Research*
University of Maryland, College Park, MD 20742
{ben, rose}

"The real question before us lies here: do these instruments further life and enhance its values, or not?" - Mumford (1934) p. 318


Computers have become an integral part of our everyday lives. Banks, airlines, motor vehicle administrations, police departments, Social Security, and the Internal Revenue Service all depend on computers. From their introduction, people have questioned the impact computers will have on society. We believe it is our responsibility as system designers to achieve organizational goals while serving human needs and protecting individual rights. The proposed Social Impact Statements (Shneiderman, 1990) would identify the impacts of information systems on direct and indirect users, who may be employees or the public. This paper proposes a framework for implementing Social Impact Statements for federal and local government agencies and regulated industries, with optional participation by the other privately held corporations. A Social Impact Statement should describe the new system and its benefits, acknowledge concerns and potential barriers, outline the development process, and address fundamental principles. Examples from our work with the Maryland Department of Juvenile Justice are offered.

KEYWORDS: Social impact, Public participation, Design


From its inception, people have been pondering the impact computers will have on society and on the image individuals have of themselves (Wiener, 1954; Sterling, 1974). Many analysts believe the social repercussions of computers may be as potent as those of the automobile and the telephone (Kling, 1980; Dunlop & Kling, 1991; Huff & Finholt, 1994).

Information systems are increasingly required to manage the government, utilities, and public services that citizens in modern societies have come to expect. But many critics have pointed out the negative effects of modern technologies: "technological evolution is leading to something new: a worldwide interlocked monolithic, technical-political web of unprecedented negative implications. And it is surely creating terrible and possibly catastrophic impacts on the earth" (Mander, 1991).

This negative view does not help in shaping more effective technology or preventing damage from technology failures. Constructive criticism and guidelines for design could be helpful in reversing the long history of disruptions in telephone, banking, or charge card systems, dissatisfaction with privacy protection or incorrect credit histories, dislocation through deskilling or layoffs, and deaths from flawed medical instruments. While guarantees of perfection are not possible, we believe that policies and processes can be developed that will more often lead to satisfying outcomes.

This hopeful stance was part of a larger argument about taking responsibility for shaping the future (Shneiderman, 1990). The Declaration of Responsibility stated that: "We, the researchers, designers, managers, implementers, testers, and trainers of user interfaces and information systems, recognize the powerful influence of our science and technology. Therefore we commit ourselves to studying ways to enable users to accomplish their personal and organizational goals while pursuing higher societal goals and serving human needs."

The second part of the Declaration proposed writing a Social Impact Statement (SIS), similar to an Environmental Impact Statement (Battle, Fischman, & Squillace, 1994). The goal is a high quality system whose design is discussed early and widely, thereby uncovering concerns and enabling stakeholders to openly state their positions. Such open discussions might improve quality which should lead to increased system acceptance. Of course there is the danger that these discussions will elevate fears or force designers to make unreasonable compromises, but these risks seem reasonable in a well-managed organization. The practicality of writing SISs was addressed by Huff (1995) who used them as a teaching tool.

This paper focuses on SISs as a tool to engage public participation in information technology design. First, we outline a framework for implementing a SIS:

1. Preparation

2. Evaluation

3. Enforcement

and then present a list of Social Impact Issues:

1. Describe the new system and its benefits.

1.1 Convey the high level goals of the new system.

1.2 Define the stakeholders.

1.3 Identify specific benefits.

2. Acknowledge concerns and potential barriers.

2.1 Anticipate changes in job functions and potential layoffs.

2.2 Address security and privacy issues.

2.3 Avoid potential biases.

2.4 Recognize needs for more staff, training, and hardware.

2.5 Propose plan for backups of data and equipment.

3. Outline the development process.

3.1 Present an estimated project schedule.

3.2 Propose process for making decisions.

3.3 Discuss expectations of how stakeholders will be involved.

3.4 Outline plan for migrating to the new system.

3.5 Describe plan for measuring the success of the new system.

4. Address fundamental principles.

4.1 Weigh individual rights vs. societal benefits.

4.2 Assess trade-offs between centralization and decentralization.

4.3 Preserve democratic principles.

4.4 Ensure diverse access.

4.5 Promote simplicity and preserve what works.


We propose a three stage framework for implementing a SIS. First, the SIS is prepared by system designers within the organization (or contracted by the organization), then presented to the stakeholders and the appropriate review panel for evaluation. Once approved, it must be enforced. Our goals are to encourage maximum participation in the review process by structuring the document, limiting its size, and controlling its complexity.

1. Preparation

The SIS should be produced early enough in the development process to influence the project schedule, system requirements, and the budget. It should be developed by the system design team which may include end users, managers, internal or external software developers, and possibly clients. Even for complex systems, the SIS should be of a size and complexity that it is understandable by users with relevant background. Some practical alternatives are to focus on those issues that seem the most dangerous or those that seem key to the system's success.

2. Evaluation

After the SIS is written, it is evaluated by the appropriate review panel plus management, other designers, end users, and anyone else who will be impacted by the proposed system. Potential review panels include federal government units (e.g. General Accounting Organization, Office Personnel Management), state legislatures, regulatory agencies (e.g. SEC, FAA, FCC), professional societies, and labor unions (Table 1).

OrganizationReview Panel
Government agencies

(e.g. IRS, Social Security)

Inspector general, GAO, OPM
State government agencies

(e.g. motor vehicles, courts)

State legislative bodies
Public utilities

(e.g. phone, electricity)

Review boards
Regulated industries

(e.g. banking, airlines)

Regulatory agencies

(e.g. SEC, FAA, FCC)

Commercial industry (optional)

(e.g. Microsoft, IBM)

Board of directors, management
Research groups (optional)

(e.g. universities, R&D labs)

Professional organizations

(e.g. ACM, IEEE)

Table 1. Organizations and appropriate Review Panels

The review panel would receive the written report, hold public hearings, and request modifications. A group of knowledgeable authorities might be assembled for consultation. Private citizen groups would also be given the opportunity to present their concerns and suggest alternatives (Wurth, 1992).

3. Enforcement

Once the SIS is adopted, it must be enforced. A SIS serves to document the "intentions" of the new system and the stakeholders need to see those "intentions" backed up by actions. Typically, the review panel is the proper authority for enforcement. There needs to be a recognized cost to the organization for not adhering to the SIS.


We are working with the Maryland Department of Juvenile Justice (DJJ) on redesigning their information system, ISYS (Information System for Youth Services). ISYS is a terminal-based system used by approximately 600 workers to support the processing of 50,000 juvenile case referrals per year. The next generation system, NISYS, will run on PCs in a windows environment.

The NISYS redesign effort has raised several social impact issues. Who should be allowed to see a juvenile's case history? How will the handling of the youths be effected? How will jobs be changed? As the user interface designers, it has been our responsibility to consider the impact of our designs on DJJ, the citizens of Maryland, and the youthÕs served. The executive staff of DJJ will be responsible for reviewing and accepting our designs, and finally for enforcing them. By offering examples related to our work, we hope to inspire others to consider the impacts of their designs.


A SIS should discuss the effects a new system will have both within the organization and on society at large:

describe the new system and its benefits,

acknowledge concerns and potential barriers,

outline the development process, and

address fundamental principles.

We recognize that the issues discussed are not complete, rather they are meant to prompt insightful dialogue about the contents. It is difficult, if not impossible, to enumerate all of the potential impacts a new system. To help in this effort, Markus (1984) defines a framework that identifies the potential impacts that different kinds of systems are likely to have.

1. Describe the new system and its benefits.

A SIS should begin by describing the proposed system and its goals. This includes identifying who will be impacted and specifying the benefits they will receive.

1.1 Convey the high level goals of the new system.

In order to be effective evaluators, stakeholders need to understand the purpose of the new system. A brief system description should be provided and the goals should be enumerated. The goals may range from reducing costs to improving worker morale to meeting new legislative requirements.

DJJ: The next generation ISYS, NISYS, will be an integrated software system designed to support juvenile case tracking for DJJ operations. The primary goal is to increase the availability of staff to serve the youths and their families by reducing the time that front-line workers spend on administrative tasks, improving the quality of decisions, and the timeliness and accuracy of the data. A secondary goal is to improve the communication of DJJ personnel across divisions.

1.2 Define the stakeholders.

A stakeholder is anyone who will be affected, directly or indirectly, by the new system like the end users, the software staff, and the organization's clients. Those interacting directly with the system are considered primary stakeholders; secondary stakeholders interact indirectly. A motor vehicle licensing officer using a computer system is considered a primary stakeholder while the driver applicant is a secondary stakeholder. This classification does not reflect the degree to which the stakeholder is impacted. For example, incorrect information might cause the applicant's license request to be rejected. Explicitly defining the stakeholders alerts designers to unanticipated impacts which may be biased towards certain stakeholders (Friedman & Nissenbaum, 1995).

DJJ: For NISYS, the primary stakeholders include the DJJ personnel who will use the system, such as the case managers and supervisors, and the MIS staff that will support the new system. The secondary stakeholders include the youths and their families, the victims, other state agencies, and the citizens of Maryland. The information contained in NISYS will directly influence how DJJ interacts with the youths.

1.3 Identify specific benefits.

"A critical factor for successful implementation of any innovation is that its benefits be construed as benefits by the potential adopters (Kaplan, 1994)." The benefits may include reduced costs, faster performance, shorter learning times, reduced errors, and increased user satisfaction and they differ by stakeholder. For example, an organization may be interested in reducing costs while employees may be more interested in reducing the workload. In order to motivate all stakeholders, the potential benefits for each must be described. The "benefits to the organization as a whole may not be sufficient motivation (Kaplan, 1994)."

DJJ: As an organization, DJJ will benefit from NISYS's ability to gather the data needed to obtain funding from the state and federal legislation in a timely fashion. NISYS will reduce the time front-line workers spend on administrative tasks by automatically generating required letters and reports. Most importantly NISYS will allow workers to focus more of their time and attention to working with the youths and their families in an attempt to reduce the rate of recidivism in Maryland.

2. Acknowledge concerns and potential barriers.

Identifying potential problems and concerns early in the development process allows an organization to manage them more effectively and minimize harmful rumors. Open and honest discussion about these problems benefits all stakeholders.

2.1 Anticipate changes in job functions and potential layoffs.

Change is a major cause of stress because it causes uncertainty. Using the SIS to describe anticipated changes can help reduce speculation and fear plus it allows an organization to manage them proactively (Kaplan, 1994). Stakeholders are most concerned with negative impacts such as layoffs, demotions, decreased skill requirements, and potential health problems. However, not all change is bad. Some positive changes may include enlarged job roles, new employment opportunities, increased wages, and flexible working arrangements (Ralls, 1994). It is hard to guess how some changes will impact an organization. Marcus (1984) discusses how changes in work flow can affect communication, socialization (involvement vs. isolation), and loyalties.

Today, job security is a major concern. When considering layoffs, organizations should weigh the consequences both to society and to individuals. Sterling (1974) points out that the cost of finding employment for those laid off is met by society not the organization and there is no way to measure the loss to individuals who are forced into less satisfactory employment. Iacono and Kling (1991) illustrates this point with the example of long distance operators whose jobs became less satisfying because their jobs became more automated and required less skill.

DJJ: In several offices, case referrals are being entered into ISYS by clerical staff. The NISYS design team is investigating techniques for facilitating electronic data entry. Some possibilities include scanning in the case referrals or having the police departments transfer them electronically. Both these techniques would drastically reduce the role of the clerical staff, who might be trained as case workers or as administrative assistants.

2.2 Address security and privacy issues.

Before computers, it was easier to physically lock away and secure information. Today, information can be collected and misused without ever violating physical barriers (Ladd, 1991). There are several measures that can be taken to secure electronic data including isolating computers (no network access), isolating networks (no internet access), requiring passwords, encryption protection, and monitoring logins. The method chosen should be appropriate to the criticality and confidentiality of the data.

Information systems should only collect the data needed. To apply for a driver's license, an applicant should not have to provide their annual income. Storage space has become increasingly affordable so more organizations are maintaining huge databases, often containing irrelevant information. An organization's desire to collect data about its clients or employees may be in conflict with an individual's right to privacy. One compromise is to store aggregate data (e.g. average number of logins per day for all employees) rather than individual data (e.g. number of times John logged into system).

A conflicting issue is accountability. Users should be responsible for their actions. The question is how to do this without violating their privacy. One approach is to keep a log of changes and when they were made so authorship is not as important. A user's identity would only be recorded for critical functions, like deleting a record.

DJJ: Since the juvenile data, especially the medical information, is confidential, there is an ongoing discussion of whether or not NISYS should be connected to outside networks. DJJ is trying to decide whether or not the benefits of network access outweigh the potential security risk. Another discussion is about what information should be recorded for each youth. The information necessary depends primarily on how the case is handled. If a youth is never placed in a DJJ facility, does medical information need to be collected?

2.3 Avoid potential biases.

Most system designs contain biases, both intentional and unintentional, but well-designed systems can limit these biases (Friedman and Nissenbaum, 1995). Functionality may be biased toward select groups of stakeholders, certain data may foster biased judgments, and some display techniques may encourage hasty decisions. For instance, an airlines reservations systems showed clear bias by always putting one airline's flights first. Unfortunately, it is not possible to avoid all biases, but thoughtful designs can minimize them.

DJJ: There are several sources of potential bias with respect to how a youth is treated. For example, who should know if a youth is HIV positive? The medical staff needs to know to treat the youth but do the cases workers need to know? Should the victim that was attacked be told? Also, what should happen to cases that are found not guilty? Should they still appear on the youth's record? If so, aren't they a source of bias? Also, the youth records naturally focus on negative behavior, but shouldn't equal attention be given to positive behavior (e.g., getting a job or staying drug free)?

2.4 Recognize needs for more staff, training, and hardware.

A successful system requires more than functioning software. Additional software staff may be needed, users may require formal training, and more hardware may be required to provide adequate access. Inadequate training and education are typical reasons new systems do not achieve their potential. ÒManagers in too many organizations still perceive people and technology as substitutes, rather than complements. They invest in technology, but too often neglect to invest in the people who operate and use the technology (Ralls, 1994)."

DJJ: The failure of ISYS is due in large part to the lack of machines and inadequate training. For NISYS, DJJ is planning on significantly increasing the number of machines. Additional MIS staff may be required to handle the increase maintenance responsibilities. Formal training is another key especially since NISYS is expected to run in a windows environment and most DJJ employees have little experience, if any, in a windows environment.

2.5 Propose plan for backups of data and equipment.

Unfortunately, all systems have the potential to fail. These failures can cause loss of business and productivity or possibly catastrophes resulting in loss of life. Organizations have the moral responsibility to take the steps necessary to minimize the impact these failures have on individuals and on society in general. A standard practice to protect data is to back it up periodically. For critical systems, like air traffic control systems, a backup system should be in place.

DJJ: Procedures to perform routine backups to protect against data loss will be needed. In case of a long term failure, DJJ should also have a backup paper system in place so case processing can continue. A youth's processing should continue even when the system fails.

3. Outline the development process.

The development process can have a significant impact on an organization. Work routines are disturbed, critical decisions need to be made, and training may be required. Outlining the process allows everyone involved to anticipate disruptions and plan accordingly.

3.1 Present an estimated project schedule.

The project schedule should outline the basic development stages, such as requirements generation, design, and implementation, and estimate how long each will take. The idea is to provide the stakeholders with a rough idea of what to expect and when. Keeping the stakeholders abreast of what is happening enhances their satisfaction with the entire process.

DJJ: The NISYS project is currently in the requirements generation and early design phase. The Request for Proposals (RFP) is scheduled to be ready by July 1, 1996. Once a contract is awarded, it is anticipated that it will be two years until initial product roll out.

3.2 Propose process for making decisions.

A component of any development process is making decisions. Hardware needs to be chosen, functionality needs to be decided on, and the user interface needs to be designed. A SIS should outline the process for obtaining input and making decisions. Assuming a democratic process, each stakeholder would be given a vote. In some cases, an executive review committee might be a more practical alternative. In any case, the process should include informing the stakeholders about the resulting decisions including the motivation behind these decisions and the reason for rejecting proposed alternatives.

DJJ: Final decisions about the NISYS design will be made by upper management with input from their staff. It will the University of Maryland's responsibility to present alternative designs and perform usability tests where appropriate.

3.3 Discuss expectations of how stakeholders will be involved.

Each stakeholder is interested in what is expected of them personally. Their involvement might consist of filling out questionnaires, participating in usability studies, and receiving training. Or, it might consist of procuring hardware, writing contracts, and analyzing user feedback. The SIS should explain what is expected and whether participation is voluntary or mandatory. If participation is voluntary, explain how volunteers will be chosen. All stakeholders should be given the opportunity to participate in the development process. Active participants will probably be more satisfied with the resulting system than those who are not.

DJJ: Users will be encouraged to be active participants in the design process. Specifically, users will be asked to fill out questionnaires, participate in interviews, review user interface designs, and produce process maps.

3.4 Outline plan for migrating to the new system.

Migrating to the new system requires careful planning. Users may require training, the software staff may need to perform backups, and hardware may need to be installed. An evolutionary approach of smaller more manageable steps is preferable to the "flip the switch" approach (Kaplan, 1994). A backup plan should be in place in case the new system fails during migration or the transition takes longer than anticipated. Another issue to consider is how long the old system and the new system will overlap because the work load during this period will be increased.

DJJ: In order to familiarize their employees with graphical window environments, DJJ plans to provide courses in PC applications, such as word processors and spreadsheets. A training lab is currently under development. Formal training for NISYS will also be provided. Ideally, some PCs would be deployed early so users could begin integrating them into their work life. Unfortunately, state procurement practices may make this difficult.

3.5 Describe plan for measuring the success of the new system.

Often times, stakeholders are left wondering if the system goals were ever achieved. The success or failure of the system to meet specific goals should be conveyed to the stakeholders along with the plan for correcting any shortcomings. Specific goals, like reduce the amount of paper used by ten percent, can be measured over time. More subjective goals like, improve user satisfaction, can be evaluated by administering questionnaires.

DJJ: The Questionnaire for User Interaction Satisfaction (QUIS) (Chin, Diehl, & Norman, 1988), was administered to 332 employees to measure user satisfaction with ISYS. Using this as a benchmark, the QUIS could be readministered to measure the success of NISYS.

4. Address fundamental principles.

As we continue to develop systems on the forefront of technology, we must strive to serve human needs by addressing fundamental principles.

4.1 Weigh individual rights vs. societal benefits.

There are times during system design when individual rights conflict with societal benefits. When developing new technologies, it is the obligation of the SIS authors to weigh alternatives, for example, it was recently decided that tax records could be searched to locate individuals who refused to pay child support.

DJJ: While a youth's record is confidential, case workers are entitled to know if the youth they are dealing with has a violent history, but should future school teachers, neighbors, or employers be entitled to this information?

4.2 Assess trade-offs between centralization and decentralization.

Centralization vs. decentralization is a long running debate about whether computer systems will result in decisions being made by a few select people (centralization) or by broader more diverse groups (decentralization) (George & King, 1991). For example, a decentralized system gives more control to the end users, while a centralized system ensures consistent policies. However, with control also comes responsibility which needs to be delegated. For example, will end users be responsible for backing up their personal data or will additional software staff be hired to do this? A SIS should assess the trade-offs and choose the approach that best suits the needs of the organization and society.

DJJ: Internally, DJJ is wrestling with the desire to empower their workers by giving them more control (e.g., letting them create their own customized reports, etc.) without burdening them with additional responsibility (e.g. data backups). Another question is if NISYS automatically generates reports who should be responsible for requesting that function. Should workers continue to generate the reports and forward them to their supervisors or should the supervisors simply generate the reports themselves?

4.3 Preserve democratic principles.

Successful system design depends, in part, on active user participation and unless users are given a vote, it can be difficult to motivate them to participate. Giving users a "vote" requires management to relinquish some control. This does not mean that users should be given full control over the system design. For example, management may give users control over certain system aspects but within a budget they define. While the ideal may be a democracy, the hierarchical nature of many organizations makes this difficult.

4.4 Ensure diverse access.

It is very common to see the phrase "Equal Opportunity Employer" on job announcements. Unfortunately, very few systems provide equal access. Ideally, systems should be designed to meet everyone's needs: young, old, handicapped, rural, foreign, etc. While it may not be practical to design systems that accommodate everyone, this should not excuse designers from considering alternative designs that satisfy wider audiences. A SIS should outline an organization's policy on ensuring equal opportunity and define the intended users of the system. In some cases, an organization may choose to provide alternative systems to ensure diverse access.

DJJ: Within DJJ there is an employee with impaired vision and another with impaired motor coordination. While NISYS will not directly incorporate functionality to accommodate these individuals, different input devices will be investigated, time permitting.

4.5 Promote simplicity and preserve what works.

Designers should be careful not to overlook simple solutions. Today, with technology advancing rapidly, we often get carried away with integrating the latest breakthroughs into our system designs. It is important recognize when certain technology works and when it does not. If organizations have devised good ways of handling their needs, then incorporate them into the new system. Designers should acknowledge and preserve what works, not reinvent solutions.

DJJ: One of the design goals of NISYS is that it is not so complex that users have to constantly refer to technical manuals and look up obscure codes. The basic functionality of ISYS is a good starting point for NISYS (e.g., add a case, add a placement, add a review, etc.). Currently, many factors, such as the user interface and accessibility problems, make it difficult to perform these functions, but these functions still reflect DJJÕs needs.


In 1974, Sterling recognized that "systems will not become humanized on their own without the conscious effort of concerned citizens.Ó Incorporating SISs into the development process would be one step toward achieving that goal. In our society, success is too often measured in terms of immediate costs: ÒThe utility of humanizing procedures is not apparent from cost/benefit calculations but arises from the point of view of quality of life - not only of our own but also of future generations who will be saddled with the systems which are designed and implemented today (Sterling, 1974)."

This paper takes a step in clarifying what a Social Impact Statement might contain and how it might be integrated into a realistic development process. We recognize the need to keep the effort, cost, and time appropriate to the project, while facilitating a thoughtful review. We believe that there can be large improvements from such a process by preventing costly problems which may be expensive to repair, improving privacy protection, minimizing legal challenges, and creating more satisfying work environments. Well designed systems will be valued by users and appreciated by colleagues. Information system designers have no Hippocratic Oath, but excellence in design can win respect and inspire others to higher performance.


We thank Batya Friedman for encouraging us to explore this domain and our reviewers, Judy Olsen and Kent Norman, for providing us with valuable feedback. This report was supported by funding from the Maryland Department of Juvenile Justice.


Battle, Jackson, Fischman, Robert, and Squillace, Mark, (1994), Environmental Law Volume 1 - Environmental Decision making NEPA and the Endangered Species Act, Anderson Publishing Co. WWW version prepared in April 1994 by Robert Fischman, Indiana University, School of Law, Bloomington, IN,

Chin, John, Diehl, Virginia, and Norman, Kent, (1988), "Development of an instrument measuring user satisfaction of the human-computer interface", Proceedings of CHI '88 - Human Factors in Computer Systems, ACM, New York, 213-218.

Dunlop, Charles and Kling Rob (editors), (1991), Computerization and Controversy: Value Conflicts and Social Choices, Academic Press, Inc., San Diego, CA.

Friedman, Batya and Nissenbaum, Helen (1995), "Bias in Computer Systems", ACM Transactions on Information Systems, in press.

George, Joey and King, John, (1991), "Examining the Computing and Centralization Debate", Communications of the ACM 34, 7, ACM, New York, NY, 63-72.

Huff, Chuck, (1995), Practical Guidance for Doing a Social Impact Statement (SIS), St. Olaf College, in preparation.

Huff, Chuck and Finholt, Thomas, Editors, (1994), Social Issues in Computing: Putting Computing in its Place, McGraw-Hill, Inc., New York.

Iacono, Susan, and Kling, Rob (1991), "Computerization, Office Routines, and Changes in Clerical Work", Computerization and Controversy Value Conflicts and Social Choices, Dunlop, Charles, and Kling, Rob (editors), Academic Press, Inc., San Diego, CA.

Kaplan, Bonnie, (1994), "Reducing barriers to physician data entry for computer-based patient records", Topics Health Information Management 15, 1, Aspen Publishers, Inc., 24-34.

Kling, Rob, (1980), "Social Analyses of Computing: Theoretical Perspectives in Recent Empirical Research", Computing Surveys 12, 1, 61-110.

Ladd, John, (1991), "Computers and Moral Responsibility: A Framework for an Ethical Analysis", Computerization and Controversy Value Conflicts and Social Choices, Dunlop, Charles, and Kling, Rob (editors), Academic Press, Inc., San Diego, CA.

Mander, Jerry, (1991), In the Absence of the Sacred: The Failure of Technology and the Survival of the Indian Nations, Sierra Club Books, San Francisco, CA.

Markus, M. Lynne, (1984), Systems in Organizations Bugs and Features, Pitman Publishing Inc., Boston, MA.

Mumford, Lewis, (1934), Technics and Civilization, Harcourt Brace and World, Inc., New York, NY.

Ralls, Scott, (1994), Integrating Technology with Workers in the New American Workplace, U.S. Department of Labor, Office of the American Workplace, Washington, DC.

Shneiderman, Ben, (1990), "Human values and the future of technology: A declaration of empowerment," Keynote address, ACM SIGCAS Conference on Computers and the Quality of Life CQL '90 (Sept 1990), Special Issue of SIGCAS Computers & Society, 20, 3 (October 1990), 1-6. Reprinted in ACM SIGCHI Bulletin (January 1991).

Sterling, Theodor, (1974), "Guidelines for Humanizing Computerized Information Systems: A Report from Stanley House", Communications of the ACM 17, 11, ACM, New York, NY, 609-613.

Wiener, Norbert, (1954), The Human Use of Human Beings: Cybernetics and Society, Doubleday and Company, Inc., Garden City, NY.

Wurth, Albert, (1992), "Public Participation in Technological Decisions: A New Model", Science Technology Society Bulletin 12, STS Press, 289-293.

Web Accessibility