September 8th, 2007
When we start designing a user interface it should be obvious that we need to understand our users. Hopefully, formal requirements will provide some information but often that’s simply not enough. They may tell us things like what kind of computer, operating system, browser, or installed software a user has and they will describe what functions the program should have but rarely do they say anything about the user themselves. Let’s examine ways we can get to know our users and use that information to improve our programs.
Know Where the Users are Coming From
The first thing to remember is that users will tend to like whatever they’re using now. It could be a pen and paper form, an Excel spreadsheet or Access database with a little VBA code behind it, or something else that is no longer capable of doing the job effectively in the project sponsor’s opinion. They will typically be resistant to change unless the current method is very painful for them. Perhaps they will see their job as being threatened by a new program or business process. They often will resist learning anything new. They may even be unaware of the business trends that are driving the change. Also, they may not be aware of technological changes and prefer to do things in what they consider the old, reliable, way.
While some of this, such as changes to business processes, may fall on the project sponsors’ plate, as a user interface programmer you have to take this into account as well. You should avoid radical changes but, instead, go for evolutionary changes will move the users forward but not give them culture shock. For example, if you were moving an old Excel based VBA app to a web based solution you would probably want to maintain some of the spreadsheet style elements in your page designs. Or, if they used a paper form, mimic it somewhat in your design. The goal is to provide them with a new home they can become comfortable with quickly while meeting the functional requirements of the program.
Who are the Users?
In most circumstances you should be able to determine the profile of your typical users. Are they upper/middle managers? Phone operators? Sales agents? A wide range of users from across the company? What is their computer use skill level? What is their cultural and educational background? There are a lot of questions like this that you should ask that go beyond what is found in the average requirements document.
For UI design, you will want to particularly focus in on current computer knowledge since this can be a strong indicator of the approach you want to take. For example, if your program is for relative computer novices, a wizard-like step-by-step interface would probably be appropriate. But, if the program’s audience is primarily power-users, they might prefer a more direct hands-on approach. If it is for both user types, you may want to include both options. By understanding who they are, you can design the best interface options for them or at least develop a well considered compromise between the multiple user profiles.
Gathering this information can be tricky, particularly if you aren’t in the same location as the intended users. However, you should try to go directly to the source whenever possible rather than relying on what a project sponsor says about them. Often it can be quite different. I recommend arranging a team field trip to visit the facility where your users work if you can. It can be quite enlightening to see how the users currently do their job and to have them talk about what they like and dislike about their current methods. I would avoid paper surveys or intrusive methods like video taping. They just don’t seem to work as well from what I’ve observed.
Understanding The Users’ Tasks
Now that we know who the user is, we need to consider how they’ll go about their tasks. While we should have this in our functional requirements at a high level, we may still need more information. I’ve found it effective to rate the various tasks based on the following criteria:
- How often a particular task will be performed
- How critical the task is to the user’s work
- The amount of information needed to perform the task
- How many steps are required to perform the task now, if it is currently being performed
- Do the users need assistance or guidelines in performing the task
- What tools, other than the computer, are needed to perform the task (phone, barcode reader, etc.)
The goal is to design your interface so that this information is blended into it. For example, you want to make the common tasks easily identifiable to the users. They shouldn’t have to stumble about the interface and find a common task buried in a secondary dialog or two levels deep in a submenu. If the program is going to interface with an external device, such as a barcode reader, make sure your design makes this a smooth, perhaps even transparent, process, not a clumsy one. For uncommon or complex tasks you may want to provide some type of walk through assistance to help the users. The bottom line is that your UI should take into account how the users will do their work.
Understand the User’s Work Environment
Finally, we need to understand where the program will be used. Sometimes it may be used everywhere and anywhere. In that case, you want to design very generically and flexibly so that it isn’t tied to a single locale or user type. In other cases, the program may only be used by a specific group of people. Some of the things you want to consider are:
- What is their physical work environment? An Office? Store? Manufacturing facility?
- Are the users mobile, like traveling sales people, or fixed in a single location?
- What are the ergonomics of the situation? Will they be sitting or standing? How well will they be able to see and/or hear?
- Do some or all of the users have special needs such as multiple language support, accessibility support, and so forth?
Each environment type combination requires different approach. For example, a grid in a small font might work well for an executive in an office but it would be difficult for a manufacturing engineer to read across the room on a shop floor. Or a dull, business like, interface may be fine for an accounting app but you wouldn’t want to have an UI with no sizzle on a in-store customer relations program.
I hope this article has been helpful to you in designing and planning your user interfaces. Please let me know your ideas, thoughts and questions on user interface design by leaving a comment.
Entry Filed under: Tip Sheets
Rate This Article: