I recently returned from Seattle interviewing for a Usability Engineer position in the Visual Studio group at Microsoft. It was an interesting time, but I won’t explain too many details here (ask me one on one for those). But there were a couple of interesting questions / points from the interview that I wanted to share, along with my two cents. For the HCI folks embarking on interviews, I think it will be interesting food for thought.

1. Having background in your user’s expertise is necessary for the job.
One of my favorite things about HCI is that it enables people to design usable interfaces in a variety of disciplines. But as an outsider / novice to the discipline, are the designs really going to be as relevant as an expert who really understands the ins and outs of the field?

At CMU, we are taught to repeat the mantra: “The user is not like me.” On the one hand, having expertise in what your user does will help you to understand his/her work better. On the other hand, it seems like our mantra is what it is to avoid HCI practitioners from substituting their own judgment in lieu of what they actually observes users doing.

Let me say, however, that at Microsoft some prior familiarity with the user is probably necessary, since you are dealing with developers. It would be hard to walk in with little prior familiarity and succeed. The challenge, then, becomes perceiving the line between understanding the user’s work and filling in the data for yourself. I think most HCI practitioners can tell the line, but it’s not something we’re confronted with everyday at CMU. Instead, we just say “The user is not like me” and the issue seems to be dropped.

2. Why not skip modelling all together and go from contextual interviews to prototyping?
We joked about this notion during Project, but one of my interviewers was the former mentor of one of the authors of Contextual Design. His take was that Contextual Interviews were important, but that in the business world, taking the time to model the user’s work is simply delaying the creation of a legitimate prototype. (For the record, I didn’t sit idly by during this discussion. I threw all of the Methods points (and a few of my own) back in response: shared language for the design team, a way to abstract the minute points of the users work, etc. - he wasn’t going for it though).

Looking back, there’s a strong correlation between the two points that I missed. I think part of the purpose of modelling a user’s work is to overcome the knowledge gap in a new discipline. At Microsoft, this may not be as necessary if their user research folks already understand enough to interpret what they see. But, in the case of a tough discipline like education research, modelling helped the group gain a lot of understanding in a short amount of time.

I think that both ways of thinking are necessary. On the one hand, when you’re job is designing for code developers, day in and day out, having little to no prior experience will make you batty in short order. On the other hand, there are a lot of disciplines out there, and I think it’s unreasonable to expect that there are enough double experts (experts in a discipline and HCI) to go around. So, to quote the classic CMU professor answer… It all depends.