Specifying a better user interface

How to change a specification from "Must be Windows compliant" to a more meaningful list of requirements!

The problem
The benefits
The four requirements for a successful user interface
Consistency
Intuitiveness
Simplicity
Versatility

The problem
This decade has seen a boom in Graphical User Interfaces (GUIs). Much of this development has been made possible due to the various Windows operating systems. From an operator's point of view, this should be a major win. Gone should be the need to remember obscure keys, poorly displayed information, and cumbersome software.

Unfortunately this has not happened. Instead, many systems now have colourful, Windows based user unfriendly access control software. This has been made possible by a number of causes:

• The operator is not the purchaser in many cases
• Many tender documents only require one feature in terms of user interface- "Windows based"
• The difficulty in establishing tangible, measurable standards which do not limit the software to one supplier
• Software development by programmers who have never met the end user

This document is intended to solve one of these problems by providing a method to specify a good user interface.

The benefits
The benefits of having a strong consideration for the end user include:

• Very short learning curve bringing operators up to full productivity quickly
• Knowledge and use of all features
• Less accidental errors due to confusion or panic
• Slow but easy to use methods for new users help beginners
• Quick shortcuts for experienced users save time
• Quick fault finding when problems occur
• Decreased need for training and documentation saving time and money

The four requirements for a successful user interface
Consistency

• The same outcome from the same action in all windows
• The same action to achieve the same outcome in all windows

Intuitiveness

• Expected outcome from an action in all windows
• Expected action to achieve an outcome in all windows

Simplicity

The Keep It Simple Stupid (KISS) principle to remove unwanted complexity.

Versatility

• Slower but easy methods for new users (typically buttons and menus)
• Fast but more complex methods for experienced users (typically keyboard actions)

Consistency

• One button message to close a window (eg close, exit, dismiss)
• One set of messages to accept or cancel changes (eg accept, continue, save, cancel, stop, restore)
• Consistent database navigation buttons
• Consistent location(s) for buttons, especially the close and navigation buttons. The industry standard is to have buttons either along the right hand side or at the bottom. Any more than two locations becomes slow and tedious to use
• Data entry methods must be consistent- eg numbers must be able to be entered directly or with scroll buttons. Note that the focus is in ensuring consistency, not in specifying how.
• Keyboard actions must be consistent. eg "escape" is always the same as "close" or "cancel". F1 will always bring up the help screen.
• Selection options must be consistent: Radio buttons for a choice of "1 of x", check buttons where multiple selections are possible, and frames around related options.
• Warnings and fault messages must all include (1) what the problem is, (2) severity, (3) implications and (4) what should be done to fix the problem.
• The same menu structure (where applicable) on all screens.

Intuitiveness

• No acronyms! (I hate TLA's)
• Unavailable options must be ghosted out or hidden.
• Ranges must be specified where the user is free to enter information.
• Default values must be available for all numerical fields and must be valid.
• Field hardware must be grouped by functional groups, not hardware types.
• Toolbars (if applicable) must include all frequently used operations. This should be at least user, access level and time zone programming and reports.

Simplicity

• Descriptions must be available for time zones, access levels and keys.
• Descriptions must be shown where available, not numbers (eg access level names, not numbers)
• Lists (eg drop down lists) must be limited to only available options
• Technical information must be hidden from the user where ever possible.

Versatility

• Hot keys to bring up commonly used screens. These include user, access level and time zone programming, reports and help.
• Hot keys to close the window, go to the next and previous record and to save information.
• Links between related screens. For example, a button to go from the user screen to the access level setup screen.
• The ability to use the system without a mouse

The above points will hopefully provide a practical method to compare user interfaces. It should be stressed, however, that it is critical to find out what the actual user will also require. We do not, however, recommend that you specify a system "the same as it is now", otherwise you will defeat the purpose of upgrading!