As digital technologies are integrated into societies, questions about who participates in technology development become increasingly crucial. When in 2016 we began FemTech, we wanted to redefine the nature of computer science in a way to reach out to people who were not already within the field – and who did not consider or see themselves as potentially successful in technology development. To make such change through interventions, in some of our first initiatives, we sought ways to create design artefacts that manifested alternative narratives of computer science while meaningfully interlinking with people outside computer science. Thus, our interest was to strive for gender equity in computing with an impact not only on educational programs but also on the underlying structures and society, through opening educational programs in alternative ways.

We wanted to enable participants in our interventions to develop critical thinking and practical skills, while allowing us to identify actionable factors to consider when designing interventions aimed at equity in computing with an emphasis on gender. This chapter contributes three analytical and operational factors that are important to consider when developing interventions for gender diversity: sociomaterial-design, social belonging, and gender representations.

In the last 30 years, a myriad of initiatives have tried to promote equal opportunities, diversity, and equity in computing. These initiatives take many different forms: from policies (Mayer and Tikka 2008) to educational programs (Valla and Williams 2012) to after-school activities (Scott et al. 2010; Pinkard et al. 2017). A popular format is short-term workshops (Çakır et al. 2017) and hackathons (Richard et al. 2015; Than et al. 2018). Research provides solid foundations for articulating insights and developing best practices (Duplantis et al. 2002; Frieze and Quesenberry 2015; Tabel et al. 2017); however, we still need more methodological guidance on how to design events in ways that consider the complex matter of gender equity. In this chapter, we report on our experiences and insights in designing and executing such events, and in particular how to develop learning events that consider gender equity, contributing to the research agenda of developing an analytical and operational corpus of research around learning and education, with an emphasis on diversity and gender in computing (Xie et al. 2019).

Concretely, in this chapter we report on the design and execution of FemTech workshops. We developed and implemented these workshops in 2017 and 2018 – and since then, the concepts have been continued by others in the Department of Computer Science and are now a recurring, yearly event. The FemTech workshop concept is based on the FemTech design principles and has as its centerpiece a design artefact that manifests these principles. The design artefact we developed for the 2017 workshop was Cyberbear and for the 2018 workshop was Cryptosphere. In 2020 the FemTech workshop concept attracted participants for two workshops (24 participants in each); however, the last one was canceled because of COVID-19. In 2021, a virtual FemTech workshop was designed as an online event for more than 100 participants invited from Denmark, the Faroe Islands, and Greenland.

What is important to point out is that the concept behind the FemTech workshop is not simply a workshop to teach young women to code. The challenge of changing gender diversity within computer science is not about teaching women programming. It should not be a surprise that gender is not related to ability in learning how to program. Teaching women or other gender minorities to program is not the challenge. The challenge that the FemTech workshop takes on concerns changing participants’ perceptions of and narratives about computer science, through practical engagements and skills.

In the last three decades, many initiatives led by industry, organizations, and public institutions have tried to engage more women in computing through different learning activities. A few examples are the Atari Camps for girls in 1984 in the US, diverse sets of IT camps for girls, or Girls Who Code (Kruger 1983; Kelleher and Pausch 2006; Kelleher et al. 2007). These initiatives are instantiated in different formats: from after-school activities to summer camps to hackathons. Most of these initiatives are time-bounded learning activities and, more concretely, activities that seek to foster equity in computing using the short-term workshop format. From a methodological perspective, workshops are an interesting challenge for us in meeting our goal of combining learning activities with an overarching agenda of changing perceptions of computing.

Prior work has demonstrated that when designing workshops that include programming activities, the choice of programming environment is essential. One of the most influential graphical programming languages, Scratch (Resnick et al. 2009; Maloney et al. 2010), has often been used in workshops seeking to increase diversity and inclusion in computing (Richard et al. 2015; Tabel et al. 2017). While Scratch is one of the most popular languages, other graphical programming environments have been used, including Alice (Dann et al. 2006), to teach girls and young women to develop video games in recruiting workshops (Fiebrink and Alcott 2003; Kelleher et al. 2007), and Virtual Family, designed as a “gender-neutral game-based software that introduces Java programming” (Duplantis et al. 2002).

However, in the context of gender and computing, placing too much emphasis on programming environments can lead to an excessive focus on including women in computing as a way to address the symptoms of gender imbalance while disregarding underlying problematic structural issues that caused this imbalance in the first place (Henwood 2000). Therefore, the FemTech approach is based on additional considerations for the design of such workshops trying to make fundamental and long-term changes. Important considerations include identifying ways to minimize problematic situations by, for example, challenging gendered stereotypes (Huffman et al. 2013), preventing essentialist perspectives on gender and technology (Trauth 2002), or considering intersectionality (Armstrong and Jovanovic 2015; Rodriguez and Lehman 2017; Buolamwini and Gebru 2018; Rankin and Thomas 2019, 2020). Indeed, recent research urges researchers to consider that gender cannot be considered in isolation; instead, it should be considered in interaction with other categories such as socioeconomic status or ethnicity (Schlesinger et al. 2017; Albusays et al. 2021).

There are examples where the design of learning activities placed special emphasis on addressing issues of stereotyping, gender, and intersectionality. For example, COMPUGIRLS is a multicourse curriculum that seeks to foster the interest of “girls of color” in computing by reconceptualizing theory of culturally relevant computing in ways that address their identities through connectedness, reflection, and skills development (Scott et al. 2010). Similarly, Digital Youth Divas is an out-of-school program that seeks to create alternatives to dominant representations of computing by creating digital artefacts based on narrative stories (Pinkard et al. 2017). In terms of time-bounded events, StitchFest is a hardware hackathon seeking to broaden participation in computing through collaborative arrangements (Richard et al. 2015). This corpus of research provides insightful outcomes; however, further methodological guidance is needed if we are to increase the number of organizations and institutions that are not experts in gender or educational studies and are willing to organize time-bounded events to foster gender equity in computing.

‘Women’ is not a singular, mutually exclusive category that can be used to guide design and interventions. Instead, women’s experiences are as diverse and fragmented as those of men or non-binary people. Thus, the gender categories cannot sufficiently be used as a guiding principle for design. Instead, we used the FemTech principles. The FemTech principles are not instantiated as recommendations but as guiding questions to aid the design and assessment of concrete activities.

The FemTech Workshops

The FemTech workshops add to the larger FemTech research agenda where we study the phenomenon of gender equity in computer science (developing knowledge) while intervening in practice (addressing problems) (Mumford 2006). The workshops began as an educational initiative seeking to create opportunities for young women to explore their interests in developing digital technologies and were organized as interventionist activities, meaning that our intention was to intervene through an activity, and then to learn about our phenomenon of interest. Our workshops were carefully crafted to make inquiry into the interests of our participants (Mumford 2001).

We conducted two workshops at the University of Copenhagen, Denmark. The first took place on April 6, 2017, from 9 am to 5 pm. The second took place on March 14 and 15, 2018, from 5 pm to 7 pm and from 9 am to 5 pm. Both workshops invited only young women since we intended to create an environment that avoided replicating gender stereotypes in computer science education as being predominantly male (Cheryan et al. 2009, 2013).

Recruitment for the first workshop was done by approaching 14 high schools’ headmasters. Concretely, the first author of this book emailed and telephoned headmasters to explain the project and workshop design. Through the replies of the headmasters, we connected with math teachers at ten schools. We encouraged them to promote students who attended math classes but having no previous programming experience and without showing explicit interest in computer science. This approach was motivated by an interest in fostering curiosity in computer science among people who had not considered computing before. The reason for requesting math skills was that, in case any of the participants decided they would like to study computer science, having passed math classes is a requirement for acceptance into the program. The invitations were sent to different areas of the city having very diverse socioeconomic profiles. We also published an open call on Facebook in a closed group for IT teachers in Denmark and on the university’s website. Finally, we reached out in our local professional network. For the second workshop, we relied on these existing contacts with high schools.

In total, 24 participants were invited by their math teachers to the first workshop; only one participant answered the open call. A total of 26 participants were invited to the second workshop. Participants’ age ranged from 16 to 22 years (mean: 17). As part of the design of the intervention and the descriptions sent to the high schools and teachers, we deliberatively did not include the terms ‘coding’ or ‘programming’. The reason for this was that the main goal was not to teach participants how to program but to open opportunities for participants to relate computer science to their interests.

Event Design

The workshops took place at the university campus. Participants sat in groups of four and collaborated in groups of two (one group had three participants in the first workshop). Similar to other initiatives (Mayer and Tikka 2008; Frieze and Quesenberry 2015; Sax et al. 2018), we designed the workshops as a collaborative activity to challenge the normative narrative that stereotypes computer scientists as individuals with few social skills, and programming as a solitary activity (Cheryan et al. 2013). We split the groups across the different schools to ensure that no participants had worked together previously (Fig. 5.1).

Fig. 5.1
figure 1

FemTech workshop events

The workshops began with an icebreaker activity. Afterwards, participants were introduced to electronic circuits and micro-controllers and to the Arduino IDE, which was installed on all individual laptops during the workshop. In both workshops, there were six teachers in the room. In the first workshop there were five women and one man; in the second, four women and two men. In the second workshop we included computer science students as teachers.

To ensure ownership of the code, teachers were instructed not to touch or take control of keyboards, breadboards, and so forth; instead, we made suggestions and answered questions. In this way, all editing of and modifications to the code were made by participants. After a basic introduction, we presented the interactive products. Participants engaged in different activities, which included programming, modeling (e.g., sewing and foam cutting), and connecting the micro-controller to the Internet and pulling information from the server.

After the workshops, some participants proactively organized activities at their high schools. These included a presentation on what they had learned (IoT, e-textiles, micro-controllers) and a video showcasing what can be done using motion sensors and how to encrypt messages on Facebook. In addition, two participants were interviewed by a journalist after the first workshop. The article was featured on the main page of a local newspaper. We joined the presentation and observed the interview (Fig. 5.2).

Fig. 5.2
figure 2

FemTech in the newspaper

FemTech Artefacts

The center of our workshops was the FemTech artefacts: Cyberbear (first workshop) and Cryptosphere (second workshop). Both artefacts were inspired by critical design artefacts (Menéndez et al. 2017), as they not only question normative narratives but also propose alternative agendas for the perception of computer science. Let’s look more closely at both designs and how they are based on the FemTech design principles.

Cyberbear Design

Briefly, Cyberbear is a hacked IKEA bear transformed into an IoT artefact by adding a WiFi-enabled micro-controller. Concretely, this IoT artefact allows participants to look up their personal high school schedule online and retrieve information about whether the first module on that day was canceled (Fig. 5.3).

Fig. 5.3
figure 3

FemTech cyberbear artefact

The artefact is actuated by an e-textile bottom (Strohmeier et al. 2017), which participants created and sewed on the bear. The output mechanism is LEDs, which blink according to how the students had programmed the output signal: usually green for canceled, allowing them to sleep longer.

When we created Cyberbear, we wanted to make an artefact that, through its very physical expression, would challenge fundamental stereotypical understandings and narratives of computer science. We discussed the design choices and their relevance as part of an interventionist inquiry. The design decision to make Cyberbear in soft materials using e-textiles was meant to shift the idea of computer science as ‘something hard’ towards computer science as ‘something soft’. Thus, by connecting digital and analog materials to the Cyberbear artefact, we manifested the sociomaterial relational connections between what is digital and what is material and produced an alternative narrative depicting computer science as reaching beyond the computer screen – as being more than what occurs in the digital world and including the physical world. The material choice challenged the taken-for-granted assumptions about the boundaries of what is relevant for computer science. By bringing in IoT technology through a Wi-Fi-enabled micro-controller design, we demonstrate how programming and creating technology is not limited to keyboard and touchscreen interaction but includes physical, material interactions. The interactive opportunities of Cyberbear also connect the FemTech artefact with participants’ everyday lives by linking the artefact to a technology they use every day – their high school online schedule.

Cyberbear was presented to participants as a relevant narrative (waking up in the morning) that has a direct impact on their lives. The purpose of contextualizing Cyberbear within a larger context of critical thinking was to trigger participants’ interest in culturally relevant technologies (Scott et al. 2010). The artefact was framed as “Hacking an IKEA bear”, since hacking a teddy bear with micro-controllers and electronic components would connote a different activity than one would normally expect to take place within computer science. Finally, we wanted to challenge basic assumptions about skills and expertise relevant for computer science (e.g., as only including programing) and instead show how alternative skills such as sewing to combine digital materials are also relevant. Thus, the choice of materials (e-textile, digital, and analog materials) related to the activity (to create and design Cyberbear and potentially changing the design expression) was embedded in the artefact and the story about the artefact (Fig. 5.4).

Fig. 5.4
figure 4

First workshop (artefact and event)

Cryptosphere Design

Cryptosphere manifests encryption as part embodied interaction through movement. Concretely, Cryptosphere is a hollow polystyrene foam sphere, digitalized by a Wi-Fi-enabled micro-controller connected to a gyrometer and accelerometer, which allows the artefact to be connected online while sensing movements as input. As output signals, Cryptospheres have an attached LED strip that reacts based on user input from movements (Fig. 5.5).

Fig. 5.5
figure 5

FemTech cryptosphere artefact

Unlike Cyberbear, Cryptosphere is a collaborative technology. Cyberbear is a single-user artefact, where the person using the artefact is interacting with their own profile on a high school scheduling system, Lectio. Cryptosphere is a personal artefact that links to the user’s Facebook profile and can be used to communicate with others who have a Cryptosphere using color-coded encrypted messages. The interaction flow between two spheres is that a message is written on a specialized message board and uploaded to the sender’s Cryptosphere. The sender then creates an encryption code using movement and gestures to set the color-coding of the message: for example, choosing light blue, red, and orange. Next, the now encrypted message is uploaded to the shared Facebook group, for everyone to see. However, to read the message, the receiver must know the color-coding and can then download the message to their own Cryptosphere and decrypt it using the color code. The encryption mechanism is created as a mixture of movements with the sphere, which results in a set of colors (each LED on the LED strip supports 250 combinations, and with up to 12 LEDs you can create multiple encoding combinations). For others, reading and decrypting the messages requires them to know the exact color combinations and how to move the Cryptosphere in creating these, which allows other participants to “read” these movements through motion sensors (Fig. 5.6).

Fig. 5.6
figure 6

Illustration of cryptosphere use

In designing Cryptosphere, we wanted to link some of the important computer science areas and technologies so that participants could gain insight into the history of the field. Among the important historical events in computer science is the story of breaking the Germans’ Enigma encryption and the role of Alan Turing and Joan Clarke in breaking the code. Turing is famous from his historic role in developing the field of computer science, illustrated by the naming of the equivalent of the Nobel Prize in computer science – the Turing Award – in recognition of his contributions. However, less known is Turing’s close colleague Joan Clarke, an extraordinary mathematician working at Bletchley Park to break the Germans Enigma code during WW2. In designing Cryptosphere, we wanted to frame the artefact within the history of encryption and link to the history of women in computing by manifesting the practice of encryption through the artefact. In this way, we wanted to give visibility to hidden minorities as part of the design. Zooming in on the interaction features (input/output) – the sensors and actuators of Cryptosphere – our interest was in taking the e-textile button from Cyberbear to the next level. Cyberbear had one only interactive possibility – pressing down on the e-textile button – and then all the interaction was driven by the code, producing only the output in the form of LED blinking patterns being red or green. The interaction opportunities of Cryptosphere are a complex coordination of sensor input (gyro and accelerometer) and how these are connected and displayed within encrypted LEDs of multiple colors. In this way Cryptosphere manifests how designing digital technology interaction is about far more than touch screens and keyboard input, and thus challenges the taken-for-granted assumptions about what kinds of devices and artefacts can be created through digital interaction. Further, the combination of polystyrene foam as the physical material and the digital programmable micro-controllers produces alternative narratives about the potentials of computer science. Thus, we combined the story about encryption with an artefact facilitating a cooperative activity using digital and analog materials, thus creating a FemTech artefact to serve as the centerpiece for the second FemTech workshop. Computer Science student Christoffer Belange took part in designing and implementing Cryptosphere and wrote his thesis on the project (Fig. 5.7).

Fig. 5.7
figure 7

Second workshop (artefact and event) Online

To facilitate the FemTech workshops, and to support the workshop participants, we decided to use the Arduino IDE and teach participants to program their artefacts using the standardized micro-controller programming – similar to C-programming. Further, we, as part of the workshops, installed all necessary programs, drivers, and so forth on participants’ own laptops, and after the workshop all equipment was given to the participants to take home.

In introducing micro-controllers, including installing the Arduino IDE on participants’ own laptops and providing them electronic components (wires, resistors, etc.) to take home, we wanted to enable them to leverage their new skills and continue to use these at home. Thus, the design structure of the artefacts allowed participants to continue to design at home – also after the workshop.

