In today’s connected world, everyone should be able to effectively interact with technology so they can access the benefits it provides. Technology creators should consider different kinds of user needs as they’re making software and hardware interfaces. To get there, tomorrow’s technology creators — today’s computing and tech design students — should be equipped with the skills they need to practice not only effective technology design, but inclusive design. Prior work indicates that teaching these skills can be difficult, though necessary if we want to build a more critical computing workforce.

In response to this need, we created the CIDER (Critique, Imagine, Design, Expand, Repeat) assumption elicitation technique. CIDER is a five-stage analytical design evaluation method that helps learners start thinking beyond “average” users by highlighting the many ways that technology can fail to meet diverse user needs and how it might be made more inclusive.

This post is written mainly for educators who are looking to integrate inclusive design topics into their computing or technology-related courses — for instance, people leading human-computer interaction (HCI), user interface/experience (UI/UX) design, or software engineering courses. We define a few key terms, describe and motivate the CIDER technique, and give an example of how an activity might look.

However, the basic CIDER framework has been used informally in other contexts — from pre-service teacher training courses on instructional design to workshops for youth critical digital literacy — and it seemed to work well there too!

Defining our terms

We use certain terms in specific ways in this post. Here’s what we mean:

• assumption: In this context, we mean designers’ (often implicit) assumptions about users’ capabilities, contexts, knowledge, or access to resources. If an interface design rests on an assumption that a user can’t fulfill, it can exclude people from effectively interacting with the technology.
• design bias: The ways that assumptions might make it disproportionately difficult for particular (groups of) users to interact with technology effectively.
• inclusive design: We broadly define “inclusive design” as an approach that tries to mitigate design biases. There are other definitions, but this is the one we’re using here.
• “average” user(s): The misconception that there is some standard set of traits, characteristics, capabilities, and/or knowledge possessed by “most” users, and that a design that works for the “average” user should work well for everyone. As it turns out, there’s no such thing as an average user. Designers that create tech for “averages” often just end up making things that only work well for socio-culturally dominant populations, disadvantaging folks from marginalized groups.

So, what is the CIDER technique?

As mentioned above, the CIDER (Critique, Imagine, Design, Expand, Repeat) technique is a five-stage analytical design evaluation method that helps learners think beyond stereotypical (and nonexistent) “average” users.

It’s one of the first educational techniques to use the lens of assumptions about users to help learners critically consider technology usability, leveraging a strategy we call assumption elicitation to help learners recognize and respond to design bias in existing technologies.

The goal of the CIDER technique is to make implicit, exclusionary assumptions embedded in designs visible to learners — and along the way give them some concrete practice doing inclusive design activities.

Why use CIDER to teach inclusive design skills?

CIDER targets common learning difficulties

CIDER was created to specifically to address several common learning difficulties computing students face in introductory design courses, namely:

1. Motivating the need to learn about critical design approaches and inclusive design by showing the pervasiveness of bias in everyday technologies.
2. Connecting design features to designers’ choices and beliefs about their potential users by revealing how implicit assumptions can impact the design of an interface.
3. Designing for human diversity while avoiding stereotyping of marginalized groups by involving learners’ own knowledge and having them engage with peers’ perspectives.
4. Moving from abstract inclusion goals to concrete actions and skills by scaffolding the process of identifying and reasoning about different kinds of design bias.

CIDER activities increase confidence, support design bias recognition, & help build actionable inclusive design skills

We did an initial evaluation of the CIDER technique’s efficacy in an introductory interface design course with university computing students. Learners did a series of six CIDER-based activities over 11 weeks on different technological artifacts. Among our results, we found that:

• CIDER activities contributed to statistically-significant increases in learners’ confidence in their abilities to practice inclusive design.
• Learners identified nine different kinds of design bias, surfacing embedded assumptions about users’ physical and mental capabilities, access to resources, prior knowledge, and surrounding environments.
• In follow-up interviews, some learners even used the skills they had gained through CIDER activities in subsequent design work (e.g. at internships or portfolio-building) to make the technology they made more inclusive.

More details on all of the above can be found in CIDER’s foundational journal paper (open access).

How does a CIDER activity work?

Through guided critique and brainstorming, CIDER help learners practice recognizing design bias and thinking beyond “average” users.

There are two roles, generally correlating to the typical roles of instructors/TAs and students.

• Activity leaders choose the technology that will be the focus of the activity and are in charge of creating the shared list of assumptions in the fourth (EXPAND) stage.
• Learners practice identifying embedded assumptions, brainstorm redesign options to improve inclusiveness, and engage with their peers’ responses to gain new perspectives.

The basic structure of each activity includes one set-up task and five stages:

1. Set-up task: Leaders choose an existing technology to be the focus of the activity. It can be software or hardware based, but it should have an evident interface or means of user interaction.
2. C: Learners CRITIQUE the technology to identify implicit assumptions about users present in the design.
3. I: Learners pick one assumption they identified and IMAGINE how it could lead to exclusion.
4. D: Learners (re)DESIGN the technology by brainstorming ways to change the design so that it doesn’t rely on the chosen assumption.
5. E: Leaders collect and create a shared list of assumptions from stage C; Learners use the list to EXPAND their knowledge of design bias using peers’ insights.
6. R: Learners REPEAT stages I and D using a new assumption from the shared list, growing their knowledge base for inclusive design.

This framework is flexible. It can be used for a quick 10 minute warm-up at the beginning of a class, or expanded into an longer session, doing the REPEAT stage multiple times with several different assumptions to investigate different instantiations of design bias. Learners might brainstorm assumptions individually or together in groups. However they fit best into your situation, CIDER activities and their adaptations can be a source of valuable insights and inclusive design skill development for learners.

An Example Activity: QWERTY keyboard

To illustrate the above framework with a concrete example, here’s one activity we used in our case study of the CIDER technique’s efficacy.

We did this study during a quarter of online teaching necessitated by the ongoing COVID-19 pandemic, so the format of this activity was both digital (through the Canvas LMS) and asynchronous. Learners completed stages C, I, and D on their own; the leader compiled a list for stage E and posted it to the course page; and learners picked an assumption from the list to complete stage R. Even in this format, we saw some pretty promising outcomes!

Set-up: Choose a technology [Leader]

To begin with, the leader picks some piece of real-world technology as a focus In this example we chose a desktop English (US) character QWERTY keyboard. When creating the activity, leaders should provide (at minimum) one or more images depicting the technology’s interface as well as a textual or verbal description of important features. If you’re doing this activity in-person, you might even bring in the technology and let learners interact with it themselves. The goal is to ensure learners have a baseline understanding of what the object is and how one might interact with it.

Any kind of technology might be used here, but keep in mind that the artifact’s prevalent interaction style will impact what kinds of inclusion learners focus on. For instance, in our case study, critiquing a keyboard led learners to focus comparatively more on motor/mobility issues, while a Google Home smart speaker led to more identified assumptions about hearing ability, and a critique of the Zoom video calling software surfaced embedded assumptions about computer capabilities and Internet speeds.

Even with the above, it’s important that learners all share a single target technology for their critiques and brainstorms. A shared object of critique is what enables the EXPAND stage to work well so learners can engage with their peers’ perspectives. If you want to try the technique on different artifacts, it’s better to conduct a series of CIDER activities on various technologies, spread out over time.

Stage 1: CRITIQUE [Learners]

Our prompt: What assumptions does this keyboard’s design make about users’ potential interactions with it? List as many as you can think of in the next 3–5 minutes. Bullet points encouraged.
For example: One assumption embedded in this design is that users can visually recognize Latin/Roman alphabet characters.

The goal of this stage is for learners to practice recognizing as many different kinds of design bias as possible. They can draw on their own experiences and knowledge of the world to identify assumptions.

In early technique development, we were worried that learners with no design experience might find this impossible at first. Luckily, that wasn’t the case! Learners’ experiences are a rich knowledge base to draw upon — see, e.g., the Funds of Knowledge teaching approach.

Stage 2: IMAGINE [Learners]

Our prompt: Select one of the assumptions you just came up with that you think is important to address. Write a 1–2 sentence scenario where a user could not use the keyboard as expected because of the assumption you selected.
This represents one way the design could exclude certain kinds of users.

In the IMAGINE stage, learners narrow their focus from many different kinds of bias to one particular instantiation of bias by choosing a particular assumption to brainstorm about. Learners write a short scenario in which the assumption prevents someone from interacting with the technology.

The scenario learners come up with here provides a means of making the effects of design bias concrete, helping to connect assumptions and reality. It also enables learners to continue integrating their own knowledge into the activity — maybe they write about their own experiences with this kind of bias, or maybe a close friend or family member’s.

Stage 3: DESIGN [Learners]

Our prompt: Brainstorm ways you might change the keyboard’s design to avoid the scenario you just wrote. List as many different potential solutions you can think of over the next 3–5 minutes — aim for ten or more. Bullet points encouraged.

In the DESIGN stage of CIDER activities, learners brainstorm different ways to make the technology more inclusive by proposing changes to the technology’s design that avoid or mitigate the scenario they just came up with. By doing so, they come up with concrete proposals to address one specific kind of design bias.

As with the first (CRITIQUE) stage, the goal for this stage ideas is quantity over quality. Not all the design changes learners propose will be feasible or even desirable, and that’s perfectly fine! Different solutions will be more or less effective, and no one solution will work for every single user (resisting that pesky “average” user notion again). Sitting with these nuances is one way novice designers can begin to grasp and navigate design tradeoffs when prioritizing inclusion.

Stage 4: EXPAND [Leader & Learners]

Our procedure: After learners electronically submit responses to the first three stages, the leader manually reviews each learner’s list of assumptions generated in the CRITIQUE stage. The leader creates a document consisting of all the different kinds of assumptions from learners’ responses, preserving breadth but removing close duplicates. The leader posts this list in a place learners can access and integrates it into a second electronic assignment containing the REPEAT stage prompts.

In the EXPAND stage, the leader uses learners’ lists of identified assumptions (from the CRITIQUE stage) to create an overall list of embedded assumptions present in the artifact. Since learners all have different backgrounds and perspectives, no two assumption lists will be quite alike. This means the resulting shared list is usually quite extensive, covering many different categories of potential design bias.

The EXPAND-stage shared list plays two major roles. First, it provides learners exposure to a wide array of different embedded assumptions, exposing them to new manifestations of design bias and new perspectives. Second, it’s the main source of feedback for CIDER activities, revealing assumptions that they “missed” in their own critiques.

In an in-person course, the form of this “list” might be more lightweight: Learners could discuss assumptions as partners or in small groups, or leaders might ask learners to simply call out a few assumptions they came up with. For our online course, where this stage resulted in an actual document, we found that learners appreciated being able to access the shared list after the activity concluded, using it as a resource in their final design projects. Options abound! So long as learners can access peers’ responses, all can work.

Stage 5: REPEAT [Learners]

Our prompt: Select another assumption from the collaboratively-generated class list that you think is important to address. Make sure to choose a different assumption than you used for the first part of this activity. Choose one that you didn’t even come up with in your first critique, if possible.
<Repeat prompts from Stage 2 (IMAGINE) and Stage 3 (DESIGN)>

The REPEAT stage is really just a second iteration of the IMAGINE scenario and DESIGN brainstorming stages using an assumption drawn from the list created in the EXPAND stage. (Plus, it makes it so the complete “CIDER” acronym can exist, and who doesn’t like a snappy acronym?)

For this second round of brainstorming, it’s critical that learners select a peer’s assumption from the EXPAND-stage list, ideally one that they hadn’t identified during their own earlier CRITIQUE stage. This is the main mechanism CIDER relies on to broaden learners’ understandings of inclusion issues and design exclusion. By engaging with an assumption that they hadn’t recognized previously, learners are virtually guaranteed to increase their knowledge base of design bias examples by at least one new manifestation, which they can later draw upon in future design work.

With the CIDER technique, learners practice identifying inclusion issues, brainstorm several concrete ways to make technology more inclusive, and gained at least one new perspective on design bias that they may not considered previously. Practice and reinforcement are important for retention of these skills, but our case study suggested that even a single CIDER activity can have positive impacts on learners’ knowledge of inclusive design! Even if it’s just a quick warm-up activity, try this technique out in your course or design group to get people thinking critically about inclusive technology.

Interested in diving deeper into the foundations of the CIDER assumption elicitation technique? Want more information about teaching with CIDER? Check out our (open access!) journal paper for theoretical foundations (Section 3) and considerations for teaching (Section 6.3), or reach out to Alannah Oleson (olesona@uw.edu).

Beyond “Average” Users: Building Inclusive Design Skills with the CIDER Technique was originally published in Critical Sips on Medium, where people are continuing the conversation by highlighting and responding to this story.

At a bright and early 6 A.M. Saturday in my time zone, I logged online to join one of the last events of this year’s virtual CHI 2021 conference — the 3rd Annual EduCHI Symposium on HCI Education. The EduCHI community consists of researchers, practitioners, and educators who are all interested in improving the ways we teach and learn human-computer interaction (HCI).

This symposium has been an official event at CHI for three years now, though its roots began nearly a decade ago in workshops, meetups, and various research projects. However, given the state of gestures vaguely at everything, two of those three events were relegated to virtual participation. I was lucky enough to attend the first EduCHI in 2019 in person, though I couldn’t make the 2020 virtual event. As I signed in and wrangled with audio issues, I silently hoped I wasn’t in for just four hours of Zoom lecture.

I needn’t have worried. Perhaps unsurprisingly, this community of educators — many of whom have been teaching throughout the era of remote learning and had to come up with creative ways to encourage participation from burnt-out students — designed a program of events that allowed for lots of engagement and rich discussion. Through a combination of a collaborative Miro whiteboard that contained dedicated areas for each presentation, ample Q&A time for each short paper, and a sprinkling of longer small-group discussions, the EduCHI organizers created a truly enjoyable virtual workshop. Read on to hear more about each presentation, get the links to each paper, and catch the highlights of our discussions!

Paper Session I: Diversity & Inclusion

Reflections on Remote Learning and Teaching of Inclusive Design in HCI

Kristen M. Byers, Salma Elsayed-Ali, Ebrima Jarjue, Rie Kamikubo, Kyungjun Lee, Rachel Wood, and Hernisa Kacorri (University of Maryland, College Park)

The authors for this paper shared successes and challenges for making their HCI course on inclusive design during the COVID-19 pandemic itself more inclusive for learning. A particularly interesting bit was their discussion of the power dynamics inherent in office hours, and how virtual drop-in hours might help reduce student anxieties and create more inclusive atmospheres. Questions in the chat and on the Miro latched onto this idea, discussing ways to support equitable communication between educators, TAs, and their students. All in all, it was neat to see some positive examples of how access and inclusion were improved in the transition to remote learning.

Perspectives in HCI: A Course Integrating Diverse Viewpoints

Anna Slavina and Stephen B. Gilbert (Iowa State University)

The authors of this paper opened with a simple provocation: Picture a camera. Now, let’s think about all the different ways that camera could be viewed. For some, it’s a form of oppressive surveillance. For others, it’s a vehicle to perpetuate and reify biased algorithms. These motivating examples led into their call to integrate more diverse literature and viewpoints into our HCI courses and to teach these different perspectives in our classes. Some technical issues cut this session short, but I would highly suggest reading through the paper (linked above) for a curated reading list for higher education HCI courses. The authors did an amazing job collecting readings from disciplines and topics such as disability studies, critical race theory, culturally relevant design, intersectional HCI, feminist HCI, trans*/queer studies, and more — and they even mapped out each reading’s main takeaways for HCI students! Seriously, check it out. Then use it. This stuff’s important and they did the legwork for us.

Discussion Session I: Designing in Context

Where, Who, Why? Tools to Encourage Design In Context

Alan Dix, Anna Carter (Swansea University), and Miriam Sturdee (Lancaster University)

After the morning’s paper session concluded, we moved on to our first of three discussion-based segments of the program. Here, we’d here a few words from the presenters on an interesting challenge or topic in HCI education, then break out into smaller groups to brainstorm and discuss, leveraging our collective expertise to come up with considerations for teaching and learning HCI design. The presenters in this slot asked us to consider the ways in which the tools we used for design education might be limiting or artificially constraining students’ consideration of how designs are used in context. For instance, popular wireframing apps are excellent at prototyping screen-based interactions — but what about what’s happening beyond the screen as the device is being used? Or what if the design doesn’t have a screen at all? The presenters showed off a few mockups of tools that would support prototyping with broader contexts in mind, then sent us off to talk amongst ourselves.

After the presentation, we moved into breakout rooms of 5–6 people apiece, with a few guiding questions from the presenters to get us thinking about how we can help design students consider broader contexts. My group chatted about our experiences with getting students to overcome design fixation, where they can get stuck with an idea of how a design “should” look and become less willing to explore or ideate on alternatives. The topic of worldbuilding to also arose as means to encourage consideration of the environment outside of the screen. I brought up this CHI’21 paper on Timelines as a means of envisioning alternate yet co-occurring design futures — maybe there was some way to combine those ideas with a tool interface that asked students to generate different scenarios of use for their design? We also discussed how to resist students’ implicit conceptions of “average” users by helping them name and consider different kinds of human diversity. A few mentioned they’d had good results in that area by integrating critical STS readings — such as those described in Anna and Stephen’s Perspectives in HCI paper above — into the foundations of their design courses, giving students the language and expertise to describe and address the power dynamics inherent in design work.

When we hopped back into the main room, we got to hear even more perspectives on the challenge of getting students to think beyond their wireframed screens. Some reported back that they’d discussed how tools could support other parts of the design process outside of prototyping — for instance, what would a contextual peer critique tool look like? Others had thought more about the students’ contexts, noting that sometimes students’ desires to learn particular tools (Figma, Sketch, etc.) overshadowed their desires to necessarily learn design, so they could list the proficiency on their CVs for internships and jobs. Another group brought up the importance of supporting collaboration in these tools, especially with much learning happening remotely right now, as well as the tensions between tools having enough freedom for creativity while still having enough constraints and support for educational contexts.

Paper Session II: Classroom Strategies

Using Group Norms as a Teamwork Technique in an HCI Class

Eliane Wiese, Koriann South, and Kaylee Martin (University of Utah)

This presentation spoke to the disconnect around teamwork that we often see in design classes: Educators LOVE teamwork because it enables collective learning, provides team support, and encourages different perspectives on a single task. Students often DREAD teamwork because they now have to work around others’ busy schedules, manage interpersonal conflict, and rely on potentially-unreliable others for their grades. The paper details ways that explicit norm-setting around group work can encourage better collaboration. Students discuss their goals at the beginning of the term (e.g., “I really care about learning everything I can and want to shoot for an A+!”, “I am super busy this term and this isn’t my top priority so I am fine with a B”) and gain an understanding of where everyone is at. Then, they co-create documentation and policy for group norms so that they have shared resources to refer to when something breaks down. Most students started out the term believing that a team was just a collection of individuals — that they could split up work, do things independently, and stitch them together at the end. The most successful teams realized, over the course of the term, that working together synchronously and leveraging each others’ unique expertise were key parts of successful teamwork.

A quick shout-out to the presenters here for their method. Elaine and Koriann co-presented their results, with Elaine voicing the educator perspective and Koriann voicing the students’ perspectives. It was very neat to watch! Many people commented in the chat how it helped convey students’ unique presence and voice, more so than your typical presentation format.

Creative Pedagogical Activities for User Evaluation Methods Courses

Carine Lallemand (University of Luxembourg / Eindhoven University of Technology)

In this presentation, we learned about different ways to help students know which design evaluation methods to use in which situations. There’s a surprising amount and expertise needed to choose an appropriate method for figuring out if a design works as well as you hope it does, and it’s even harder for novices, who don’t even necessarily know what their options are. Exacerbating this is the fact that many HCI educators are pressed for time in their courses and, as a result, focus on teaching the steps of each evaluation method, but not necessarily the meta-knowledge of when to apply each one. This paper described a few different activities designed to address this, each of which could be used in-person or remotely: Self-exploration booklets (which scaffold stepping through a design from a user’s point of view); flipped classroom presentations (where students create/synthesize knowledge into a educational video on a method for peers); and scenario-based debates (given a context and scenario, students debate and decide on an evaluation method, justifying their choices). One challenge brought up and discussed during Q&A was teaching about the tradeoffs of each method, especially when novice designers don’t have the real-world experience to anticipate what could go wrong when applying each one.

Discussion 2: Teaching HCI Online

Disrupting Tertiary User-Centered Design Course with Design Thinking 2.0

Eunice Sari (UX Indonesia) and Ellya Zulaikha (Institut Teknologi Sepuluh Nopember)

In our second discussion period of the day, Eunice and Ellya shared their experiences teaching their Design Thinking 2.0 framework, which brings together Agile software development ideas with the classic Design Thinking steps, and doing all of this in the time of remote learning. They described a case study they’d done where they introduced the technique to a cohort of students through remote learning, sharing that the added structure and guidance seemed to help reduce confusion around design process for students. It also helped them ground their design work better in industry-relevant points of view and articulate their designs in more professional ways — less “fluff”, according to the presenters.

For our subsequent small-group discussions, we were prompted to think about our experiences with online teaching and learning in HCI contexts. What techniques and tools had we found to be effective in remote design learning? What might we keep doing when, or if, we went back to in-person instruction? In my group and when we returned to the main room, folks brought up many positive things about online learning. Some upsides were:

• Recording lectures and providing transcripts helped make courses more accessible.
• Miro boards and other collaborative tools helped increase participation in ways that weren’t always possible for in-person large courses, providing new new methods of engagement at scale.
• All the documentation of the design process students do during remote learning affords opportunities for students to reflect upon their actions and become more mindful practitioners.
• Sometimes students formed stronger community ties within courses, such as when one group of students met up to watch recorded lectures together and discuss them afterwards.

However, as I’m sure surprises no one, remote learning can also introduce challenges for teaching and learning design:

• Classroom management can be difficult, since you can’t “eavesdrop” on small group work as easily — it’s very obvious when you pop into a team’s breakout room, and it changes the conversation flow. One educator noted this made it more difficult to pick up on microaggressions.
• Though the tools used in remote learning make the course more accessible and engaging to some, we still lack a comprehensive overview of which tools are accessible and in what ways. Most educators mentioned relying on word of mouth to know which tools to use or to stay away from, if they thought of it at all.
• Distractions are always a problem in remote contexts where everything’s done through screens — especially because students are expected to keep tabs on so many different platforms for all their various classes. It’s easy to check out mentally when nothing physical anchors you to a lesson.
• All the setup that it takes to run a good online course is difficult and time consuming, and educators are often tired, stressed, and under-prepared to take on this labor, especially because there’s little guidance on best practices.

Hearing all these different perspectives really illuminated a lot of the nuances and opened up insights into even more challenges. Remote HCI pedagogy will surely continue to evolve over time, but for now it seems to remain a mixed bag.

Paper Session 3: Curriculum Design

HCI-Collab: Collaborative Network Supporting HCI Education in Iberoamerican Countries

Huizilopoztli Luna-García (Universidad Autonóma de Zacatecas), César A. Collazos (Universidad del Cauca), Jaime Muñoz-Arteaga (Universidad Autónoma de Aguascalientes), and Antoni Granollers (Universidad de Lleida)

The authors of this presentation shared with us their efforts to build and sustain an HCI education focused community in countries across Latin America. They began by noting a number of challenges particular to the context: that HCI was still seen as an emerging discipline in the computing landscape; that there were few HCI conferences located in Ibero-American countries or other ways for practitioners to connect; and that there are few HCI teaching materials available in Spanish, among others. After some recent successes organizing workshops related to teaching HCI — one as early as 2005, and then a handful in the years since 2018 — they spun up the HCI-Collab: A network to support HCI education and tackle these challenges. HCI-Collab brings together members of 47 universities in 13 countries, as well as industry practitioners, to promote community, build awareness of HCI, and create materials that can be used for HCI education. One very neat thing they described was their repository of HCI webinars: A year-long series of talks on HCI and UX design topics organized by the HCI-Collab crew, with slides and videos archived and made freely accessible to educators for use in their classes. They’ve also created an HCI reference book written entirely in Spanish to make the concepts accessible to more practitioners and students. HCI-Collab has seen tremendous interest and success over the past few years in growing the Latin American HCI community, encouraging interdisciplinary collaborations, and increasing access to HCI education materials.

Research and Education in Accessibility, Design, and Innovation (READi) Training Program: Preparing Graduate Students for Careers in Accessibility Research and Design

Jin Kang, Chantal M. J. Trudel, Audrey Girouard, and Adrian D. C. Chan (Carleton University)

In our final paper presentation of the day, we learned about READi: a 4-part training program to help grad students to learn to advocate for accessible design, whether they intended to go into academia or into industry. The first component, a graduate level course titled “Accessibility and Inclusive Design”, gives students a primer on the topic through invited speakers and discussion. Some of the topic covered in the past include legislation around access, accessible gaming, and designing for neurodiversity. Second, students engage in an Action Team Project (ATP), which is what makes READi unique. In these ATPs, students work with community partners on real-world access issues. They’re not expected to necessarily solve the issue by the end of their project, but they should at least be able to provide guidelines that fit the environment and the needs of their stakeholders. Through doing this, they gain context on how tradeoffs, constraints, and other limitations can create barriers to accessible design. Once these projects wrap up, students present their projects at a two-day retreat which includes faculty, community partners, industry professionals, and the general public. Finally, alongside the course-ATP-retreat experience, students take part in workshops on various accessibility-related topics throughout the year.

Discussion Session III: Academic-Industry Partnerships

Shaping UX Academia-Industry Alignment: A Strategic Partnership Through an Industrial Advisory Board

Nadya Shalamova, Amii LaPointe (Milwaukee School of Engineering), Rob Nero (Spotify), and Michael DelGaudio (Google)

For our final discussion section of the day, the presenters brought our attention toward a model of industry collaboration they’d been practicing at their institution: Industrial Advisory Boards (IABs). One known challenge facing HCI and UX design programs is that there really aren’t any standards or accreditation processes for the courses they teach or for the programs overall. These folks discussed how industry-academic partnership by means of committee-based IABs can serve to fill that gap, with both working together to define learning outcomes and proficiencies students should gain throughout their time in the program. Sharing results from a trial run of the IAB model, they highlighted its efficacy in promoting close partnerships between the department and the local UX community, which helped graduates gain mentorship as well as get jobs. They also shared some insights gained from trying to get academics and industry professionals to work together smoothly, such as being sensitive to differing timelines and communication styles.

Off to our breakout rooms we went for the final time, with priming questions about what sort of role IABs might play in assessment and accreditation, as well as how industry could best support the growing HCI and UX education community. This session was a quick one to account for time, so conversation was somewhat limited. My group chatted about the tensions between supporting industry’s fast-changing preferences (e.g. this tool is the current standard, this method is now the default, but it might change at the drop of a hat) and teaching more enduring understandings of what it means to design well, agnostic of context or tools. Perhaps industry reps could be more involved in near-term planning (1–5 years), but might be less suited to discuss longer timelines (10 years), someone proposed.

I did notice an implied assumption in this session’s framing and presentation: Students were largely being referred to as future workers that would inevitably enter the UX industry, and therefore should be molded to best fit its needs. This isn’t wholly unwarranted — many HCI and UX students do go into their programs with this intent, after all — but prioritizing industry perspectives first and foremost can easily lead to ethical conundrums, especially when partnering with profit-driven companies and relying on them for financial support. What happens, for instance, if an IAB advocates for primer courses that teach current design tools and frameworks rather than courses that teach students to critically consider their positionality as designers and their ethical responsibilities? With recent tech controversies like Timnit Gebru’s forced departure from Google AI after attempting to publish research that might have reflected poorly on the company, and the ensuing string of resignations and firings, I can’t help but be wary of the way these constraints might show up in industry-led-and-funded HCI education spaces, too. I didn’t get a chance to raise these issues in the discussion, but it’s certainly a consideration we need to be aware of as programs begin to integrate industry partnerships into their curriculum development and assessment processes.

Closing

As we wrapped up the day, the organizers shared several exciting updates for the future of EduCHI:

• There’s going to be a special issue on Teaching and Learning Human-Computer Interaction in the Frontiers in Computer Science journal this year! More info here. Deadline for (optional) abstracts July 16th; manuscripts October 13th.
• EduCHI has joined up with the ACM’s EngageCSEdu initiative to do a special issue on HCI teaching materials! The cool part about this is that the materials are peer-reviewed (double-blind) and accepted materials will be indexed in the ACM Digital Library. This is the start to the living curriculum that is one of EduCHI’s major goals! If it takes off, it can become a permanent fixture and they’ll start recruiting editors and such. More info here. Deadline July 15th.
• We’ve got plans to one day spin EduCHI up into a conference of its own! But until then, we remain a symposium, and we need volunteers to chair next year (among a myriad of other tasks). Express your interest here! Students are encouraged to apply, too. I was on the program committee this year — would definitely recommend as a way to get involved.
• And, as always, to keep up with what’s hip and happening in the HCI education community, we have a number of communication channels you should join.

With that, we all wished each other a pleasant morning/afternoon/evening/middle of the night and went our separate ways.

Overall, I was pleasantly surprised that the virtual format worked so well — though given how many of those attending had been using Miro to teach remotely for so long, maybe I shouldn’t have been. It was fun to see the board fill up with so many diverse perspectives on each presentation, providing an alternate engagement style and pseudo-backchannel. Even better, there are plans to freeze and archive the board on EduCHI’s site, so all these great thoughts can be shared with the virtual universe too.

It’s neat to watch the community grow year over year. When I started my PhD program in 2018, one of my major challenges was finding literature relevant to my interest area of inclusive software design education. There just wasn’t a lot out there at the time (though what existed was good solid work to build upon). But just three years later, there’s enough interest for EduCHI’21 to have an entire paper session about diversity and inclusion! I look forward to seeing where the EduCHI community goes next — and hopefully, meeting some of these people in real life rather than through a screen (one can dream).

Trip Report: EduCHI 2021 was originally published in Bits and Behavior on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last Thursday, a tweet floated across my timeline with an invitation: “On Monday, August 17th, we’re having a virtual workshop on Software Developer Diversity and Inclusion Research. Join us, won’t you?”

Following the accompanying link, I found out about the second annual Workshop on Software Developer Diversity and Inclusion (SDDI 2020). With a self-stated goal of “rais[ing] awareness about developer diversity and inclusion challenges faced by industry today” and a public attendee list of software engineering and human-computer interaction researchers I’d heard about and read work from, this seemed like a great opportunity. On top of that, it was free to attend and open to all through virtual participation! I signed up, looking forward to Monday.

Day 1: Talks and Discussion

The first day of the workshop consisted of a series of short (~10–15min) talks from researchers and practitioners with accompanying live Q&A afterward. There were a few keynotes in there as well. The workshop’s #questions4speakers Slack channel provided an interesting stream-of-consciousness-esque view into attendees’ thoughts and reactions alongside each talk, with participants both posting questions and linking to resources for others to use.

Is 40 the new 60? How popular media portrays the employability of older software developers — Alexander Serebrenik

Due to some A/V issues on my end, I wasn’t able to catch the first talk of the day live. However, all of SDDI’s talks this year were prerecorded and uploaded to YouTube, so I caught up on Alexander’s talk during the mid-day break.

Ageism in tech is one bias that lurks beneath the field, but up to this point it hasn’t received as much attention as, for instance, sexism or racism in the industry. Alexander and his team collected publications from popular media outlets like Medium and TechCruch to see what kinds of common themes arose in public discourse around age and the software industry. They found a number of strategies suggested to increase “older” workers’ employability in what turned out to be a largely young-coded field, ranging from different hiring emphases for workers in different age groups on the company side, to practices like specializing and adopting “youthful behaviors” on the individual side (which included detrimental practices like working late and working weekends). Notably, Alexander’s team found that many of these articles defined “old” as 40 years or older, which is well below retirement age in most industrialized countries. Overall, this was a fascinating look into the way ageism perpetuates not just within tech companies, but in the discourse around them as well — which likely influences who applies for those jobs in the first place. A preprint of Alexander et al.’s work can be found here.

A Theory of Software Change — Ayushi Rastogi

Ayushi presented her process theory of the factors which influence software change on GitHub, which she mentioned was intended to be a representation of the world as it was, not necessarily a prescriptive theory of what the world *should* be. By reviewing literature on the nature of GitHub pull requests and related workflows, Ayushi found six main factors that relate to software change: Available unit changes, the existing codebase, the community, existing governance, tools and technology available, and the overall ecosystem in which the software exists. During Q&A, attendees brought up some of the tensions that might impact these factors (such as if the community and the governing authority have conflicting goals) and what that might mean for making meaningful software change. This work is ongoing, and Ayushi is currently refining this theory by soliciting feedback from developers and researchers.

