Friday, February 13, 2009

The human side of user interfaces, part 2

After coming up with the list of things I wanted my to-do list software to do or not do, I started looking at Task Analysis.

As far as I can tell, task analysis is one step back from the software and looks at the humans almost exclusively. You analyze who the users are, what their backgrounds with computers are, and their goals. Task descriptions say what the user will do, not how they will do it, and reflects their real interests.

At first, I thought "add a task to my to-do list" is a goal, but it's not. Having an item on the list is my goal; I don't really want to add it, that's just the mechanism I use to have the reminder.

Perhaps a better example is one from the book I linked above. It was describing a store where you could enter the item number of something you wanted to buy into a computer and someone would bring it to you from the store-room in back. The computer UI for this looked completely reasonable to me: it had name and address fields, a place to choose cash or credit, etc, and a field to enter the item number.

But, reading the descriptions of the user's goals, it became clear to me that filling out the form is not the user's goal. The customer's goal is to buy something; they're not interested in using the software just for the sake of using it. If this user is paying cash, they don't want to fill out all that personal information, they just want their item and want to go. Most likely they will find a human or give up and go elsewhere. That's bad UI for the store!

Armed with this new way of thinking about tasks, I sat back and considered what tasks I wanted to accomplish with a to-do list. Here's what I found, first listing a few of the task descriptions I wrote up (made easier since I'm the only user).

Description 1

While getting a new bar of soap for my shower, I see that we are now out of reserve bars of soap.  I make a note to myself to get soap the next time I'm at a store that sells soap (CostCo, Target, drug store, etc).  I proceed to use the existing bar of soap for my shower.

Description 2

While sitting at work, I see something that reminds me I should call my mother that evening or over the up-coming weekend.  I make a note to myself to call my mom.  I continue with my previous reading or task.

Description 8

While at work, Willie emails me something else to add to the grocery list since I said I was going after work. I add the items to the list. I go back to checking my email.

Description 9

I'm coming home on Wednesday evening. I need to be reminded that it's time to take out the trash and whether it's a recycle week. I take out the trash.

I came up with 13 task descriptions in total. They fell into these categories:

  • add to list (shopping, reminder, projects, someday) - location varies
  • be reminded to do something - location varies
  • pick something to do - at computer
  • postpone item from reminder list (re-add with diff date/time) - location varies
  • plan a project - at computer
  • read whole shopping list - not at computer


After looking at that list, I realized that "paper and pencil" probably worked best for when I was not at the computer. But I also realized that paper can't remind me to do things at a certain time. So, I started looking for wristwatches with alarms.

What writing the task descriptions did for me was remind me that computer software is not always the answer. I'm not saying that I've found my to-do list nirvana or even a system that mostly works for me, but I have realized that focusing on computer software to the exclusion of other solutions is not the answer. And that any good software UI will be built with an understanding of how that software fits into the user's whole life, not just their interaction with the software.

No comments: