1 Introduction
Privacy can be characterized as the right of individuals to have control over data about themselves [
4]. With rapid technological progress and the evolution of the Internet from “a web of pages to a web of people” [
40], companies and governments are gaining new powers of surveillance and manipulation over citizens by gathering, sharing, and using the vast amount of personal data generated by people’s everyday online and offline activities [
16,
34,
51]. Users increasingly recognize that receiving personalized services and other benefits often requires disclosure of personal data. At the same time, users report being concerned about how their data is collected, used, and stored. In a 2019 Pew survey of 4,272 American adults, 81% of the respondents felt that they had little control over the data collected about them by companies, 79% said they were not confident that companies would handle their personal data responsibly, and 70% said their data is less secure compared to five years ago [
3].
The past couple of decades have seen the issue of personal data protection addressed via a number of important privacy regulations, such as
European Union (
EU)
General Data Protection Regulation (
GDPR) [
19] and various U.S. state-level privacy laws, including the most recent
California Consumer Privacy Act (
CCPA) [
7]. Complying with these laws by implementing the regulatory requirements in software systems necessitates translating complex social, legal, and ethical matters into technical system requirements and operation [
24], thus raising a number of challenges for software professionals. First, legal regulations are written using jargon not easily accessible to system designers and developers [
2]. Second, consideration of legal implications is typically handled by legal compliance teams rather than developers [
45]. Third, regulations are usually framed in general terms to ensure broad coverage at high levels, thus making it difficult to apply them to low-level specifics of software implementation [
12].
To include privacy considerations
within the software lifecycle, rather than considering them as an afterthought relegated to those handling quality assurance and legal compliance, researchers and regulators have proposed the
Privacy by Design (
PbD) framework for software development [
8,
9]. The central philosophy of PbD is to “create a sustainable data protection system through the early use of adapted privacy enhancing technologies in the design of the processing operations and throughout the lifecycle of the data” [
10]. However, PbD has been criticized as vague and ineffectual because it does not include specific tools and methods to train software engineers to deploy these principles, models, and mechanisms into real-world systems [
24,
49,
53,
54,
58]. To facilitate practical application of PbD principles, Luger et al. [
36] proposed a set of
Privacy Ideation Cards (
PICs) to make privacy regulations more understandable and accessible to software professionals. However, their empirical investigation of the application of PICs was limited to pre-defined system descriptions created by the researchers themselves. As a result, the impact of PICs has not yet been explored in real-world software development.
Further, it has been widely recognized that adequately trained software professionals are key to facilitating effective translation of privacy principles into system requirements [
30,
49]. Accordingly, instilling privacy proficiency in software students before they graduate and join the workforce can promote more effective consideration of privacy compliance in the software industry in general [
14,
30,
35]. Although most software engineering curricula require students to work on real-world projects as a capstone experience, these projects typically do not explicitly require students to consider privacy aspects related to the projects. PICs could be used to help students learn about and address privacy aspects of their capstone projects. However, their utility as a pedagogical tool for inexperienced software professionals has not yet been examined.
To fill the two gaps identified above, we formulated the following two research questions:
RQ1: What are the main considerations related to privacy compliance in real-world software projects?
RQ2: To what extent do privacy ideation cards help students consider the privacy aspects pertaining to real-world software?
We addressed the above two research questions by conducting three iterations of ideation sessions using PICs in undergraduate capstone courses involving real-world projects. Each iteration involved one cohort of software students who engaged in team sessions in which the teams applied PICs to reflect on the privacy aspects related to their capstone projects. We analyzed how student teams applied PICs to their capstone projects using the reflective practitioner’s perspective [
26,
48].
Based on our analysis, we make the following contributions:
We empirically demonstrate the extent to which PICs are applicable to real-world software projects, highlighting their important strengths and shortcomings as a practical tool for software professionals.
We apply the reflective practitioner’s perspective to software engineering education and show that PICs can be a useful pedagogical tool to help software students learn about privacy.
We surface several themes that can serve as the foundation for privacy education in the computing disciplines.
We apply our insight to provide a number of suggestions for improving PICs, pedagogical strategies, and software development practices to support privacy considerations.
In the following section, we review current approaches to privacy compliance in software engineering and summarize Lugar et al.’s [
36] study on utilizing PICs that inspired our work. We additionally discuss the reflective practitioner perspective in the context of software development that guided our analysis of student learning in ideation sessions using PICs. Next, we present the research design, including the context and participants, the ideation activity procedures, and details of the data collection and analysis. Based on the analysis, we proceed to answer the two research questions mentioned above. We then discuss the insight gained from the findings to present a range of privacy considerations that are not yet fully supported in the training of software engineers and apply the insight to provide suggestions for improving PICs, software engineering education, and software development practices. Finally, we acknowledge a few limitations before concluding with proposing promising directions for future research.
3 Method
Capstone projects allow students to put their skills to the test to solve real-world problems [
59]. Therefore, capstone projects are instrumental in helping students develop the hard and soft skills required for their future careers. Those who sponsor these projects can make progress on lower-priority activities and gain access to a pool of graduating software developers for recruitment [
22].
We addressed our research questions with an empirical investigation of student teams in a two-term capstone course in Informatics at the University of California, Irvine, a large public university in the United States. As a requirement for this course, students work in teams of four to six on projects provided by external sponsors, such as corporations, government organizations, educational institutions, and non-profits. For instance, the student teams we studied were creating an email scheduler, improving the User Interface (UI) design of a video game, developing a conversational application, and so on. These projects revolve around developing a software system, at least at the level of a functional prototype or proof-of-concept, along with associated documentation such as requirements (in the form of use cases or user stories), designs (in the form of Unified Modeling Language [UML] diagrams or UI/User eXperience [UX] mockups), test cases, and test results. Most students who take the course have no prior real-world industry experience. However, approximately 15–20% of them have limited exposure to industry via internships. In essence, the capstone projects in the course provide teams with a supervised and controlled real-world experience analogous to that of an individual industry internship.
For the study, we developed a set of PICs for the U.S. regulatory context and used these cards to engage each team in an ideation session. During these sessions, the teams discussed the application of the drawn cards to their respective capstone projects. We conducted the ideation sessions in three different offerings of the course: (1) Fall 2015–Winter 2016; (2) Fall 2016–Winter 2017; and (3) Fall 2017–Winter 2018. The ideation sessions were conducted as a mandatory part of the course. However, it was optional to permit the use of the data for research. To avoid coercion, the course instructor was not involved in the administration of any study procedures and had no knowledge of whether a student consented to permit the session data to be used for research purposes. Similarly, the researchers were not involved with the course in any other way and had no knowledge of, or influence over, grades connected to the ideation session component of the course. All study procedures were reviewed and approved by the Institutional Review Boards (IRBs) of Indiana University and the University of California, Irvine.
We conducted the ideation sessions with the first student cohort in the second term of the course (i.e., Winter 2016). Upon initial data analysis, we discovered that the ideation sessions, although beneficial, could not induce a meaningful impact on the projects because they occurred too late within the project schedule. Therefore, we moved the subsequent ideation sessions to the first term of the course offerings (i.e., Fall 2016 and Fall 2017, respectively). Table
1 summarizes the information of student teams who participated in the three iterations of the ideation sessions, and Table
2 provides a brief description of each capstone project.
In the following subsections, we explain the development of the PICs used in the study, the protocol followed during the ideation sessions, and the data collection and analysis approach.
3.1 Development of Privacy Ideation Cards
Inspired by the work of Luger et al. [
36], we used an equivalent deck of ideation cards (see Appendix), containing 29 cards in total. These cards are grouped under three themed suits:
User (9),
Constraint (11), and
Regulation (9). The
User and
Constraint suits cover two regularly considered factors in the design process. They were included in the card deck to contextualize the discussion. Our PICs cover the U.S. regulatory context by selecting privacy guidelines from the
Office of Economic Co-operation and Development (
OECD) [
44] and the Fair Information Practice Principles from the
Federal Trade Commission (
FTC) [
20], which provide a basis for the U.S. regulatory framework. We consulted with privacy lawyers in the United States to use these guidelines for creating a set of
Regulation cards comparable to those derived from the EU GDPR. Figure
1 shows two example cards from each of the three suits.
3.2 Ideation Session Protocol
In the ideation sessions, the teams were asked to apply the cards to their software projects. They drew cards from the deck and discussed the relevance of the cards to their projects. Figure
2 shows the general flow of activities during each ideation session. As instructed, each team drew one
User card, one
Constraint card, and two
Regulation cards, in that order. However, we let the teams skip the drawn card if the team members found that it was not applicable or relevant to their project. Time permitting, we allowed the teams to draw one or two more cards if the team members expressed interest in doing so. Based on the experience with the first two cohorts, we decided to have the teams in the third cohort draw two
Constraint cards to produce more detailed and richer discussion. In the ideation session, the team members discussed each drawn card separately for about 5 minutes per card, ending with an approximately 10-minute discussion of all drawn cards considered together as a set. We provided the suggested duration for the discussion as such limits “can symbolize and facilitate the possibility for meaningful use in a brief amount of time” [
21]. The facilitator’s main responsibilities were to introduce the cards and the activity at the start of the session and answer any procedural questions and monitor discussion time during the session. Table
3 lists the sets of cards that the teams drew in their respective ideation sessions. A researcher assisted by the last author acted as the facilitator for the first cohort while the last author was the facilitator for the latter two cohorts.
After the facilitator introduced the cards and the activity at the beginning of the ideation session, the team members engaged in a general discussion of their project. There were no designated topics for this discussion, and team members were free to talk about anything of their choice. For example, some teams gave a brief overview of their project for the facilitator’s benefit, and some others chose to use this time to organize their project-related tasks.
Following the general discussion, the facilitator instructed the teams to draw a User card from the shuffled, face-down card deck and discuss how their system might support the needs of the user group presented on the card. For example, a team who drew the Older People card proposed that this user base might be “not used to using technology all the time” so their system would have to display information in simpler terms.
After 5 minutes of discussing the User card, the facilitator instructed the teams to draw a Constraint card to discuss how their system might deal with the presented constraint. For example, a team who drew the Low Energy card considered making the system available offline so that the system could operate with low levels of power consumption when necessary.
Next, the facilitator instructed the teams to choose cards from the Regulation suit. Students engaged in a 5-minute discussion on how the regulatory concept of the first drawn card was related to their project and repeated the process with a second card. For example, a team who drew the Explicit Consent card decided to provide a checkbox for their users to confirm that they explicitly consented to data collection. In the rest of the article, we focus on the discussion stimulated by the Regulation cards. While User and Constraint cards were useful for contextualizing the ideation session, we exclude the data and results related to these cards as these are orthogonal to the scope of the research questions addressed in this article.
When the teams finished discussing the drawn cards individually, the facilitator asked the teams to have a 10-minute overall discussion considering all cards drawn during the session. Students took a broad look at the scenario as a whole and talked about what they needed to do to satisfy the various requirements stated in the drawn cards taken together. We video recorded all sessions and additionally took photographs of any artifacts, such as drawings, white board notes, and so on, produced by the student teams during the sessions.
One week after the activity, we asked the teams to submit a report on their ideation session experience, including a summary of any changes they planned to make to their projects based on the discussions that occurred during the ideation sessions. The changes could pertain to any aspects of the project, such as changing the user interface, adding components connected to privacy compliance (e.g., a notice to inform users of the purpose of data collection), raising privacy issues with their sponsors, and so on.
3.3 Data Collection and Analysis
We collected and analyzed data only for the sessions for which all team members consented to the research use of the data. Data was collected from two main sources: video recordings of the ideation sessions and post-session reports from the teams. Audio from the recordings was transcribed verbatim, and the video was used to add relevant contextual information, such as the specific card that was being discussed. For 24 student teams, all members (106 participants in total) consented to having their ideation sessions be part of the research, and 21 out of these 24 teams submitted post-session written reports.
We analyzed the transcripts and post-session reports using qualitative content analysis [
29]. To answer RQ1 (i.e.,
“What are the main considerations related to privacy compliance for real-world projects?”), we adopted a bottom-up approach using techniques from grounded theory [
13], allowing common themes to emerge from the data without
a priori assumptions. Specifically, we adopted Straussian grounded theory [
13,
55] and coded for themes as a team using an iterative process, starting with open coding, followed by axial and selective coding.
To answer RQ2 (i.e.,
“To what extent do ideation cards help students reflect and learn the privacy aspects pertaining to real-world software?”), we proceeded top-down and used the validated coding framework provided by Leung et al. [
33], with the following few modifications to tailor it to our study:
(1)
We operationalized the code “Connect information to experience and practice” to mean “Connection information to personal experience and practice” because students described their personal experience anecdotally in relation to the card drawn.
(2)
We combined the original codes “Revise an idea or practice” and “Replace an idea or practice” as they were not distinctively separable in our data.
(3)
We extended the definition of code “Identify flaws in the information provided” by adding “express doubt over” to capture situations in which students were unsure about the information provided.
(4)
We removed the code “Apply information provided in other contexts” because we did not observe any such task in our data.
Table
4 presents our adjusted coding framework and provides examples from the data to illustrate the codes.
The first two authors independently applied the above modified framework to code a random sample of 10% of the data and compared the results of the individual coding. The two coders discussed and resolved all discrepancies until they reached consensus. The second author then coded the rest of the data, supervised by the first author. We identified 14 tasks, each connected to one of five cognitive processes. The second author then applied the 14 codes corresponding to each of these tasks to all ideation session transcripts, yielding a total of 2,642 coded segments within the transcripts. We engaged in a second coding pass to check the results for accuracy and consistency. For this article, we used the 636 coded segments pertaining to the Regulation cards. We do not report the remaining coded segments as they related to the User and Constraint cards.
For a quantitative comparison of the extent to which the teams responded to different Regulation cards, we used the number of lines in the respective transcripts to measure how much the teams discussed each card. We operationalized a line as one interactive round, where a team member continued the discussion by building on the ideas of others or proposing a new idea. The number of lines is a reasonable metric because it shows the level of engagement independent of the influence of other factors, such as differences in talking speed and pauses in interaction. Specifically, for every card, we counted the number of lines of discussion that were about that card in each transcript and added them across all transcripts. We then divided the sum by the number of times the card was drawn across all sessions to yield the average number of lines prompted by the card.
5 Discussion
The motivation behind our research was to understand how PICs could be applied as a privacy compliance tool for real-world software projects and as a pedagogical instrument to improve privacy proficiency of software students as novice developers who are about to join the workforce. Our findings show that PICs are a promising tool for engaging software professionals with issues of privacy compliance in their projects. At the same time, the findings point to a range of considerations for successful application of PICs within software development processes. Pedagogically, PICs induce surface-level cognitive processes, at least at the first attempt.
5.1 Privacy Compliance in Real-World Projects
Unlike the simulated design scenarios used by Luger et al. [
36], we examined the application of PICs in
real-world software projects. Luger et al. [
36] intentionally constructed their scenarios to impinge upon legal and ethical issues regarding data use. In our study, the software projects were not fictitious, but assigned by external sponsors to address real-world problems independent of our research. Our exploration revealed that the application of PICs in-the-wild differs from that in pre-crafted scenarios in several notable ways.
The features and requirements of real-world software projects are framed by the in situ properties of the system and shaped by software industry practices. As a result, in contrast to simulated design scenarios created specifically with the PICs in mind, not all Regulation cards might be applicable to a given project. For example, Team 9, which developed a dashboard for an existing database, did not need to collect any data directly. Therefore, the Regulation cards drawn by the team, Subject Access and Purpose Specification, were not directly applicable to the development activities for the project. In addition, in a typical real-world industry project, developers are not the only, or even the main, decision makers for privacy compliance matters. As our study shows, developer autonomy is greatly influenced by the characteristics of the project and the nature of the organization. The teams working on a more independent system had more freedom to respond to the regulations, while the teams developing a system with multiple dependencies with other systems in the organizations tended to consider themselves as mere bystanders in matters of privacy compliance. A lack of sufficient autonomy can prevent developers from being motivated to consider and engineer privacy compliance in the systems they develop, thus undermining the core vision of PbD. PICs can help address this issue by serving as tool that can increase the engagement of software engineers in discussions of privacy implications of the software they build.
Ambiguity regarding data classification poses a challenge when applying PICs in real-world projects. The PICs we used did not include a specific definition for the term “personal data,” relying instead on a shared understanding of the term as understood in common practice. While a definition is essential from a regulatory point of view, we found that it was difficult to disentangle personal information from sensitive information from a software developer’s point of view. Some considered the term personal data as being applicable only to highly sensitive pieces of data, such as social security numbers, medical records, or banking information. Many were unsure whether personal data covers seemingly benign pieces of information, such as name, gender, age, and so on. While it is reasonable that sensitive personal data is afforded greater protection, many privacy-related regulations require special treatment for any information that can reveal someone’s identify. As such, personal data can cover a wide variety of information, such as name, location, online identifiers, license plates, biometrics, and so on. Our study shows that a lack of knowledge and agreement over personal data can get in the way of more nuanced discussions regarding privacy implications, thus affecting privacy compliance.
It was unclear who was responsible for privacy compliance when data was accessed as a third party. For instance, many teams seemed to be relieved that they collected no data themselves, instead using the data provided by other services and platforms, such as Google and Twitter. Since they did not proactively collect or store any user data themselves, they considered themselves not responsible for privacy compliance aspects. However, as those handling the data, third-party software developers are not free from the liability. Using third-party data may even complicate the situation as system developers need to know more details about collection and compliance processes used by the first party that obtained the data.
In terms of scheduling the ideation session, students found the PICs activity particularly useful at the beginning of the project. Due to logistical constraints, the first iteration of the ideation sessions was carried out in the second term of the course, 2 weeks before code freeze. Most students reported that it was simply too late to introduce any of the privacy-related ideas spurred by the sessions into design and development. Based on the experience of the first cohort, we moved the ideation sessions in the other two iterations to the middle of the first term, just after the teams received their project details and started early work on their plans. Students in the latter two iterations considered the timing beneficial for them to take privacy into consideration early on.
“It’s good since we have not actually started coding, it’s good for us to start thinking about all the things.” – (Team 21)
Aligned with the philosophy of PbD, scheduling the ideation sessions at the early stages of software development prods software engineers to adopt proactive measures to address privacy considerations in the development process. For example, when discussing the Privacy card, Team 17 proposed the addition of a consent form:
“If you’re asking for information when they sign up for it, that’s collecting stuff too. Because right now we have their names, their birthdays, their contact information ...that’s big stuff. And the fact that they are participating in this ...if that stuff is tied together. So to go back to this all you really need is a consent form, preferably an IRB [Institutional Review Board] form that promises that it’s going to be private.” – (Team 17)
5.2 Learning about Privacy via the Reflective Ideation Activity
We systematically examined student engagement in the ideation session as a
reflective learning opportunity. We found that ideation cards were successful in triggering lower-level cognitive processes for specific components within a project. As Figure
3 shows, 81.1% of the 636 cognitive tasks we observed fell into the lower-level categories (i.e., Meaning construction, Interpretation, and Change). A closer look at the the distribution of specific codes and the content of the interaction suggests that students had not previously considered privacy compliance issues at all. As a result, the PICs prompted them to spend a considerable amount of time discussing and negotiating the meaning of each card and confirming whether the card was relevant to their projects in the first place.
These findings suggest that PICs are a promising pedagogical tool to expose student software developers to knowledge about privacy regulations as an initial step for improving the privacy properties of their software. This observation further confirms the gap between advocating the importance of privacy requirements and the practical application of these requirements in real-world software development. To many developers, privacy consideration come second to ensuring that software is functional. In addition, project sponsors and managers might view privacy considerations as the purview of legal compliance teams and/or designated privacy managers, so they may not task developers with privacy requirements [
45]. As a result, software engineers are neither trained to keep privacy in mind when developing software nor equipped with sufficient knowledge to understand and comply with up-to-date regulations. PICs can help address this issue by providing a learning opportunity for students and sponsors, thus advancing the PbD agenda.
When comparing the amount of interaction generated by each Regulation card, we noted that the Explicit Consent, Subject Access, and Breach Notification cards ranked at the top, while Accountability, Data Minimization, and Data Quality spurred the least discussion. In discussions spurred by the PICs, students often drew upon their previous experiences as users of particular technologies (e.g., Google apps). For instance, students from Team 1 realized that they could apply the Explicit Consent card when users sign up, “like how people have the terms and regulations.” They continued that explicit consent “is for protecting the company more...We need the legal protection. We have to have the explicit consent of ‘I have signed this waiver. By signing here, I say I have read this and I understand this.’” The discussions during the ideation sessions indicated that students leverage implicit knowledge of privacy compliance measures that are observable in the systems and services they use. Practical examples based on the UX of widely used systems can serve as a lead-in topic that instructors can use to make privacy compliance more relatable by building upon the prior knowledge of the students as users. On the other hand, cards like Accountability and Data Minimization are associated with background processes that are not as directly accessible to students in their everyday use of technology. Consequently, students may find these cards vague and hard to decode.
To comply with privacy regulations, a common strategy adopted by the students was emulating the operation of mainstream services. It is undeniable that studying and following established practices and standards provides easily accessible solutions to tackle issues. Inexperienced developers, in particular, are more likely to be influenced by the background set by mainstream services and consider it as the correct way to comply with privacy regulations. However, this practice can be problematic if students follow these practices unconditionally without reflection, even when they notice problems with typical privacy compliance measures. For example, one member of Team 1 commented: “It’s funny that people don’t read it [the privacy consent] but they just check it anyway. Even for Facebook and Snapchat...no one reads it. They just press okay, you can take all my photos.” The reliance on using familiar practices as standard approaches points to the need for privacy-related critique of common design patterns prior to incorporating them within other projects.
6 Implications
We discuss the implications of our findings from two perspectives: software engineering education and PIC design.
6.1 Implications for Software Engineering Education
Based on the analysis of the ideation sessions, we propose the following measures to facilitate the use of PICs as a pedagogical instrument to help software students learn about privacy-related practices.
Hold an information session at the beginning.. For promoting more higher-order discussion over PICs in ideation sessions, we propose holding a brief information session or workshop to go over key privacy principles prior to the ideation sessions. Such an introduction could include a set of definitions that clarify the key terms related to the PICs as well as examples of typical privacy compliance practices in industry.
Provide PICs as a reference tool.. Because of the time constraints in our ideation sessions, each team could draw only four to six cards in total. The discussion therefore focused mainly on limited topics directly related to the drawn cards. Moreover, due to the specifics of each project, some Regulation cards were not applicable. Students wished to see the other cards to gain a more comprehensive consideration of the compliance requirements. Accordingly, we suggest providing the entire set of ideation cards as a reference tool for capstone courses so that students can utilize them throughout the project as needed.
Repeat ideation sessions.. When students received the initial instructions for the projects, they began by clarifying requirements and planning the development steps. Applying PICs at early stages of the projects may have contributed to the lower-level discussion of the meaning and applicability of the PICs in the projects. It could be beneficial to conduct the ideation sessions multiple times during the capstone course to capture different stages of the projects. Along with the ideation sessions, instructors could assign a privacy-focused deliverable. For instance, such a deliverable could mimic privacy impact assessments that are being used increasingly in relation to technology [
43,
62]. Further, the task related to such a deliverable can serve as a self-directed learning opportunity in which students externalize their thoughts and document the improvement in their understanding and practices for developing privacy-compliant software.
Adopt active strategies to facilitate discussion.. In order to prompt more higher-order reflection, we suggest that the facilitator provide guidance and clarification during the ideation sessions. This could help students better differentiate seemingly similar cards. In addition, some facilitation strategies, such as introducing real-world cases, inviting questions, asking for clarification, suggesting comparisons, prompting summary, and so on, can promote more higher-order thinking in reflective discussion [
42,
60]. In this regard, the facilitator could play a role akin to that of a product manager or a privacy manager.
Incorporate privacy in software engineering education.. Privacy regulations and principles are becoming increasingly vital for personal and corporate use of technology. Yet, current software engineering curricula lack adequate training for these purposes. Therefore, in the long run, there is a pressing need for privacy-related curricular content in software engineering education. Such curricula can ensure that students will be equipped with basic privacy proficiency prior to entering the workforce. Research on privacy-related education has thus far focused mostly on
user education by challenging and correcting misconceptions that guide their online behavior [
11,
32,
61]. However, educating software professionals on privacy-related matters is equally important because they are the ones who design and develop the systems that must be privacy compliant and serve the privacy needs and expectations of the users.
Communicate proactively with sponsors about privacy compliance.. To improve privacy protection within their projects, some teams in our study planned to bring up privacy-related matters with their sponsors.
“There is a lot we don’t know like a lot of stuff that he [the sponsor] takes care of in the backend that we don’t really touch, so it could be good just to have that conversation with him to start.” – (Team 21)
Working within an organization necessarily restricts the freedom of developers to work as they please. However, the organizational context should not be a barrier that prevents software engineers from designing proactively for privacy compliance. Without empowering developers with the knowledge and autonomy they need to make privacy-related design decisions, PbD will remain disconnected from the development stage of the software lifecycle in practice. To address this issue within capstone courses, we advocate greater communication and transparency between student teams and their industry sponsors regarding the handling of privacy-related matters. In particular, the relationship between the teams and their sponsors should emphasize shared interest and responsibility regarding privacy compliance.
6.2 Implications for PIC Design
In addition to perceptions of the ideation activities, the reports submitted by the teams after the ideation sessions pointed to several suggestions for PIC design.
Make the cards aesthetically pleasing and fun.. The aesthetics of the cards and the game element involved in their use contributed to the students enjoying use of the cards as stimulative props for reflection. For instance, the students found the color schemes and icons attractive (“The cards are really cute.” “The icon is very good.”). The inclusion of the game element (i.e., card playing) made the learning activity enjoyable and relatable as the students had fun drawing and examining the cards (“I almost feel like it’s a game.” “It’s like we are playing a game.”). As one student commented, “It feels natural to start talking about these cards.”
Avoid lengthy descriptions and jargon.. Most prominently, the students suggested rewording the text on some Regulation cards for greater clarity:
“They [the cards] were kind of wordy, some of them. The ones with multi-line sentences were hard to understand ...like the Subject Access one. I don’t know what this is saying. You read it like three times.” – (Team 17)
There is a tension between sufficiently capturing complex regulatory nuance while keeping the text short and easily understandable by a lay person. Clearer and shorter descriptions could reduce the cognitive burden of understanding the cards. It would also be worthwhile to refine the descriptions through an iterative process that incorporates student feedback. In fact, the card design process could itself be educational by serving to engage software students in learning about privacy aspects of technology and helping develop an appreciation for the PbD approach.
Include illustrative examples.. Supporting examples to illustrate application of the concept connected to a card could help enhance comprehension. The students sometimes failed to differentiate the nuance between different cards because they lacked prior exposure to the basic concepts presented in the ideation cards. For instance, the students complained that some cards presented overlapping concepts, thus coming across as repetitive. For example, a student argued that the Notice and Purpose Specification cards cover a similar concept.
“I noticed that the two cards we happened to get are fairly similar: Notice and Purpose Specification. Both go with the idea that you have to be explicit and make sure the user knows what the information is and what it’s being used for. So those kind of went hand in hand.” – (Team 8)
In cases such as the one mentioned above, illustrative examples could help students grasp nuanced differences and become familiar with basic privacy-related concepts. However, providing examples could have a priming effect that prevents a full examination of the matter. Therefore, if examples are included, they should be chosen carefully to avoid constraining people’s thought processes.
7 Limitations and Future Work
Our study has the following main limitations. First, we were able to conduct the ideation session only once during each offering of the two-term course because of logistical constraints. Therefore, our results might not present a comprehensive view of privacy compliance as an ongoing practice throughout the software development lifecycle. Future studies could repeat the ideation sessions multiple times during a project and examine the changes across the stages in privacy compliance proficiency and processes.
Second, participants in the study were university students. While the capstone course facilitated an investigation of PICs as a pedagogical tool, the students were not yet industry professionals. Future studies with industry professionals could help understand the generalizability of PICs as a training tool for experienced developers.
Third, we could not investigate how the student teams implemented the proposed changes in their projects due to confidentiality concerns of the sponsors. Future studies should study how ideas generated in the ideation sessions influence properties of the code and outcomes of the projects.
Fourth, we used time-limited discussion to focus participant attention and facilitate meaningful discussion in a brief amount of time based on an established protocol of ideation card activities (e.g., [
18,
21]). Since complex cognitive tasks typically require extra processing time, the time limit may, however, create constraints that could inhibit students from moving to a higher-order cognitive thinking. Future studies could investigate whether an extended discussion time induces higher-order thinking in ideation activities and examine how the cognitive processes unfold over time.
