2

S pecifi c HCI G uid elines

2.1 Guideline Categories

While principles are very general and applicable to wide areas and
aspects of human–computer interaction (HCI) design, guidelines
tend to be more specific. Table 2.1 shows major criteria and areas for
which specific guidelines can be of help in HCI design. For instance,
in the criterion of “user type,” there could be further specific guide-
lines for specific age groups or gender.
Many guidelines in the categories listed in Table 2.1 have been put
forth by a number of HCI researchers, practitioners, and organizations
over the years and are considered to be reasonably objective. There is
even an international standard; the International Organization for
Standardization (ISO) 9241 document guides the ergonomics aspects
of HCI designs, with topics covering visual display, physical input
devices, workplace/environment ergonomics, and tactile/haptic inter-
actions [1]. Broadly, we might divide the guidelines into two catego-
ries: (a) domain specific (i.e., specific to user, platform, etc.) and (b)
of general HCI design. Note that these guidelines can be relevant
and common across the different categories shown in Table 2.1. For
example, guidelines for e-commerce application might also address
different general HCI design issues such as display layout, how to
solicit input, how to promote vendor-specific styles, and how to target
for a particular user group.
Even though guidelines are much more specific than the principles,
it is still not very clear how to reflect them into the HCI design in
a concrete and consistent manner. In this regard, Tidwell has com-
piled many user interface (UI) design patterns in the form of guide-
lines [2]. Tidwell’s guidelines address many categories of the “general
HCI design” issues (see Table 2.1) such as display layout, information

13
14 Hum a n – C o m p u t er In t er ac ti o n

Table 2.1 Examples of Criteria/Categories for HCI Guidelines

CRITERIA MAIN CATEGORIES EXAMPLES
User type Age/generation Kids, elders, visually challenged,
Disability/accessibility baby boomers, students, parents,
Gender East Asians, athletes, etc.
Consumer group
Occupation
Culture/country
Platform/system setup Mobile/handheld Smartphone, padlike device,
Desktop desktop, kiosk, embedded OS,
Large display/virtual reality cloud based, navigation systems,
Embedded personal game players, MP3
Public installation players, e-book, etc.
Operating system/network
Vendors/organizations Private NASA, Korea University, Android™,
Public iOS, Windows® XP, etc.
Design style/identity
Interface style/ WIMP Voice/aural, gesture, single/
modality/technology Non-WIMP multitouch, tactile/haptic,
3-D multimodal, menu driven, GUI/
Multimodal widgets, visual perception, etc.
Task/operational Location/place Office, outdoor, road/street, home,
context Time automobile, subway, classroom,
Noise/lighting eyes free, hands free,
Bodily constraints handedness, etc.
Applications Game
Media/information
Electronic commerce
Design/editing
Social network service
General HCI design Display layout
Information structure/navigation
Soliciting input
Information/output visualization
Design process and practices
User experience
General aesthetics
a WIMP is an acronym for windows, icon, mouse, and pointer, which represents the conventional
desktop interface.

structure and navigation, as well as data entry and even aesthetic aspects.
Each guideline illustrates specific UI examples with exact descriptions
of what it is and what it does and why and when it should be used. Such
design patterns are of great help during actual HCI design.
It is not possible to list and explain all the guidelines that exist for
all the various areas. Despite differences in the specifics, most of them
 Sp ecific H CI Guid eline s 15

are commonly shared and equivalent or can be understood in terms of

the higher level principles. Here we present a few examples.

2.2 Examples of HCI Guidelines

2.2.1 Visual Display Layout (General HCI Design)

One of the main focuses in many design guidelines is on the display

(page) layout. This problem concerns organizing and allotting relevant
information (both the content and UI elements) in one visible screen
or scrollable page. Generally, the display layout should be such that it
is organized according to the information content (e.g., importance,
sequence, functionality), is sized manageably (e.g., divided into proper
sections), is attention grabbing, and is visually pleasing (e.g., aligned
and with restricted use of colors). Table 2.2 is a summarized guideline
for web-page layout put forth by the U.S. Department of Health and
Human Services (HHS) for the US government [3].

