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