Interaction Design Preece Assignment 2

Interaction Design:  Beyond Human Computer Interaction
by Jennifer Preece

Preece, J., Rogers, Y., & Sharp, H.. (2002). Interaction Design: Beyond Human-Computer Interaction.
A typical undergraduate level textbook to introduce you to the field, including both scientific background and usability design methods. One of the few that adequately addresses affective measures. [DS & DN]

Jump To:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15

Table of Contents:

Ch. 1:  Intro to Interaction Design
Ch. 2:  Conceptual  Models and Interface Metaphors
Ch. 3:  Cognition and Mental Models
Ch. 4:  Conversational, Coordination, Awareness Mechanisms and Collaboration
Ch. 5:  Affective Aspects of Interfaces and User Frustration
Ch. 6:  The Process of Interaction Design and Life-Cycle Models
Ch. 7:  Needs and Requirements (Scenarios, Use Cases, Essential Use Cases, HTA)
Ch. 8:  Prototyping, Conceptual Design and Physical Design
Ch. 9:  Ethnography and Participatory Design
Ch. 10:  Introduction to Evaluation
Ch. 11:  Evaluation Paradigms, DECIDE Framework
Ch. 12:  Observing Users
Ch. 13:  Interviews, Questionnaires, Inspections and Walkthroughs
Ch. 14:  User Testing, GOMS, KLM, Fitt's Law
Ch. 15:  Example Applications of Interaction Design

Preece's Summary of the Chapters:

Remember, usability is of utmost importance to Interaction Design, while user-experience follows (see graph on p. 19 of book)

usability goals:  at center of Interaction Design
user-experience goals:  outer ring of diagram (secondary to usability goals)

Chapter 1:  What is Interaction Design?

Main Goals of this Chapter:
  • Explain the difference between good and poor interaction design
  • Describe what interaction design is and how it relates to HCI and other fields
  • Explain what usability is
  • Describe what is involved in the process of interaction design
  • Outline the different forms of guidance used in interaction design
  • Enable you to evaluate an interactive product and explain what is good and bad about it in terms of the goals and principles of interaction design

Good and Poor Design

  • Central concern of interaction design:  products that are USABLE
    • Easy to use
    • Effective
    • Enjoyable
  • Example:  Marble interface versus Voicemail:  an incoming message signaled by a marble dropping through- you grab it and drop it to play the message (good interface but breaks down if system gets more complex)

What to Design

  • Who will use it?
  • Where are they going to be used?
  • What kinds of activities will it support?
  • A key question:  How do you optimize the users' interactions with a system, environment or product, so that they match the users activities that are being supported and extended

Match goals to users - get them involved

  • Take into account what people are good and bad at
  • Consider what might help people with the way they currently do things
  • Thinking through what might provide quality user experiences
  • Listening to what people might want and getting them involved in design
  • Using tried and tested user-based techniques during the design process

Interaction Design:

Definition:  "Designing interactive products to support people in their everyday and working lives"

Interaction Design comes from a multidisciplinary background, extends and enhances the way people work, communicate and interact

Interaction Design involves four basic activities:

  1. Identifying needs and establishing requirements
  2. Developing alternative designs that meet those requirements
  3. Building interactive versions of the designs so that they can be communicated and assessed
  4. Evaluating what is being built throughout the process

Evaluating what has been built is the heart of Interaction Design

Three characteristics of the Interaction Design Process:

  1. Users involved throughout the development of the project
  2. Specific usability and user experience goals should be identified, documented and agreed upon at the beginning
  3. Iteration through the four activities (above) is inevitable

The Goals of Interaction Design:  Usability Goals & User Experience Goals

- Usability Goals:  concerned with meeting a usability criteria (e.g. efficiency)

  • Effectiveness - how good  system is at doing what it is supposed to
  • Efficiency - the way a system supports users in carrying out their tasks
  • Safety - protecting the users from dangerous conditions / undesirable situations
  • Utility - extent to which the system provides the right kind of functionality so that users can do what they need or want to do
  • Learnability - how easy a system is to learn to use
  • Memorability - how easy a system is to remember how to use, once learned

- User Experience Goals:  User experience is what the interaction with the system feels like to the users (subjectively)

  • Satisfying; enjoyable; fun; entertaining; helpful; motivating; aesthetically pleasing; support creativity; rewarding; emotionally fulfilling

Usability:  Design and Usability Goals (generalized abstractions)

  • Norman's Design Principles:
    • Visibility - functions can be seen
    • Feedback - necessary part of interaction
    • Constraints - ways of restricting what kinds of interaction can take place
    • Mapping - relationship between controls and what happens
    • Consistency - similar operations / use similar elements for achieving similar goals
    • Affordance - attribute of an object that allows people to know how to use it

Usability Principles / Heuristics (heuristics are design principles used in practice - more prescriptive usability principles that are used as a basis for evaluating a system / prototype)

  • Nielsen's 10 Usability Principles:
    • Visibility of System Status
    • Match between system and real world
    • User control and freedom
    • Consistency and standards
    • Help users recognize, diagnose and recover from errors
    • Error prevention
    • Recognition rather than recall
    • Flexibility and efficiency of use
    • Aesthetic and minimalist design
    • Help and documentation

There are always tradeoffs with usability - can't over constrain things, because it limits how much info is displayed


Chapter 2:  Understanding and Conceptualizing Interaction

have a clear understanding of what, why and how you are going to design something before writing any code.

Goals of the chapter:

  • Explain what is meant by the problem space
  • Explain how to conceptualize interaction
  • Describe what a conceptual model is and explain the different kinds
  • Discuss the pros and cons of using interface metaphors as conceptual models
  • Debate the pros and cons of using realism versus abstraction at the interface
  • Outline the relationship between conceptual design and physical design

Understanding the Problem Space

- the problem with solving a problem on the nuts and bolts level is that critical usability goals and user needs can be overlooked

- the design of physical aspects are best done AFTER we understand the nature of the problem space

- to understand the problem space:  clarify usability and user experience goals.  Make explicit your implicit assumptions and claims.

Framework for making your implicit assumptions explicit:

  • reason through your assumption about why something might be a good idea
  • this enables you to see the strengths and weaknesses of the proposed design

Conceptual Models

A conceptual model is a description of the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave and look like, that will be understandable by the users in the manner intended.

"The most important thing to design is the users conceptual model." (David Liddle, '96)

To Develop a Conceptual Model:

  • Envision the proposed product based on users' needs and requirements
  • Do iterative testing
  • What kind of interaction mode would support this?  Which interaction mode to use, and which interaction style to use?
  • Concrete solutions to support the above comes last
  • Development should be done using:  iteration, using a number of methods, by sketching out ideas, storyboarding, and scenarios, and by making use of prototypes

Two types of conceptual models are:

  • Those based on activities

    1.  Instructing:  describes how users carry out their tasks through instructing the system what to do (1-way process:  like word processing, CAD, email)

    2.  Conversing:  based on the idea of a person conversing with the system where the system acts as a dialogue performer (2-way process:  such as search engines, advisory systems, etc)

    3.  Manipulating and Navigating:  manipulating and navigating through a virtual world by using users' knowledge of the real world (like video games, virtual reality)

    4.  Exploring and Browsing:  allows people to browse / navigate through information

  • Those based on objects

    based on objects or artifacts, and are more specific than those based on activities (focus on a particular object in a particular context - for example:  a spreadsheet, based off of a ledger sheet)

The best type of conceptual model to use depends on the nature of the activity.  Often the best answer is a hybrid (such as shopping on the Internet).  However, mixing conceptual models will raise the complexity of the system.

Interface Metaphors

definition:  a conceptual model that has been developed to be similar in some ways to aspects of a physical entity, but that also has its own behaviors and properties

Interface metaphors combine the familiar with new concepts

Benefits:  a good orientation device
Drawbacks:  often the metaphor looks / feels like the physical entity, when they should just map the familiar with the unfamiliar so that users can learn the new (unfamiliar)

There is a growing opposition to metaphors because they can break the rules of the object they represent, they can be too constraining, can conflict with design principles, can cause misunderstanding of system functionality, can limit the designer's imagination, and can have overly literal translation of existing bad design.  See Metaphors description for more information.

Interaction Paradigms

- moving away from WIMP interface / paradigm

- new paradigms:  ubiquitous computing, pervasive computing, wearable computing, augmented reality, attentive environments

From Conceptual Models to Physical Design

Interaction design is an ITERATIVE PROCESS, involving:

  • cycling through various design processes and different levels of detail

  • thinking through a design problem

  • understanding users needs

  • coming up with possible models

  • prototyping models

  • evaluating them

  • thinking about design implications

  • making changes

  • etc...

The book describes ways of DOING INTERACTION DESIGN

  • First pass: thinking about the problem space
  • Second pass: more extensive information gathering about users’ needs and problems
  • Third pass: continue explicating the requirements through models
  • Fourth pass: Fleshing out models using variety of user-centered methods. Such as: prototyping, storyboarding, physical objects, informally asking users what they think.

Issues in testing prototypes:

  • Way information is to be presented and interacted with
  • What combinations of media
  • Kinds of feedback
  • What combinations of input and output devices to use
  • Whether to provide agents and in what format
  • Whether to design operations to be hardwired or through physical objects or software
  • What kinds of help to provide and in what format

Physical design decisions come out of conceptual decisions (i.e. what information, how to structure graphical objects, what feedback navigation and mechanisms, what kinds of icons…).

  • These kinds of design decisions need user testing to ensure usability goals.


Chapter 3:  Understanding Users

This chapter focuses on USERS and COGNITION.  Cognitive aspects of Interaction Design include:

  • what humans are good and bad at
  • how this knowledge can be used to inform design of technologies that,
  • extend human capabilities and
  • compensate for their weaknesses

Main aims of chapter:

  • What cognition is and why it is important for I-D
  • Main ways cognition has been applied to I-D
  • Number of examples from cognitive rese4arch
  • Explain what mental models are
  • Give examples of conceptual frameworks useful for I-D
  • Enable you to try to elicit a mental model and understand what it means

Norman said there are two modes of cognition:  Experiential (real world experiences) and Reflective (thinking, comparing, deciding, etc).  Both are necessary for everyday life.

Cognition has been described in SIX KINDS OF PROCESSES:

  1. Attention - selecting things to concentrate on
  2. Perception / Recognition - how information is acquired from the environment via sense organs and translated into experiences (vision is the most dominant)
  3. Memory - recalling various knowledge.  We filter what knowledge to process / memorize. (most researched area)
  4. Learning - how to do something (like learning to use a program)
  5. Reading / Speaking / Writing - using language
  6. Problem Solving / Planning / Reasoning / Decision Making - involves reflective cognition

Often designers try to emulate the physical world with designs in the digital world.  Sometimes this works well, other times it doesn't.

Conceptual Frameworks for Cognition:

  • Mental Models
  • Information Processing
  • External Cognition

Users' Mental Models

- defined as:  when people are using a system, they develop knowledge of how to use the system and to lesser extent how the system works.

- the mental model is used to help people carry out tasks.  It can also give suggestions on what to do in unpredictable situations

- in cognitive psychology, mental models are defined as some sort of internal construction of the external world that are manipulated enabling predictions and inferences to be made

- w/r/t system design:  ideally, the users' mental models should match the designer's conceptual model

- to increase transparency- might make system image easier to learn (p. 95 example?)

Information Processing

- another approach to conceptualize how the mind works:  through metaphors and analogies

- thinks of the mind as an information processor

- mental representations can be images, mental models, rules, other knowledge forms

the human processor model (Card, et. al 1983) is the best known approach (see p. 96)

  • model predicts which cognitive processes are involved when a user interacts with a computer, allowing for calculations to be made on how long it will take a user to complete a task
  • this is helpful for comparing different interfaces (efficiency)
  • the approach is based on modeling mental activities that happen exclusively in the head.  There are always external cues in the environment... so how truly representative are these models?

- there has been an increase in people studying cognitive activities 'in the wild' - in the context in which they take place (how can things in the environment aid human cognition and lighten the cognitive load?)

Alternative frameworks have been suggested:  External cognition and Distributed Cognition

External Cognition

main idea:  people interact with or create information through using a variety of external representations (books, etc.)

- an impressive array of technology has been created by humans to aid cognition (calculators, pens, etc)

- these tools have combined with external representations to extend and support our ability to carry out cognitive activities.

- some of the main goals of this:

  • Externalizing to reduce memory load (external representations / cues as reminders)
  • Computational offloading (using a tool / device to carry out a computation - like a pen / paper to do a math problem) Note:  representation of the task is key- imagine the difficulty of multiplication if the numbers were represented as Roman numerals
  • Annotating / Cognitive tracing (modifying representations to show changes - like crossing something off a list


Informing Design:  From Theory to Practice

Theories, models and frameworks provide abstractions for thinking about phenomena.  They provide generalizations, but can be difficult to digest.  For this reason researchers have tried to make them more practical by providing design principles / concepts, design rules, analytic methods and design / evaluation methods.

This has helped - for instance - the human processor model (Card, 83) which has been simplified into GOMS.


Chapter 4:  Designing for Collaboration and Communication

humans are SOCIAL beings

Purpose of the chapter:  look at ways interactive systems could be developed to support and extend communication and collaboration between peoples.

Social Mechanism in Communication and Collaboration:

Rules, procedures and etiquette have been established to help people know how to behave in social groups, such as:

  • Conversational mechanisms- to help the flow of talk and to help overcome breakdowns
  • Coordination mechanisms- to allow  people to work / interact together
  • Awareness mechanisms- to find out what is happening, what others are doing and to let others know what is happening

Conversational Mechanisms:

  • "turn-taking" helps coordinate conversation
  • Implicit cues and Explicit cues (indirect vs. direct / obvious)
  • Turn taking rules:  speaker chooses next speaker by asking question / request, etc.
  • Back channeling, body orientation, gaze, gestures are used to signal to others the flow of conversation
  • Farewell rituals help end a conversation (bye, see ya later)
  • Breakdowns in conversation occur when someone is ambiguous and it gets misinterpreted (followed by a re-questioning)
  • Conversations can take the form of arguments, discussions, debate, chat, etc.

How to design collaborative technologies to support conversation:

  • First, how do technology-mediated conversations compare to FTF?  Do the same rules apply?  Are there more breakdowns?  How do they get repaired?
  • Design implications:  A key issue has been to determine how to allow for and support people to carry on communicating as if they were in the same place, even thought they are geographically separated.
  • Some existing apps:  phone, videophone, email, IM, videoconferencing, chatrooms, SMS texting
  • How successful are these?  Do they mimic or extend existing ways of conversing?

Synchronous CMC: (p.112 table 4.1)

  • real-time conversations, like a chatroom
  • Pros:  more informed of what's going on, can allow shy people to talk more, if video support:  can allow nonverbal communication to occur
  • Cons:  bandwidth issues can cause video to get choppy, very hard to establish eye contact, people can behave badly behind the mask of an avatar

Asynchronous CMC:

  • remote communication at various times, such as email, newsgroups
  • Pros:  read at any time, flexible response, easier to say things, can contact many people easily
  • Cons:  Flaming, spamming, new message overload, don't know when people will reply

Many new communication technologies combine the above, and try to provide new / novel ways to communicate

  • Collaborative virtual environments, media spaces, shared drawing tools, tools for collaborative document creation
  • Pros:  support talking while doing a task at same time, can be efficient to have multiple people working on the same thing at the same time, and greater awareness of what is going on
  • Cons:  WYSIWIS:  we can't always see what people are referring to in a remote location, and floor control (file conflicts from multiple people working on the same thing at the same time)

Coordination Mechanisms:

Collaborative activities require us to coordinate with each other, so we need to figure out how to work with others to progress through the activities.  Examples include:

  • Verbal and Nonverbal communication (commands, gestures, nods, shakes, hand raising, to coordinate their communication)
  • Schedules, rules and conventions (to organize people who take part in a project- can be formal or informal)
  • Shared external representations (allow people to make inferences about the changes / delays on their current project)

How to design collaborative technologies to support coordination:

Shared calendars, schedulers, project management tools, and workflow tools have been developed to support coordination activities.

People tend not to follow conventions, because they are often not socially acceptable.  Failure to make them socially acceptable can cause people to not use the system in the way intended or can cause them to abandon it totally.

Awareness Mechanisms:

These provide others with awareness of who is around, what is happening, who they are talking to.  This requires knowing when is an appropriate time to interact with others and to get / pass information.

How to design collaborative technologies to support awareness:

Function is to make others aware of the others they are collaborating with.  For example:

  • Portholes:  a series of digitized images showing people in their offices from various locations (led to increased sense of community)
  • Notification systems:  users notify others, rather than being monitored, and provide information about shared objects and progress of collaborative tasks (so others can see each other and their progress)


Ethnographic studies of collaboration and communication

A main approach to informing the design of collaborative technologies that takes into account the social concerns is to carry out an ethnographic study.

This can be a home, work, school, public place (setting)

Since Suchman's "Seminal Work" many companies have invested in ethnographic studies to see how work actually gets done in a range of companies (government too)


Conceptual Frameworks:  Language / Action Framework and Distributed Cognition

Language / Action Framework:

  • people act through language
  • goal to inform the design of systems to help people work more effectively by improving the way they communicate with each other
  • this framework doesn't take into account the use of artifacts / external representations in everyday work

Distributed Cognition:

  • describes what happens in a cognitive system:  interactions among people, artifacts they use, environment they work in
  • the way that cognitive activity is described contrasts with others in that it focuses on not only what is happening in the head of individuals, but on what is happening across individuals and artifacts
  • Examines:  distributed problem solving that is taking place, role of verbal / nonverbal behavior, coordination mechanisms that are used, communicative pathways that take place as collaborative activity progresses, and how knowledge is shared / accessed



  • social mechanisms, like turn taking conventions, allow us to collaborate / coordinate our activities
  • keeping aware of what others are doing and letting others know what you are doing are important aspects of collaborative learning / socializing
  • many collaborative technologies (CSCW / groupware) systems have been built to support collaboration, especially communication and awareness


Chapter 5:  Understanding How Interfaces Affect Users

Goals of this chapter:  AFFECTIVE LEARNING - a way to design systems to elicit positive responses from users (feeling at ease, being comfortable, enjoying the experience)

  • How can the appearance of the interface elicit positive responses from the user?
  • How can user frustration be caused by an interface?
  • How do interface agents (anthropomorphism) and synthetic characters affect us?

Affective Aspects of HCI

  • traditionally, HCI has been about designing efficient and effective systems
  • recently, HCI has moved towards considering how to design interactive systems to make people respond in a certain way (to be happy, to be trusting, to learn, to be motivated)
  • It has been suggested that computers be designed to recognize and express emotions in the same way that humans do
  • How can interactive systems be designed (both deliberately and inadvertently) to make people respond in certain ways?

Expressive Interfaces

  • Colors, icons, sounds, graphical elements and animations are used to make the "look and feel" of an interface appealing
  • A benefit is that these embellishments provide reassuring feedback to the user that can be both informative and fun- which can affect the usability of the interface
  • People are willing to put up with certain aspects of an interface (slow download rate, etc) if the end result is very appealing and aesthetic
  • Aesthetics have been shown to have a positive effect on people's perception of the system's usability
  • Some friendly interfaces:  Microsoft's 'at home with Bob' interface, 3D metaphors (living rooms, etc), agents in the guise of pets (dog) that talk to the user.  These make users feel more at ease and comfortable.
  • User-created expressiveness:  emoticons - these provide non-verbal type expression in interfaces not originally intended to have this :-)  Also, icons / shorthand have been used to add emotion to SMS texting (I 12 CU 2NITE)

User Frustration

Can be caused by:

- application doesn't work / crashes
- system won't do what the user wants it to do
- user's expectations aren't met
- when the system doesn't provide enough information to enable the user to know what to do
- vague error messages
- condemning error messages
- when the interface's appearance is patronizing, gimmicky, noisy
- when the user does a long series of steps to complete a task, only to discover an error was made and they have to start over

Things to avoid:

- Gimmicks:  "under construction"
- Error messages:  "the system has unexpectedly quit" (see Shneiderman's guidelines for error messages:  don't use "FATAL" "INVALID" or "BAD", or long hex codes - try to provide context sensitive help)
- Overburdening the user:  forcing them to upgrade, install plugins, do housekeeping just to use a product
- Unpleasant Appearance:  too much crap on the page, featuritis (too many features), weird sound effects, childish interface, poorly laid out input devices

Dealing with User Frustration:

- people will vent, by beating the hell out of their computers, flaming, etc.
- offer helpful error messages that offer a way to fix the problem, and offer hints, help guides, cartoon agents, etc. that can help point the user in the right direction
- Reeves and Naas (1996) argue that computers should apologize when they mess up

Anthropomorphism in HCI:  How much is enough?

Anthropomorphism- assigning human traits to non-human things (dancing butter, talking soda cans, dogs, cars, etc.)
- used heavily in advertising

People debate how much of this to use in system design.  They can add a human feel to the system, but can also get annoying.

Which is more preferable?
- "Hello Matt!  Welcome back.  It's nice to see you again.  Now, what were we doing last time?  Ah, yes, problem five.  Lets get started again."
- "User 24, commence exercise 5."

Or, when doing something wrong:  "Now Matt, that's not right, you can do better than that.  Try again." vs. "Incorrect, try again."

The answer: 
Pros:  Reeves and Naas (1996) found it is helpful to use praise in educational settings when people do something right.  It increased students willingness to continue working. 
Cons:  However, others argue this can make you feel stupid, anxious, inferior.  People hate when a computer character shakes their finger at them and says "you can do better than that, Matt, try again".  In this case, many prefer the impersonal message "Incorrect, try again".

Virtual Characters

virtual characters are becoming more common.  They can be used on the web, in video games, as learning companions, wizards, newsreaders, etc.  However, they can be misleading (people confide in them), they can be very annoying and frustrating ("Clippy" from MS Office 97, etc).

- categorized by degree of anthropomorphism:  synthetic characters, animated agents, emotional agents, embodied conversational agents

Design Implications:  which one to use?
- believability:  the extent to which users come to believe an agent's intentions and personality
- appearance:  better to use cartoon-like characters, or those resembling humans?  it depends on the situation- often the cartoon character is more believable / acceptable
- behavior:  how does the agent move, gesture, refer to things?  facial expressions can show emotion (remember we want constructive feedback rather than conveying inferiority / stupidity / patronizing effect on users)


  • affective aspects are concerned with how interactive systems make people respond in emotional ways
  • well designed interfaces can elicit good feelings in users
  • expressive interfaces can provide reassuring feedback
  • badly designed interfaces make people angry and frustrated
  • anthropomorphism is increasingly used at the interface, through the use of agents and virtual screen characters


Chapter 6:  The Process of Interaction Design

The ultimate goal of design is to develop a product that helps its users achieve their goals.  Developing a product must begin with gaining understanding of what is required of it.

The goals of this chapter are to:

  • Consider what 'doing' interaction design involves
  • Ask and provide answers for some important questions about the interaction design process
  • Introduce the idea of a lifecycle model to represent a set of activities and how they are related
  • Describe some lifecycle models from software engineering and HCI and discuss how they relate to the process of interaction design
  • Present a lifecycle model of interaction design

What is Interaction Design?

dictionary:  "design is a plan or scheme conceived in the mind and intended for subsequent execution"

The plan or scheme must be informed with knowledge about its use and the target domain, together with practical constraints such as materials, cost and feasibility.

In Interaction Design, we investigate the artifact's use and target domain by taking a user-centered approach to development.  The users' concerns direct the development rather than technical concerns.

Design is also about trade-offs and about balancing conflicting requirements.  Generating alternatives is a key principle and one that should be encouraged in interaction.  "To get a good idea, get lots of ideas." (Mark Rettig)

Typically there is a group of designers.  Therefore, plans should be captured and expressed in a way that allows for review, such as sketches, descriptions in natural language, a series of diagrams, and building prototypes.

Four Basic Activities:

1.  Identify needs and establish requirements
- Who is the target user?
- What kind of support will the interactive product provide?

2.  Develop alternative designs that meet those requirements
- suggest ideas to meet the requirements
- Conceptual design:  produce the conceptual model for the product
- Physical design:  consider the details of the product (colors, sounds, images, menu design, icons, etc.)  Alternatives are considered at every point.

3.  Build interactive versions (so that they can be communicated and assessed)
- a software version is not required- paper based prototypes are quick and cheap to build
- through role-playing, users can get a real sense of what it is like to interact with the product

4.  Evaluate the designs (measure their acceptability)
- determine the usability of the product or design.  Criteria are:  how appealing is it?  how well does it match the requirements?  Is the product fit for the purpose?
- Evaluation results are fed back into further design (FEEDBACK / ITERATIVE DESIGN PROCESS)

Three Characteristics of Interaction Design:

1.  Focus on the USERS
- involve users in the interactive design process, provide opportunities for evaluation and user feedback

2.  Specific usability and user experience goals
- identify and clearly document these at the beginning of the project.  They help designers to choose between different alternative designs

3.  Iteration
- allows for designs to be refined.  It is always necessary to revise ideas in light of feedback, several times.  Innovation rarely emerges whole and ready to go.  Iteration is inevitable because designers never get the solution right the first time

Practical Issues in Interaction Design:

1.  Who are the users?
- those who directly interact with the system.  However, can be any stakeholder:  purchaser, testers, people receiving products from the system
- primary user:  directly use it
- secondary user:  occasionally use it or use through intermediary
- tertiary user:  affected by the system, or will influence its purchase
- stakeholders:  people or organizations affected by the system who influence the system requirements

2.  What do we mean by "needs"?
- we need to understand the characteristics / capabilities of users, what they are trying to achieve, how they currently achieve it, and whether they would achieve their goals more effectively if they were supported differently
- characteristics that impact a product's design:  users physical characteristics (ergonomics:  size of hands, height, etc), strength of product (so a child can't break it), cultural diversity of intended users
- representative users MUST be consulted!
- users rarely know what is possible.  Therefore, users cannot tell us what they "need" to do achieve their goals.
- We need to examine existing task (Activity Theory?) and what the tasks' context, requirements, collaborative nature, and procedure is.  Then we can envision the task being done in a new way (scenarios, etc.)

