Talk to Target Users

Now that you have identified target users, the next step is to actually talk to them. You need to understand them and their goals in more detail. You need to ask target users the following questions:

  • What is their work environment?
  • What tasks do they do? How can software improve those tasks? Can the tasks be made more productive and more enjoyable? What are the biggest problems?
  • What is their skill level for the task that the program will perform? What is their software skill level?
  • What hardware do they feel comfortable using? What hardware do they have?
  • What Windows features do they understand?
  • What terminology do they understand? What languages do they speak? (Obviously, not everyone speaks English.)
  • How often will they use the program? For how long?
  • How much training will they receive?

If you are able to, you should watch users perform their work. (This is referred to as a site visit.) See what they do. Ask them why they do it. Try to understand what tasks are really necessary and what tasks are unnecessary overhead. See what mistakes they make. Not only will this allow you to understand the tasks better, but it will also allow you to identify problems the user isn't even aware of. Also, try to determine the accuracy of your target user profile. Is the typical user similar to the target user or is the target user only the center of a broad spectrum of users?

The goal behind this research is to really understand your program's users and their needs and goals. What you want to do is to create a framework that you can use to make good design decisions. You definitely want to avoid speculating on what tasks users might want to do or how they might want to do them—work from the direct knowledge of your users that your research gives you.

TIP
Avoid designing user interfaces based on speculation of the user's needs and goals. Work from direct knowledge whenever possible.

As I discussed in Chapter 6, "Beginning vs. Advanced Users" and Chapter 7, "Using Applications vs. Utilities" the answers to these questions really do make a difference in the design of a program. These chapters describe how knowing that a program is a utility targeted specifically for beginning users leads to an understanding that certain design possibilities are appropriate and others are not. Specifically, a program aimed at beginners should have visible features so that the user can figure out the program just by looking at it. The program shouldn't rely upon interface elements that are not visible—such as context menus, direct manipulation, or keyboard shortcuts—and should avoid elements like edit boxes and interactions like double-clicking. A program that is a utility should be simple to use and have a flexible layout that works well in a small space. It should not use MDI, be initially maximized, or have a complex toolbar.

While understanding the type of user and type of program will help you choose which user interface elements to use, understanding your users' needs and goals will help you decide everything else. This knowledge will help you determine factors critical to the success of the program, such as what features to provide, what data is required, how the tasks should be performed, how all the program activities should fit together and how they should be implemented. This information will also help you make decisions about design details, such as the importance of the mouse vs. the keyboard, the performance of the target hardware, and whether it is appropriate to use audio. For example, using audio is inappropriate in an office environment but can be appropriate in other settings.

TIP
Use specific target user information to make decisions about design details.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net