From the requirements of the Manson and O'Neill theory outlined in both this chapter and Chapter 1, that is, consultation with the stakeholders in the project, identification of normative expectations, and the successful resolution of conflicts, a practical implementation of informed consent in an information technology should choose normative expectations according to the following guidelines, or similar guidelines depending on the nature of the project:
1. Identify the design goals for the project. For example, a piece of software that wishes to track a user's choices in music from their collection and make playlists for others to see on the Internet. These goals should be from both the vendor/developer and user point of view, in order to make sure that all values and expectations within the project are identified.
2. Identify the nature of the users of the project. In this example, they are likely to be people who live all over the world, of certain ages (probably, and this would require field studies by the vendor, between ages 10 and 60), they could include people with disabilities, they could include people who are at work or at home, or who live in countries where information is restricted.
3. Identify the values of the users. Different users may have different priorities in values. Older users may value usability more than younger users, who may value privacy or honesty more. Disabled users would likely value measures put in place to help them use the software more easily.
4. Identify the expectations of the users for the project. These are likely to include (but not be limited to) the expectations outlined in section 3.2.3. These would be developed according to the guidelines I outlined above, with guidance from user interviews and surveys, or from codes of good software design. Ultimately the developer has the final say as to which of the expectations to include for the purposes of informed consent, but ideally they would be open to inclusion of others depending on the actual use of their product once it is released.
5. Identify the expectations of other stakeholders for the project. These are the sorts of things that the company might expect from the project, for example, that it be delivered on time and to budget, that it include some sort of advertising potential, that it conform to professional codes of conduct, that it doesn't break any laws, etc. Other stakeholders may include shareholders in the company, the environment, etc. All of these must be considered when drawing up a list of values and expectations.
6. Reconcile any conflicts between values and expectations, both internally and between different stakeholders. Conflict is likely to occur, such as trade-offs between security and usability. In this case, the best effort needs to be made to make the most of both values. Going back to the users (or user groups, or professional societies, or other special interest groups) and discussing the importance of values with them would be an excellent way to decide which values are the most important. The same is to be said for conflicts between stakeholder and user values or expectations. Wherever possible, it is important to acknowledge any conflicts if they are completely incompatible, possibly giving the option to the user to choose between value implementations (for example, a more secure but harder to use program or an easier to use but less secure program), explaining the differences between them, or disclosing outright any values that needed to be violated in order for the project to work (for example, privacy in giving up information about song preferences). It is important to attempt to require waiving of as few norms as possible; having them explicitly established will make it harder for them to be forgotten in the project's implementation process.
The limitations of these guidelines are that they may not be appropriate for use in every situation or project, and are restricted to the context chosen by those in charge of project development. A continual re-assessment process should be put in place in order for any unexpected stakeholders or uses of a particular project arise, so that the expectations arising from these can be taken into account in any ongoing development of the project. The emphasis should be on the importance of developer and vendor discussion with users of the project, allowing users to establish the expectations they would have of the project based on their values.