We wanted to create a space for participants to continue the dialogue after the workshop. Here the purpose was for participants to share pictures of their accomplishments after the workshop – and potentially to make contact again at a later point. Therefore, we created a closed Facebook group (Fig. 5.8).

Fig. 5.8
figure 8

FemTech Facebook pages setup

We also created the website, which included a detailed, step-by-step description of how to create the FemTech artefacts, using open-source materials, inviting others to join and use the same concept elsewhere (Fig. 5.9).

Fig. 5.9
figure 9

Step-by-step creating cryptosphere

Moreover, the website was continuously updated with activities from the research project, including summaries and photos of past events and announcements of future events. The website continues to exist (

We followed up with workshop participants though a Facebook page for them only. We asked them to share pictures of their artefacts there (Fig. 5.10).

Fig. 5.10
figure 10

Facebook setup: sharing pictures of cyberbear and cryptosphere online

In 2017, we also visited two of the high schools after the workshop: Ørestad Gymnasium and Albertslund Gymnasium. At Ørestad, one of our participants presented Cyberbear, how she hacked her own Lectio profile, and created the e-textile button. At Albertslund, two students were interviewed for a local newspaper and presented what they had created. Two Ørestad students also created a video presenting Cryptosphere (Fig. 5.11).

Fig. 5.11
figure 11

Student presentation at Ørestaden

However, other than these immediate interactions, we did not have the resources to follow up on the long-term impact on specific workshop participants. We can, however, see that as the FemTech workshop has developed into a yearly event, the number of participants has increased, and when we asked new students entering the bachelor’s program in computer science, several had joined the FemTech workshop earlier.

Documenting and Learning from the FemTech Workshops

The FemTech workshops were documented through detailed, rich observation notes and audio files of participants’ interviews. In addition, parts of the workshops were video recorded. Following the first workshop, we emailed a questionnaire to all participants. We received 19 responses. For the second workshop, we email a pre- and post-questionnaire, for which we received 23 and 21 responses, respectively.

Most of the responses were in English, and we translated all material into English and then imported everything into ATLAS.ti. We then analyzed the complete material using inductive thematic analysis. This bottom-up approach ‘allowed the data’ to guide our analysis and point us to interesting directions (Glaser and Strauss 1967). This analysis yielded 373 empirically driven categories (codes), clustered in 28 groups such as “assumptions regarding IT”, “sewing as stereotypical activity”, and “positive opinions towards social aspects of the workshop”.

In analyzing the data, we became intrigued by the impact of the design of the FemTech artefacts and activities on students’ experience of the workshop. Following this insight, we began to detect patterns in the responses across participants. More precisely, through our analysis, it became evident that there were distinct differences in the way the participants experienced the activities, and that many of these differences were related to the methodological choices we took to make the event inclusive. In addition, the distinct differences were often based on their understanding of computer science and prior knowledge. We found that the responses could be categorized into three main classifications of perceptions and reactions to the FemTech workshops and FemTech artefacts: ‘Computer Science is not for me’, ‘Computer Science is maybe for me’, ‘I am a Computer Scientist’.

Computer Science Was Not for Me

Although we intended to include only participants with no prior expertise in programming, it turned out that both workshops attracted a variety of participants ranging from no expertise to relatively high expertise. This variety, while not originally intended, gave us the opportunity to explore differences among participants. These results show that the workshop challenged the normative narrative on computer science and that most participants embraced our alternative narrative – but not all of them did.

The fact that the participants joined the workshop through personal invitations by their teachers influenced the group’s composition. Some participants claimed that even though they had opportunities to engage with technology in other situations, technology did not appeal to them. Others expressed that their lack of engagement with technology and programming was influenced by their lack of interest in what can be considered the “stereotypical aspects of technology”, such as gaming and robots:

When PS, Xbox, and Wii emerged, my brother was one of the first buyers, as he was a gamer, unlike me. I was not that much interested in video gaming, it did not really appeal me as colours and white canvas did. So, I did not really try anything with technology or programming other than playing some video games. However, I always had ideas of inventing a machine, such as inventing a running machine that convert the output into electricity. [P9, 2017]

What is interesting with the above quote is that after the workshop, the participant expressed a broader idea of the nature of computer science, and of how inventing technology to collect and track running activities could be included in the definition of computer science in a way that was appealing to her. Indeed, many participants expressed being positively surprised about encountering a context different from the stereotypical representations of computer science:

I never really noticed the computer science education because I believe it is an all boys/gamers place. Or my prejudice was that only gamers study computer science there to become game developers. But now I have found out that women study there too and people study at [department’s name] for many different reasons and not only because of a gaming past. [P3, 2018]

This quote suggests that prior to the workshop, the participant assumed that technology development and programming were not for her. However, the workshop changed that view and, as she also explained in the questionnaire, made her think that it would indeed be possible for her to learn how to develop technologies. The important point for her was that she experienced being able to engage with the topic and be successful.

Working with everyday prototyping materials (textiles, foam) challenged several of the participants’ assumptions about computing. More concretely, the choice of materials helped move away from a representation of computing as a complex and tedious activity; instead, the workshops exemplified that it is possible to develop technologies through low-cost and hands-on activities:

I learned that creative ideas can create new technologies with fairly simple equipment. There are countless ways to use, for example, one LED strip, micro controller and motion sensor to create something. [P4, 2018]

In addition, the choice of using physical prototyping materials (micro-controllers, sensors, actuators) and collaborative activities also seemed to influence the experience of learning digital technologies as more attractive. Working with physical interactive devices challenged several of the participants’ perspectives on programming from an uninteresting activity to a creative activity, as illustrated by the following quote:

Most importantly is that I have changed the way I used to see technology. I learned that technology is not really sitting on a chair and programming for the whole day, but it really is not boring at all! and that one can invent anything and make it come true as long as one learns the basis and have patience. [P9, 2017]

Analyzing the responses from the participants with no prior experience in computer science, it is clear that the workshop design succeeded in drawing interest and providing participants an experience of agency and ability in working with technology, which they did not have prior to the event. The fact that the interactive product was deliberatively designed to bring success after 1 day allowed those who had never worked with technology before to try and not be afraid of engaging with programming or developing digital technologies.

Another grouping of participants had previously tried to engage with computer science but found those experiences frustrating and excluding, leading them to conclude that computing was not for them. Prior experiences with programming classes or events seemed to have influenced their expectations for the workshop. For example, one participant, who had tried some basic programming at school, explained:

I thought that we would be doing a lot of coding or doing something with computer hardware. I was nervous because I do not have any experience. [P17, 2017]

Indeed, the data suggested that emotional distress prior to the workshop was related not only to the risk of lacking the right technical capabilities but also to the social experiences of participation, as exemplified in the following quote:

I have really liked this workshop. Usually I am quite shy and do not feel good about meeting new people, but I was surprised about how easy it was for me this time. [P6, 2017]

The workshop was designed to make everybody feel welcome. Participants not only learned new things but also developed a network of contacts across the participating schools. The effort involved in the design of the social structure turned out to be crucial. Many participants highlighted that they really enjoyed the format of the workshop and how it facilitated meeting new people while creating a convivial atmosphere.

The data also suggest that those who had previously tried to get engaged with programming but had dropped out – or did not find it interesting – found especially important that the workshop combined many different materials and activities. For example, one found that the proposed activities tackled many different interests:

The workshop had both: theoretical work and some practical as well, there was something for everyone; sewing, programming, breadboards. Everyone seemed happy and satisfied. [P3, 2017]

The above participant stayed after the workshop had ended to finish the e-textile button. In the evening on the day of the workshop, she also posted a picture of her finished Cyberbear to the Facebook group (Fig. 5.12).

Fig. 5.12
figure 12

Facebook cyberbear picture

Similarly, another participant, who had reported previous experiences with trying to learn programming without success, appreciated the combination of different materials and highlighted it as one of the strengths of the workshop and a reason for suggesting that others participate in future events:

I would tell them [to her classmates/friends] about the fascinating way one combines soft technology and hard technology and stitching. [P18, 2017]

Clearly, the combination of materials and micro-controller programming was deemed exciting by participants who had not previously experienced computer science as relevant to them.

Computer Science Might Be for Me?

There were also participants who had prior experience at the intersection between design and technology, such as web and product design; however, they did not consider themselves as having expertise in developing digital technologies. Several of these participants reported having only limited technological skills prior to the workshop, even if they also reported extensive experience with HTML and CSS. In general, participants often did not mention skills such as experience with conductive materials, breadboards, and wiring as relevant to developing digital technologies.

The data show that participants with prior and unacknowledged technical skills found it particularly important that developing technology entailed creating something meaningful in a concrete context, where it could serve a purpose. This was exemplified by one participant who had quite extensive experience in web design and found that it was “cool to see how to incorporate computer science in everyday life” [P1, 2017], or by another participant, who had studied design of interactive products at school, and thought that it was “fascinating to create technology and see it ‘come to life’” [P11, 2017]. Similarly, for other participants, programming was not relevant as a goal in itself but only acquired meaning when it could be used as a means to act in the world:

I have attended a programming camp, 2 workshops and I have tried to study it at my Efterskole, however, all I can do at this point is Lua and basic Arduino. I understand basic java, but I am unable to write it. I want to be able to write code that actually does something, and I hope to understand how codes can interact with machinery to get a job done. [P1, 2018]

For these participants, developing an interactive product contextualized in their daily lives – by checking their class schedule or sending encrypted messages through social media – influenced their engagement in the workshops and their interest in computing. This group of students expressed how it was important to be introduced to theoretical concepts in programming and subsequently be able to instantiate them in a concrete, meaningful product:

I thought […] that it was a smooth transition and was pleased to experience that the abstract programming functioned in real life and that we were able to create an interactive product (the cyberbear) with it. [P10, 2017]

These results support not only the importance of learning through practice but also how legitimating skills beyond programming as part of computing is important to making computing inclusive. Shaping the workshop around an interactive product not only supported learning by doing but also prompted participants to think about the use of the product and reflect on it in terms of design and innovation. For example, participants emphasized the importance of considering the product’s aesthetic aspects. Concretely, some participants commented on the appearance of the e-textile button, and one suggested that it should be improved so it did not look like “a broken arm”. Another student described that she would have liked to work on the Cryptosphere so that it looked like a finished product and not a prototype. Another participant stressed that creating the interactive product also entailed reflecting on design constraints:

It was exciting to work with the production of the teddy bear, when you still have to think a part of that power conducting wires not to touch each other and so on. [P1, 2017]

Some participants had relatively extensive experience in programming prior to the workshop. Their skills ranged from scripting languages to object-oriented programming. These participants had learned programming at school, had proactively engaged in coding activities with friends, or had used online educational resources (Code academy or Khan academy). Some embraced the workshop activities and the interactive product – especially the collaborative engagement. The challenge for them was that when they engaged in programming activities, they usually experienced the activities as working alone, which often negatively influenced their engagement:

Currently, I don’t do any programming, since I could not find a community or opportunity though I definitely enjoyed it while taking it at school. Over the summer, I briefly tried to get back into programming via ‘’ but it required self-learning a lot of new scripts so after learning HTML and Java I dropped it. As a solitary activity, it wasn’t extremely enjoyable. [P5, 2017]

Even these experienced participants explained that the workshops helped them feel more confident about their knowledge and skills. In addition, the workshops seemed to open up possibilities for combining technology with other, varied, interests. For example, some explained that after the workshops, they had become interested in exploring technology with respect to other topics, such as medicine and engineering. One student explained that prior to the workshop, she had wanted to become a medical doctor but that now, after the workshop, she was considering education in technology innovation for healthcare. Similarly, another student described that the workshop made her want to explore the potential of technology with respect to art. Another participant expressed her perspective on computer science after the workshop thus:

I don’t think I would take an education in Computer Science since I’m about 99% sure I want to do mechanical engineering. However, I’m more interested in Robotics as a subsection of mechanical engineering now, so I will definitely look more into that topic. [P5, 2017]

The workshops thus helped reveal capabilities of technology development that participants had not previously considered despite their prior interest and expertise in programming. In this way, the workshops incited participants to think about combining their programming expertise with other academic interests in the future.

I Am a Computer Scientist

The final grouping of students had previous experience in and knowledge of programming and were quite critical of the workshops. Interestingly, their critiques were mostly based on the misalignment between their expectations and their experiences of the workshop. While they found working with e-textiles, foam, micro-controllers, sensors, and actuators interesting and novel, they also expressed that the workshop activities did not match their expectations of what a computer science workshop should be. One such participant expressed how the interactive product of the first workshop was not related to computer science in any way:

Cyberbear was strangely irrelevant and bored me. It had nothing to do with technology. [P16, 2017]

Many of the critical comments referred to the activity of connecting e-textiles together through sewing. The fact that the first workshop required sewing was largely discussed during the activities and in the questionnaires. Few participants thought of sewing as enjoyable. For some, it was a tedious and unfamiliar activity, requiring a lot of time. However, for those who knew how to program and were critical of the workshop, sewing was not only tedious but also problematic because it reinforced stereotypes. In this regard one participant explained:

I felt a bit forced to be a ‘girly’ girl when it isn’t what it is all about. Maybe a more down to earth programming experience with the hands more into the dirt next time? Try microbit? [P7, 2017]

This is somewhat paradoxical if we consider that they liked e-textiles and that sewing is the activity required to combine pieces of e-textiles, in the same way that soldering is the activity required to join metal pieces. If we consider a scenario in which we had used traditional conductive materials, soldering would have been required to connect them. If we assume that soldering can be seen as an activity traditionally performed by men, we might speculate whether participants would have felt forced to be a ‘manly’ girl? Alternatively, the empirical observations reflect a larger concern, namely that participants wanted to experiment with activities that are “gendered”, because they wanted to escape the narrow script of their gender roles and try something either “neutral” or “opposite”. In this way, their expectation for the workshop might be that they wanted to be exposed to a narrative opposite of expectations, and then they felt forced into a script they were not interested in.

Moreover, the data revealed different assumptions regarding computer science and what is – and is not – included. It is interesting that the normative narrative about computer science influences the criticisms. Indeed, participants’ answers to the questionnaires revealed assumptions regarding their perspectives on computer science, as illustrated in the following quote:

I was already interested in IT, and was already considering studying IT or something like it at a university. My opinion has not changed since the workshop, but I am pretty certain, that if I had known little about IT before the workshop, my interests wouldn’t have changed for the better since the workshop didn’t really show a good side of IT. [P13, 2017]

Note that what some participants believed qualified as proper, or improper, is linked to their references to previous skills or assumptions. The data suggest that the stereotypical narrative of computing made them differentiate between what was part of computer science and what was not. For this group, designing situated technologies was considered outside “proper” computer science, as illustrated in the following quote:

I was already considering it [studying computer science] and I do not feel that this was a proper introduction to computer science itself, more of an introduction to interactive design and how to incorporate technology into everyday situations. [P1, 2018]

It is crucial to note that while the workshops were inclusive in terms of inviting new participants, who had not previously seen themselves as fitting in, the format also challenged the normative narrative on computer science, which risked pushing away participants who already subscribe to the existing narrative. Thus, by pushing for one type of inclusion, we risked excluding others. Indeed, some participants subscribing to the normative narrative had different expectations for what inclusion would look like:

I think my expectation was more like ‘We are going to make some killing- zombies-videogame or something’ and kind of get the boy/girl differences and expectation according to IT away. [P2, 2017]

The above perspective clearly reinforces the normative narrative that technology is about ‘killing-zombies-videogames’. Interestingly, it also provides us new insights into how some participants had different perspectives on inclusion: namely, that inclusive participation entails supporting minorities to become part of the normative representation – without questioning the fundamental structures. This group of students had already experienced computer science as an attractive domain, and their challenge was related to fitting in to the existing social and cultural structures. These might be examples of the few (the 7–9%) who already choose an education in computer science at the university.

These results suggest that even though this group of young women represent a minority in computer science, it is not an excluded minority in terms of interest. Instead, the exclusion they experience is linked to the gender expectations they meet when trying to fit in. They wanted to develop ‘zombie games’ and get rid of the ‘boy/girl’ expectations they had experienced. This insight also highlights that making the field of computer science more inclusive by relying on minorities within the field experiences risks posing limitations. Actually, the results suggest that their efforts in making themselves fit in to the field might place them in a defensive mode, insisting on the normative narrative, and therefore refusing change.

Embracing Alternative Agendas

The FemTech workshops succeed as a scaffold for designing time-limited events that help participants engage with technology design while being challenged on basic assumptions about computer science. In both workshops, all participants managed to create, build, and implement a FemTech artefact – either Cyberbear or Cryptosphere – successfully. Moreover, all participants managed to install all drivers and the Arduino IDE on their personal laptops, which meant that they had the technical resources if they choose to change anything in the code or re-mix it later.

We structured the workshops so that even though each participant made their own FemTech artefact, they worked in groups of two and were introduced to pair programming as a working method. This focus on the social element in technology development was an important feature of the workshop, as part of the purpose was to begin socializing participants into considering that they themselves might be able to achieve and work together on the kinds of agendas they find interesting – and that technology design could be a potential element in this.

Most participants did not know each other prior to the workshop, and we wanted to support all in experiencing a belonging – also in case some participants afterwards might want to continue in any of the computer science degrees around Denmark – knowing others from different high schools who might do the same and that being able to reach out would be supportive.

The first workshop took place on 1 day, and we experienced that the program was long, leaving little time for breaks – and since we wanted to include socializing, we extended the second workshop for one evening, and then 1 day. The evening before the actual workshop took place as a socializing event with food combined with installations of software and drivers. This turned out to be time well spent. It also meant that we could begin directly on the content the next morning.

Introducing the workshop format initially for the participants included introducing them to the FemTech artefact they were to create. This included the story behind the artefact – and here a simple story (like sleeping late) was easier to convey than the history of encryption, since participants were eager to simply begin building and programming. The narratives around the design artefacts are important because this is what makes it engaging and potentially challenging of participants’ previous perceptions. However, finding ways to display and manifest the alternative narratives as part of the crafting and making of the artefacts works better. We also found that the DIY aesthetic of the artefacts made participants interested in adding and changing part of the design both digitally and physically – e.g., re-designing the blinking patterns of LEDs on the Cyberbear or decorating the Cryptosphere like the Death Star from Star Wars. These small design changes were part of personalizing the artefacts.

Part of the purpose behind the design of the FemTech workshop was for participants to learn through experimenting and examples – and then to reflect on their experiences as potential future ideas for how technology could be used in novel ways. Since time was short during the first workshop, there was not really time to reflect together – however, we could see in the follow-up questionnaires reflections on the potential use of technology in diverse domains: e.g., one participant explained how health and computer science could be combined. During the second workshop, we spent more time on reflections together, and through drawings it was clear that participants drew potential links between their knowledge of micro-controllers and motion sensors and different domains and usage (Fig. 5.13).

Fig. 5.13
figure 13

Femtech workshop, second workshop

Most participants in both workshops embraced the alternative narrative, which we introduced through the FemTech artefacts. However, we also found that our empirical insights demonstrate the diverse and fragmented nature of women’s experiences, where not everyone experiences computer science as an alien culture (Sproull et al. 1984). Women are not a distinct group sharing all the same features, characteristics, and interests. Instead, women – like all other genders – have different interests and concerns. This points to the importance of creating and demonstrating the wide variety of potential narratives that exist in parallel and simultaneously. However, since there are specific gender minorities in computer science, it is important to make extra efforts to actively not exclude minorities and favor the majority. Further, these insights are not narrowly linked to gender but instead apply to all kinds of diversity dimensions. When we facilitate welcoming a minority, we also facilitate people from majority groups but with different interests fitting in. Based on our experiences, we propose three main considerations that can help guide the design of events and activities to foster equity in the very design. These are sociomaterial-design, social belonging, and gender representations (see Table 5.1). Let’s consider each in turn.

Table 5.1 Factors and guiding questions that provide methodological guidance when designing workshops to foster gender equity

Sociomaterial-design includes considerations of how participants comprehend the boundaries of the domain of computer science and its impact and potential reach in the outside world. Designing activities where you learn about technology for the sake of technology is interesting and engaging for participants who already have an interest in technology; learning about culturally relevant technologies can be engaging for participants without such pre-existing interest. However, previous research has highlighted tensions between culturally relevant approaches and traditional approaches to skills development (Enyedy and Mukhopadhyay 2007; Tissenbaum et al. 2019), such as programming or coding. In our experience, seamlessly creating learning activities that combine reflective activities on the societal impact of technology and low-level programming exercises is difficult. Our workshops show promise for how the digital-analog artefact approach is one way to combine the two. Creating specific artefacts, which include design activities in combination with programming, can extend the definition of computing while allowing for diverse interests. For example, the design of the Cryptosphere (storytelling, materiality) introduced privacy issues of protocols while embedding practical exercises to control sensors and actuators.

Sociomaterial-design also includes considerations of which types of domains are used in concrete examples as well as in a general teaching approach (Scott et al. 2010). These decisions entail considering whether to include domains that can be easily recognized as relevant for computer science (e.g., video games) or other types of examples that are less obvious but equally relevant (e.g., biology, art). If we had made the participants create a zombie-killing game, we would have confirmed the expectations of some of our participants by confirming their bias towards what belongs in computer science. However, challenging the normative narrative, and proposing an alternative, allowed us to open up the domain to be relevant for other participants who are currently excluded from the gaming narrative as a computer science domain.

Interestingly, after the workshop all participants found themselves potentially included in technology development, although in different ways. Most participants embraced the alternative narrative introduced at the workshop. Thus, their technological perspectives extended the definition of computer science to include various parameters, such as different types of use (sleeping longer in the morning, encrypting messages on social media), different kinds of materials (e-textiles, polystyrene foam), and different kinds of activities (design-oriented activities). In addition, they expressed an interest in exploring the potential of using digital technology development to innovate in other domains, e.g., healthcare, art, and engineering.

Some participants refused our alternative narrative and stated that we ‘luckily’ did not scare them away with our intervention. This was especially true in the first workshop because of the use of e-textiles. Some participants did not enjoy working with e-textiles and described them as too “girly”. That some of the participants rejected this material challenges prior work suggesting that working with e-textiles can minimize the sense of ‘gender inauthenticity’ (Faulkner 2000; Weibert et al. 2014). Our results reveal a complex scenario in which some participants did not want to express themselves through e-textiles, because it was not aligned with what they thought was within the reach of computer science. Therefore, initiatives seeking to open up participation through alternative and critical approaches (Menéndez et al. 2017) need to work to legitimate those activities as part of a broader understanding of computing through structural changes. Otherwise, these initiatives risk designing engaging activities for under-represented minorities that remain disempowered in the broader context (Hicks 2017; Bjørn and Rosner 2021).

Social belonging includes considerations of how prior positive or negative social experiences with computer science matter in shaping future experiences. More concretely, whether participants feel they belong or are alienated (Sproull et al. 1984; Frieze and Quesenberry 2015) depends on the social organization of activities and contexts. All participants offered positive evaluations of the social engagement and of experiencing programming as a social activity. Indeed, the workshop highlighted the importance of collaboration in computing, which can be also considered an alternative to the predominant stereotype of the lonesome computer scientist in the basement.

More concretely, computing is often depicted as an individual activity rather than a collaborative endeavor, and such a depiction shapes the nature of inclusiveness. For example, the extent to which computing is displayed as a collaborative activity displays the value of group activities and discussions and of finding the best solutions together with others. In addition, our collaborative approach challenges predominant representations of success: from individual geniuses to groups of people having complementary skills.

If we want changes in the demographics in computing, it is important to consider the recruitment process for the activities. Concretely, by personally inviting participants, we were able to engage with young women who would not proactively engage with programming and technology development themselves. Thus, we extend existing research focused on self-driven adopters (Buechley and Hill 2010; Tabel et al. 2017) towards not-self-selected participants. Finding ways to engage people who do not self-select is a huge challenge if we want to a have long-term impact. When the math teachers promoted the event as a ‘programming activity at the computer science department’, the expectations for the activity were not aligned with our workshop design. This could have a positive or a negative impact, depending on participants’ pre-existing interests.

Our findings show that experiencing social belonging to an academic field and practice is also shaped by how society embodies certain gender identities in the use of materials (e-textiles, polystyrene foam) and activities (sewing, foam modeling). Our choice to introduce these materials engaged the majority of participants and thus promoted inclusion (Weibert et al. 2014; Richard and Giri 2017). However, the sewing activity was seen as a gender-laden activity; thus, it alienated a minority of our participants, who described feeling forced into a stereotypical gender representation.

Finally, the design of our event as ‘women only’ was aimed at providing an environment where people felt they could join and be themselves (Fox et al. 2015). This choice was explicitly mentioned and appreciated by many participants, who highlighted the social interaction and structure of the workshop as positive and welcoming. This choice amplifies our interest in change, and it allowed us to explore the diverse nature of the category of women. Still, to be truly open and diverse, future workshops should consider the gender spectrum beyond the binary (Henwood 2000; Vitores and Gil-Juárez 2016). To accommodate this, we in the current call for participation in the FemTech workshops explicitly phrase the audience as open to other genders beyond binary. Concretely, we write: “we use an inclusive definition of women and invite transgender, genderqueer, and non-binary students to join, as well as everybody who identify as women” (DIKU 2022).

Gender representations remind us how choices in the design of the event, dynamics, artefacts, or materials can have gendered connotations. When we designed our activities, we were cautious about whom to include as teachers (Scott et al. 2010) because we did not want to manifest the predominant stereotype that men know about technology (as teachers) and women know less about technology (as students). Thus, when inviting teachers, it was very important to us that most of the teachers were aware of these sensitivities. The leading teacher was a woman full professor demonstrating that women can also be successful computer scientists. It is critical to carefully consider which gender roles and stereotypes are introduced and embedded within the structure and context of the inclusive interventions.

Gender identity played an important role for the participants in our workshop, who also displayed their experiences in their individual descriptions of having a particular gender (girly-girl and boyish-girl). We gained insights into what these gender types entailed for the participants and how they shaped the ways in which participants performed their gender through their appearance and actions (Cheryan et al. 2009, 2013). When participants rejected or embraced the sewing activity, the main issue they expressed was that sewing was a feminine activity, which they refused, rather than seeing sewing as an activity of ‘attaching materials.’

Our findings support prior studies of the gender transformation in computer science in higher education, which show that the essentialist approach to gender cannot explain the lack of diversity in computer science (Henwood 2000; Frieze and Quesenberry 2015). Our findings thus confirm that the gender imbalance in computer science education has nothing to do with the biological sex of students, and everything to do with structures and norms of the academic field and education in society.

Moving from gender binaries to gender representation, we need to consider how diverse gender categories extend the ways in which we design and evaluate inclusive and exclusive mechanisms. So, the question is: Did we manage to produce such an inclusive environment at the workshop? We did include participants who had been excluded in prior situations through the ways we organized the workshop topic, activity, social engagement, interactive product, et cetera. However, we did not manage to create a fully inclusive workshop. As a minority of the participants expressed, we were lucky that we did not push them away from pursuing a computer science education.

Essentialist approaches risk reinforcing the gender divide (Henwood 2000; Frieze and Quesenberry 2015; Bjørn and Rosner 2021) by reproducing existing gender stereotypes. Despite good intentions for an agenda of inclusion, essentialist approaches to gender and diversity might have totally opposite effects. When the results of experiments report differences between women and men, we neglect the role of education and society in shaping how we comprehend gender in particular ways. Approaches based on elements of what is stereotypically classified as a behavior performed by men or women in a certain society reinforce the assumption from this society instead of challenging the very existence of such essentialist classifications of gender in the first place.