Table 2.2 Examples of Guidelines for Government Web Page Layout

GUIDELINES EXPLANATION
Avoid cluttered displays Create pages that are not considered cluttered by users
Place important items Put important, clickable items in the same locations and closer to
consistently the top of the page, where their location can be better estimated
Place important items at top Put the most important items at the top center of the web page to
center facilitate users finding the information
Structure for easy Structure pages so that items can be easily compared when users
comparison must analyze those items to discern similarities, differences,
trends, and relationships
Establish level of Establish a high-to-low level of importance for information and
importance infuse this approach throughout each page on the website
Optimize display density To facilitate finding target information on a page, create pages
that are not too crowded with items of information
Align items on a page Visually align page elements, either vertically or horizontally
Set appropriate page Make page-length decisions that support the primary use of the
lengths web page
Choose appropriate line If reading speed is most important, use longer line lengths
lengths (75–100 characters per line); if acceptance of the website is
most important, use shorter line lengths (50 characters per line)
Use frames when functions Use frames when certain functions must remain visible on the
must remain accessible screen as the user accesses other information on the site
Source: Leavitt, M. O., and Shneiderman, B., Research-Based Web Design and Usability Guidelines,
U.S. Department of Health and Human Services, Washington, DC, 2006 [3].
16 Hum a n – C o m p u t er In t er ac ti o n

2.2.2 Information Structuring and Navigation (General HCI Design)

A single display is often not sufficient to encompass all of the required

information content or to control the UI for a given application.
Thus, structuring the information and making it easy to move (or
navigate) among the various items becomes a very important issue
for high usability. Structuring information content and controlling
the interface for the purpose of HCI is closely related to the prin-
ciple of understanding the task (Section 1.2.2). By understanding the
task, we identify the sequence of subtasks and actions, and each task
will be associated with information either for making input or for the
resulting output. The task structure, action sequence, and associated
content organization will dictate the interaction flow and its fluidity.
In this way, only the right amount of information or control will be
available at the right time.
Aside from such internal structure, it is also important to provide
external means and the right UI for fast and easy navigation. Fast and
easy navigation means enabling the user to find the needed action
(e.g., menu item) and information quickly (Figure 2.1). Here, we
introduce a summarized guideline for the design of an easily navi-
gated interface from Leavitt and Shneiderman [3].

Figure 2.1 An example of a site map for a website. (From Korea University, http://www.korea.
ac.kr. With permission.)
 Sp ecific H CI Guid eline s 17

Navigation refers to the method used to find information within a Web

site. A navigation page is used primarily to help users locate and link to
destination pages. A Web site’s navigation scheme and features should
allow users to find and access information effectively and efficiently.
When possible, this means designers should keep navigation-only pages
short. Designers should include site maps, and provide effective feed-
back on the user’s location within the site. . . .
. . . To facilitate navigation, designers should differentiate and group
navigation elements and use appropriate menu types. It is also important
to use descriptive tab labels, provide a clickable list of page contents on
long pages, and add “glosses” where they will help users select the correct
link. In well-designed sites, users do not get trapped in dead-end pages.

As a more concrete example, we illustrate two design patterns from

Tidwell [2]. Note that as design patterns, very specific uses of UI ele-
ments are suggested addressing the concerned issue (Figures 2.2 and 2.3).
What:

Put two side-by-side panels on the interface. In the first, show a

set of items that the user can select at will; in the other, show
the content of the selected item.

Use when:

You’re presenting a list of objects, categories, or even actions. . . . You

want the user to see the overall structure of the list. . . .
Physically, the display you work with is large enough to show two
separate panels at once. . . .

Figure 2.2 The use of a two-panel selector, a design pattern for information structuring and
facilitated navigation. (Adapted from Tidwell, J., Designing Interfaces, 2nd ed., O’Reilly Media,
Sebastopol, California, 2010 [2].)
18 Hum a n – C o m p u t er In t er ac ti o n