3.  How do you generate alternative designs?
- it is easy to stick with something that is "good enough".  Humans stick to what they know works.
- innovations arise from cross-fertilization from different applications- allows us to "break out of the box"
- often browsing a collection of designs will inspire designers to consider alternative perspectives and solutions.  Designers are trained to consider alternatives, software people are not.
- design is a process of balancing constraints and constantly trading off one set of requirements with another, and the constraints may be such that there are few viable alternatives available.
- alternatives come from looking at other, similar designs, and the process of inspiration and creativity can be enhanced by prompting a designer's own experience and by looking at others' ideas and solutions.  ("Flair and creativity" : research and synthesis)

4.  How do you choose among alternative designs?
- there are factors that are externally visible and measurable and those that are hidden from the users' view.  Focus on the external / visible.
- prototypes can be used to evaluate with peers and users
- fundamental user-centered design:  choose between alternative designs by letting users and stakeholders interact with them and by discussing their experiences, preferences and suggestions for improvement.
- technical feasibility:  some are just not possible
- quality thresholds:  usability goals lead to criteria.  This USABILITY CRITERIA need to be set early on and checked frequently.
- usability engineering:  the process of writing down formal, verifiable and measurable usability criteria.  Some suggestions:

  • Effectiveness:  Appropriate support?  Task coverage, information available
  • Efficiency:  response time?  Performance measurements?
  • Safety:  How safe?  How often does it crash / loose data?
  • Utility:  Which functions are superfluous?
  • Learnability:  How long does a novice take to learn?  High learning curve?
  • Memorability:  How log to remember how to perform common tasks?

