BRIGHAM YOUNG UNIVERSITY
BYU LiveCode Lessons Gateway
Office of Digital Humanities
Principles of Interface Design
Human Interface refers to the "face" that your software presents
to the user. Interface design is a complex topic that I can't hope
to cover in a single lecture. I would recommend that if you are interested
in the subject that you take a course and read in this area. However, I will
try to present some principles that you may use as a guide when designing
our own interface.
Know Your User
For any interface to be successful, you must try to predict as accurately
as possible how your user thinks. For this reason, it is essential to have
a clear idea of your audience, including age, education and computer experience.
One way of avoiding having to do a great deal of research into the way
users think is to adopt an existing interface model, one that is proven
through research, testing, and use. Whatever you choose to do, whether you
use your own interface or adopt an existing one, there are guidelines you
can use to make your design a successful one.
The Mental Model vs. the Functional Specification
The functional specification of your software is a checklist of all the
features the software should have. But it says nothing about how the features
should be organized or how the user will proceed through the program. (A.
Marcus, New Media, Feb. 95, p. 100)
The mental (or cognitive) model represents the way the user will encounter
your program's functions and data. Research has shown that for your interface
to be successful, the user must be able to form a consistent mental model
of how the software works and how it is organized. This requires you to
plan carefully so that you can assist the user in forming this mental model.
The Interface Metaphor
A key in your effort in helping the user to form an effective mental
model of your software is the selection of an appropriate metaphor.
[Look at the metaphor of the MacOS Finder or Windows desktop. This is
a good point to discuss what class members found while doing their conventions
Both of these interfaces use a desktop metaphor—elements are arranged much
as your common workplace environment might be. It is a surface upon which
users can place tools, documents and file folders. Menus allow you to give
commands and instructions to objects on your desktop. The mouse lets you
manipulate them in various ways.
Other commonly used metaphors are the book (cf. Toolbook) and the stack
(cf. HyperCard, LiveCode).
The most important concerns in developing an effective metaphor are simplicity, consistency
and clarity. Common elements should operate in the same way throughout the
Let's look at a few goals and principles to help you in designing an
effective metaphor. [based in part on Computer Interface Design Guidelines,
by Sallie Gordon. This presentation was excerpted from S. Gordon, Systematic
Training Program Design: Maximizing Effectiveness and Minimizing Liability,
Prentice Hall, 1994. Additional information drawn from Macintosh Human Interface Guidelines.]
- Create a system that is easy for the learner to use.
- At any given point, the user should understand...
- what is being presented,
- what they are required to do or have the option of doing,
- how to accomplish their current goal.
At the same time, the system should display what the system is currently
doing, if anything.
Static Screen Design (Screen Layout)
[For more information, see Deborah Mayhew, Principles and Guidelines
in Software User Interface Design.]
- Don't try to place too much information on the screen. Tullis
(1983) suggests that, based on research, alphanumeric characters should
not take up more than 25-30% of the total screen space. This is equivalent
to leaving plenty of white space in written documents. Include only information
that is really necessary.
- Even when trying to keep the screens uncluttered, be sure to include
all information that is necessary.
- Group characters so that they are moderately (but not extremely)
- The items on a screen should be logically grouped so that people
perceive the screen as consisting of blocks of related pieces of information.
This may often include functional groupings. (eg., navigation elements
vs. content elements.)
- Leave adequate space around each group of items.
- A smaller number of groups is better than a larger number of
individual items or a large number of groups.
Put the star on center stage. The most important information should
occupy the largest, central area.
[Show example from Ballet tutorial.]
- Minimize the complexity of the layout.
[Show Vocabulary Editor: This is an example of a layout (which I created)
that I happen to think is not very well designed. In trying to cram as
much functionality into one screen as possible, I have made a very cluttered
interface. This would require greater learning time on the part of the
- Maximize visual predictibility. I.e., "based on a knowledge
of the location of some items on the screen, one should be able to predict
the locations of others."
[Back to Vocab Tutor. If I wanted to look for a way to return to the starting
menu, where would I look? If I wanted to add a "Return to Menu"
button, where would I put it?]
- Use redundant coding. That is, have two or more different variables
providing the same information. For example, active buttons could always
be shown as "shadowed rectangles" and also always be colored
[I have done this in another way with my Show Example buttons--using both
visibility and color.]
- Use symbols or icons for input buttons that are consistent with
learners' previous knowledge. For example, a question mark is relatively
well known as a symbol for requesting help or information. If possible,
use both words and icons .
The best icon is one that passes "predictive" user testing. That
is, the function of an icon, when it first appears on a screen, whould
be predictable by a novice user. If you ask them, "what happens when
you click this icon?", they should be able to accurately tell you.
- Don't use hidden buttons (where parts of the screen are active
hot spots, but you can't tell by visual inspection). Exceptions are when
(a) all parts of the screen are hot, as in a map or picture with parts
acting as hot buttons, and users know this; or (b) the cursor symbol changes
when it is over buttons, giving visual feedback that the area is hot.
- In most circumstances, start in the upper left-hand corner of the
screen, as this is where people habitually begin search and reading
(at least in our culture.)
- Use upper and lower case for text. Use minimal or no text that
is all upper case (Tullis, 1988).
Read more on fonts and typography.
- Blinking is a very strong visual cue and can be distracting.
Use only in emergencies or critical situations (or never).
- Use reverse video sparingly. Appropriate uses might include
indications that an item has been selected, or to indicate an error field.
[demo card shows Vocab Tutor with one item in list highlighted]
- Messages should be brief, concise, specific, helpful, and comprehensible.
Here are some examples of poor and improved messages from Mayhew (1992).
- Use instructional prompts to cue users when they must type or
perform other necessary input activity.
[May be something as simple as a label for a field where data is to be entered.]
Instructional computer systems should be transparent, that is,
at least two things should be readily apparent to the user:
- The overall purpose of the program--what it is used for;
- How to interact with the program.
User should know how to accomplish goals, whether they are vague (I'm
lost--what do I do next?) or specific (How do I quit?)
Here are some basic guidelines for developing interaction in instructional
- At the beginning, present an overview of how the system works, and
how the learner interacts with the system. This may be explicit information
or implicit in the screen design.
- Provide an advance organizer. This can be something as simple
as a list of topics, or a map of the program that clearly conveys the contents.
[Humanities 101 Architecture Tutorial provides good example of this.]
- Make use of previously existing knowledge. This can range from
using icons such as a "?" to using an entire metaphor. (Desktop,
schoolhouse, city metaphors). Most users are now familiar with touching
a place on the screen or clicking on buttons with a mouse, so these are
good input mechanisms. A variety of symbols may be familiar, depending
on the target population.
[VCR or cassette recorder controls]
- In general, a graphical interface will be better than command line
input for training programs. As always, a designer must match the complexity,
input mechanisms, and symbology of a system to the target user population
and to the nature of the task.
- Use consistent design elements from one screen to the next.
This includes color coding for functions, placement of control buttons,
use of symbols for icons, etc.
- Old Humanities 101 Architecture--Gothic. Example of inconsistent placement
[example of inconsistent interface from booklet, p. 14]
- For most hypertext or hypermedia systems, make the underlying organizational
structure hierarchical rather than an unstructured networks of nodes. (See
Gordon & Lewis, 1992.)
- Avoid the overuse of modal alerts (messages that float atop all other
windows and must be dealt with immediately). "A modal alert is like
yelling 'Fire!' " (Clifford Nass, quoted in "Six Tips for Better
Interfaces", Byte, July 1996, p. 86.)
In summary, a design team must create a simple and obvious system for
the user interface, and stick to that system consistently thoughout the
Most design teams do this by creating a style sheet, which specifies
the characteristics of interface elements in careful detail. Along with
this it may also be useful to create a template card, so that for each new
card added to your stack, you can simply paste a copy of the template, then
change the elements or information unique to that card. HyperCard's card-background
structure is very conducive to this approach, allowing you to put common
elements on the background so that the design remains consistent.
http://www.baddesigns.com - Examples
of poor industrial design.
http://www.webpagesthatsuck.com/ - Often hilarious, always insightful site that gives "awards" for the ugliest or worst web sites. (PG-13 language warning.)
http://homepage.mac.com/bradster/iarchitect/ - Aging but still insightful commentary
on computer human interface design, good and bad. Mostly Windows examples.
Many links to usability guidelines for web page design, but also generally
applicable to designing interface layout.
Human interface commentary. Heavily pro-Mac.
Even more user interface design commentary.
A comparison of interface features of Mac OS X and Windows XP from a usability perspective.
Human Interface Guidelines, Apple Computer, Inc. Internet document:
Usability Guidelines, Microsoft Corp. Internet document: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/uidesign.asp
Nielsen, Jakob, “Ten Usability Heuristics”, http://www.useit.com/papers/heuristic/heuristic_list.html
- Burger, Jeff, "An Elegant Interface Design," New Media.
September 1995, p. 77.
Corry, Michael D., "Mental Models and HyperMedia User Interface Design,"
Educational Technology Review. Spring/Summer 1998, pp. 20-24.
Gordon, Sallie, Systematic Training Program Design: Maximizing Effectiveness
and Minimizing Liability. Englewood Cliffs, NJ: Prentice Hall, 1994.
Heckel, P., Elements of Friendly Software Design. San Fransisco, CA:
Sybex Books, 1991.
Helander, M., Handbook of Human-Computer Interaction. Amsterdam: North
Marcus, A., Graphic Design for Electronic Documents and User Interfaces.
New York: ACM Press/Addison-Wesley, 1991.
Mayhew, D., Principles and Guidelines in Software User Interface Design.
Englewood Cliffs, NJ: Prentice Hall, 1992.
McFarland, Ronald D., "Ten Points for the Human Interface to Instructional
Media", T.H.E. Journal. February 1995, pp. 67-69.
Salvendy, G. (Ed.), Handbook of Human Factors. New York: John Wiley
& Sons, 1987.
Salvendy, G. and Smith, M. J., Human-Computer Interaction: Software and
Hardware Interfaces. Amsterdam: Elsevier, 1993.
Schneiderman, B., Designing the User Interface. Reading, MA: Addison-Wesley
Publishing Co., 1987.
"Six Tips for Better
Interfaces," Byte. July 1996, p. 86. (10/1/09 - article seems to be unavailable. Hoping it will reappear soon.—DNA)
BYU LiveCode Lessons Gateway
Maintained by Devin Asay
Copyright © 2005 Brigham Young University