Figure 2.3 The use of one-window drilldown as a design pattern for content organization and
fast navigation. (Adapted from Tidwell, J., Designing Interfaces, 2nd ed., O’Reilly Media, Sebastopol,
California, 2010 [2].)

What:

Show each of the application’s pages within a single window.

As a user drills down through a menu of options, or into an
object’s details, replace the window contents completely with
the new page.

Use when:

Your application consists of many pages or panels of content for

the user to navigate through. . . . For a device with tight space
restrictions, . . . you may have a complexity limit. Your users
[also] may not be habitual computer users—having many
application windows open at once may confuse them.

2.2.3 Taking User Input (General HCI Design)

Clever designs for taking user input (e.g., raw information or system
commands) can improve the overall performance, in terms of both
time and accuracy, for highly interactive systems. Modern inter-
faces employ graphical user interface (GUI) elements (e.g., window,
text box, button, menu, forms, dialog box, icon), support techniques
 Sp ecific H CI Guid eline s 19

Figure 2.4 Display layout and user interfaces for facilitated date entry: Selection menus,
default values, and structured forms are used to reduce errors. (From Smith, S. L., and Mosier, J. N.,
Guidelines for Designing User Interface Software, Mitre Corporation, Bedford, MA, 1986 [4].)

(e.g., autocompletion, deactivating irrelevant options, voice recogni-

tion), and devices (e.g., mouse, touch screen) to obtain user input in
different ways. It is up to the UI designer to compose these input
methods for the best performance with respect to the design con-
straints (e.g., user type, task characteristics, operating environment,
etc.). Figure 2.4 is a collection of guidelines for use in applying these
input methods to facilitate data entry [4].
1. Consistency of data-entry transactions: Similar sequences of
actions should be used under all conditions (similar delimit-
ers, abbreviations, etc.)
2. Minimal input actions by user: Fewer input actions means greater
operator productivity. Make proper use of single-key commands,
mouse selection, auto-completion features, and automatic cursor
placement rather than typing/pressing in the full alphanumeric
input. Selection from a list (e.g., by a menu or by mutually exclu-
sive radio buttons) also reduces possibilities of error. Avoid switch-
ing between the keyboard and the mouse. Use default values.
3. Minimal memory load on users: When doing data entry,
use menus and button choices so that users do not have to
20 Hum a n – C o m p u t er In t er ac ti o n

remember a lengthy list of codes and complex syntactic com-

mand strings.
4. Compatibility of data entry with data display: The format of
data-entry information should be linked closely to the format
of displayed information (i.e., what you see is what you get).
5. Clear and effective labeling of buttons and data-entry fields:
Use consistent labeling. Distinguish between required and
optional data entry. Place labels close to the data-entry field.
6. Match and place the sequence of data-entry and selection fields in a
natural scanning and hand-movement direction (e.g., top to bot-
tom, left to right).
7. Do not place semantically opposing entry/selection options close
together: For example, do not place “save” and “undo” buttons
close together. Such a placement is likely to produce frequent
erroneous input.
8. Design of form and dialog boxes: Most visual-display layout
guidelines also apply to the design of form and dialog boxes.
Note that most of these guidelines apply only when using mouse/
keyboard-driven GUI elements. Situations become more complicated
when other forms of input are also used, such as touch, gesture, three-
dimensional (3‑D) selection, and voice. There are separate guidelines
for incorporating such input modalities.

2.2.4 Users with Disability (User Type)

The W3C has led the Web Accessibility Initiative and published the
Web Content Accessibility Guidelines (WCAG) 2.0 [5]. It explains how
to make web content more accessible to people with disabilities. Web
content generally refers to the information in a web page or web appli-
cation, including text, images, forms, sounds, and such (Figure 2.5).
The following is a summary of the guidelines:
1. Perceivable
A. Provide text alternatives for nontext content.
B. Provide captions and other alternatives for multimedia.
C. Create content that can be presented in different ways,
including by assistive technologies, without losing meaning.
D. Make it easier for users to see and hear content.
 Sp ecific H CI Guid eline s 21

