Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

1 of 8

15.4.2005 8:54

Designing a Graphical User Interface

by

Leslie Cortes, MD

Clinical Information Engines
Austin, Texas

accepted for publication in Medical Computing Today May 1997

Sections

Design

-

Event-Driven

-

Affordance

-

Principles

-

Suggested Readings

-

Comments

W

hether you aspire to develop the next big software hit or simply create computer

applications for your personal and office use, your applications will need effective user
interfaces to fulfill their potential. Designing such an interface is part discipline (following
platform conventions and good design principles), part science (usability testing) and part art
(creating screen layouts that are informative, intuitive and visually pleasing).

Tax preparation software illustrates the principles behind effective user interfaces better than
almost any other type of application. Tax preparation is a one-time task, practically all the
users are new to the program, and none of them will want or have time to read a manual.
Despite this, millions of taxpayers, including many barely computer literate ones, manage to
prepare their own tax returns on home computers. How is this possible?

The answer: functionality and interface. If functionality is what a program actually does,
then interface is how the user interacts with the program, perceives how the program does its
work. Concealing the details of a complex technology behind a good task-oriented interface
is not a new concept. One does not have to understand the inner workings of an automobile to
drive one, or how an ICU monitor works to run a strip.

A

lthough pure text interfaces are still appropriate for some applications, nowadays most

Windows and Mac programmers use the more popular and versatile graphical user interfaces
(GUI). The hallmark of GUI programming lies in its graphical control features, such as
toolbar buttons or icons. Unlike pure text interfaces which accept only keystroke commands,
GUIs allow for a variety of input devices (such as a mouse or penlight) for the user to
manipulate text and images as visually displayed. Web pages like this one employ a graphical
interface, for example, by using image maps to help users navigate the site.

Visual Basic, Delphi and C++ are tools commonly used for GUI application development;
you can also use Help and HTML processors, numerous database scripting tools, ToolBook,
Hypercard, and many other products. All simplify the process of writing an application while

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

2 of 8

15.4.2005 8:54

(this is critical) simultaneously creating its visual interface. Unless the programmer also
devotes attention to this interface the software created may function well, but not be easy or
pleasant to use.

I

n my experience, three main factors conspire against our creating successful GUIs. Each

will be elaborated on in turn: (1) we fail to shift from a problem-centered to a

user-centered

design

process; (2) we fail to fully understand and exploit the power of

event-driven

programming

; and (3) we ignore

affordance, metaphors and manipulation

. Further, we tend

to overlook sound

GUI design principles

, 10 of which I've summarized below. This article

closes with an

annotated reading list

of several favorite books and web sites, and an

editor's

note

.

1. User-centered Design

In early days of computing, a good software program was one that worked. A great program
was one that worked and expended the fewest computing resources. Creating a program was
an engineering process, delivering a working solution given the programming constraints
imposed by the last decade's computing environment. Computer programmers designed
programs for use by other computer professionals and not the general public, so a generic
interface permitting expeditious user input was the order of the day. The point of contact
between the general population and the computer was not the software application but some
output or printed report, such as a bank statement or lab results.

But in today's world, in which computer resources are abundant and computer users are
usually non-programmers and computer neophytes, a good program is one that not only
works but is also easy to learn. And a great program is one that works and is so user-friendly
it does not even need to be learned! With this shift to non-programmers who need computers
to perform many essential functions, the focus of software development has extended beyond
the traditional problem-centered task to center upon these users' needs.

From a user's perspective, the secret behind successful software is that it makes sense. To
create sensible software, user-centered designers involve users throughout the development
process. Unlike problem-centered programming, which first and foremost focuses on the
task, user-centered designers begin by observing how users confront present manual and
automated methods. Their goal is to understand users' work tasks, their mental models of
those tasks, and the tools already familiar to them. Programming can then incorporate
selected task-solving behaviors. An important component of this process is repeated cycles of
user testing and refinement prior to releasing the software.

