Mo Duffy is a senior interaction designer at Red Hat, a billion dollar company that is the world's leading open source and Linux provider. I met Mo this past spring when we spoke on a panel at SxSW. I was struck by her insights into her profession and how those insights relate to all design professions. Not only does she get into the nitty gritty of the politics of the workplace and the realities of usability testing, but she is a passionate advocate for open source and the democratization of design.

Xanthe Matychak: How do you define Interaction Design?

Mo Duffy: I define interaction design to mean the design of systems and interfaces where humans and computers interact with each other, and, more importantly, where human beings interact with each other mediated by computer systems.

And the goal of interaction design, in my opinion, is to be as invisible as possible. Whenever a person is jerked into thinking about their computer system or their software rather than the task they are trying to do, such as getting a video chat with a loved one to work or checking their work email, that's when poor interaction design is noticed. Good interaction design is transparent because it allows for an experience so seamless, you don't notice it. It's invisible!

What challenges did you have when you first started and how did you overcome them?

I had a few challenges when I first started. I came from a graduate program that, at least in the track I ended up following, had a very strong quantitative bent to it: useful for generating HCI research and running a usability lab, yes, but I wasn't interested in either, as it turns out. In my program I started worrying that pumping out awkwardly-written research papers in pricey academic journals developers wouldn't or couldn't afford was not going to make a huge difference in open source software, and I started worrying that I was wasting my time.

It also felt like the maxim that you must run hours of rigorous usability tests on every piece of software before it's ever put in front of an end user had somehow been drilled into my head, and when I finally found myself in industry, I discovered the dirty secret that what I was taught regarding usability testing and how it happens normally is hardly ever the case in reality, at least in industry. Most testing that I've encountered or been involved with has aligned far most closely with Steve Krug's methods in Don't Make Me Think than any of the rigorous multivariate statistical analysis and eye-tracking studies I was involved with in my academic program. I feel kind of dirty and bad to admit this, but cheap and quick testing works, and sometimes you need to get a product out the door and you aren't in a position to stop the train no matter how much you think it needs more time and polish. You feel lucky you got any sort of testing in at all. There are so many forces that affect software, well beyond usability, and they deserve respect as well: for example, if you delay and delay until you have the most wonderful, engaging user experience in a piece of software that connects with a completely irrelevant technology—say, the world's best VHS player—did you make the right call? Coming to terms with non-textbook reality here took me a long while and was a big challenge.

Another challenge that was at least in part unique to those of us who work on open source projects as designers—I found out that as an interaction designer, you really have to learn to market and sell your ideas to the developers and other open source community contributors involved in a project. There is no management chain and expectations that a developer must write the software the way your design spec states simply because you're The Designer. The challenge was learning (the hard way) that a great interaction design is not enough: if you want it to happen, you need to develop some salesmanship, build up trust, use your research to back your designs up, and have a real enthusiasm and excitement for what you do in order to inspire the developers and other folks involved to pick that design up and make it into working software.

In my first job as an interaction designer, I was the first designer several of the developers had worked with. That was a bit of a challenge, because at times I had to take on an educational role, advocating for design itself, when I felt I didn't even really have enough experience to be in that position. I still sometimes get confusion over what an interaction designer is—thanks people who keep coining new terms for the discipline—to the point I get a continuous stream of logo and icon design requests. The software development process the team followed didn't really account for design or usability testing in the schedule, nor did the business processes involve it much at all. At times I felt I had to fight to interject myself into the process or risk being ignored by it, but I definitely had sincere enthusiasm both for the project and the team and I think that helped me bust through a lot of these kinds of barriers.Communication between designers and programmers can be challenging. What are some special tips for working negotiating with programmers?

I have a background in computer science and it has helped immensely. I am a terrible, terrible programmer myself, but from that background I know a lot of the basic lingo and concepts so I can, to a point, have a technical discussion with a programmer and understand what the software is doing enough to make smart compromises in the design when technical limitations come up in its implementation. So my tip here is to try to take even an entry-level computer science course, even a free online one, just to grok the basics, so you can understand just how much work that little thing you're asking for really is, and how to pare it back so it's much more achievable.

Another thing I've found handy is to keep a blog, and to post any mock-ups or design ideas in the blog. The open source projects I work on have related blog aggregators, so I make sure I'm signed up for those. Then the developers will see my blog posts when they read the whole daily aggregation, and leave comments on my post if they notice some issue or have a better idea. They can be shared with end-users as well, who often have great insights neither the designers nor developers thought of.

One odd tip here: if you have graphic design chops, offer them to developers. Designing icons, logos, and websites for their projects can be another good way to build rapport, and is a good way to introduce them to your design process; familiarity with your process later on something low-risk like a fun logo or design can result in a much more smooth interaction design process.

What are the key elements you strive for when designing for users?

Just the essentials: I try to strike for the right balance of providing as curated a set of information on screen as possible without providing too much. As in good writing, I think in interaction design you have to cut, cut, and cut until you think maybe you've cut too much. Keep interactions as simple as possible by keeping the amount of information thrown in the users' faces as pared down as possible.

It's important to step back and think about how this thing you are designing fits into the users' whole lives. What are they worrying about when they use it? What other things do they have on their plate? How high is this task on their personal priorities when weighed with other things in their life? When you work on a project, and it's the main thing you work on, I think it may be human nature to elevate its importance, so it's a good (and humbling) exercise to think about how it effects a real life person and try to fit that, instead.

What other fields do you take inspiration from for your work? (dance? animation? breakdancing?)

Film-making and narrative theory. I took a fantastic course with Alan Nadel when he was at RPI on narrative theory, and I use things I learned through that course probably every day on the job. Film-making principles and the meaning you get from them is very directly applicable to software interaction design.

Gardening is also a good way to look at communication around software design and development in general, if only to teach the virtue of patience and regular check-ins.

If the field of Interaction Design needs a hero, what would that hero do?

That hero would come work on making free and open source software better and convince other designers to do the same.