Changing the font size and contrast

Figure 2.5 Adjustment feature for visually challenged users. The colors of the background and
foreground text can be changed.

2. Operable
A. Make all functionality available from a keyboard.
B. Give users enough time to read and use content.
C. Do not use content that causes seizures.
D. Help users navigate and find content.
3. Understandable
A. Make text readable and understandable.
B. Make content appear and operate in predictable ways.
C. Help users avoid and correct mistakes.
4. Robust
A. Maximize compatibility with current and future user tools.

2.2.5 Mobile Device (Platform Type)

Recently, with the spread of smartphones, usability and user experi-

ence of mobile devices and applications has become even more impor-
tant. Many conventional principles equally apply to mobile networked
devices (Figure 2.6), but the following are more specific and impor-
tant, as summarized by Tidwell [2]:
1. Fast status information (especially with regard to network
connection and services)
2. Minimize typing and leverage on varied input hardware
(e.g., buttons, touch, voice, handwriting recognition, virtual
keyboard, etc.)
3. Fierce task focus (for less confusion in a highly dense infor-
mation space)
22 Hum a n – C o m p u t er In t er ac ti o n

(a) (b)

Figure 2.6 Comparison of two mobile game interfaces (the initial entry screen): (a) information
and object density is needlessly high and distracting (left), (b) simple and minimal layout, and object
sizes fitted to ergonomic usage (right). (From http://www.withhive.com.)

4. Large hit targets (for easy and correct selection and

manipulation)
5. Efficient use of screen space (with condensed information)
Following is a similar set of guidelines available from the Nokia
developer’s home page [6]:
1. Enable shortcuts (e.g., hot keys) for frequently used functions
2. Keep the user informed of his or her actions
3. Follow the device’s (vendor’s) interface patterns (positioning
of the buttons and menus).
Figure 2.7 shows another design pattern put forth by Google® for
the Android mobile interface [7]. It concerns the limited and differ-
ent sizes of a family of handheld devices (i.e., smartphones, padlike
devices, mobile Internet devices, netbooks) and more specifically

Figure 2.7 Android design guideline promoting the use of list views and detailed views (multiple
panels) to efficiently use the screen size of mobile devices. (From Google, Multi-Pane Layouts, 2013,
http://developer.android.com/design/patterns/multi-pane-layouts.html.)
 Sp ecific H CI Guid eline s 23

suggests the use of “panels” as a way to achieve usability under such

hardware constraints.
Make sure that your app consistently provides a balanced and aestheti-
cally pleasing layout by adjusting its content to varying screen sizes and
orientations. . . .
. . . Panels are a great way for your app to achieve this. They allow
you to combine multiple views into one compound view when a lot of
horizontal screen real estate is available and by splitting them up when
less space is available.

2.2.6 Icons for Apple® iOS and Fonts for Windows® XP (Vendor)

Major vendors publish style guides for user-interaction elements to be

used for applications running on their platform. For instance, Apple
has published a design guideline document [8] that details how appli-
cation icons should be designed and stylized:
1. Try to balance eye appeal and clarity of meaning in your icon
so that it is rich and beautiful and clearly conveys the essence
of your app’s purpose.
2. Investigate how your choice of image and color might be
interpreted by people from different cultures.
3. Create different sizes of your app icon for different devices.
For iPhone and iPod touch, both of these sizes are required:
(a) iPhone: 57 × 57 pixels and 114 × 114 pixels (high resolu-
tion) and (b) iPad: 72 × 72 pixels and 144 × 144 (high resolu-
tion). When iOS displays the app icon on the home screen of
a device, it automatically adds the following visual effects: (a)
rounded corners, (b) drop shadow, and (c) reflective shine.
Another example is the suggested choice of fonts/sizes for Windows
XP or applications based on it [9]. These guidelines promote organi-
zational styling and its identity and, ultimately, its consistency in user
interfaces.
1. Franklin Gothic is used only for text over 14-point size. It is
used for headers and should never be used for body text.
2. Tahoma is used as the system’s default font. Tahoma should
be used at 8-, 9-, or 11-point sizes.
24 Hum a n – C o m p u t er In t er ac ti o n

Figure 2.8 An example of Trebuchet font used for a window title bar. (From Microsoft®,
Windows XP Design Guidelines, 2002, http://msdn.microsoft.com/en-us/library/windows/hardware/
gg463466.aspx [10].)

3. Verdana (bold, 8 point) is used only for title bars of tear-off/

floating palettes.
4. Trebuchet MS (bold, 10 point) is used only for the title bars of
Windows (Figure 2.8).

2.2.7 “Earcon” Design for Aural Interface (Modality)

Blattner, Sumikawa, and Greenberg [10] have suggested a few guide-

lines for designing “auditory” analog-to-visual icons. Similar to visual
icons, which must capture the underlying meaning (for whatever it
is trying to represent) and draw attention for easy recognition, ear-
cons should be designed to be intuitive. They suggest three types of
earcons, namely, those that are (a) symbolic, (b) nomic, and (c) meta-
phoric. Symbolic earcons rely on social convention such as applause for
approval; nomic ones are physical such as a door slam; and metaphori-
cal ones are based on capturing the similarities such as a falling pitch
for a falling object [10]. Aural feedback (including earcons) involves
a careful choice of sound-related parameters such as the amplitude/
loudness, frequency/pitch, timbre, and duration. We take a more in-
depth look at the aural modality in Chapter 3.

2.2.8 Cell Phones (or Making Calls) in Automobiles (Task)

Green et al. [11] have categorically outlined interface guidelines for

automobiles and vehicles whose interfaces are nowadays mostly elec-
tronic and computer controlled, as seen in Table 2.3. The categories
include design guidelines for manual control, spoken input and out-
put, visual and auditory display, navigation guide, and cell phone con-
sideration, to name just a few (Figure 2.9).
 Sp ecific H CI Guid eline s 25

Table 2.3 Samples of Guidelines for Car Phone Interfaces in Vehicles

SUBCATEGORIES GUIDELINE
Basic Car phones should operate like phones people have at home. The use of send
to make a connection and power to turn a phone on and off are notable
inconsistencies.
Voice dialog Verbal commands and button labels should use the same terms. Commands
of interest include dial, store, recall, and clear. This is an instance of the
consistency principle.
Manual dialing The store and recall buttons, used for similar functions, should be adjacent to
each other. This is an instance of the grouping principle.
Source: Green, P., Levison, W., Paelke, G., and Serafin, C. Suggested Human Factors Design
Guidelines for Driver Information Systems, Technical Report UMTRI-93-21, Transportation
Research Institute, University of Michigan, Ann Arbor, 1993 [11].

Figure 2.9 Phone interface for automobiles.

2.2.9 E-Commerce (Application)

Kalsbeek [12] has collected and formulated very extensive, detailed,

and structured HCI guidelines for e-commerce applications. A total
of 404 guidelines structured in four groups (general, input/output
forms, UI elements, and checkout process) are given and applied to
several real systems for validation and evaluation. The following is a
guideline under the checkout-process section concerning the steps of
a subtask (the checkout process).
Check-out should start at the shopping cart, followed by the gift options
or shipping method, the shipping address, the billing address, payment
information, order review and finally an order summary. . . . Then the
26 Hum a n – C o m p u t er In t er ac ti o n

Figure 2.10 Status information (circled) shown in the process of a book purchase at Amazon.com.

site displays a confirmation page and gives customers the option to reg-
ister. The checkout process is linear.

Figure 2.10 shows the status information (circled) shown in the

process of a book purchase at Amazon.com.

2.3 Summary

While most of the guidelines—specific or general—seem quite

straightforward and are easy to understand, incorporating them in
actual design and implementation is very difficult. Many guidelines
are still at quite a high level, similar to the HCI principles, and leave
the developer wondering how to actually apply them in practice.
Another reason is that there are just too many different aspects to
consider (especially for a large-scale system). Sometimes, the guide-
lines can even be in conflict with each other, which requires priori-
tizing on the part of the designer. For instance, it can be difficult to
give contrast to an item for highlighting its importance when one is
restricted to using certain colors, e.g., for a corporate identity pur-
pose. Another example might be when attempting to introduce a new
interface technology (e.g., touch gestures). While the new interface
may have been proven effective in the laboratory, it still may require
significant familiarizing and training on the part of the user. It is
often the case that external constraints such as monetary and human
resources restrict sound HCI practice.
 Sp ecific H CI Guid eline s 27

There is no straight answer to how such conflicts can be managed

and how to incorporate all the requirements simultaneously, particu-
larly under stringent external constraints. One must realize that all
designs involve compromises and tradeoffs. Experienced designers
understand the ultimate benefit and cost for practicing sound HCI
design. In spite of the acknowledged aspect of “black art” to HCI
design (in which good judgments are made by experienced develop-
ers), the HCI guidelines still help greatly to ensure overall usability
and performance. In Chapter 3, we will study cognitive and ergo-
nomic knowledge (more theoretical), which, along with the principles
and guidelines we have learned so far (more experiential), will be
applied to HCI design.

References
1. Wikipedia. 2013. ISO 9241. http://en.wikipedia.org/wiki/ISO_9241.
2. Tidwell, Jennifer. 2010. Designing interfaces. 2nd ed. Sebastopol, CA:
O’Reilly Media.
3. Leavitt, Michael O., and Ben Shneiderman. 2006. Research-based web
design and usability guidelines. Washington, DC: US Department of
Health and Human Services.
4. Smith, Sidney L., and Jane N. Mosier. 1986. Guidelines for designing user
interface software. Bedford, MA: Mitre Corporation.
5. Caldwell, Ben, Michael Cooper, Loretta G. Reid, and Gregg Vanderheiden,
eds. 2010. Web content accessibility guidelines (WCAG) 2.0. W3C. http://
www.w3.org/WAI/GL/WCAG20/.
6. Nokia. 2012. Guidelines for mobile interface design. http://www.
developer.nokia.com/Community/Wiki/Guidelines_for_Mobile_
Interface_Design.
7. Android. 2013. Multi-pane layouts. http://developer.android.com/
design/patterns/multi-pane-layouts.html.
8. Apple. 2014. iOS human interface guidelines. http://developer.apple.
com/library/ios/documentation/userexperience/conceptual/mobilehig/
MobileHIG.pdf.
9. Microsoft (Windows XP Design Team). 2001. Windows XP visual
guidelines. Microsoft Corporation.
10. Blattner, Meera M., Denise A. Sumikawa, and Robert M. Greenberg.
1989. Earcons and icons: Their structure and common design principles.
Human–Computer Interaction 4 (1): 11–44.
11. Green, Paul, William Levison, Gretchen Paelke, and Colleen Serafin.
1993. Suggested human factors design guidelines for driver information
systems. Technical Report UMTRI-93-21. Ann Arbor: University of
Michigan, Transportation Research Institute.
 28 Hum a n – C o m u t er In t er a t on

p
c
i

12. Kalsbeek, Maarten. 2012. Interface and interaction design patterns for
e-commerce checkouts. Master’s thesis, University of Twente. http://
essay.utwente.nl/62507/.

ANNOUNCEMENT

QUIZ NEXT MEETING (LAB/LECTURE) :)

ASSIGNMENT 1
Differentiate or research about the
following interfaces:
1. touch-oriented interfaces and
web-browser interface
2. spreadsheet interface and table-in-a-
word-document interface
3. web-browser games interface VS Body-
based and action-oriented interfaces

- You can print your answers. Bring it

during our QUIZ. I will not allow your
classmates to borrow your assignment.
- Bring SHORT BONDPAPER

Thanks