Systems Analysis & Design: Topic 9b
User Interface Design
- any portion of the application that allows users to input data or commands into or receive outputs from the
- includes the system aspects that are "visible" to users and that allow users to interact with the
system's data, software, and hardware.
Approach to Interface Design
- The tasks to be supported by the system are analyzed.
- Based on the physical data flow diagrams or
use cases of the proposed system, the user interfaces required
for the system are identified.
- Based on an understanding of the system's tasks and intended users, the design of each user interface is specified
and aligned with the users' skill level and the logical flow of their tasks.
- Prototypes of the interfaces are often constructed and demonstrated to the users to gain their feedback.
Note: Because a good interface combines aesthetics, usability, and functionality, designing user interfaces
is as much an art as it is a science.
Five-Step Process for Interface Design
|(1) Analyze the Users and their Tasks
||Task analysis is used to identify, categorize, and define the procedures users employ to perform work tasks.
|(2) Identify Required User Interfaces
||Examine physical DFDs to identify the documents, data entry screens, printed and screen reports, and other interfaces
||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.
|(3 & 4) Select a Dialog Type and Develop a Prototype
||Design the command hierarchy, detailed interactions between user and system, and the interface objects required
to manage the interactions.
|(5) Review and Revise Prototype
||Validates the design but also builds user commitment because users feel that their needs and opinions were considered.
||Usability tests can help to ensure that system interfaces are easy to learn and use and that they support the desired
level of user productivity.
||User reviews should be conducted repeatedly during the iterative analysis, design, and prototyping stage.
Types of User Interfaces
- External Documents
- External documents include all tangible "pieces of paper" that are used to gather inputs to or that
are generated as outputs from the system.
- Examples: application forms, purchase orders, invoices, checks, bills of lading
- Data Entry Screens
- Data entry screens are used to enter data into the system.
- A data entry screen is needed
- for each of the system's master files or object classes so that records or object instances can be created,
edited, and deleted and
- for each transaction the system automates so that data about the transaction can be captured by the system.
- Minimizing the amount of data entered by the user can increase user productivity and reduce data entry errors.
- Reports summarize and organize data in a format meaningful to their intended users.
- A well-designed report should be easy to scan, highlight important facts, and use a consistent, symmetrical
- Reports differ from external documents in that reports are generally intended for internal use and are produced
by sorting, calculating, and compiling data stored in the system's database.
- Short reports that have a limited audience and are stored for only a short period of time can be generated
as screen reports.
- Longer reports that have a wider audience and that are used over a longer period of time should be printed
- Human-Computer Dialog
- Human-computer dialog refers to the style of interaction between the system and its users.
- Types of dialogs include command, menu, form-filling, direct manipulation, or a combination of these.
- The primary considerations in selecting a dialog type are the level of user expertise and frequency of use.
||A command dialog triggers the execution of system functions by employing a command language that defines
the valid terms and syntax for execution.
||Although command dialogs are appropriate for compute-literate frequent users, they are inappropriate for most business
||A menu dialog lists several possible actions and requires the user to select an option.
||Menu dialogs are especially appropriate for infrequent or inexpert users.
||A form-filling dialog typically replicates a source document and requires the user to fill in the form.
||This form of dialog is appropriate for novice or infrequent users.
||A direct manipulation dialog is one in which a pointing device such as a mouse is used to manipulate screen objects
that perform system functions.
||Direct manipulation interfaces provide several benefits such as ease of learning and ease of use, and are therefore
appropriate for novice users.
||examples: point-and-click menu selection; double-clicking icons to launch applications or to open files, using
drag-and-drop to copy a file
||History of the Desktop
- User documentation is the part of the user interface that describes how to use the system.
- Designers and documenters should work concurrently so that documentation evolves as the system evolves.
- A poorly designed system is difficult to document; thus, documenters can serve as front-line testers of the
- User documentation may include the following components:
- A user guide that describes the system and explains its use.
- A reference card that summarizes basic functions and commands.
- Specialized guides that describe how to install the application or explain system error messages.
- Tutorials that instruct users in the system's basic functionality.
- An on-line help system that basically replicates the user guide and assists users in understanding and using
system features and functions.
- One issue in creating user documentation is determining how material should be presented.
- The trend is to create self-documenting systems instead of making documentation a separate, add-on product.
- For example, many commercially available software packages provide on-line help systems and/or cue cards that
explain how to perform a task.
- Most GUIs use the status bar to display a brief explanation of what a menu option or tool bar icon does.
- Having a few representative users try to perform use-case tasks by using the documentation is the best test
of its clarity and completeness.
CRITERIA FOR EVALUATING USER INTERFACE DESIGNS
- The user's mental model of the system consists of the concepts he or she uses to explain the behavior of the
- A well-designed interface helps users map what they want to do to what they can do, or what
they did to how the system responded.
- Make clear what actions are currently possible. (example: show available options in dark type and "gray
out" other options.)
- Provide timely feedback about the effect of user actions.
- Anticipate errors and design the system to help users avoid them.
Simplification of Tasks
- The interface should help to simplify users' tasks.
- Minimize user memory load by employing menus, function key mappings, pop-up windows, tool bars, and so on to
remind users of frequently used features and functions.
- Limit the number of menu options, open windows, and so on to adhere to the
- Follow the Rule of
1.7. At the normal viewing distance from a monitor, the human eye can focus on an area only
1.7 inches in diameter. Thus, each circle with a diameter of 1.7 inches is a natural "chunk" for the
human information processor. Arranging data elements on the screen into logical chunks of data, each chunk related
to one task or one concept, will focus the user's attention and simplify task completion.
- Create a simple, natural dialog by moving seldom-used features, functions, or information from the main application
screens to sub-menus and screens.
- Provide shortcuts to exploit the experience of expert users. Shortcut keys and keystroke combinations make
an interface more flexible and thus more usable by a broader range of users.
- A well-designed user interface makes clear what can and should be done.
- Provide clear, understandable, relevant feedback. An hourglass, a clock, a gauge moving from 0 percent to 100
percent are all standard feedback mechanisms used to indicate that the system is busy.
- Clearly indicate how to exit the system, cancel a command, or close a window.
- Avoid technical jargon and cryptic system language in designing error messages. Where possible, suggest an
action to recover from the error.
- Use color, boxes, and font changes sparingly and logically to improve visibility and to focus the user's attention.
- The interface must be consistent and its behaviors predictable.
- Interface standards (also known as application standards) specify design decisions and stipulate templates
for window components, such as the title bar, type and location of options on a menu bar, and so on.
Example Use Case
|Use Case Name: Rental Customer Rents Rental
|Use Case Purpose: Describes the process of renting rental tapes to rental customers
|Uses: Rental Customer Pays Fines; Customer Makes Payment
|Extended by: Rental Customer Rents 3/3 Rental Tapes
|Typical Course of Events:
|The main menu is displayed on the screen; waiting for employee number and menu selection:
- When a customer presents membership card and selected rental tapes for check out, this use case
is initiated by the sales clerk's entering a valid employee number and selecting "Process order" from
the main menu. The Process Orders menu is displayed.
|Waiting for menu selection:
- The sales clerk selects "Process rental orders."
|The rental order screen is displayed; waiting for member number:
- The sales clerk scans the member number from the membership card, and the system verifies
that the member number is valid and that the rental customer has no unpaid fines.
- If the member number is valid, the system completes the rental order header, indicating
a valid employee number, a valid member number, order number, and order date.
- The system prompts the sales clerk to enter a rental tape stock number.
|Waiting for stock number:
- The sales clerk scans the stock number from the rental tape.
- For each rental tape being rented, the system creates a rental order line, giving the stock
number, title, rental category, and rental fee of each rental tape; in addition, the due date calculated for each
rental tape is shown on the rental order line.
- The system prompts the sales clerk to enter another rental tape stock number or to signal the
end of the order.
- If another stock number is entered, the system creates another rental order line.
|Waiting for end of order indicator:
- When the sales clerk signals the end of the order, the system creates a rental order footer
by calculating and displaying the total cost for the order.
- Customer makes payment. (See Customer Makes Payment use case.)
|Waiting to print receipt:
- The sales clerk requests that the receipt be printed.
- The system prints the rental order receipt.
- The customer signs the rental order receipt.
- The customer is given one copy of the receipt; the other copy is retained for the audit file.
Figure: Partial detailed use case for Rental Customer Rents Rental Tape(s)
Adapted from: S.D. Dewitz, Systems Analysis and Design and the Transition to Objects, McGraw-Hill, 1996.