Most clinician-developers do not have a staff of developers, professional designers and
usability testers. In fact, most clinicians develop applications by and for themselves, or for a
small target audience such as their office staff. For individual developers, is the distinction
between a problem-centered versus user-centered design rhetorical? The answer depends on
how much you enjoy training new staffers, undoing their mistakes, and answering questions
that result from their not understanding how your programs work. If your goal is to write
applications that even a new staffer can use correctly without much training or supervision,
you might shift your software development approach from problem-centered to
user-centered: critically evaluate and discuss how the tasks are presently performed, decide
what aspects should be mirrored by the interface, program the tasks with that interface as part
of the blueprint, then allow the future users to finalize your work with comments and
suggestions.

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

3 of 8

15.4.2005 8:54

2. Event-driven Programming

In procedure-driven programming, tasks are performed in a predictable ordered fashion, one
step following the other. For example, in tax software, a procedure-driven program would
advance the passive user from one line to the next and through all the tax forms in sequence.
The user would enter data when directed and would be unable to jump to another section out
of sequence, except as part of a pre-programmed menu. But GUI permits event-driven
programming, and therein lies another part of its strength.

In event-driven programming, the user controls the program's tasks via GUI events -- entries
using a keystroke, mouse click, pen light, voice command, joystick motion, etc. The variety
of events a user can generate is set by the hardware and operating system. For example, if the
computer has a single-button mouse, the user cannot perform a right mouse button click even
if one is programmed into the software.

Both procedure- and event-driven programming restrict the user's possible choices, but only
the latter gives the user control over several task steps. Most tax programs today are
event-driven, so the user may complete wizards, import financial information from another
financial package, follow a user-appropriate predetermined order, or enter expert mode to
manually select which form to next complete. Fields may be omitted; estimated amounts
accepted to "guesstimate" payments or refunds; and output stored, printed or forwarded
electronically to the IRS. Procedure- and event-driven programming both arrive at the same
calculations, but differ in how the user interacts with the program to create and process the
output forms.

The best event-driven programming incorporates user-centered design, and the best of these
emphasize the user's knowledge of the real world. As a developer, your programs will excel
if you first understand your users' mental models, then create visual metaphors that they will
find meaningful. In event-driven tax software the user is completing the familiar 1040 on
screen while behind-the-scenes programming uses IRS tax algorithms with spreadsheet
calculations. The user experiences a variety of ways to enter data on the tax form and the
results of these calculations -- not the complex processes that produce them -- and so
perceives the software as user-friendly and simple to use.

3. Affordances, Metaphors, and Manipulations

Real world objects have physical features, and some of those features lend themselves to
human manipulation. The ways in which a particular object can be used are its affordances
(afford = is for). A mouse button, for example, has one affordance: it can be depressed to
produce a mouse button click. Its affordance is obvious; a button has no handle that can be
pulled, so there isn't much chance a user would try to pull it.

The mouse itself, on the other hand, is an object with multiple affordances. While clearly
fitting the human grasp it is not intuitively obvious that one must move it across a surface to
perform its function -- a fact warmly portrayed by futuristic Star Fleet engineer Mr. Scott as
he first encounters a 20th century mouse in Star Trek IV - The Voyage Home. The mouse is
easy to use, but only after all its affordances have been taught or discovered.

Successful developers exploit a user's knowledge of the affordances of real world objects to
create visually meaningful and intuitive environments by using metaphors and analogies.
The Macintosh trash can is a classic example. To discard real documents we throw them in
the trash. To recover something tossed into the trash, we empty the trash can and pick
through its contents. Further, in the real world we deal with objects using direct
manipulation. We do not ask a trash can to empty itself, but we pick it up and empty it.
Direct manipulation environments are achievable with GUIs using metaphors and analogies.

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

4 of 8

15.4.2005 8:54

Such design improves the user's interface dramatically, because they are more intuitively
learned and retained than command environments, such as menus and buttons.

Study your users carefully. Look for metaphors that make sense to them. Create analogies to
the affordances of the real world objects when it is helpful. Explore the direct manipulation
techniques such as drag-and-drop mouse gestures that your platform supports. In this regard I
find painting, drawing and image processing programs more illustrative (sic) than tax
preparation software.

Ten Principles for Good GUI Design

The user must be able to anticipate a widget's behavior from its visual properties.

Widgets in this context refer to visual controls such as buttons, menus, check boxes,
scroll bars, and rulers. So let's call this the Principle of Consistency at the Widget
Level. This principle stresses that every widget in your application should behave
consistently. If one button responds to a single mouse click then every button should
respond to a single click. In software development environments such as Delphi you
can create your own widgets. If your application requires a new widget that behaves
differently from a common or closely related widget, anticipate the confusion and give
your new widget a distinctive appearance. Use metaphor affordances whenever
possible to make your widget's appearance tell the user how that widget behaves.

1.

The user must be able to anticipate the behavior of your program using knowledge
gained from other programs.

This is the Principle of Consistency at the Platform Level.

Consistancy is important not only to visual elements like widgets but to abstractions
such as mouse gestures, accelerator keys, placement of menus, and icons and toolbar
glyphs. There are plenty of decisions regarding GUIs that are arbitrary and
platform-specific. Obtain a good GUI application design guide for your target
platform, and follow it. If you feel compelled to improve upon conventions, you will
more than likely undo your "improvements" after users complain about them. If you
are doing cross-platform development, maintain consistency with the host platform.
Maintaining consistency with the host platform trumps achieving consistency of your
application across platforms. Your users will change applications on the same
platform far more frequently than they will run your application on different platforms.

2.

View every user warning and error dialog that your program generates as an
opportunity to improve your interface.

Good GUI interfaces rarely need or use

warnings and error dialogs. Exceptions include those that signal hardware problems
such as a disk failure or lost modem connection, or warnings that ask the user's
permission to perform an irreversible and potentially erroneous step. Otherwise, error
dialogs in GUI interfaces represent interface design flaws. Prevent, don't complain
about, user errors. The most common flaws arise from improperly formatted user input
and inappropriate task sequencing. Design your program interface to help your users
enter appropriate data. If your program requires formatted data (dates, currency,
alphanumeric only, or a particular numeric range) use bounded input widgets that
appropriately limit the user's input choices. If a certain program step cannot be
legitimately performed until your user completes other steps, disable the dependent
step until all its dependencies are satisfied. Most GUI environments dim disabled
widgets to signal that the widget cannot be selected. Use disabled widgets to limit user
actions to those that are valid.

3.

Provide adequate user feedback.

Like the Consistency Principle, the Principle of User

4.

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

5 of 8

15.4.2005 8:54

Feedback applies to widgets and to program activity. Widgets often provide visual
feedback; click a button, and it briefly suggests it has been depressed. Click a check
box and its new appearance alerts the user it has been selected or deselected. If you
create your own widgets, be sure to provide users with visual feedback for each
affordance. User feedback at the program level requires that users know whether a step
is in progress or completed. Change the cursor (the Mac wristwatch or the Window
hourglass) to indicate brief delays, and use progress bars to indicate progress of longer
tasks. Design every screen in your application so a novice user can easily tell what
steps, especially critical steps, have been performed.

Create a safe environment for exploration.

Humans are born explorers. Great interfaces

invite and reward exploration, and offer the novice both the thrill of discovery and the
satisfaction of unassisted accomplishment. Some interfaces encourage users to explore
unfamiliar features, others do not. By allowing users to undo or redo, you encourage
them to explore your application without fear of corrupting the database. Undo/Redo
capabilities also eliminate the need for dialogs requesting permission to perform a
seemingly erroneous function. A good interface makes a user feel competent, while
poor interfaces leaves the same user feeling incompetent.

5.

Strive to make your application self-evident.

Good applications have comprehensive

manuals and online help materials explaining program features and how to use them to
solve real world problems. Great applications are those whose novice users rarely need
to refer to the manuals or online help. The difference between good and great is often
the degree to which the application and its interface are self-evident. From your choice
of labels and widget captions to the arrangement of widgets on the screen, every
interface design decision you make needs to be tested by users. Your goal is to create
an interface that needs no explanation. A pharmacy management system interface need
not be self-evident to a newspaper editor, but it should be to every pharmacist.

6.

Use sound, color, animation and multimedia clips sparingly.

Sound, color, animation

and multimedia presentations are appropriate for education or entertainment, but
effective use in other applications is difficult. Most platforms have written conventions
that describe the appropriate use of sound, color and animation. Follow them, and
remember never to use color or sound as the sole means of communicating with the
user (many users are colorblind or hearing-impaired). Remember that these
components must pass the same usability tests as all other application features: include
them only if they improve your users' ability to accomplish tasks. Returning to our
example, tax programs may use multimedia clips to extend the utility of the software as
part of their online educational strategy, for interested users seeking added tax
information. They are a software asset because these clips are under user control and
independent to the task of completing the tax forms.

7.

Help users customize and preserve their preferred work environment.

If your

application will be installed and operated by a single user, preserving the work
environment may be as simple as creating a few registry entries such as the window's
latest size and position. However, applications designed for multiple users or installed
on different computers must address additional issues. Most common among these are
video issues -- both hardware-specific involving the display (screen size, video
resolution and color depth) and user-specific such as poor visual accommodation and
acuity or colorblindness. Keep in mind that regardless of programming, the
characteristics of the user's display will affect your application's appearance; your
full-screen interface may look fine on a 14-inch VGA display, but will those 8-point
Times-Roman labels and captions be legible on a 17-inch display at a resolution of
1152x864? One popular solution to any hardware irregularities or user preferences is to

8.

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

6 of 8

15.4.2005 8:54

permit the user to tailor the basic interface. Common user-tailored details include fonts,
toolbar location and appearance, menu entries, and (especially important for users with
impairments) color and sound. It is helpful to give users a way to choose among
several predefined schemes, and always include a way to return to the default color or
sound scheme. If multiple users take turns using your application at a single
workstation, consider recording preferences as user-specific profiles rather than as a
single description of the application's appearance the last time it was run.

Avoid modal behaviors.

Programs using modal behavior force the user to perform

tasks in a specific order or otherwise modify the user's expected responses. Modal
behaviors generally feel uncomfortable to the user because they restrict more intuitive
or natural responses, but if consciously and thoughtfully applied they can be used to
advantage. For example, "Wizard" type tools simplify complex tasks by modal
behavior. Warnings and error messages are also typically modal, forcing users to first
address a critical issue before returning to the task. Modality in this latter context is
necessary but interrupts the user's concentration and goal-oriented behavior, and so is
another reason to avoid unnecessary warning and error messages (see Principles 3 and
5 above). The best modal behaviors are subtle but not hidden, and come forth naturally
as a consequence of the metaphor.

In a typical painting program, for example, selecting a widget generally alters the
subsequent function of the program and therefore results in modal behavior. Pick the
brush widget, and you are ready to paint. Pick the letter stencil widget, and you type
some text. Pick a shape widget, and you then draw that shape. This rarely causes
confusion because the modal behavior is based on a real world analogy; we already
know that by selecting a drawing instrument we are limiting the color, texture and line
thickness that will appear on our paper. Good interfaces reveal the palette selection at a
glance, and change the cursor to provide additional visual feedback once a selection is
made.

So if your application absolutely requires modal behavior, bind that behavior to a
strong metaphor and give your user visual feedback so the mode is natural and
obvious.

9.

Design your interface so that your users can accomplish their tasks while being
minimally aware of the interface itself.

We could call this the Principle of

Transparency. Interface transparency occurs when the user's attention is drawn away
from the interface and naturally directed at the task itself. It is the product of several
factors, including a screen layout that puts both tools and information where the user
expected them to be; icons and labels that are meaningful to the user; and metaphors
(including gestures) that are easy for users to recognize, learn, remember, and perform.
Choosing good metaphors and adhering to the above principles are an important start,
but the most direct way to insure a transparent interface is to perform user testing
throughout the program's creation.

10.

F

ollowing these 10 principles should help you create more effective, user-friendly

interfaces while avoiding many design errors. Unfortunately, following sound design
principles cannot alone guarantee success. It is entirely possible to create completely
unworkable interfaces while strictly adhering to the rules. I know, because I have written a
few of these, too.

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

7 of 8

15.4.2005 8:54

Suggested Reading

This is my personal collection of background materials. It is not exhaustive and certainly
omits many important works. But life is too short to read everything, and we must set aside
some time to learn by doing!