Lifecycle Models:  Showing how the activities are related

- lifecycle models:  represent a set of activities and how they are used; management tools; simplified versions of reality

- some models from software engineering:  waterfall, spiral, RAD, etc

  • Waterfall model:  a linear process where each step must be completed before moving to the next.  This is bad because there is no iteration, and modifications cannot be made to the design.  Users cannot evaluate prototypes

  • Spiral model:  two features:  risk analysis and prototyping.  Alternatives are considered and encouraged.

  • RAD (Rapid Applications Development):  takes a user centered view and tries to minimize the risk of changing requirements through the project.  A system or partial system must be delivered on a set of intervals.

- some models from HCI:  Star, usability engineering

  • Star Lifecycle model:  does not specify order of activity.  All activities are highly interconnected.  You can move from one activity to another easily, but you MUST go through the evaluation activity (in the center).  Evaluation is central to this model

  • Usability Engineering Lifecycle model:  provides a holistic view of usability engineering and a detailed description of how to perform usability tasks.  This is helpful for those with little experience.  Three phases:  requirements analysis; designing / testing / development; installation

- a simple lifecycle model for interaction design:  see p. 186, Fig. 6.7

(note how the above principles apply to this model)


There are four basic activities in the interactive design process:
1.  Identify needs and establish requirements
2.  Develop ([re]design) alternative designs that meet those requirements
3.  Build interactive versions of the designs so that they can be communicated and assessed
4.  Evaluate them

These are permeated with three principles:
1.  Involve users early in the design process and evaluation of the artifact
2.  Define quantifiable & measurable usability criteria
3.  Iteration is inevitable

Key characteristics of the interaction design process are explicit incorporation of user involvement, iteration and specific usability criteria.

Before you can begin to establish requirements, you must understand who the users are and what their goals are in using the device.

Looking at others' designs provides useful inspiration and encourages designers to consider alternative design solutions, which is key to effective design.

Usability criteria, technical feasibility, and users' feedback on prototypes can all be used to choose among alternatives.

Prototyping is a useful technique for facilitating user feedback on designs at all stages.

Lifecycle models show how development activities relate to one another.

The interaction design process is complementary to lifecycle models from other fields.


Chapter 7:  Identifying Needs and Establishing Requirements

This chapter talks about different ways to gather requirements by introducing:

  • Types of Requirements

  • Data Gathering Techniques
  • Task Descriptions
    • Scenarios
    • Use Cases
    • Essential Use Cases
  • Task Analysis
    • Hierarchical Task Analysis (HTA) (task analysis)

What are we trying to achieve in this design activity?

  1. Understand as much as possible about users, task, and context
  2. Produce a stable set of requirements

How can we do this?

  • Data gathering activities
  • Data analysis activities
  • Expression as 'requirements'
  • All of this is iterative

Why bother getting it right?

  • Typically, the requirements definition stage is the most common place for failure
  • Getting the requirements right is crucial, because unclear objectives will cause a project to FAIL
  • A 'user-centered approach' to development is the way to solve this problem (What do users want?  What do users 'need'?)

Requirements need clarification, refinement, completion and re-scoping.

Input:  requirements document (maybe) 
Output:  stable requirements

Why 'establish' requirements?

  • 'Establish' requirements:  we establish requirements because -they arise from the data-gathering and interpretation activities and have been established from a sound understanding of the users' needs. 
  • Because of this, requirements can be justified by and related back to the data collected.