How can we include the EU Accessibility Directive in our on-line teaching materials? — Ita Richardson

Now that most institutions are teaching online, creating accessible materials becomes incredibly important for equitable remote learning. The European Union put out a 152-page Accessibility Directive for remote learning that mandates certain accessibility features be integrated into educational materials (lectures, assignments, etc.). Ita’s team distilled this document into a set of 21 questions for educators to audit their materials with, in order to hopefully support better compliance with the directive. Ita pointed out that some of the questions were simply traditional usability concerns for software interfaces (e.g. “Is there something in place to notify users when making a change in the user interface?”, and another about error prevention). Others were more targeted at particular disabilities and conditions that could present barriers to learning if overlooked.

During Q&A, I asked Ita’s opinion about the best ways to balance accessibility with student engagement for remote learning. Methods of teaching that use more active learning styles often rely on synchronous student engagement, which in the COVID-19 era has translated into video chats over platforms like Zoom or Google Meet. However, this can present barriers to students that don’t have constant reliable Wi-Fi or electricity (as at least five of my forty students struggled with during spring quarter), not to mention concerns about real-time accessible audio or video. Ita, who’s done some work on techniques like Problem-Based Learning, suggested structuring classes around smaller synchronous student groups that meet together to work on activities. She also noted that flexibility on educators’ parts is key in the time of remote learning — doing what’s best for your students’ learning should supersede any generalized recommendations.

Keynote: Diversity and Heterogeneity — Biao Xiang

Biao’s keynote began by discussing the undercurrents of structural racism through the lens of the recent upswing of Black Lives Matter activity in the wake of George Floyd and others’ murders at the hands of police. Biao drew parallels to structural inequities that discriminated against groups of people in other countries and other times. He noted that even the recognition of diversity often unsettles these entrenched structures (which are often predicated on assumptions of homogeneous majority populations), which can disenfranchise and drive out those who hold minortized identities. Biao raised three “D” concepts throughout his talk — diversity, differentiation (of stakeholder groups and their goals/actions), and divide (between ideologies that drive what kinds of software gets developed). At the end of his talk, Biao challenged us to do three things:

1. Continue to celebrate, protect, and enhance diversity in the high-tech industries.
2. Be mindful that diversity initiatives that are taking place at universities and in industry are only impacting those who could make it there in the first place, and look for opportunities to expand beyond those borders.
3. Pay attention to differentiation that exists (or doesn’t) around us, and actively work to create heterogeneous high-tech spaces.

Equity Engineering: Impact & Opportunity — Dominique Wimmer

Dominique introduced us to the Equity Engineering team at Google, sharing their goals and processes for ensuring that products can be used by as many diverse users as possible with the result of equitable outcomes. The team starts with User Experience (UX) research that prioritizes the most marginalized users first (with a focus on racial and gender diversity). Additionally, the Equity Engineering team tries to build what they call “equity fluency” across different departments within the company, with efforts to teach and train technologists who can effectively put these ideas into concrete action. Dominique highlighted that the team’s efforts involved not only the developers and designers, but also human resources and hiring practices, since creating inclusive technology requires a diverse group of employees and a supportive company culture. The team subscribes to the philosophy “Don’t build for everyone. Build with everyone.”, which means including users who are the most unlike the development team in all stages of design and development and centering marginalized voices. Dominique was optimistic that while change wouldn’t happen overnight, concerted efforts like these could start to change the culture of software development to be more inclusive and welcoming to folks of all genders, cultures, races, abilities, backgrounds, and experiences.

Empathy, Opportunity and Inclusion in Accessible Design: A perspective from undergraduate CS education — Stephanie Ludi

After a short break, Stephanie presented her work on teaching undergraduates the skills they needed to design and develop accessible software. As most folks in the HCI education space know, teaching and learning these skills is difficult. Stephanie discussed some findings from a recently-wrapped-up four year longitudinal study of students who took courses which involved an emphasis on accessible software development early on in their undergraduate educations. Unfortunately, interviews with these students two or three years later revealed that students tended to ignore or devalue accessibility concerns in their final capstone project unless it was explicitly incentivized by the grading scheme, suggesting any attitude changes toward accessible development didn’t stick in the long term. Stephanie closed her talk with some recommendations for teaching accessibility concepts:

1. Integrate accessibility early and often in undergrad curricula
2. Make accessibility part of the grading scheme for large projects so students can’t ignore it
3. Provide resources that students can use in their projects
4. Be aware that students might not necessarily know or interact regularly with disabled people
5. Absolutely DO NOT rely on students with disabilities to educate their peers (as unfortunately ended up happening on occasion)

The Q&A for Stephanie’s talk was lively, with questions on topics ranging from teacher expertise, to embedding accessibility concepts throughout the curriculum, to how we might promote empathy with diverse user groups in a way that persists when they enter industry.

At this point I had to step away for some other meetings, which took up a bit more of my afternoon than I expected, so I couldn’t make a good chunk of the afternoon talks. Even the titles looked intriguing, so I’m sorry to have missed them!:

• Predicting Developers’ Negative Feelings about Code Review — Carolyn Egelman
• Investigating Bias in Code Review using Medical Imaging and Eye-Tracking (and A Summary of Diversity Work at UM) — Yu Huang
• Keynote: What I learned from 6 years of building CodeNewbie — Saron Yitbarek
• Experiences Running a D&I Program at ASE 2019 — Andrew Begel
• Conducting Covert x Overt Inclusion Research—Denae Ford [accompanying paper here]

One upside of the workshop’s virtual format is that the talks were largely pre-recorded, and the workshop’s Slack backchannel has a persistent record of (some of) the comments and questions for each speaker. The wonders of modern technology will allow me to catch up on Carolyn’s, Yu’s, Andrew’s, and Denae’s talks when I have time. (Saron’s keynote wasn’t recorded.) I caught the tail end of a discussion on bias in community-based research after Denae’s talk when I hopped back into the Meet room, so I’m sure there was some good stuff.

If you’re interested in checking out some of the pre-recorded talks yourself, you can find speakers’ videos and slides on the SDDI 2020 homepage.

Agile Inclusive Accelerator: A research and education program for an equitable tech future — Rafael Prikladnicki

Rafael spoke about a program running at his institution for nearly a decade that focuses on preparing diverse students to succeed in the tech field by teaching the basics of the Agile software development workflow. Though the project began with undergraduates, the team found they didn’t have enough folks in their target population at the university, so they expanded to high schools. The Agile Accelerator saw big improvements in gender and social class balance over recent years, the result of inclusive application practices like selecting students not on the basis of their technical skills, but through a more holistic view of their fit for the program. Rafael also gave a brief overview of the newest version of the program, the Inclusive Accelerator, which had an explicit goal of supporting social and economic inclusion. He closed by describing some challenges that still faced the program, including emphasizing students’ learning over their desire to deliver a finished product, and figuring out how & whether this experience could be replicated in different contexts (both in Brazil and in other countries).

Hidden Figures: Different Roles and Success Pathways in Open Source — Anita Sarma

To close out the first day of the workshop, Anita presented on some of the work she and her team have done on diversity and inclusion in open source. Anita described the current state of OSS as a field where contributors are largely male, English-speaking, college-educated, and socioeconomically secure enough to have volunteer time. To figure out how to improve OSS community diversity, she and her team conducted a series of interviews to understand the pathways different folks followed into open source work. The diversity in participants’ paths led their team to call for more recognition of the “hidden” roles and work often overlooked in customary representations of the OSS community, and especially around how we can support folks in these less-visible (but still vital) positions. Anita et al.’s freshly-minted CSCW paper with more details on the topic can be found here.

Day 2: Breakout Sessions

The second day of the virtual workshop was structured around breakout sessions: two parallel tracks of 90-minute informal chats with other attendees. Topics for the breakouts were sourced from workshop participants on day 1, and we self-sorted into groups based on our interests. I was able to attend three in the (Pacific Time) morning hours. Each group made good use of Google Docs for collaborative notetaking during the breakouts, with participants sharing resources and commenting to share their thoughts.

Diversity and Inclusion (D&I) in Software Education

The first session I attended focused loosely on D&I in educational settings. Attendees raised a number of challenges they’d seen or experienced around diversifying the incoming populations to computing higher education, as well as how to support minoritized groups enrolled in CS courses. When someone mentioned that the focus on higher ed limited our scope to folks who’d already managed to get there, the conversation naturally turned to attempts to improve perceptions of computing for students in younger (primary and secondary) contexts. With many of the workshop attendees being current or former educators, there was a lot of sharing about institutional efforts to improve D&I, what worked, and what didn’t. The idea of situating computing as a culturally relevant and social topic threaded through many of the efforts that worked. Others reported success from interdisciplinary computing courses located in non-CS departments (e.g. a “CS for bio-engineers” type of class). We also briefly discussed how to combat anti-Black racism in CS education, but we ran out of time to do the topic justice. I ended up dropping a bunch of links in the shared document to articles my anti-racist CS education reading group discussed over the summer.

There were some plans to tidy up our notes from this breakout session and make them publicly available, so I’ll update this section with a link if & when that happens.

Understanding Challenges and Barriers to achieving D&I in Software Development

Before trying to fix something, it never hurts to get a good strong understanding of the challenges facing you. This session focused on surfacing those barriers to D&I research and brainstorming concrete ways to get around them. One topic that surfaced early on was that of ensuring anonymity for our participants — If we’re working with groups that are by definition small, how can we ensure they feel safe and comfortable sharing their experiences with us? We discussed good interviewing and reporting practices in these cases, with some attendees sharing personal anecdotes about methods they’d found useful when working with different populations. From that, we moved to what it meant to “meet” D&I goals — What does success look like, and how can (or should) we measure it? I chimed in with a shameless plug for the usefulness of qualitative analyses in these situations, which led us to revisit the anonymity question.

During the latter half of the breakout session, someone asked how we might respectfully do research with communities we aren’t necessarily a part of. Many folks shared their strategies for community research, stressing the importance of including community members in all stages of the research design process as well as ensuring the work you’re doing is aligned with community goals. The importance of learning from other disciplines’ successes in this area was brought up (with Indigenous studies and anthropology being two that were mentioned). One attendee suggested cross-department collaboration and sitting in on other researchers’ processes to gain an understanding of how participatory research methods worked. The general sentiment seemed to be that CS researchers could learn a lot by looking to other social science disciplines on this topic.

Doing D&I Research in Company Settings

The last breakout session I was able to attend focused on the realities of doing D&I-related work (mostly research) in industry settings. As someone without a lot of industry experience, it was neat to gain some insights into how some lager tech companies’ internal reviewing and legal constraints shaped the kinds of work employees participated in, as well as how D&I research in particular often interacted with existing codes of conduct or mandatory reporting measures. We also chatted at length about the nuances of conducting research internally (with the company’s own developers and their processes) versus externally (with other populations), as well as how those distinctions could impact the publish-ability of any findings. Toward the end of the session, talk turned to the differences in conducting D&I research in academic versus industry settings. We had a number of attendees in the session who had both kinds of experience and were able to relay the contrasts they’d seen.

At this point, the workshop took a longer mid-day break. I had other prior commitments for the rest of the day, so this is where my trip report ends, but there were at least six more breakout sessions in the afternoon that I’m sure sparked good conversations.

I’m glad I got the chance to attend SDDI this year. Since I started my PhD and pivoted toward HCI education research, I’ve spent more time in design and education spaces than primarily software engineering-focused spaces. If not for the fortunate coincidence of me being online at the right time to see Emerson’s tweet, I doubt I would have stumbled upon the workshop. Being immersed in this community for two days felt like I was revisiting some threads of my undergraduate research on gender-inclusive software engineering and design (in a good way!), with the added experience and perspectives I’ve gained in the past few years. The workshop’s virtual nature and open participation was certainly a plus as well — It allowed folks to join in from numerous locations without the financial and logistical burdens of travel.

Shout-out to the SDDI 2020 organizers (Emerson Murphy-Hill, Google; Margaret-Anne Storey, University of Victoria; Denae Ford, Microsoft Research; and Sophie Qiu, Carnegie Mellon University) for their hard work, and to all the speakers for taking the time to share their expertise with us.

Depending on what the world looks like at this time next year, I’ll be looking forward to seeing folks again (virtually or not) at SDDI 2021.

Trip Report: 2020 Software Developer Diversity and Inclusion Workshop was originally published in Bits and Behavior on Medium, where people are continuing the conversation by highlighting and responding to this story.

Right now, we’re training vast numbers of students in higher education computing programs to build software. These students go on to become software engineers and developers, creating software that’s used by a wide range of diverse people. We know that software developers frequently make design decisions that impact the usability, accessibility, and inclusiveness of their software — so it stands to reason that computing students should be equipped with some sort of design training to help them build software that works for everyone.

In today’s higher ed, this kind design training typically happens in one or two courses on human-computer interaction (HCI) scattered throughout an undergraduate computing curriculum. Students in HCI classes might learn design processes like Design Thinking. They might even work with real clients and stakeholders to design and implement a software solution to real-world issues. Ideally, students come out of these classes with enough functional proficiency to avoid the worst design mishaps in software they create.

However, the HCI education community is very aware that design is hard to teach and harder to learn. Even though applied design education research in other fields stretches back decades, there’s simply a lot we don’t know about the unique tangle of software interface design and HCI education. We recently expanded on this body of knowledge by surveying and interviewing more than 120 computing students and educators to explore the design-related struggles students faced in HCI classes. We found evidence to suggest at least 18 different types of learning difficulties — you can check out the paper for examples and more in-depth descriptions (and for a screen-reader accessible version of the table screenshot below).

Identifying these design learning difficulties is a first step towards more effective HCI education that enables computing students to create more usable, accessible, and inclusive software interfaces. But, as you (and my reviewers!) likely want to know, what should I do about this? How can I address these learning difficulties in my own classroom? In the rest of this article, I’ll describe some of the most interesting kinds of learning difficulties we saw and share some tips on how higher ed HCI classes can avoid some of the worst pitfalls.

Problem: Students devalue design or think it’s just “making things pretty”.

Computing students often just don’t know what design is or why it’s important outside of aesthetics. It’s an especially common issue in computer science departments which emphasize the programming and algorithmic aspects of software creation over software’s impacts on the world and on users. This usually (negatively) affects students’ motivation and engagement with HCI concepts.

Tip #1: Motivate good design by appealing to a broad range of perspectives.

Not every student will be swayed by the same arguments, so it’s best to cover as many bases as possible. In my upcoming classes, I’m planning to motivate the importance of good design in at least three ways:

• Better market share/bigger user base. For students interested in this aspect of software creation, it’s easy enough to see that better-designed software interfaces tend to draw and retain more users.
• Situate inclusive and accessible design as grand challenges. It’s hard enough to make functional software, but it’s even harder to make software fully usable, inclusive, and accessible. This may appeal to the more competitive students in the class.
• Appeal to inclusion as a principle. Poorly-designed software excludes certain people (those with less tech knowledge, for instance) from using it. Exclusion is bad, but software that’s designed well is often more inclusive.

Problem: Students have a hard time managing projects and working with teams.

Many HCI classes support design learning with a term-long team project, often involving external clients. In these cases, students are asked not only to pick up all the new design knowledge they need to create a software interface over the course of the term, but also the softer skills they need to work with teammates and clients as well. Unfortunately, many of the students we interviewed said they were forced to rely on trial and error to figure out effective project management strategies, sometimes missing deadlines as a result.

Tip #2: Spend some time discussing “less obvious” skills of design, like project management and ways to work effectively with clients and teammates.

Especially if they haven’t yet held internships or jobs, students often don’t have developed knowledge bases for communicating with stakeholders and prioritizing work. Some helpful lesson topics might include:

• Clear communication and conflict resolution between teammates
• Negotiating deliverables and communicating results to stakeholders
• Strategies for prioritizing different aspects of design work over others when you’re tight on money/time/resources

Students may pick up these skills on their own over the course of the term, sure, but explicitly teaching project management skills will likely help avoid the worst problems. As an added bonus, these kinds of skills will serve students well no matter what kind of career they end up with.

Problem: Students struggle to design for diverse users who are unlike them.

In my past experience, computing students, due to their background knowledge and high familiarity with software, sometimes can hold an implicit belief that they know best when it comes to creating technical artifacts. They might think, “Well, if I can use it, everyone else should be able to too!”, or they’ll design in some feature that they think would be awesome, but that their users don’t want and won’t use. This usually ends up leading to poorly designed software that doesn’t fit well in the world.

Tip #3: Make it clear that a good design is one that serves the needs of users, not of the designer.

Have them say it with you: “The user is not like me.” Drill it into their heads. Shout it from your classroom’s metaphorical mountaintops. The earlier students recognize that they are almost certainly are not the target audience for their software, the better. And even if they are, that doesn’t excuse them from going out and talking to users before they begin making important design decisions! If I could make sure every computing student left an HCI class with one nugget of knowledge, it’d be this one.

Tip #4: Require students to ground every design choice they make in some sort of user-based rationale.

In your HCI class, students will likely be doing some sort of needfinding or requirements elicitation exercise, whether it’s user research, literature review, or some other activity. Challenge them to tie their interface design decisions directly back to their results. Students will likely require a bit of scaffolding to learn how to translate user research results back into design decisions, since it’s not always immediately obvious how to interpret user requests, but this is one of the most effective ways to keep students from falling back on their own unfounded assumptions.

Problem: Computing students approach design problems like they would programming problems (which doesn’t work).

When working with code, especially at an introductory level, students often learn to work on well-defined problems. Program specifications are given as part of the assignment. There’s a particular input and a particular desired output, and students’ work becomes creating a program to transform the input into the desired output. Students can tell correctness at a glance: by simply comparing actual to desired outputs, or by checking if their program compiles and runs on a set of test data. The answer to “Am I done with this?” is a typically a simple yes or no depending on the results of testing.

Design problems, on the other hand, are what we call wicked — they have unclear definitions and no definitively correct answers. There are always trade-offs to design problems, and a solution to a design problem will by necessity have to prioritize some aspects of the problem over others.

Tip #5: Spend some time discussing the differences between HCI design and computing/programming/software engineering.

In the beginning of the term, emphasize that success in a design-based class will probably require different ways of thinking and problem-solving than their computing classes have up to this point. Cuing students into this early may help them avoid nonproductive behavior like trying to define every single aspect of the problem before beginning their user research. There’s going to be a lot more ambiguity and satisficing in design than there is in programming, especially if you’re working with real clients and stakeholders. Some students will likely be uncomfortable with this, which leads into my next tip.

Tip #6: Emphasize that unlike many programming problems, most design problems have no single optimal answer — only “better” and “worse” for a given context.

In a previous class I taught, a student asked “How can you even grade us fairly if there’s no right answer?” The important distinction to make to students here is that while there isn’t a right answer for design, a good solution (a) addresses users’ needs and (b) fits within the constraints of the environment while (c) balancing necessary trade-offs against competing goals and resources. Well-designed software interfaces should hit all these criteria, though it may take on any number of different forms. One way to make this rubric a bit more workable is to implement the above tip of requiring students to ground every design decision in user-based rationale.

Tip #7: Explicitly provide students with strategies and heuristics to know what “good enough” looks like.

Since design problems don’t have obvious right answers, students we talked to often reported confusion over whether their work was finished. It wasn’t necessarily that they didn’t want to continue working — they simply didn’t have a stopping rule and would rather avoid iterating into oblivion for diminishing returns. One way to address this is by explicitly defining criteria for what “good enough” looks like: Perhaps it’s when their interface successfully meets all of Nielsen’s heuristics, or maybe it’s when a certain proportion of people can successfully complete a task during a user study. Maybe it’s a combination of those and others. In doing so, it’s also a good idea to have students think about what measures of quality these criteria don’t cover: Evaluation by these particular criteria might fit well in your particular class’s environment, but students should recognize that diverse designs in diverse contexts will require diverse methods of evaluation.

Teaching HCI design is a huge topic, and I know I didn’t cover everything here. What learning difficulties have your students (or you, as a student) run into? What tips do you have for HCI educators? Share below or tag me on Twitter (@OAlannah) with your thoughts!

More Information

This post accompanies a conference paper accepted to the upcoming 2020 ACM CHI conference on Human Factors in Computing Systems, written with my excellent collaborators Meron Solomon and Amy Ko. For more details and to see descriptions of the full set of HCI education learning difficulties, read the pre-print, or reach out to me on Twitter (@OAlannah) or at olesona@uw.edu.

Seven tips to improve HCI education was originally published in Critical Sips on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design has been on my brain lately. What is design? Where does it happen? How does it happen best? How can we teach others to design well? These are the questions I’ve been considering as I wrap up my first year of graduate school at the UW Information School.

In December I took a step back and tried to think critically about what it takes to become a functional PhD student. I used a learning science model of competence to break down the journey toward competence and highlighted a few of the more salient barriers facing new students. But, of course, there are many ways to skin the metaphorical cat. What might it look like if we treated the graduate student experience not as a learning progression, but as a design problem?

We might start by defining the problem statement: Create an experience such that by the end of grad school, I (or you, or your grad school friend) am a functional, successful, PhD student, prepared to take the post-grad world by storm. This phrasing immediately suggests that PhD life is a wicked problem — an ill-structured, complex issue not easily solved through traditional problem-solving methods. Wicked problems also tend to have seemingly contradictory constraints (e.g., wanting to excel in your research, but also trying to maintain some semblance of work-life balance) and no optimal solutions (e.g., each student’s definition of success will differ).

Wicked problems lend themselves well to design processes. Designers often have to balance constraints in their work as well as facing situations in which there is no “right” answer. In turn, this has led to a growing body of work around wicked problem design, such as DesignX, Transition Design, and the trendy notion of design thinking taught as a lightweight, portable version of the design process. (Design thinking has both advocates and opponents, but that debate is outside both the scope of this piece and of my concerns.)

