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.
Post a Comment