Five-Step Process for Interface Design
1. ANALYZE THE USERS AND THEIR TASKS
The first step in interface analysis and design is to analyze the users and their tasks. A new system is easier to learn and to use if it is aligned with the user's method of completing a task, and if its flow of activity parallels the user's task flow. Hence task analysis is used to identify, categorize, and define the procedures users employ to perform work tasks. Then the new system is designed to support those methods where possible.
Questions to answer as you analyze users and their tasks include the following:
- Who are the intended users? This question investigates characteristics of the intended users: their level of expertise at performing the task, their experience using automated systems, and any other relevant factors. The answers will influence your choice of a human-computer dialog and the amount and type of documentation, help screens, and other support your interface provides the users.
- What are the users' goals in performing the task? Determining users' goals helps you to identify criteria for evaluating interface design. A good design helps users to achieve their goals.
- What information do users need to perform the task? This question investigates the inputs to the task: what the user must know and what data the user must access to perform the task.
- What information do users generate as they perform the task? This question examines the outputs of the task: what outputs must be generated and how each should be generated. Should these outputs be displayed in real time, or can they be compiled (batched) and generated as a single output?
- What methods do users employ to perform tbe task? This question investigates the shortcuts, rules of thumb, and other methods that users have developed to facilitate task completion. Methods used to perform a task can be identified by interviewing expert users, observing users as they perform the task, and examining physical DFDs or use cases describing system behaviors.
2. IDENTIFY REQUIRED USER INTERFACES
Your next step is to examine physical DFDs to identify the documents, data entry screens, printed and screen reports, and other interfaces it requires. A user interface is required whenever a manual process interacts with an automated process or an external entity provides input to or receives output from a process. Each interface data flow will not necessarily require a different interface.
3. (and 4.) SELECT A DIALOG TYPE AND DEVELOP A PROTOTYPE
Now that you understand the system's users and their tasks and have identified the required interfaces, you can begin to design and to prototype these interfaces. Following a three-step process will help you to complete this task [Yourdon 1994]:
- Design the command hierarchy.
- Design detailed interactions between user and system.
- Design the interface objects required to manage the interactions.
3.1. Designing Command Hierarchy
During the first step of designing the command hierarchy, you identify the major screens or windows that users will employ to access and to perform system functions. Basically, what you are doing is providing
- A view of the system's functions or object methods in the form of menus or command buttons.
- A way for the system to accept inputs from the user in the form of data entry screens.
- A way for the system to display information to the user in the form of screen reports and error messages.
A technique used to model the command hierarchy is the dialog flow diagram, which shows the major screens or windows of the system as labeled rectangles and indicates the flow of control between screens as directional arrows. The symbols used in a dialog flow diagram are explained in Figure 1.
Figure 2 gives the dialog flow diagram for an order processing system. The dialog flow is presented as a hierarchy of functions, beginning with the topmost system menu. Each screen at the next lower level must be accessible from the preceding screen. Thus, each of the screens must be options on the system's main menu screen. Notice that all eight second-level screens are accessible from this menu.
A dialog flow diagram presents the structure of the system's user interfaces; these interfaces allow users to interact with system processes, whose structure is documented in a program structure chart. Thus, the structures of both diagrams are similar. The flow of control between system interfaces also tends to mimic the flow of control between program modules, which suggests that examining your program structure chart can help you design the flow of control between interfaces. Furthermore, you should compare these two diagrams to ensure that the interface structure design supports the program structure design.
3.2. Designing Detailed Interactions Between User and System
During the second step of designing detailed interactions, you make the design decisions that determine the look and functionality of the system's user interfaces. You determine which data elements will be entered by users versus those that will be retrieved, calculated, or assigned by the system's software. Other design decisions include whether a report should be printed or displayed on screen and how external documents and reports should be formatted.
Users must be involved in making design decisions.
TABLE: Guidelines for selecting window objects to trigger a process
Frequency of Access Number of Selections Appropriate GUI Object Infrequent Many Pull-down menu, pop-up window Infrequent Few Button or tool pallet Frequent Few Button with hot-key or function key Most frequent --- Default button
TABLE 11.4 Guidelines for selecting window objects to enter text
Text Characteristics Appropriate GUI Object Single line Text entry field Fixed number of lines Multiple text entry fields Indefinite number of lines Scrollable multi-line text entry field Tabular Matrix window object
3.3. Designing Interface Objects Required to Manage Interactions
The last step in prototype development, designing the interface objects required to manage the interactions, transforms your design decisions into tangible interfaces. Depending on the resources and tools available, you can prototype user interfaces by drawing report and screen layouts on graph paper or using a word-processing, spreadsheet, or graphics program. Ideally, you will have access to a GUI generator or the interface design capabilities of a DBMS. For example, Microsoft Access, Visual Basic, or Java can be used to design and construct all the typical components of a GUI--menu bars, tool bars, buttons, pop-up windows, and so on--and a variety of user interfaces, including data entry and menu screens and printed and screen reports.
If you choose to construct user interfaces employing a GUI generator or a DBMS such as Microsoft Access, you are practicing object-oriented design. Each window, button, icon, and so on created using these tools is an object, which remembers its attributes and performs methods.
5. REVIEW THE PROTOTYPE WITH USERS AND REVISE AS NEEDED
The last activity in prototyping the user interfaces is to review the prototype with users to gain their feedback. This critical activity not only validates the design but also builds user commitment because users feel that their needs and opinions were considered. User interfaces may be subjected to a usability test, whose purpose is to ensure that system interfaces are easy to learn and use and that they support the desired level of user productivity. You should conduct user reviews repeatedly during the iterative analysis, design, and prototyping stage. After the functionality of an interface has been programmed (e.g., a data entry screen interface actually accepts and processes data), users can work with the interface to evaluate its "feel"--that is, how smoothly and efficiently users can move from field to field on a data entry screen, select menu options, and so on. Finally, when all the system's interfaces are operational, users can evaluate the functionality of the system's full human-computer dialog.
Adapted from: S.D. Dewitz, Systems Analysis and Design and the Transition to Objects, McGraw-Hill, 1996.