COS 368 Graphical User Interface Design

User-Centered Design
What is design? In computer science courses we deal with software design. 
We assume that all the work has already been done to determine what the
software is being built for.  We are given a programming problem and our job
is to solve it efficiently and, if possible, elegantly.

In real life, the problem to be solved has often not been determined before
the programmers start in on the work.  The programmers then actually do all
the design of functionality, interface, etc. as well as the software design.  We
do not really have the expertise to do all this design and the products often
suffer.

We need either to have design specialists in the group or give programmers

the tools to do the design themselves.  This will probably depend on the size of
the company involved and the project budget.  If the resources are not there,
design will be up to the implementers.

As stated earlier, there is no such thing as a "good design" considered in

isolation from the environment it is used in and the people who use it. 1
How else would interface and software design be done?
Often the users are presented with a long, wordy, technically-oriented
requirements specification to read.  These are often incomprehensible to the
users.  If the users want a different functionality, the designers tell them "the
computer can't do that" and give strong, jargon-heavy reasons.

The resulting software is often unusable and is never used.  Or, even worse, it
is unusable and its use is required.  This may be the case because the
software performs some tasks that are useful to management.  The users only
see the headaches caused by the software, and not the benefits that
management gleans.

Users are easily intimidated by programmers.  Programmers do not want

anyone to change the design because they have already started to program
and see the design as "in concrete".  But, programmers often see any code that
is compiled and running as "in concrete".  Programmers hate to change code.
[A note on programmers:  Programmers are proud that they can deal with
obscure systems and make them work.  They have little sympathy for the
novice user.]

2
Old Days-
•Code from specifications, documents, aimed at on-time, on-budget. 
•Often difficult to derive what the system will end up looking like. 
•Software people often run over user objections with technical  babble. 
• Implementers do not want to implement difficult stuff when they see no reason
for it. 
•The user interface is tacked on at the end.

Programmers made decisions based on how they would like the system to
work.  Disagreements on design were often decided by the person with the
most power, loudest voice, etc.

Change in user expectations –

•Users began to see attractive, understandable, learnable PC  software in other
aspects of their lives.  
•They began to wonder why their systems were such a mess.

3
Now (user centered design)-
•Same desire for on-time, on-budget but User Interface is basic part of design. 
•The prototype process lets the users see what the system will be like. 
•Testing may show the implementers the necessity of making changes.  
•The prototype is used to communicate with users.

The basis of the user-centered approach (aka contextual design) is the use
of user data to inform design decisions.  Having users try out a facet of the
design can yield real information for the designers to use.

User-Centered Design cycle

•Design
•Prototype
•Test
•(repeat until the design is clean)

4
What does Design represent in User-Centered Design Cycle?
Understand who the users are:
•background
•expertise
•limitations,
•experience levels
•etc.

This is a very important stage. 

•You must not take yourself or your coworkers to be the users.
•It is necessary to actually meet real users and learn from them.

What does Prototype represent in User-Centered Design Cycle?

•Early "paper and pencil", good way to communicate design to others, later
build partial systems.
•Prototyping is an effective way to communicate the design to others.
•The prototype is an excellent reference for implementers. 
•Implementers should not take the prototype too literally.  That smudge may
be a coffee stain that requires no corresponding graphic image.
5
What does Test represent in User-Centered Design Cycle?
•Test with actual users.  Not easy to do or to be funded with time or money.
•Users must be from the target population.  This can get difficult and expensive
if the proposed users are CEOs, orthodontists, or plumbers.
•Purpose is to evaluate the software, not the users.
•If done correctly, testing can help tremendously in the next design phase.
•Testing must be detailed, specific tasks must be tested.  Do not simply ask if
the user likes the way the interface looks.

Four principles of system design - according to John Gould

•Early continual focus on users.  Direct contact through participatory design
interviews, observations, and surveys (ethnographic studies).
•Integrated design.  All aspects of usability done in parallel.  The user is the
focus.   Don't tack the interface design on at the end.
•Early and continual user testing.  Users do (or simulate doing) real work using
prototypes.
•Iterative design.  All aspects of the design could possibly be modified based on
user testing.

