This blog has been moved to

Monday, September 17, 2007

University of Washington User-Centered Design Certificate

I am now officially registered for the University of Washington User-Centered Design certificate program (UCD from here on). I'll be starting classes in October and should finish the program in the Spring (3 quarters). The company I work for offered to pay for training so I readily accepted. I was a bit worried that this would be too much for the budget ($1,800 a quarter for 3 quarters), but I don't think many others in the department are doing much.

The last certificate program I took at the UW (Object-Oriented Analysis and Design Using UML) took almost a year and a half to complete (I was definitely ready to be done with it by the end). It was all done online (except for a single trip to a testing facility for a written test). Being online was convenient, but I did miss the interaction with other students and the professors.

The UCD program, by contrast, is being held in classrooms, once a week, in the evening. Luckily I was able to arrange to take the first of the classes in Bellevue which isn't too far from Kirkland where I work (hopefully traffic won't be a major problem). Unfortunately the rest of the classes are going to be in Seattle, so that will suck trying to get over to the campus during rush-hour traffic. 

I was hoping I could find a program at the UW Bothell. It's only a few minutes from my work and is where I received my bachelors degree (Computing and Software Systems). Unfortunately they don't seem to offer any certificate programs, though maybe I'll get an MBA from there once the kids are out of the house (though their might be a branch campus near where I live by then).

I am hoping that this usability program that I am taking will provide me with plenty of material for my blog. If you are interested in this subject and don't want to spend the time or money on the course, stay tuned.

Sunday, September 16, 2007

Usability Rule #3: Know Thy User

Before you can design an interface that is easy-to-use, you must first know something about the user and how they plan on using the interface. Unless you are building an interface for only yourself, it is unlikely that you will get it right without actually talking to potential users.

So what characteristics are important when designing an interface? Although this list might change based on the interface you are designing, for a line-of-business application, the important characteristics tend to be...

  • Frequency of use - How often will the user use this interface. If they will use it every day, you will probably want to provide a very efficient interface. Focus on keyboard entry, allow entering codes instead of selecting from a list, make sure that frequently used fields are grouped together, etc. If they will use it once a month, the interface should be very easy to learn since they will probably have to re-learn it every time they open the interface.
  • Duration of use - How long will the user use the interface. If they will only use the interface for a few minutes then you can get away with a less-attractive, less-responsive interface. However, if they use the interface all day long, it had better respond very well and be at least somewhat aesthetically pleasing (would you want to stare at an ugly screen all day?).
  • Technical Competence - What kind of computer experience does the user have? Are they a power user? If so, you can provide many advanced bells and whistles (in fact, you probably should). On the other hand, if the user is afraid of turning on the computer, then the interface should be extraordinarily simple or the user doesn't stand a chance.
  • Work Environment - What kind of environment will the user be using the interface in? Will they be sitting in a private office with air conditioning and sound protection, free of distractions? If so, then work environment probably won't have much impact on the design. However, if they work on the shop floor of a manufacturing plant with heavy machinery constantly grinding away and a conveyor belt that moves every minute, this could have a significant impact on your design. In this situation for example, you will want to provide an interface that will allow the user to complete the task in less than a minute and does not rely on audio cues.
  • Hardware - What kind of hardware will the user be using? Hardware includes the computer and any peripherals (such as keyboard, mouse, monitor, printer, scanner, barcode reader, etc). Many users suffer with older, slower computers (you might be surprised by what even some software companies use). The user might not have much memory on their computer, have their monitor set to a low resolution, use a barcode scanner, or many other hardware considerations.
  • Physical Limitations - Does the user have any physical conditions that might limit their use of the interface? This includes eyesight, hearing, and dexterity along with any other physical conditions that might be prevalent amongst your targeted users. Getting an age bracket is probably the most useful information you can gather for this characteristic because that can have a significant impact on their abilities, though work environment could very well play a role here as well (perhaps many users come from years on the shop floor and now have some hearing loss because of it, perhaps they have worked with chemicals and have difficulty controlling the mouse).

As you can imagine, if you are planning on your interface being used by many people, you will probably need to talk to many potential users to get a reasonable understanding of what is common (though if you only talk to a single individual that would still probably be better than having a software developer guess).

So how do you compile this information? Once you've interviewed the users, you can use the information to put together a user profile that includes all of the common and important user characteristics. Persona's have become a common technique for building this profile. A persona is basically a fictional character that you create that typifies the target user. The reason that many people use personas is that it makes it easy to discuss requirements by just mentioning the persona's name.

 Example conversation between two interface designers:

[John] Hey Sally, what do you think of this form I'm designing?

[Sally] Who's it for?

[John] Frank [persona] is going to be using it.

[Sally] It looks good except for that link. I don't think Frank will be able to use it. He's been working with those chemicals for years and would never be able to get the mouse to hover over it. You should make it larger.

As long as both designers agree on the persona, John can immediately see that Sally is right and they can avoid all the discussion usually accompanied by such criticism. Of course, the main power of personas is that John's interface is already mostly correct with no discussion necessary.

One of the best examples of personas I've found on the Internet is from Microsoft. The Dynamics team has put together an excellent list of personas for their product and have made a couple of those personas available on the Internet. Microsoft Dynamics RoleTailored Business Productivity whitepaper

Sunday, September 02, 2007

I Got a Promotion!

Ok, not really, but I got my Evil Mastermind t-shirt from Source Gear. The payment was that I had to post a picture of myself wearing it. I don't really like getting my picture taken, so I created this picture instead (hopefully it's good enough).

If you want the full story for the picture, read the Evil Mastermind comic book.


The picture of me was created with the Simpsonizer. I added the Evil Mastermind image and the text using Paint.Net.

Source Gear (the company that sent me this t-shirt) is run by Eric Sink. Eric has also written a book called Eric Sink on the Business of Software, coined the term Micro-ISV, and has a great blog that I read regularly.