Seven tips to improve HCI education
Teaching software interface design is hard, but it doesn’t have to be
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.