Norman DA.

The Design of Everyday Things

1988 Doubleday; ISBN 0-385-26774-6

Learn more about affordances, mental models and effective user interfaces. This is an
excellent introduction to user-centered design. Norman's analysis of design errors
covers topics ranging from door handles to airplane cockpits. The lessons are just as
applicable to software development.

Tognazzini B.

Tog on Interface

1993 Addison-Wesley; ISBN 0-201-60842-1

Although this book is about the Apple Macintosh interface it addresses many design
issues common to all GUIs. Most of the design principles in my column are addressed
by Tog. This book is a "must read" for anyone who still thinks the command line
interface is faster.

Mandel T.

The GUI-OOUI War Windows vs. OS/2 - The Designer's Guide to

Human-Computer Interfaces

1994 Van Nostrand Reinhold; ISBN 0-442-01750-2

There is a lot here -- some history, some design principles. There is a good discussion
about guidelines being both a foundation and hindrance to good design. The book
compares and contrasts the features, virtues and shortcomings of a variety of computer
interfaces while focusing primarily on the essential differences between a graphical
user interface (Windows) and an object-oriented user interface (OS/2). OOUI is similar
to GUI but allows the user to interface with some types of data as if they were objects.
Object manipulation simplifies such tasks as data entry and transfer between
applications.

The Windows Interface - An Application Design Guide

1991 Microsoft Press; ISBN 1-55615-439-9
This is the Windows 3.x interface guide. The more recent Win95 version,

The

Windows Interface Guidelines for Software Design

, is ISBN 1-55615-679-0.

Knudson R.

User Interface Design Guidelines - A Brief Overview for Skiers and

Applications Developers

. The Information Management Group

This brief web page summarizes the important differences between the Windows 3.x
and Win95 interfaces.

Macintosh Human Interface Guidelines

Apple Computer
This is the complete online book of Mac-specific interface guidelines. In the context of
the issues discussed in the preceding column, Chapter One on The Human Interface
Design Principles is particularly relevant. This book is not only excellent reading but
completely free!

NASA User-Interface Guidelines (Goddard Space Flight Center)

These are generic rather than platform-specific user interface guidelines. If my 10
design principles seem too general to satisfy your craving for detail, you need to read
these. This 1996 book contains literally hundreds of admonitions and requirements for
you to relish.

Miller RH.

Web Interface Design: Learning from Our Past

Bell Communications

Designing a Graphic User Interface

http://www.medicalcomputingtoday.com/0agui.html

8 of 8

15.4.2005 8:54

This short but thoughtful paper addresses interface design issues as they pertain to both
web page layout and legacy software applications deployed across the web.

Comments

added at time of original publication by

Marjorie Lazoff, MD

Medical Editor
Medical Computing Today

Dr. Cortes' excellent article makes no reference to

Alan Cooper

, the "Father of Visual Basic"

and proponent of completely separating design from programming during software creation.
He even recommends distinguishing software design from graphic design, as illustrated in
Cooper's

design test

(and if he likes your answers he may offer you a job). Cooper's

Goal

Directed Design

extends the concept of Dr. Cortes' user-centered design by challenging

designers to use logic and creativity (rather than analyze users or employ user testing).
Coincidently, Cooper used the same Star Trek sequence as did Dr. Cortes to explain his
preference of

idiomatic over metaphoric paradigms

.

Articles by Cooper and others

also contain information on his well-regarded 1995 paperback,

"About Face." The

Association for Software Design

lists even more resources, in addition to

software designers' articles, listserv messages, etc.

Comments or questions for posting?

of other articles

©

Copyright 1997-2002 Medical Computing Today

E-mail Medical Computing Today's

editor

or

webmaster

.

Copyright: This article is copyright © Medical Computing Today and the individual author(s).
Permission is granted for nonprofit purposes to download, print, and distribute material from Medical

Computing Today for educational purposes, provided that the material is not altered and that this copyright notice is
included. No individual or corporation shall charge for this content, or include any of it in a larger document for which
charges are levied, without the prior permission of Medical Computing Today, who may be reached by contacting:
Editor, Medical Computing Today, e-mail:[e-mail].