6
User-centered design principles:
User is in Control
•User feels in control of software, not controlled by the software.
•User initiates actions
•User can personalize software (to some extent).
•Avoid "modal" operation where a command has different meaning in some
circumstances than others.  If modes are used, make them very visible.

Directness:
•User can directly manipulate the items of interest.
•Results of manipulation must be visible.
•Familiar metaphors can be helpful.  Metaphors may or may not be useful.
•Don't overdo correspondence to the metaphor.  "Purpose of a metaphor is to
provide a cognitive bridge; the metaphor is not an end in itself" - Windows
Interface Guidelines

7
Consistency:
•Try to avoid modal operation (or at least make mode visible).  Modes -> Same
command has different meaning.
•Allows user to transfer existing knowledge to new tasks (e.g. click-and-drag).
•Consistent command names, visual presentation of information, operational
behavior.
•Consistency within your products.
•Consistent use of metaphors.
•Consistency is the primary focus of most interface guidelines publications by
software manufacturers. (MS, Apple, etc.).

8
Forgiveness:
•Allow only appropriate choices (restrict through drop-down menus, sliders,
etc.).
•Have a recovery method (UNDO?).
•Delay commitment of changes until user explicitly does it.  Even then, keep
backup files.
•Make it reasonably easy to recover from errors.
•Disable buttons and menu choices that do not apply to the present situation. 
Leave them on the interface, though.  (Leaving them lets the user know that an
action is possible, but not at this time.)

Feedback:
•Show that the user's action causes some effect.
•Should be timely and visible. 
•Sound can be excellent feedback.

9
Aesthetics (Visual Design):
•Need someone with expertise.
•Important impressions are made visually in a GUI.
•Don't put too much on the screen.  There should be a reason for everything
visible on the screen. A graphics of visual designer may be very helpful. 
Software people usually do not have the expertise.

Simplicity:
•Interface should be simple but not simplistic.
•It is easy to make simple things hard but difficult to make hard things easy.
•"Things should be made as simple as possible but no simpler." - Einstein
•Unfortunately, software systems are often judged by the number of features
incorporated into the product.   Software reviewers check off various features
in comparative reviews.  Advertising also compares software by feature lists. 
Having more features is not necessarily the sign of a better piece of software. 
More features make the software more complex to learn and use.
A favorite quote:
“I have only made this letter longer because I have not the time to make it shorter.”—
Blaise Pascal
10
Managing the design process (Schneiderman)
Major points
•First, be sure that there are users for your system.  (Over the years, many
systems have been designed and built but not used.  Many of these were for
hundreds of millions of dollars.)
•Many projects fail.  (A commonly seen figure is that 46% of software projects
end up in failure.)
•Main difference between today's design process and that of the past is
usability testing.
•Paying attention to the user actually pays off in the market place.

3 Pillars of design
•Guidelines documents
•User Interface Software tools (e.g., C# drag-and-drop)
•Expert reviews and usability testing

11
Guidelines documents
•Think about look and feel from the beginning.
•Use published guidelines such as the ones from Apple and Microsoft.  Others
exist, too.
•Have your own specific guidelines
•General guidelines -  icons, wording, layout, I/O/o devices, action sequences,
training.

User Interface Software tools

•Use sketched or printed versions of the interface very early on.
•On-screen display with active keyboard & mouse is better (used in later
stages).  Use Visual Basic, Java, etc. for fast prototyping.
•Limited functionality, right look.  (Some of the feel may be right, too.   Feel
means action.)

Usability Testing and Expert reviews

•Test on real users if possible
•Using experts can be faster and cheaper

12
Design Aids
Ethnographic Observation - Observe people in workplace.  (Akin to cultural
anthropology, but the purpose in not understanding the culture, but
understanding the work and workplace to aid in design of software.)
•An "ethnographer participates, overtly or covertly, in people's daily lives for
an extended period of time, watching what happens, listening to what is said,
asking questions"  (Hammersley and Atkinson, 1983)
•Purpose is to find out what work is really done, how the work is done, and
how to improve it.
•Often it is only possible to do this for a few days.  Still must try to find the
important elements of the work.
•Observers must try not to influence people on the job while observing.
•Interviews do not get as much true information as observation.  Asking people
what they do often does not yield very complete descriptions.

13
(Page 108, Shneiderman, 3rd. Ed.)

The goal of an observation is to obtain the necessary data to influence

interface redesign. Unfortunately, it is easy to misinterpret observations, to
disrupt normal practice, and to overlook important information. Following a
validated ethnographic process reduces the likelihood of these problems.
Guidelines for preparing for the evaluation, performing the field study,
analyzing the data, and reporting the findings might include the following
(Rose et al., 1995):

Preparation
• Understand organization policies and work culture.
• Familiarize yourself with the system and its history.
• Set initial goals and prepare questions.
• Gain access and permission to observe or interview.

14
Field Study
•Establish rapport with managers and users.
•Observe or interview users in their workplace, and collect subjective, objective,
quantitative, and qualitative data.
•Follow any leads that emerge from the visits.
•Record your visits.

Analysis
• Compile the collected data in numerical, textual, and multimedia databases.
• Quantify data and compile statistics.
• Reduce and interpret the data.
• Refine the goals and the process used.

Reporting
• Consider multiple audiences and goals.
• Prepare a report and present the findings.

These notions seem obvious when stated but they require interpretation and
attention in each situation.

15
Participatory Design - Have users as part of the design team (Controversial)

•Advantage  
o More accurate task information
o Sense of participation
o Increased user participation
o Earlier discovery of design flaws
o Public relations (designed by actual users)

•Disadvantage
o Costly
o Lengthen development time
o Antagonize users whose ideas are not implemented
o Force designers to deal with incompetent(?) people

Participatory has been more used and more successful in European

countries (especially Scandinavian countries) than in the U.S.

16
Jakob Nielsen - Users are good at evaluating prototypes.  They are
probably not good at design.  Have a pool of users available for
ongoing questions and prototype evaluation.

Rule: Listen to the users, but do not do what they say!

17
Scenario Development.
When testing a prototype it is necessary to have a "scenario".   The
scenario is the story given to the user of what they will be doing
with the system.  It might be simply to order lunch at a fast food
place. Or, pizza at a pizza place.

A realistic, meaningful, doable (using the prototype) scenario is

best.  Having users just play with the system will not get good
results.  Having a real problem to solve themselves is probably
better than just having them key in a specified sequence of 
commands.

18
Design for specific users
•Pick a set of real people and design for them. 
•People are from the potential user population
•Differ in various meaningful ways from each other (age, gender,
computer experience, ... ).

Personas
•Several fictional, composite users
•give them names
•task characteristics
•background information
•sometimes, provides pictures of them to the design team. 

The design team then thinks in terms of these users when questions
arise.  This is an interesting idea and is now more commonly used than
in the past.  The task characteristics (what they do in their jobs) are
determined from ethnographic studies.

19
Dialog flow and task flow

When we design a GUI, we will design a dialog flow. This is

the flow through various windows, command selections (from
menus, etc.), that will be used to perform a task.

Before we can do this, we must understand the tasks.

Task Flow and WorkFlow

Work Flow - The sequence of actions a person takes to do a

job.

Task Flow - That portion of the workflow in which the person

uses a computer

20
Task Flow

One of the most difficult user interface components to design.

Must meet user needs and expectation as well as the company's
business requirements.

•A systems analyst will use a variety of techniques to do the task

flow.
•This is one of the things the software person is not qualified
(usually) to do.
•Interviews, ethnographic studies, etc. are used.
•Must work with real users, not surrogates. (Programmers usually
need not apply.)
•The analyst must really understand the business end of things.
•In this course, we will assume the task flow has basically been
done.

21