Types of requirements:

  • Functional requirements:  what the system should do (historically this was the main function of requirements activity)
  • Non-functional requirements:  memory size, response time, date product must be finished by, etc.
  • Data requirements:  What kind of data needs to be stored, how will they be stored (database)?
  • Environment / Context of use requirements:  Circumstances in which product will be used / expected to operate
    • What are the physical (dusty, noisy, vibration, light, heat humidity, etc) requirements?

    • What are the social (sharing of files, displays, paper across distances, working individually, privacy of clients, etc.) requirements?

    • What are the organizational (hierarchy, IT department's attitude, user support, communication structure / infrastructure, training ability, etc.) requirements?

  • User requirements:  Who are they? - captures the characteristics of the intended user group
    • Characteristics - ability, background, attitude to computers

    • System use - novice, expert, casual, frequent

      • Novice:  step by step (prompted), constrained, clear information
      • Expert:  flexibility, access / power
      • Frequent:  short-cuts
      • Casual / infrequent:  clear instructions (such as menu paths)
  • Usability requirements:  (note:  different than user requirements) - these capture the usability goals and associated measures for a particular project.
    • learnability
    • throughput
    • flexibility
    • attitude

Data Gathering Techniques:  (see p.214 / Table 7.1 for excellent graph)

  • Questionnaires

    • elicit specific information
    • can be YES / NO, multiple choice, comment
    • often used with other techniques
    • can give quantitative / qualitative data
    • good for answering specific questions from a large, dispersed group of people
  • Interviews

    • forum for talking to people
    • can be structured, unstructured, or semi-structured
    • props, scenarios of use, prototypes can be used
    • good for exploring issues
    • can be time consuming, infeasible to visit everyone
  • Workshops / Focus Groups

    • group interviews

    • good at gaining a consensus view and / or highlighting areas of conflict

  • Naturalistic Observation
    • spend time with stakeholders in their day-to-day tasks, observing work as it happens
    • gain insight into stakeholders' tasks
    • good for understanding the nature / context of tasks
    • Requires time and commitment from a member of the design team, and can result in huge amounts of data
    • ethnography is one form of this
  • Studying Documentation
    • procedures and rules are often written down in manuals
    • good source of data about the steps involved in an activity, and any regulations governing a task
    • not to be used in isolation
    • good for understanding legislation and getting background information
    • no stakeholder time, which is a limiting factor on the other techniques

Which of the above data gathering techniques to use?  The above techniques differ in the amount of time, level of detail and risk associated with the findings, and the knowledge the analyst requires

The choice of technique is also affected by the kind of task to be studied: 

  • sequential steps or overlapping series of subtasks?;
  • high or low, complex or simple information?;
  • task for a layman or skilled practitioner?

Problems with data-gathering:

  • identifying and involving stakeholders:  users, managers, developers, customer reps?, union reps?, shareholders?
  • involving stakeholders:  workshops, interviews, workplace studies, co-opt stakeholders onto the development team
  • 'Real' users, not managers:  traditionally a problem in software engineering, not so bad now
  • requirements management:  version control, ownership
  • communication between parties:  within development team, with customer / user, between users
  • domain knowledge distributed / implicit:  difficult to dig up and understand
  • availability of key people
  • political problems
  • dominance of certain stakeholders
  • economic / business environment changes
  • balancing functional and usability demands


  • focus on identifying the stakeholders' needs
  • involve all the stakeholder groups
  • involve more than one stakeholder from each group
  • use a combination of data gathering techniques
  • start data interpretation soon after the data gathering session
  • do an initial interpretation before deeper analysis
  • use different approaches to different problems, such as class diagrams for object-oriented systems, and entity-relationship (E-R) diagrams for data intensive systems

Task Descriptions:  (more on p. 226-231)

  • Scenarios - an informal narrative story, simple, 'natural', personal, not generalizable
  • Use Cases - assume interaction with a system, assume detailed understanding of the interaction
  • Essential Use Cases - abstract away from the details, does not have the same assumptions as use cases

Scenario for a shared calendar:

“The user types in all the names of the meeting participants together with some constraints such as the length of the meeting, roughly when the meeting needs to take place, and possibly where it needs to take place. The system then checks against the individuals’ calendars and the central departmental calendar and presents the user with a series of dates on which everyone is free all at the same time. Then the meeting could be confirmed and written into people’s calendars. Some people, though, will want to be asked before the calendar entry is made. Perhaps the system could email them automatically and ask that it be confirmed before it is written in.”

Use case for a shared calendar:

1. The user chooses the option to arrange a meeting.
2. The system prompts user for the names of attendees.
3. The user types in a list of names.
4. The system checks that the list is valid.
5. The system prompts the user for meeting constraints.
6. The user types in meeting constraints.
7. The system searches the calendars for a date that satisfies the constraints.
8. The system displays a list of potential dates.
9. The user chooses one of the dates.
10. The system writes the meeting into the calendar.
11. The system emails all the meeting participants informing them of them appointment

Alternative courses for a shared calendar:

Some alternative courses:
    5. If the list of people is invalid,
        5.1 The system displays an error message.
        5.2 The system returns to step 2.
    8. If no potential dates are found,
        8.1 The system displays a suitable message.
        8.2 The system returns to step 5.

Example Use Case Diagram for a shared calendar:

Example Essential Use Case for a shared calendar:

Task Analysis:  (p.231-234)

Task analysis is an umbrella term that covers techniques for investigating cognitive processes and physical actions, at a high level of abstraction and in minute detail.

Hierarchical Task Analysis - involves breaking down a task into subtasks, then sub-sub-tasks and so on.  These are grouped as plans which specify how the tasks might be performed in practice

  • HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device
  • HTA starts with a user goal which is examined and the main tasks for achieving it are identified
  • These tasks are then divided into sub-tasks

Example Hierarchical Task Analysis:  Borrowing a book from the library

0. In order to borrow a book from the library
    1. go to the library
    2. find the required book
        2.1 access library catalogue
        2.2 access the search screen
        2.3 enter search criteria
        2.4 identify required book
        2.5 note location
    3. go to correct shelf and retrieve book
    4. take book to checkout counter

Example HTA (Plans):

  • plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.
  • plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.

Example HTA (Graphical):


  • Getting requirements right is crucial
  • There are different kinds of requirements, each is significant for interaction design
  • The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation
  • Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices.
  • Task analysis techniques such as HTA help to investigate existing systems and practices


Chapter 8:  Design, Prototyping and Construction

This chapter will cover:  prototyping and construction (low and high fidelity prototyping, vertical and horizontal compromises); conceptual design (conceptual model, using scenarios and prototypes in conceptual design); and physical design (guidelines and widgets).

Flow of Interaction Design:
Identify Needs / Requirements (Ch. 7) --> Prototype cycles / Design (Ch. 8) --> Construction

What is a Prototype?

  • in other fields, it's a small scale model (miniature car, building, etc)
  • in Interaction Design it can be a series of screen sketches, a storyboard, a PowerPoint, a video simulating use of the system, a lump of wood (e.g. PalmPilot), a cardboard mock-up, or a piece of software with limited functionality

Why Prototype?

  • Evaluation and feedback are central to interaction design
  • stakeholders can see, hold, interact with a prototype more easily than documents / drawings
  • team members can communicate effectively
  • can test out ideas immediately
  • it encourages reflection, a very important aspect of design
  • prototypes answer questions and support designers in choosing between alternatives

What gets prototyped:  technical issues, work flow, task design, screen layouts / information displays, and any difficult / controversial / critical areas

Low-fidelity Prototyping:

  • uses a medium unlike the final product (paper, cardboard)
  • quick, cheap and easily changed
  • can be screen sketches (drawing ability not important, practices simple symbols), task sequences, post-it notes, storyboards (often used with scenarios, and consists of a series of sketches [such as 3x5 index cards] showing how a user might progress through a task using the device)
  • low fidelity prototypes have limited functionality / utility, but are helpful for identifying requirements and evaluating multiple design concepts

High-fidelity Prototyping:

  • uses materials you would expect in the final product
  • prototype looks more like final version than a low-fidelity version
  • include software environments like Macromedia Director, Visual Basic, Smalltalk, etc.
  • one drawback / compromise is that users might think they have a full system.  High fidelity prototypes are time consuming / expensive to make, and are not effective in requirements gathering

Compromises associated with Prototyping:

  • every prototype has a compromise - for software this may be slow response time, sketchy icons, limited functionality, etc.
  • Two types of compromise:  horizontal and vertical
  • 'horizontal' compromise:  provide a wide range of functions, but with little detail

  • 'vertical' compromise:  provide a lot of detail for only a few functions

  • Compromises must not be ignored:  products need to be engineered

Construction:  taking a prototype and making it whole by engineering a complete product (focus on quality:  usability, reliability, robustness, maintainability, integrity, portability, efficiency, etc.)


Conceptual Design:  From requirements to design

  • transforms user requirements / needs into a conceptual model, "a description of the proposed system in terms of a set of integrated ideas and concepts about what it should do, behave and look like, that will be understandable by the users in the manner intended"
  • should ITERATE, ITERATE, ITERATE:  don't move to a solution too quickly
  • should consider alternatives (prototyping helps this) Fudd's first law of creativity:  "To get a good idea, get lots of ideas" (Rettig, 1994)

Three Perspectives for a Conceptual Model:

  1. Which interaction mode?

    - how user invokes actions
    - Activity-based:  instructing, conversing, manipulating and navigating, exploring and browsing
    - Object-based:  structured around real-world objects
  2. Which interaction paradigm?

    - desktop paradigm with WIMP interface
    - ubiquitous computing
    - pervasive computing
    - wearable computing
    - mobile devices, etc.
  3. Is there a suitable metaphor?

    - Interface metaphors combine familiar knowledge with new knowledge in a  way that will help the user understand the product
    - 3 steps:  understand functionality, identify potential problem areas, generate metaphors
    - evaluate metaphors:  How much structure does it provide?  How much is relevant to the problem?  Is it easy to represent?  Will the audience understand it?  How extensible is it?

Expanding the Conceptual Model:

  • What functions will the product perform?  What will the product do and what will the human do?  (task allocation)
  • How are the functions related to each other?  Sequential or Parallel?  How are they categorized?
  • What information needs to be available?  What data is required to perform the task?  How is this data to be transformed by the system?

Scenarios:  Using them for Conceptual Design

- scenarios can be used to explicate existing work situations, but are more commonly used for expressing proposed or imagined situations to help in conceptual design.

- they can be used through design in various ways:  as scripts for user evaluation of prototypes, as a means of co-operation across professional boundaries

- in extreme cases, plus and minus scenarios can be used, which attempt to capture the most positive and the most negative consequences of a proposed design solution

Prototypes:  Using them for Conceptual Design

- prototypes allow for evaluation of emerging ideas

- low-fidelity prototypes are used early on, while high-fidelity prototypes are used later

Physical Design: Getting Concrete

  • physical design considers more concrete & detailed issues of designing the interface
  • can be things like screen or keypad design, which icons to use, how to structure menus
  • Some guidelines for physical design: 
    • Nielsen's heuristics (see Chapter 1)
    • Shneiderman's eight golden rules:

    1.  Be consistent
    2.  Enable frequent users to use shortcuts
    3.  Offer informative feedback (meaningful error messages)
    4.  Design dialogs to yield closure (like when you complete a task)
    5.  Offer error prevention and simple error handling (to err is human, so figure that in to your design)
    6.  Permit easy reversal of actions ('undo' button)
    7.  Support internal locus of control (user feels in control)
    8.  Reduce short-term memory load (less info to remember between screens)

  • style guides (commercial, corporate, etc. - decide the 'look and feel', along with widgets [icons, menus, toolbars, dialog boxes, etc])

    • menu design:  How long will menu be?  In what order?  How will they be structured (sub-menus / dialog boxes)?  What categories will group menu items?  How will division of items be denoted?  How many menus?  What terminology will be used?  What physical constraints (mobile phone) must be accommodated?
    • icon design:  can be difficult, as icons can be cultural / context sensitive - so draw on traditions / standard, use concrete objects
    • screen design:  Split screen?  How much white space?  How to group things (boxes / lines / colors)?  Draw attention to the focus point, using color, motion, possibly animation, and use good organization.  Balance the tradeoff between overcrowded / sparse displays
    • Information display:  show only relevant information, make different mediums (computer / paper) consistent

There is no rigid border between conceptual and physical design... they are all iterative processes.  Often in conceptual design some detailed issues come up in the iterations.  The important part is that in the conceptual design that we don't get tied to physical constraints early as they will inhibit creativity and limit our options.


  • Different kinds of prototyping are used for different purposes and at different stages
  • Prototypes answer questions, so prototype appropriately
  • Construction: the final product must be engineered appropriately
  • Conceptual design (the first step of design)
  • Physical design: e.g. menus, icons, screen design, information display
  • Prototypes and scenarios are used throughout design


Chapter 9:  User-Centered Approaches to Interaction Design

The main aims of this chapter are to:

  • Explain some advantages of involving users in development.
  • Explain the main principles of a user­centered approach.
  • Describe some ethnographic­based methods aimed at understanding users' work.
  • Describe some participative design techniques that help users take an active part in design decisions.  (users as co-designers will raise acceptance of product)

Why involve users at all?

  1. To manage their expectations:  no surprises, communicate their expectations, get a common set of realistic expectations
  2. So users feel ownership:  by making users active stakeholders, they are more likely to forgive / accept problems, and are more likely to accept the final product

Degrees of user involvement:

  • member of the design team (part time vs. full time:  degree of input / time and contact; short term vs. long term:  degree of consistency across project life.  Long term members might loose contact with users)
  • newsletters / e-mail / etc (disseminate information to a large selection of users, but requires 2-way communication, not 1-way)
  • Actual user involvement may be a combination of the above two ways. 
  • Microsoft involves users by 'activity based planning' (studying users doing tasks), usability tests, internal developer usage of products, and customer support lines.

What is a user-centered approach?  User-centered approach is based on:

  • Early focus on users and tasks: directly studying cognitive, behavioral, anthropomorphic & attitudinal characteristics
    • users' tasks and goals are the driving force behind the development
    • users' behavior and context of use are studied and the product is designed to support them
    • users' characteristics are captured and designed for
    • users are consulted throughout development, from earliest phases to the latest, and their input is seriously taken into account
    • all design decisions are taken within the context of the user, their work, and their environment

  • Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analyzed
  • Iterative design: when problems are found in user testing, fix them and carry out more tests

Understanding Users' Work:  Ethnography

  • Ethnography stems from anthropology, and literally means 'writing the culture' - a form of participant observation.  However, it is difficult to use the output of ethnography in design.  Design is concerned with abstraction and rationalization, while ethnography is concerned with minute details, so it is difficult to harness the data gathered from ethnography so that it can be used in design.
  • Framework for using ethnography in design:
    • distributed coordination:  distributed nature of the tasks / activities and the means / mechanisms by which they are coordinated
    • plans and procedures:  organizational support for the work, such as workflow models and organizational charts, and how these are used to support the work
    • awareness of work:  how people keep themselves aware of others' work
  • Coherence:  a method offering questions to address these dimensions (above) by presenting the ethnographic study data as a set of "viewpoints" and "concerns"

    Distributed coordination:
      How is the division of labor manifested through the work of individuals and its coordination with others? 
    Plans and procedures:
      How do plans and procedures function in the workplace? 
    Awareness of work:
      How does the spatial organization of the workplace facilitate interaction between workers and with the objects they use?

Contextual Design:  developed to handle data collection and analysis from fieldwork for developing a software-based product (used commercially quite widely)  There are seven parts to Contextual Design:

1.  Contextual Inquiry
2.  Work Modeling
3.  Consolidation
4.  Work Re-design
5.  User Environment Design
6.  Mock-up and test with customers
7.  Putting it into Practice

1.  Contextual Inquiry:  an approach to ethnographic study where the user is an expert, and the designer is an apprentice.  It is a form of interviewing, but takes place at the users' workplace / workstation, and is often 2-3 hours long.  Four main principles of contextual inquiry are:

1.  Context:  see workplace and what happens
2.  Partnership:  user and developer collaborate
3.  Interpretation:  observations interpreted by user and developer together
4.  Focus:  project focus to help understand what to look for

2.  Work Modeling:  In interpretation sessions, models are drawn from the observations.  Five models are:

  • Work flow model:  the people, communication and coordination
  • Sequence model:  detailed work steps to achieve a goal
  • Artifact model:  the physical 'things' created to do the work
  • Cultural model:  constraints on the system from organizational culture
  • Physical model:  physical structure of the work, e.g. office layout

3.  Consolidation:  each contextual inquiry (one for each user / developer pair) results in a set of models, which need to be consolidated into one view of 'the work'

  • Affinity Diagram:  organizes interpretation session notes into common structures and themes
    • Categories arise from the data
    • Diagram is built through induction
  • Work models consolidated into one of each type

Participatory Design:  (Scandinavian background) emphasizes social and organizational aspects - based on study, model-building and analysis of new and potential future systems.  Aspects to user involvement include:

  • Who will represent the user community?  Interaction may need to be assisted by a facilitator
  • Shared representations
  • Co-design using simple tools such as paper or video scenarios
  • Designers and users communicate about proposed designs
  • Cooperative evaluation such as assessment of prototypes

Benefits of Participatory Design:  “Computer-based systems that are poorly suited to how people actually work impose cost not only on the organization in terms of low productivity but also on the people who work with them. Studies of work in computer-intensive workplaces have pointed to a host of serious problems that can be caused by job design that is insensitive to the nature of the work being performed, or to the needs of human beings in an automated workplace.”  [Kuhn, S. in Bringing Design to Software, 1996]

PICTIVE:  Plastic Interface for Collaborative Technology Initiatives through Video Exploration:  Intended to empower users to act as full participants in design

Materials used are:

  • Low-fidelity office items such as pens, paper, sticky notes
  • Collection of (plastic) design objects for screen and window layouts

Equipment required:

  • Shared design surface, e.g. table
  • Video recording equipment

Before a PICTIVE session:

  • Users generate scenarios of use
  • Developers produce design elements for the design session

A PICTIVE session has four parts:

What is usability? One distinction is easy; the difference between useful and useable. Useful means that the system does what it should. Usable means that it is easy to do it. But there is no usability without usefulness and no usefulness without usability. So the distinction is not so clear. This illustrates one difficulty with defining usability.

Another difficulty is what is usable to one user my not be to another user. Consider the command line interface for controlling the operating system. It is very usable by system administrators, but unusable by mortals like me. So usability should always be considered in context with the user.

Another difficulty is that it tends to become just a laundry list, rather boring and uninformative.

Let us try to compare how well current UI achieve their usability goals. Also, we should delineate what particular usability concerns there are for mobile devices and apps.

Usability Goals (Pragmatic Goals)

Preece, Rogers and Sharp (Interaction Design) propose 6 usability goals:

  • Effective: effective to use
  • Efficient: efficient to use
  • Utility: have good utility
  • Learnable: easy to learn
  • Memorable: easy to remember how to use
  • Safe: safe to use

Some other usability goals added by me and classes:

  • Ergonomics: especially for smartphones, can be used in different environments…
  • Accessibility: can be used by many different people, even people with disabilities.

The above usability goals are pragmatic or operational goals. Preece, Rogers and Sharp (Interaction Design) propose that designers evaluate how well a design achieves these usability goals by asking questions directed at the design. The questions should not be general, such as “Is the design effective?” Rather, the question should be more specific, such as “Can users of a filing systems understand the categories and use them to find information?”

Effectiveness and utilities refer to usefulness. Effectiveness is an overall measure of how well the system performs. “Can users use the system to do the work they need to do?” Efficiency is more akin to usable and can refer to the time required to use the interface and the likelihood of making errors using the system. Amazon’s single button shopping is an example of design driven by efficiency. ” Can experience users be productive using the system?” Utility is a measure of the correct functionality and breadth of functionality. Most good software is driven by utility, for example word processors have nearly all the features required to compose and format text documents. “Does the system provide all the functionality that users needs?”

Because the computer is a new cognitive tool, learnability has been a concern of UI designers. Designers have been plagued with trying to design “familiar and natural interfaces” that can be learned without reading a manual.   But learnability depends on functionality; not all interfaces should be expected to be immediately usable. A programming language is a UI, how many hours did you spend learning it? A question that designers can ask, “Can users figure out what to do by exploring the interface?”

Memorable is how easy is it to remember how to use an interface after the user has experience with the system. Memorable is related to learnability and has generated GUIs with menus and icons, but the menu names and icons images need to be appropriate for them to be memorable. “What kind of support does the system have for remembering how to do tasks, especially infrequent tasks?”

Safety is protecting the users from dangerous errors, for example losing all the user’s data or protecting the user’s confidential information. Safety can also refer to how users recover from errors. Safety is a little considered usability goal. An example of designing by safety is not putting the delete button next to the save button. Another example, is providing users various ways to recover from errors, both by reverting to a priority state or progressing the system to the correct state. For example in a word processor, the write can use control-z to correct, back button, or retype to correct mistakes. “What kind of errors can users make and how can they recover from the mistake?”

A little thought of usability is ergonomics. “Is the device physically safe and comfortable to use?” I believe that new devices, smart phones and tablets, should drive designers to consider ergonomics. For example the designers should ask, “Can the user perform the operations in the work environment?” “Can the user press buttons wearing gloves?”

Consider some interfaces and how they address these usability goals:

  • Word processor
  • Operating system interface (the alternative between linux command line interface and Windows control panel)
  • Spread sheet software
  • Programming languages and IDE
  • Shopping Websites

Spend some time identifying interface elements that successfully address usability goals and failures in achieving usability goals.

What pragmatic usability goals are important for mobile devices and especially our apps?

  • Learnability – many apps on the device without help documentation and users generally do not have time.
  • Efficient – app user generally do not have time to perform complex task.
  • Ergonomic – Mobile devices are handheld and have small screens.

User Experience Goals (Subjective Goals)

Preece, Rogers and Sharp (Interaction Design) identify UI goals that are more than pragmatic goals and call them user experience goals. User experience goals is a new aspect of design driven by the video games and ubiquitous devices. Some positive user experience goals are:

  • Satisfying
  • Enjoyable
  • Fun
  • Entertaining
  • Helpful
  • Motivating
  • Aesthetic
  • Supports creativity
  • Rewarding
  • Emotionally fulfilling
  • Informative
  • Support social networking
  • Support society

The list above is not exhaustive. In their new versions of Interaction Design, Preece, Rogers and Sharp have added to the list of user experience goals and include negative experiences such as:

  • boring
  • frustrating
  • bosy
  • annoying
  • cutesy

Preece, Rogers and Sharp propose that the user experience goals be used as adjectives to describe the experiences of a user using the interface. User interfaces should not try to appeal to all possible experience, but it should provide a positive experience or users will not continue using it.

Let us list some software applications that address some experiential goals:

  • Are there any experience goals in a word processor? Should there be?
  • Consider the bell in Quicken after making an entry, is this addressing user experience.
  • Computer games are obvious.
  • Websites?

What user experience goals are important for our apps?

  • Helpful – Especially are apps are meant to be helpful
  • Motivating – we want users (which might not really want to be on the field trip) to use the app
  • Rewarding – Rewarding will ensure that users continue using, how can reward the user?
  • Support Creativity – Although our apps constrain the user to performing the task correctly, we hope that users will feel creative during the pursuit of data while recording the data.
  • Enjoyable – At least we do not want the app to be frustrating.
  • Informative

Usability Design Principles (General Rules)

Another approach is to list usability principles, abstractions or general rules for good usable interface design. In his famous book, “The Design of Everyday Things,” Don Norman list 6 usability principles:

  • Visibility – visibility of functions and information
  • Feedback – as a result of an interaction
  • Constraints – restricting interactions
  • Mapping – mapping of controls to their function
  • Consistency – similar operations and tools for similar tasks
  • Affordance – property of a object that allow users to know the how to use the object

Can we add to the list above? These maybe more associated with user experience goals.

  • Flexibility – perform the same the task in different ways or different order
  • Control – Does the system hold the user prisoner or does the user have control
  • Robustness – Can the user perform errors and recover from errors
  • Responsiveness – does the UI respond correctly and timely
  • Predictability – Can the user predicate how the interface will perform?
  • Synthesizability – does the user construct the proper model or metaphor of the system?

Again let us list some good and bad examples of Usability Design Principles for each of the following:

  • Door affordances, also fire warning over elevator control
  • Typing and feedback
  • Uploading a file and feedback
  • Context menus and visibility
  • Graying (deactivating) menu items and constrains
  • Physical plugs and constraints
  • Mouse button and scroll wheel affordances
  • Inoperative menu items graying constraints selection and are visible
  • Telephone company provided answering service and poor visibility of the number of messages.
  • Mapping of arrow keys
  • Web page constancy
  • Menu bar consistency. In Microsoft, why do I always go to ‘Insert’ to insert a table?
  • others?

What design principle is important for mobile apps?

  • Visibility – the user should see what the need to do.
  • Feedback – the user should be aware of what they have done.
  • Affordance – because screen resolution is low, buttons need to be clear. Because our users will not have much time to learn the app, objects to act on should have good affordance.
  • Responsiveness
  • Robustness – the user should always be able to recover for errors, especially when use a new app.
  • Constraints – mobile apps generally do not offer many ways to do a task.
  • Consistency – This is a principle that help user learn the system and not to perform errors.
Categories: 1

0 Replies to “Interaction Design Preece Assignment 2”

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *