Privacy by design is a widely acknowledged necessity, yet its practice is still in its infancy. Many scholars have argued that privacy by design requires a cross-disciplinary approach in which privacy perspectives from different disciplines need to be integrated from the beginning of the design process. This paper investigates the potentials and shortcomings of a workshop format, used in the early stages of a (re)design process, to integrate viewpoints of multiple stakeholders from different disciplines. The workshop is used in two cases involving privacy issues, in the healthcare and in the insurance domain. The results show that different stakeholders, representing social, technological, ethical, legal, domain and user perspectives, identified different problems. Together, they thus provided a more complete view on the issues at stake, forming a better starting point to account for privacy in the design process. Based on the results, the paper suggests a number of research directions for combining diverse views from multiple stakeholders.
The ubiquitous presence of technology creates ever more urgency to account for
privacy issues [
One of the best-known works on privacy by design is by Cavoukian [
One of the major challenges in applying privacy by design is that it requires the
integration of perspectives from multiple stakeholders (user, designer, developer, etc.)
and disciplines (HCI, software engineering, law, etc.) [
Although the above works aim at taking into account multiple perspectives in eliciting privacy requirements, they do not elaborate upon how well the applied methods integrate these perspectives in practice. In this paper, we therefore investigate the potentials and shortcomings of using a workshop with multiple stakeholders as a method to surface privacy-related problems from multiple perspectives, by applying it to two design cases. 2
The workshop we use is suitable for the initial phase of a systematic privacy by design
approach, aiming to identify privacy issues and trade-offs from multiple perspectives
related to the (re-)design of an information system. A diverse participant group is key
to the approach, as the participants represent multiple perspectives on privacy. The
workshop centers around a timeline, which serves as a boundary object to bridge the
participants’ domains of expertise [
To gain practical experience with the workshop format, we organized two sessions with 6 stakeholders: a problem owner (domain expert), an end-user, and four privacy experts with a social, ethical, technical and legal perspective, respectively. The workshops were led by a moderator (a designer). The roles of moderator and privacy experts were fulfilled by researchers at Rotterdam University of Applied Sciences (RUAS), and those of problem owner and end-user by people outside of RUAS, associated to the respective domains. In an iterative design fashion, the results of the first session were used to inform the second. 2.1
The first case deals with the design of recording surgeries in the Operation Theater (OT) in a so-called OT Black Box. Data stored in this OT Black Box contain video and audio recordings of the OT, featuring the patient and the OT team, typically consisting of surgeons, anesthesiologists, nurse anesthetists and OT nurses. These recordings are later used by the OT-team to analyze and evaluate their performance, and by a quality and safety manager to detect potential safety issues and improve the OT procedure if possible. After two days, the recordings are anonymized (patient and OT-team are no longer identifiable) and used for medical training purposes. Recordings are then no longer available for the patient who underwent the surgery.
Before the workshop, the moderator and problem owner prepared a timeline consisting of five steps (see Figure 1). For each step, a large (A0-sized) paper was put on the wall, on which the other workshop participants could write and add sticky notes. Each participant was provided with markers and sticky notes of a unique color, so that the contributions on the poster could be traced back to the different perspectives.
The four-hour workshop session consisted of five activities. First, the design case was introduced by the problem owner, explaining what happens in each timeline step. Second, data assets per timeline step were identified by the workshop participants (first individually, then in a group discussion), and added to the posters. Third, privacy violation risks per timeline step were identified (first individually, then in a group discussion), and added to the posters. Fourth, opportunities and risks of the information system as a whole were determined and trade-offs were identified (in a group discussion). Fifth, the workshop participants agreed on a set of design constraints, based on the identified trade-offs (in a group discussion).
Figure 1 shows some of the ‘data’ and ‘privacy risks’ that were identified per timeline step. The overview is not exhaustive but intends to provide a gist of the contributions from different participants. The results show that they bring in different perspectives. For instance, the social privacy expert mentions that the patient’s dignity may be at stake, whereas the legal privacy expert points at the application of a privacy impact assessment.
Fig. 1. Data and privacy risks identified by workshop participants for case 1 (OT Black Box).
After identifying privacy risks, participants agreed that the most important trade-off was improved healthcare versus deteriorated privacy, i.e., recordings by the OT Black Box can enhance the quality of healthcare, but they introduce privacy violation risks for both the patient and the OT team. There was little time left to perform the last activity, identifying design constraints. Participants stressed that data should only be used for the purpose they were collected for. 2.2
The second design case involves the use of the mobile application WhatsApp for damage claims to an insurance company. The insurance company offers its customers the possibility to send text and pictures of car damage (including pictures of the location) via WhatsApp, when claiming the damage to the insurance company. These messages and pictures are encrypted by WhatsApp.
Although detailing the ‘data’ of all timeline steps in the first workshop brought forward deeply engaged participants, it also led to discussions in which domain-specific details were explored by non-experts. Moreover, it led to time shortage later on in the session. We therefore asked the problem owner in the second workshop to detail the data in each timeline step beforehand (Figure 2, 3rd column). The other workshop activities remained the same.
Figure 2 shows the results of the second workshop session. Again, these results are not exhaustive, yet indicative. Similar to case 1, privacy issues related to ownership, faulty data and function creeps were identified. In the discussions, a lot of attention was paid to the trustworthiness of the photos sent for a damage claim via WhatsApp, as they could easily be manipulated or uploaded from the internet. Thanks to the new setup of the workshop, it was possible to complete all workshop activities this time.
Participants identified a trade-off between ease of use and privacy. Using WhatsApp for reporting damage increases ease of use for customers but introduces privacy risks due to relying on a 3rd party service provider. Other trade-offs identified were knowledge versus privacy (collecting and storing information increases insurers’ knowledge, but introduces privacy risks), costs versus privacy (building an in-house application protects customers’ privacy, but increases costs), ease of use versus security (as the ease of using WhatsApp creates security risks due to relying on a 3rd party service provider).
The workshop participants identified the following design constraints and recommendations: 1) insurance companies should develop their own application rather than relying on 3rd parties such as WhatsApp, this should be done according to privacy by design principles, 2) customers should always be able to choose whether they want to make use of WhatsApp, 3) customers should be informed about their options and the implications of their choices, 4) as least data as possible should be collected, data should not be collected if they will not be used, 5) customers should be able to access their personal data stored by the insurance company, and 6) authorization of data access should be implemented carefully in the insurance company in order to avoid function creeps. 3
In both design sessions, stakeholders from different disciplines identified different (privacy) problems and high-level requirements. For instance, the technical expert focused on issues related to the processing of data, such as data leaks and de-anonymization of data, whereas the social expert brought up the issue of human dignity and the legal expert identified issues related to authorization of access. The number of identified issues of all stakeholders was larger than any of the individual stakeholders’ contributions. Having multiple perspectives represented thus provided a richer view on the design case at hand. Besides helping the privacy by design of IT systems, the workshops were increasing awareness about privacy and its complexity among the participants, i.e., they learned from each other and gained more insight in the complexity of privacy by design.
A number of issues should be considered when combining perspectives of multiple stakeholders in a workshop in general, and in this workshop in particular. First, in a multiple stakeholder workshop, there is a risk that some perspectives are more dominant in the discussion than others. This could be countered by stricter time management by the moderator, making sure that all participants receive an equal amount of speaking time. Second, different perspectives, objectives and/or identified risks may not be of equal importance. In future work, guiding principles for weighing different perspectives should be developed. Third, the boundary object of a multi-stakeholder workshop, in our case the timeline, steers the discussion in the workshop. In future research, developing guidelines for preparing the timeline could help avoiding too directive descriptions. Fourth, in our workshops, a number of well-known tradeoffs did not surface (e.g., data-subject/user control versus central/system control, prevention versus mitigation, and technical versus procedural). This could be explained by a lack of expertise of the participants. Yet, the likelihood of overseeing important trade-offs can be lowered by providing more structure for discussing design trade-offs and providing design recommendations, for example by systematically holding design tradeoffs along various dimensions (e.g., data usage vs data privacy, data-subject control vs central control, prevention vs mitigation, and technical vs procedural).
In future work, we will take up the issues mentioned in this discussion and work on
the subsequent steps of a privacy by (re)design approach. We foresee the need of
developing a method that systematically translates the current workshop outcomes (i.e.,
design recommendations and constraints) into software requirements, e.g. by using
bridging concepts such as value stories [
The authors thank all the workshop participants for sharing their expertise and for their valuable contributions.