User Interface Design Considerations
and Guidelines
The user
interface is often (especially in academic exercises) an afterthought:
if this notion rings a bell with you be warned, there is much to be
gained from designing and specifying interfaces for your system at
the same time as other system development decisions are being made,
especially in an event driven development environment.
In fact, user interface design can be considered in terms of the three
axis model: lifecycle stage, modelling technique and engineering
practice. We shall consider this thought later, first a definition of
user interface.
What is a user interface?
The primary role of a user interface is communication, both human to
computer and
vice versa. Communication covers many areas of
information transfer:
data entry;
system response;
usability: understanding; usage; clarity of display.
An important but secondary role (but also one of some consequence in the
commercial sector) is appearance.
The emphasis placed on each of these roles depends almost entirely on
who the user of this system is likely to be. There are many species of
user, eg. the novice, the new user, the expert, the hacker etc.,
and it may be necessary for you to attempt to create a system which
is suitable to interface with more than one of them. The user
interface is many things to many people. Finding out
what the
interface means to a specific user is
therefore of importance to a system designer.
Identifying the intended user of a system is the first stage in
designing an interface.
Once the designer has discovered this fact
interface design and specification can be considered. Interface design and
specification
can occur at many points throughout the system's
lifecycle stages. Designers should carry out some task analysis and
use task scenarios to help them gain knowledge about the system's
intended user and user requirements. Prototyping the
interface in the early stages of
system development, and intentionally involving the user, can be helpful in
gaining further information about user requirements and/or in the
clarification of system functionality.
Modelling techniques for
interface design can be
informal, such as storyboarding, semi-formal such as state transition
diagrams, or more formal such as CCS or CSP
(process algebras used in interface dialogue design, see Dix 1998 for
a brief description). Many of the interface design
considerations that need to be made are engineering practices,
for
example: at the system level, cross checking of data model entities,
system events
and expected interface actions; and at the users'
level examining
user feedback/comment on usability, layout,
fonts, colours etc. The last
stage of interface development is the evaluation of
the interface
produced and the consideration of changes that need to be made to
it. This stage must (to some extent) involve the target
user(s).
Developing a user
interface
1. Identify the user This usually comes within
the initial interview stage of the systems design and development,
but it may not. E.g., Willowbank's system is likely to be used by
the Sellers and
their staff (who are probably computationally at the
same level as the Sellers), but developing an ACM for a Building
Society or Bank is not usually done with the clients
of the Building
Society, all several million of them, but with the IT and transactions
departments (and the customer care section if they're
psychologically aware).
Many design choices that you'll
make during system development are dependent on the
requirements of
the user. The user predominantly dictates which data is to be held
within the system, but its structure is often beyond the knowledge
of the user and
as such, the user interface bridges the gap between
the external requirements and desires
of the user and the structure
of the data held within the system.
2. Interface Design and Specification
User interface specification can be approached in a number of
ways. Informal methods, such as storyboards have been used to reflect
the relationship between "screens" in the final system and thus
reflect the control of system use. Storyboard are
typically paper based although they are used as a guide when
prototyping an interface using applications such as MSAccess,
MSVisualBasic or Delphi.
More formal techniques such as CCS, CSP (Dix 1998) or USE notation (Wasserman 1987) are
also available for modelling the interface before
production.
Events and actions are a useful starting point in
specifying and designing the actions of a user interface, they can be
developed further into storyboards (as they are really very simple
state transition diagrams) or state charts. All these techniques aim to specify the functionality of
the interface.
A Brief guide to storyboard design:
extract a list of events from your event scenario and/or your state transition diagrams;
use your entity relationship model and your data dictionary to establish input, internal
and output information associated with each event;
group your listed events by functionality
develop a storyboard of I/O "screens" for each grouping of events.
For example, some of the events for a grossly simplified Building Society ATM
could be listed as: card entry, PIN entry and cash withdrawal.
Information associated with these events is:
EVENT
INPUT info.
INTERNAL info.
OUTPUT/ACTION
Card entry
Card Details
Customer Details
PIN request
PIN Entry
PIN info
Customer Details
-
Cash Withdrawal
Request+ Amount
Customer Details and ATM's resources
Acknowledgement and Money output
Grouping events by their function (i.e., by the time at which they occur; the object they
act on, or the type of function performed) we can see that "screens" will be needed for card
entry and PIN number entry and for cash transactions. Other "screens" required
by this system will be concerned with balance enquiries, statement enquiries and
provide error information.
The second stage of interface design considers
more aesthetic qualities of the interface in combination with
efficiency and usability.
Further Design
Considerations
a) Common sense characteristics (from Heckel, 1991) and practical
design suggestions.
Focus the user's attention: use colour changes, highlighting or
sound, make screens
attractive.
Speak the user's language; it's their system after all. Correct
use of terminology/keywords
and links between menus with associated
terms are essential for the user to get
the most from their
system.
Communicate visually: use buttons, sliders, menu's with colour
changes where appropriate.
Anticipate problems in the user's perception: prototype your
interface, involve your
user in interface development, test your
interface thoroughly.
Make your design simple, but not too simple. Your users may be a
combination of novices
and experts: allow command lines as well as
menus; provide short cuts, allow protections
and confirmation
queries to be turned off. Complicated gimmicks can become boring, as
can sound.
If you can't communicate it, don't do
it!
b) Some guidelines for good dialogue design (from Sutcliffe
Human-Computer Interaction p. 101-102)
Feedback:
Tell users what is going on,
particularly if there is a delay
Status: Inform users which part of the system they
are in
Escape: Allow users a way of terminating an operation
and escaping from options
Minimal Work: Keep the number of dialogue steps to a
minimum and reduce amount of typing by abbreviations and codes
Default: Set default replies where the answer is
predictable
Help: Provide on-line help wherever possible - preferably layered so
it refers only to the current option or facility
Undo: Provide the facility for the user to backtrack and recover a
previous state
Consistency: The format and execution of commands should be consistent
throughout the interface
Evaluating a User Interface
Evaluation of user interfaces is necessary for two main reasons. The
first is as a
method to establish how an existing interface may be
developed or enhanced. Of
course you would say that you've spent
time and effort on your interface design and
therefore this would
never apply to you; you may be right, but how do you know that you're
designing a good interface for your user if you don't evaluate the
interface you've
created before you commit it to full implementation
system*.
Evaluation considerations:
Consider issues of design (outlined above).
Put yourself in the user's shoes.
Do you know what is
happening at each and every stage of interaction with the
interface?
How long does it take to learn the system?**
How efficient is the system?**
Is there optimal use of
the system defaults?**
Are the user commands easy to remember/find?**
(*Design implications of producing user interface are
addressed in Martin Lea's paper
held in Short Loan Collection, see
refs.
** Evaluation measures described by Card, Moran, Newell.)
Final Comments
The use of specification techniques and consideration of design issues
will help to
minimise the production of interfaces which are
unsuitable for the task or the user: remember the user is the
ultimate judge and you might well have a legal obligation to provide
them with an interface suitable to their needs.
This paper addresses user interface design from a broad
perspective. It provides guidelines
and some general theory of interface
design and as such only touches the surface of user
interface design
and evaluation. There are many sources of information on user design,
the appendix provides sources I have used or that have been
recommended to
me. If you are interested in this area of system
development you must read widely
as many sources are quite
subjective in the view they present.
References
Baecker and W. Buxton
(Eds.)
"Readings in HCI: A multi-disciplinary
approach"
1987.
L.Bass and
J.Coutaz
"Developing Software for the User
Interface"
Addison-Wesley, 1991.
S.Card, T.Moran,
A.Newell "Psychology of Human Computer
Interface"
1983