To start designing the PhD student experience, I’ll leverage the Stanford d.school’s model of design thinking. This model structures the design process as made of five stages — empathize, define, ideate, prototype, and test. These stages help scaffold creative process, scoping from a nebulous “just come up with something good” to more actionable stages and concepts. Below, I’ll try to fit my thoughts and experiences into the stages of this model, emphasizing what’s worked so far and how I can use this framing to become even more of a functional student.

Empathize

The Empathize stage involves trying to understand the bigger picture. Who are the stakeholders in your graduate school experience? In the case of designing PhD life, you are the obvious expert in the area, but you aren’t the only one playing a part in the story. Who else is involved, and what sorts of goals, needs, and requirements do they bring to the table? In this stage, you’re trying to set aside your own preconceived notions about people and truly understand their perspectives. Consider empathizing with:

• Yourself. Cheesy for sure, but in this case very necessary. You have the fullest understanding of your own PhD experience and will have the best insight into what will and won’t work for you. Be aware that biases like impostor syndrome can cloud that view, though, and take negative perceptions with a grain of salt.
• Your adviser/manager. Arguably the most important person in your academic life other than yourself. Understanding their perspective — their expectations and goals for your especially — will inform the larger picture.
• More senior students/labmates. What do they know that you don’t? Leverage these perspectives to prepare for the years to come.
• Your support network. Family, friends, pets, or otherwise. These people help you persist. Understanding how they see you as a grad student can also shape your own needs, goals, and constraints.

Define

During the Define stage, you’ll try to identify pressing problems that are preventing you from functioning at your peak grad-student-ness. The fodder for this comes from the Empathize stage. What challenges you? What is lacking? How do others see your PhD experience, and does this align with your view? As part of this stage, it’d be helpful to define:

• Your goals. What do you want out of this degree? Where are you going afterward, or even where are you going next month? Defining these will help you start to identify barriers in the way of achieving them. I know that I am particularly terrible at goal setting (especially for the far future), so that’ll come up as one of my own barriers.
• Others’ goals for you (and how much you value targeting them). Perhaps your adviser wants you to graduate in three years. Perhaps your family wants to spend time with you in the evening. Stakeholders you identified in the Empathize stage will have targets they want you to hit, and you need to understand where your priorities lie.
• Your deficits. What do you feel is missing in your grad life? Maybe it’s enough time in the day to finish everything. Maybe it’s interest in the project you’re working on. Maybe it’s financial or social resources. Whatever it is, identifying deficits is one way to define the problem.
• Your resources. What are you working with? Some people have a limited amount of physical or mental energy they can dedicate to grad school. Others might be working part-time jobs to afford groceries in high cost-of-living cities. Know what you have and what you can use.

Ideate

In the Ideate stage, you start answering “How might I…?” questions about your chosen problem from Define. For instance, I might ask “How might I ensure I’m using my time productively, so that I can have time off on evenings and weekends to relax?” Based on the specific facet of grad life you’re tackling, your questions will vary. Now, start thinking about ways to address that question. Some things to keep in mind at this stage:

• It doesn’t have to be a physical thing. You’re designing the PhD experience here, so the ideas you have here might take the form of an action, a change in thought patterns, or anything else. For instance, one idea I might come up with is that I need to become more cognizant of how I’m spending my time.
• It doesn’t have to make sense. The goal here is not to come up with a single bulletproof idea (that comes later), but to generate many possible ideas. Some of those ideas will be terrible. That’s okay. Keep ideating.

Prototype

After a healthy amount of divergent thinking, you’ll have many possible answers to your question. Pick one or two to more forward with, but keep in mind you can always come back and choose another should it not fit.

During the Prototype stage, you’ll begin to envision what one of those crazy ideas will look like in real life. Don’t put a whole lot of time into these concepts yet — just enough so that you start to get a feel for whether they’d work or not. As part of Prototype, remember to consider:

• The ripple effects. Change is not a one-and-done kind of action. For instance, I might decide that to be more productive in the office, I need to better understand how I spend my time. I might consider a spreadsheet based setup or an automated time tracker program. Either of these choices will impact my daily routine in some way, so I need to ensure that change is sustainable.
• The original problem. Sure, it’s neat to try out fancy new apps that claim to improve your exercise habits in 10 easy steps. But if your chosen goal was to cut back on monthly spending, is that really useful for this specific case? Filter your prototyping through the lens of the original problem.

Test

In the fifth stage of the design thinking model, you get to Test your prototypes. Here’s where all this planning gets put into action. Try it and see what happens. This part is fairly self-explanatory, but some things to keep in mind include:

• It’s okay if it doesn’t work the first time, or the fifth, or the tenth. Designing is hard. It’s an iterative process of refinement, not a linear path to an optimal solution. If your solution doesn’t seem to be working, take a step back, decompose it, tweak the the components, and try it again.
• It’s okay to throw it out entirely. If after some tweaking it’s still not working, you have full license to scrap the solution and start over with another concept. Simply by trying a certain path of action you’ve learned more about the problem space itself, and that’ll inform future attempts to become a functional grad student.

In all of this design thinking, it’s important to remember that this model is iterative, not linear. Work in later stages of the model might spark some cool new idea that you hadn’t considered before. Your PhD experience is always changing and so should your design-based response to it.

Treating the grad student experience as a design problem allows for a new perspective on what it means to become a functional PhD student. It affords agency and helps scaffold action. Instead of situating students as passive members of the grad school grind, it reframes us as designers in control of what we are doing and what we are becoming. At the risk of sounding like a cheesy self-help book, I think this shifting of agency perceptions is quite powerful. After all, who is better situated to change your experience for the better than yourself?

Learning to think II: Designing the functional PhD student experience was originally published in Bits and Behavior on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week, I attended the Computing Research Association’s (@CRAWomen) Grad Cohort for Women in Chicago, IL, USA. The two days of the workshop covered a lot of ground, from advice for first years on how to choose an advisor to strategies for third years thinking about post-degree life.

Ayanna Howard (@robotsmarts) and Maria Gini (website) officially welcomed us Friday morning. Ayanna spoke about the importance of building a community in a field where women can be few and far between. Maria followed up by highlighting the global impact of CRA-W: The workshop was hosting visitors from Kuwait, Turkey, and a few other countries who wanted to see if this program could work for them. After some concrete tips for networking and elevator pitches — which we were told to practice at least 50 times this weekend! — they turned us loose for sessions.

Networking and Finding Advocates

A.J. Brush (@ajbrush) & Soha Hassoun (@sohahassoun)

A.J. kicked off the first-year track by tackling what is a very intimidating topic for many new grad students (myself included): networking.

“It takes a community to help you succeed and reach your full potential.”

Unfortunately (fortunately?), simply being a great researcher can only get you so far. Having a network of people who know about your work and your talent enables you to become part of a greater scientific community. A.J. brought up the very true point that there’s always another chance to network. You will survive a missed connection or less-than-eloquent elevator pitch. She also gave a few concrete strategies, such as having a simple pre-elevator pitch handy (“Hi, my name is X, I’m from Y, and I work on Z”) or blaming your advisor if you need an excuse to talk to someone (e.g. “They said I have to take pictures with 10 new people in my research area”).

Soha then switched topics slightly to the task of finding advocates (or sponsors).

“Somebody who is powerful, influential, and is actively opening doors for you … talking you up to other people, telling the story of your work.”

Mentors help you craft a career vision; sponsors help drive that vision. Mentors lead discussions about building skills, knowledge, and confidence; sponsors directly promote your work and make active connections for you. Some mentors may act as sponsors, but the roles don’t necessarily overlap. Women are over-mentored and under-sponsored relative to their male peers, so it’s important to start seeking advocate connections early and intentionally. Soha’s strategy for doing so:

• Create opportunities for research/education/business focused conversations at conferences, workshops, lab meetings, etc. with the particular person.
• Seek their advice on important issues and take it.
• Follow up with them and let them know how their advice helped you.
• Rinse and repeat.

Publishing your Research

Andrea Danyluk (site) & Margaret Martonosi (@margmartonosi)

Why do we write? Margaret began session 2 by unpacking that question. Not only is writing the way that most academics share their super-cool interesting research, but it also can be a neat challenge. Margaret demystified the conference submission process and the intricacies of peer review. Of particular interest were her tips on how program committees choose reviewers:

“Be aware when you’re building your references list that the people you cite might be reading your paper.”

Margaret also underscored that reviewers tend to look for clear contributions, technical soundness, and solid evidence to back up a claim. If a reviewer can’t easily identify these in your paper, a rewrite (or even abandonment of the project, in worst cases) is in order.

Andrea spoke to the writing process itself. She framed iteration as key to creating a good argument:

“You shouldn’t view it as I’m going to research for N weeks, and I’m going to write for N weeks, you should view it as this iterative process … the writing guides the research too.”

“In the act of writing it and rewriting it, we realize, oh, that’s what we’re doing, that’s the part that’s interesting.”

Andrea also emphasized the need for writers to take the perspectives of their readers and avoid “kidnapping” them. Consider this: you’re asking readers to grasp in a few minutes the concepts it took you months or years to figure out. Explicitly tell readers where you are going and why it matters that you go there.

Panel: Balancing Grad School and Personal Life

Andrea Danyluk (site), Mandy Pant (site), & Rebecca Wright (site)

We’re all told that we need to have a healthy work-life balance if we’re going to succeed in grad school. But sometimes that’s really hard, dang it. This session focused on these challenges.

The three panelists first shared their stories about finding balance in grad school. Some felt it was better to take a holistic approach:

“There’s a way of thinking about work and life as two separate entities and that there must be some sort of 50/50 balance between them, whatever that means….I see my work as contributing to my good life.”

Others took a pragmatic approach to self-care:

“You can even think about it in a formulaic way — It’s about making your brain work better and your body work better so that you can continue to exist and function.”

“Your sleep, your nutrition, your hydration: It’s hard to do these things when you’re putting out fires that come from you running on empty.”

The panelists also stressed the importance of identifying unbalancing forces, as well as strategies for addressing tradeoffs in the wicked design problem that is grad school life.

“You cannot have it all, at least not at one time. … Find the set of tradeoffs that are going to be appropriate for you personally.”

At lunch, we sat with our self-identified research interest groups. I hung out with the CS education people and was pleasantly surprised to see there were enough of us to fill a whole table! Briana Morrison (@Bri_Morrison) of U. Nebraska Omaha, Jamie Gorson (@jamiesarahg) of Northwestern, and I chatted for a while about research methods like think-aloud protocols and interviewing strategies. It’s difficult to figure out what’s in a student’s head when the very act of them vocalizing it can change their perceptions. Surprisingly, we didn’t solve this open problem in twenty minutes of lunchtime conversation, but we collectively shared some resources to work toward more effective methods.

Keynote: The Pursuit of Collective Intelligence, and Happiness, in Science

Radhika Nagpal (site)

Radhika focused her talk around how to change implicit rules that reinforce power structures within scientific communities. She took apart four pervasive myths that underlie academic culture:

#1 — The Myth of the Isolated Genius: that there’s a single person out there who is going to change the world all by themselves, and the only way to succeed in academia is to be that person. However: Research is done in teams, science is done over generations, and group intelligence can outweigh any one individual.

#2 — The Myth of the Highly Competitive: that science is a competition, a survival of the fittest scenario, and to be the best you have to win. However: Science is an international collaboration. The best work happens when we create opportunities for talent from everywhere — not just Western, first world countries — to join the conversation, which rests on generosity, not competition.

#3 — The Myth of Gender-in-STEM: that the fix to gender issues in STEM is to simply increase exposure by running events for women in STEM and making STEM classes mandatory. However: Women aren’t absent from STEM, they’re absent from careers and powerful positions.

“We don’t have a Gender-in-STEM problem, we have a patriarchy problem. … I’m not here to encourage you to stay in computer science. I’m here to encourage you to stay in power.”

#4 — The Myth of Success as an Image: that if you don’t look like the people in successful stories, you can’t be successful. However: We have the power to choose the stories that we tell. By sharing diverse portrayals, we enable people to imagine that they can be successful too, which can start to change the narrative.

Radhika’s keynote kicked ass. One day I hope to be as confident, well-spoken, and radical as she is.

Strategies for Human-Human Interaction

Jamika Burge (@JDBurge), Margaret Martonosi (@margmartonosi), & Kathryn McKinley (site)

The opening panel for Saturday morning focused on the reasons women and gender minorities often don’t feel welcome in computing: harassment and the generally unpleasant humans who discriminate against us. The goal for the session was to share stories, strategies, and resources.

Kathryn started by explaining the iceberg model of sexual and gender harassment based on the recent National Academies harassment report. There’s all the overtly gross and illegal activities that are obviously sexual harassment above the water, but much more often there’s oblique gender harassment below the water. For more details, check out the report.

Margaret spoke about how to report harassment so that we’d know what to do when (not really “if”, unfortunately) it occurred.

“I worried about this information dump on women so early in grad school. But everything that’s happened lately has convinced me … now you can go forward and make your own decisions.”

She pointed out that the NSF now has an official harassment-free policy. If a PI or co-PI on an NSF grant has a harassment claim filed against them, they can lose their funding — and since 75%+ of computer science research is funded by the NSF, that’s a pretty big deal.

Jamika stressed the importance of intersectionality.

“If your harassment feels different, it probably is.”

Women of color, especially, can experience a double bind where it’s difficult to tell whether harassment is due to their gender identity or their racial/ethnic identity. So, while the world spins its wheels and tries to figure out how to deal with diversity in computing, how can we thrive in these contexts? The panelists opened up the floor for questions, anecdotes, and thoughts from the audience, which I won’t report to respect the confidentiality of those brave enough to speak up. Suffice to say that there are many strong women in computing dealing with bullshit that is not their fault and that harassment comes in many shapes and forms.

Building Self-Confidence

Bushra Anjum (@DrBushraAnjum) & Patty Lopez (@pittrpatt)

Ah, impostor syndrome: The close friend of many PhD students. This session dealt with the lack of confidence that often undercuts women’s computing experiences.

Patty and Bushra began by emphasizing that no one is automatically born with confidence — it’s a learned skill, just like any other skill of PhD life. One way to start gaining confidence is to reframe failure as a learning experience rather than an ending. The idea of “productive failure” is a key concept in creative professions like design, where failure is an opportunity to gain new knowledge.

“If you succeed, you succeed; if you fail, you become smarter. There is no harm to this! … When you face a challenge, it’s okay if you fail. Next time you will not.”

Another is to understand that comparing one’s self to others is irrational. Though we can’t stop ourselves from doing it, we can recognize that it’s a vain pursuit:

“We know as scientists to make comparisons, you have to control the variables. … You cannot control for an infinite number of variables to ‘truly’ compare to others.”

Finally, the speakers wrapped up with a metaphor: Power, success, and influence are not pies! It’s not a matter of who gets the largest piece, and there aren’t limited amounts to fight over. It’s about making sure that everyone has a chance to succeed in their own optimal ways.

After some closing remarks and lovely lunch discussion about ethics in research, they turned us loose. Some stayed for resume and career advising, but I opted to wander downtown in search of Chicago style pizza and adventure.

The Grad Cohort was a great experience. Though the sessions sometimes seemed a bit generic, the keynotes were amazing and inspiring. I’ll be back next year to reconnect with this amazing community of women in computing.

Community Building at the 2019 CRA-W Grad Cohort for Women was originally published in Bits and Behavior on Medium, where people are continuing the conversation by highlighting and responding to this story.

This week, Seattle welcomes the IxDA’s Interaction Week 2019, bringing together interaction design practitioners, researchers, and fangirls to explore the state of the discipline. In collaboration with the University of Washington DUB group, the conference began with the seventh annual Interaction Design Education Summit.

My current research projects explore the role of design skills and principles in introductory computing education, so I couldn’t pass up this opportunity to learn about interaction design education from the best in the field. Luckily, the summit was very welcoming to outsiders like myself. I met designers and educators from all over the world in fields ranging from marketing to architecture. Each attendee brought their unique perspective to the conference’s themes of interaction design in flux and experimentation. Below, I’ll share summaries and thoughts about my time at the summit and what computing education can learn from interaction design pedagogy and practices.

The summit kicked off Sunday afternoon at the Microsoft Studio B campus in Redmond.

Microsoft Inclusive Tech Lab Tour

Bryce Johnson of the Inclusive Tech Lab showed off how Microsoft was making gaming more accessible for a wider range of ability levels. The lab itself was designed to be an ability and sensory-friendly space. Chairs were upholstered in high-contrast colors to the floor, light levels could be adjusted for sensory accommodation, and tables could raise and lower to ensure no gamer’s controls were out of reach. Bryce described the origins of the Xbox Adaptive Controller, created for gamers with limited mobility and how it followed Microsoft’s inclusive design principles: recognize exclusion, learn from diversity, and solve for one/extend to many. Before leaving the lab, the group gathered around to watch Bryce demo a game of no-hands Rocket League.

Panel: Anticipating the Future of Organizations

After the opening remarks, a panel of industry leaders, moderated by Microsoft AI Design’s Ana Arriola, took the stage to discuss human-centered design in today’s culture. From the start, panel members emphasized the need for design educators to teach softer skills as well as craft. Multiple panel members called out effective communication as one of the most important skills a designer can have. Others discussed the role of failure in novice designers’ education and how important it was that failing become normalized so students would feel okay taking risks. Empathy — with users, teammates, and humanity in general — was lauded throughout the talk as well, though some of the panel members were skeptical about whether proper empathy could be taught, going so far as to ask:

“How do we teach each other to be a human being?”

From a computing education perspective, I’m not sure if we can teach empathy, but I do believe we can teach students more effective perspective-taking to better understand their users’ needs. Perspective-taking is necessary for some types of empathy, but it is unclear whether it is sufficient. One of my current research projects is exploring what constitutes “useful” empathy in UX design processes, so I hope to start answering questions like these in the next few months.

Keynote: Sadia Bashir, Pixelart Games Academy

Sadia Bashir, the co-founder of PixelArt Game Academy, gave the summit’s opening keynote. The academy focuses on collaborative learning and was born out of Sadia’s dislike of traditional computer science education, which often (intentionally or not) emphasizes competition over cooperation. PixelArt welcomes students from all backgrounds — two described were a mechanical engineer who wanted to become an artist and a member of a rural village seeking training in new skills. Each student brings different experiences and knowledge to their group as teams work on designing, developing, and deploying a game over the course of a few months. Sadia finished with a call to consider how each of us can support learners to explore their passions and take risks, either formally as an educator or informally in the form of tweets, blog posts, and video calls.

After the requisite networking and socializing, I joined a few other attendees in catching one of the earlier shuttles returning to the conference hotel. At this point, the snowfall that started in the afternoon had begun to stick, lending a festive atmosphere to the whole proceeding as we made our way back to downtown Seattle.

A snowy Monday kicked off at the University of Washington’s Alder Hall with a brief welcome from Michael Smith, Director of UW’s MHCI+D program. Isabelle Sperano also let the group know about the IxDA Medium publication, which houses the resulting discourse from previous workshops. Keep an eye on this page for updates in March with the 2019 summit’s activity.

I opted to attend the presentation track for both the morning and afternoon sessions, where each speaker had 30 minutes to talk about a subject of their choice related to the guiding ideas of interaction design in flux or experimentation.

Beyond the IxD Degree Program: Why and How Industry and Academia Should Partner Around Pedagogy

Dianna Miller of Syracuse University began the morning session with a response to a talk at the 2018 Education Summit on identifying core competencies for design. A better way to approach design education, she claimed, was to begin by analyzing how designers know what they know (their epistemology) and how they know they are teaching and assessing effectively (their pedagogy). To better prepare students for interaction design careers, Dianna called for teaming up around education: Industry should host educators as “faculty-in-residence” to gain better understanding of real-world design processes , and academics should invite practitioners from diverse fields to engage students in challenging conversations. She also encouraged educators to “radically share our teaching journeys,” not only in paywalled academic papers, but in publicly available mediums such as blog posts or repository websites.

Building Transdisciplinary Design Capability through an Integrated Studio Approach

Colin Gray of Purdue University gave an overview of the institution’s new undergraduate UX design major. The program squarely positions design as a transdisciplinary field, drawing from six different areas — psychology, anthropology, history, graphic design, philosophy, and ethics — to inform its curriculum. Colin argued that traditional design education, in which competencies are often taught in semester-long, siloed formats, aren’t as effective as threading the development of those competencies throughout students’ intellectual development.

“It’s like a rope…It’s the combination of all those strands together than make it work.”

In CS education, we’ve seen a similar approach being used for topics that don’t fit well into traditional computing curricula, such as HCI and ethics. A neat distinguishing feature of Purdue’s program is its support for students’ growth: Each student has a peer and faculty mentor throughout the duration of the program, and projects are conducted in teams of first, second, and third-year students rather than stratifying based on experience.

Silo-Busting and Island-Hopping: Blending Theory and Practice

Keeping to the theme of integration, Michael Gibson and Troy Abel of the University of North Texas presented a way to use theory to help students learn to avoid “solving the wrong problem in the right way.” At UNT, design students are taught theoretical frameworks for approaching problem-solving in their first term of instruction. As they design, students explicitly identify which of these frameworks they’re using to approach their research question, prompting them to explicitly consider not only their solution, but how and why they arrived at that solution. This allows students to start generalizing their approaches beyond one specific problem and gain intuition on which to base similar solutions.

In computing education, these kinds of metacognitive strategies have shown promise in helping novices programmers learn to problem-solve, so it’s great to see that similar approaches can help novice designers. Moving forward, CS education might consider integrating theoretical frameworks as guidance too, especially into introductory classes where novices tend to flounder.

4D Design at Cranbrook Academy

In the last talk of the morning session, Carla Diana walked us through Cranbook Academy’s radical approach to their graduate art and design curriculum. Cranbrook, labeled as “the most dangerous design school in the world,” takes a critical theory approach to teaching design and challenges its students to learn by interfacing with their wildest ideas. For example, Carla spoke of a student who asked What if plants could help nurture long-distance relationships? and eventually designed a “smart plant” that, when paired with a partner’s, would allow the user to see when the other person was watering or taking care of it. Central to Cranbrook’s approach is an emphasis on physical, functional hardware prototypes. Students learn techniques for creating not only with electronics and code, but with everything from traditional woodworking to 3D printing.

Over lunch I had a chance to connect with some of the other summit attendees. Surprisingly, a large portion of those I spoke with weren’t interaction designers by trade. Instead, like me, they were there to observe and learn about design education to gain some insight into the state of the field. One person at my table brought up the need for design literacy in other fields so that team members could communicate well with designers and understand what they were capable of. Another spoke about how the mark of a good designer is that they can dissociate their ego from their ideas and avoid tying their identity into their designs. I see a parallel there with computing education: students often get very invested in the first few programs they create and are offended on a personal level when they break. Introductory CS might do well to embrace design’s philosophy of productive failure and teach students to reframe breakdowns as learning experiences, not defeats.

Also present at lunch: much criticism of Seattle’s inability to deal with what most attendees considered the barest dusting of snow. Most major cities in the Pacific Northwest don’t get snowy weather more than once or twice a year and often aren’t equipped with the machinery or infrastructure to deal with it. This leads to horrible traffic snarls as drivers spin out on highways and city transit diverts to snow routes. As a PNW native from west of the Cascades, I can confirm that two inches of snow and ice is our soft apocalypse.

What can the Circus Arts Teach us about Pedagogy?

Paloma Holmes of Normative kicked off the afternoon session with a discussion of what design education can learn from circus pedagogy. Through a two-year ethnography on circus communities in Canada, she found an inclusive pedagogical culture that welcomed those who “didn’t fit” in traditional schools. Paloma pointed out ways that circus pedagogy encouraged students to engage in exercises on their own terms and learn through failure, to communicate without relying on words and overcome their fear of public criticism. Each of these finds a parallel in the goals of design training. Perhaps by emulating the circus, educators in all fields can help their students to become more resilient, creative, and collaborative.

Encouraging Experimentation: Helping Students Respond to Interaction Design in Flux

Daniel Buzzo from the University of the West of England, Bristol spoke to what he saw as a key shortcoming in design education: a lack of room for exploration and failure.

“We didn’t get here by design. We got here by stumbling through dozens and dozens of alleyways that didn’t work.”

Daniel claimed that the best path to engage students in learning is to allow them to teach themselves — show them what they should avoid, and let them figure out what should be through iteration and experimentation. In this way, learners develop their own language and intuition around the problem and design solutions that aren’t artificially constrained by best practices or prior examples. Instead of emphasizing outcomes, which contributes to a fear of failure, Daniel’s students are graded on their mastery of the design process and their ability to contribute ideas.

Interaction Design and Motivational Video Games

Isabelle Sperano and Robert Andruchow of MacEwan University presented a case study of interaction design for educational video games — a topic close to the CS education community’s heart. However, instead of focusing on K12 as these kinds of games are prone to do, the design students in question were tasked with creating a game to teach undergraduate-level biology concepts. Students had a short five weeks to design and prototype the game with the help of a biology professor (for content knowledge) and a team of CS students (for implementation). Teaching undergrad-level content through a video game presented unique challenges for the design students, but when the dust settled, many of them named the challenge as a favorite project. Some were even encouraged to pursue game design as a career — a route they hadn't considered before.

A particular challenge called out by the MacEwan team was that of communication — especially between the design students and the CS students. According to the talk, CS students weren’t used to presenting their work to teams and handling public critique, and design students encountered similar difficulties conveying ideas to the CS team. This scenario underscores the need for some form of design literacy in computing education. Given how often designers and programmers work together in industry, it’s crucial that both are able to understand each others’ skills, proficiencies, and mindsets.

High School Students Create Startups

To wrap up the afternoon session, Melanie Kong presented her experiences on teaching design to high school students through a year-long entrepreneurship class. The first quarter of the year helps students to identify real-world problems, ask good questions, and begin ideating solutions. During the second quarter, students learn skills like networking and iterative problem-solving that they’ll need in the third and fourth quarters, when they’re unleashed on the world to launch their own startups and compete with their peers on the annual demo day. Melanie shared students’ stories, emphasizing that these high schoolers were successfully learning and implementing design principles through the class’s embedded approach. She ended by encouraging educators not to underestimate the abilities of secondary school kids and calling for design education to be integrated into primary and secondary curricula.

Closing Keynote: Andrew Davidson, Senior Lecturer, UW HCDE

Summit attendees reconvened to listen to UW’s own Andy Davidson give the closing keynote on filling the human-centered design pipeline through K12 outreach. Andy began by unintentionally echoing Melanie Kong’s sentiment that the earlier kids are exposed to design, the better. Through his experience as a high school teacher, he quickly realized that, more often than not, students weren’t aware that the field of design existed before they got to college:

“This is not a problem of ability; it’s a problem of opportunity.”

When he joined UW’s Human-Centered Design and Engineering (HCDE)department, Andy worked to integrate service learning into the undergraduate curriculum. Now, he estimates that around half of HCDE undergrads participate in some sort of design outreach before graduation, traveling to middle schools in underserved areas and teaching students problem-solving, ideation, and prototyping. Check out the UW Pipeline Project for more info on this excellent program.

The rhetoric surrounding Andy’s closing keynote (and, indeed, throughout the summit) strikes me as very similar to the language driving initiatives in computing education: increase access, immerse learners as young as possible, and prepare students to engage with a new and challenging world.

There, the momentum comes from the idea that computing is a new literacy for a citizen of the 21st century. Here, though, the topic is design. This begs the question: Is design another new literacy? Would students benefit from exposure to design skills and principles in ways that would allow them to become better, more critical thinkers? If so, perhaps it’s time to push for access to design education not as an elective, but as a fundamental right for learners.

The IxDA Education Summit was a fantastic opportunity to connect with the world of interaction design. I got to spend two days among leaders in design education, getting a feel for both the present and future of the field. I’d highly encourage everyone interested to attend next year’s summit (which, apparently, will be somewhere in Europe — vacation anyone?) to interact with a community that pushes the boundaries of pedagogy and practice in pursuit of a well-designed future for all.

Two Days with Designers: IxDA Education Summit 2019 was originally published in Bits and Behavior on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week marked the end of my first quarter at the University of Washington’s Information School. After ten weeks, I can confidently say that I have this research thing down. I can quote seminal works at the drop of a hat. Every sentence that falls from my keyboard is publishable. I have transcended time and space and now exist on a dimensional plane of pure scholarship.

Right?

Wrong. So very wrong.

Though I have a better idea of what I’m doing now than I did three months ago, it takes a lot of work to be a successful PhD student.

To scaffold this work a bit, I’m approaching the process of becoming a functional researcher as I would any other skill that I want to master, beginning with recognizing where I’m starting from. Consider Martin Broadwell’s model of competence popularized in the 1970’s.

In this four-stage model of mastery, each learner begins in unconscious incompetence, fully unaware of their lack of knowledge, then advances through conscious incompetence, conscious competence, and finally unconscious competence, where they’ve internalized the skill and its intricacies. In the grand scheme of mastering PhD studies, I’m probably somewhere in between conscious incompetence and conscious competence.

As with any new skill, though, I’ve hit stumbling blocks that trip me up on my path toward mastery. Since my current research involves understanding barriers students face when learning user experience (UX) design and I’m very primed by that train of thought, I’ll flippantly call these difficulties PhD student learning barriers. This framing allows me to do four things:

• Scope from a nebulous “Grad school is hard” to the more actionable “I struggle with this particular aspect of research”;
• Understand that there must be some way to address the barrier, since others have overcome it;
• Identify needed information to help me progress past the barrier; and
• Recognize when I overcome the barrier and gain competence in the skill.

The following are a subset of PhD student learning barriers I’ve found myself facing in the past ten weeks.

Barrier 1: I don’t feel like I have enough grounding to ask the “right” questions.

There’s a lot of emphasis on asking questions in grad school — questions from your advisor and labmates, questions to ask tomorrow’s guest speaker, and of course your own ever-important research questions. All of these are somehow supposed to resolve into the question that eventually earns your degree. As a first year student, I’m obviously not expected to know all the answers, but I often feel like I don’t even know the right questions to ask.

This isn’t necessarily a bad thing, though. From the field of UX design, we know that iterating on an idea can make it better. This applies to research, too. Though I may not have the right questions now, I can work toward them by iterating on an initial question. Some strategies to make meaningful gains in between iterations are:

• Reading relevant literature from a broad range of related fields (not just your own)
• Talking to experts and leveraging their intuitions
• Describing questions to non-experts and getting fresh perspectives

Each of these allows me to refine my questions and work toward what I’d really like to know. When in doubt, try something, see what happens, triage the fallout, and do better next time.

Barrier 2: My advisor/instructor/collaborator told me to do something, but I don’t know how to do it.

Many of the skills that contribute to being a functional PhD student — doing thorough literature reviews, reading academic papers, communicating effectively with other academics — are just that, skills, and so will take practice. No one explicitly teaches these skills. You’re supposed to pick them up as you go along.

A good way to learn the component skills of research is (surprise surprise) asking the successful researchers around you about their methods and processes. Much of academia seems to hold to oral tradition and you’ll likely find the best advice by being around people who have been there, done that, and come out mostly unscathed. By asking around, I’ve come up with explicit strategies for lit reviewing, reading and writing papers, and getting feedback from professors so far.

The way I see it, my first couple years as a PhD student are an apprenticeship. I am here to learn these skills and get very good at them, so I can leverage them to do dissertation research later on. So it’s okay to ask questions.

Barrier 3: I have so many things to do/read/research, but I can’t keep track of them long enough to make meaningful progress.

There are a ridiculous number of things to keep track of in grad school. Meetings, classes, random research ideas, that paper your advisor told you to read that you forgot to write down…

To stay sane and semi-productive, I’ve taken to externalizing as much of my cognition as possible. Zotero keeps my ever-growing reading list in check. Google Calendar manages my schedule (though I’m looking into getting a old-school paper planner). Notion collects my workflows and To-dos.

If you think you’ll remember it later — you’re wrong. Write everything down. Why impose extra load on your memory? Free up those mental resources for the Big Thoughts™️ that will move your field forward.

Calling it now: strong organization skills will be a major reason I make it through the next five-to-N years.

Barrier 4: I want to do well but…I’m not sure I can.

There’s been enough said about imposter syndrome to fill many books and articles, so I won’t waste words here describing what others have already done better. Surrounded by the excellent people at my university, it’s incredibly easy for me to believe that I’m here due to some mistake in the admissions process. Talking to other first year students reveals a similar sentiment.

I’d be lying if I said that I was fully cured of my own imposter syndrome after a short ten weeks of PhD life. This is a barrier I’m actively working on. However, I’ll keep the following in mind as I keep trudging toward competence:

You don’t deserve to be here more than anyone else, but no one else deserves to be here more than you, either.

What barriers to becoming a functional PhD student have you faced, or seen students face? What novel (or mundane) strategies did you use to overcome those barriers?