Thursday, February 5, 2009

The human side of user interfaces

I had the fortune of working on user interfaces for the last several years. During that time, I got to work closely with a usability/human-computer interaction (HCI) expert. I have been fascinated by user interfaces since college when Windows 3.11, MacOS, MWM, and CDE were the big contenders. I always wondered what made some UIs "good" or "pleasant" or "easy" and others "annoying" or "stupid".

Working with UIs as a computer programmer, I was more concerned with making sure the right data got into the right fields at the right time, that errors were handled correctly, and the UI could communicate with the other programs it needed to. In other words, I was concerned with the mechanics of the user interface. My few forays into design usually had me thinking, "that just doesn't make sense, let's do it this other way instead". But, I had no training or credentials to back me up, just instinct.

The UI expert I worked with has her PhD in psychology and specialized in HCI. I kind of expected some psychology, or at least sociology, to be part of an HCI ciriculum, but not the focus. Recently, I asked for some pointers on how to measure a UI and determine if it's usable. She pointed me at the Goals Operations Methods and Selection-rules (GOMS) methodology. It's fascinating and bears a striking resemblance to how one writes or refactors code.

But most of the references I read included disclaimers to the effect of "you need to understand human cognition to apply this correctly". I was fairly disappointed, but I've never been one to let lack of training or knowledge keep me from trying something. The worst case scenario here is I make a bunch of useless UIs for programs that I'm likely to be the only user of. Oh damn.

The prerequisites for GOMS are a list of goals and you determine those goals by doing task analysis. I found a few papers discussing task analysis and most of them were quick to point out that you're not analyzing a machine, you're analyzing a human. For example, the paper I read pointed out that in addition to the goal of "open this valve" for a chemical plant operator, he also had goals like "get paid" and "don't screw up so I can keep my job". It's the analyst's job to be aware of those other goals and keep them in mind when coming up with the user's goals within the software.

At this point, I was feeling very under-qualified for ever writing a UI again. But, people do it all the time, so screw it, I plowed ahead. I started writing down what I wanted out of a to-do list application. I started with "add task" and "break task down into smaller steps", but decided that was too goal-specific. I thought about how I'd want to use the software and what I want to feel when I use it.

I know, it sounds cheesy, like the "lickable" interface in Mac OS X. I thought, "I don't want to have an emotional reaction to my UI, I just want it to work!". But, then I let go and tried really capturing what I want from a to-do list app. Here are a few of the more touchy-feely things I noted:

  • Gentle reminder of things I could be doing, not things I must do
  • Calendar/grocery list are more transient and more insistent, so different feeling of interaction with those items - no harm in crossing off an item, need reminders/popups
  • A way to ease the pain of letting go of something I thought I wanted to do, but just haven't gotten to

Suddenly, I understand why a psychology degree might be relevant to UI design. Those aren't just things I made up to be silly, that's really how I want to feel when using the perfect to-do list application. Of course, I can make do with a UI that doesn't meet those needs, but I will consider a UI "better" or "pleasant" if it meets my unspoken, even unconscious, needs.

It appears I have a lot to learn about UI design and about users.

No comments: