background image

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 

background image

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. 
 

background image

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. 

background image

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.

background image

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.

background image

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. 
 
 

background image

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

background image

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:editor@medicalcomputingtoday.com.