1.1 Figure Out Who's Going to Use the System to Do What

The industry terminology for this step is "task and user analysis." The need for the task analysis should be obvious: if you build an otherwise great system that doesn't do what's needed, it will probably be a failure. But beyond simply "doing what's needed," a successful system has to merge smoothly into the user's existing world and work. It should request information in the order that the user is likely to receive it; it should make it easy to correct data that's often entered incorrectly; its hardware should fit in the space that users have available and look like it belongs there. These and a multitude of other interface considerations are often lost in traditional requirements analysis, but they can be uncovered when the designer takes time to look into the details of tasks that users actually perform.

Understanding of the users themselves is equally important. An awareness of the users' background knowledge will help the designer answer questions such as what names to use for menu items, what to include in training packages and help files, and even what features the system should provide. A system designed for Macintosh users, for example, should provide the generic Mac features that the users have come to expect. This might mean including a feature like cut and paste even though cut and paste plays no important part in the system's main functionality. Less quantifiable differences in users, such as their confidence, their interest in learning new systems, or their commitment to the design's success, can affect decisions such as how much feedback to provide or when to use keyboard commands instead of on-screen menus.

Effective task and user analysis requires close personal contact between members of the design team and the people who will actually be using the system. Both ends of this link can be difficult to achieve. Designers may have to make a strong case to their managers before they are allowed to do on-site analysis, and managers of users may want to be the sole specifiers of the systems they are funding. It's certain, however, that early and continued contact between designers and users is essential for a good design.