Interaction design involves understanding how users interact with technology over time within a specific context. Early designs focused on "operating the machine" but the field has evolved to focus more on how people perform tasks and experience technology as part of their daily lives. Effective interaction design considers contextual factors, user activities, and aims to make experiences useful, usable and pleasurable.

1. Designing Structure
Interaction Design

3. interaction design
By marc rettig
marcrettig.com
Then edited by christina
history in a teeny
little nutshell
Originally presented at
carnegie
and shrunk teenier
mellon
universityon 2 april 2004
By mrettig@well.com
and remixed by
christina
http://www.slideshare.net/mrettig/interaction-design-history

4. Consider these planes (an ancient tool):
their designers sought fitness for use, ease
of use, good control, long-lasting materials,
a good feel in the hand, efficiency of
operation, precise adjustment. In use over
time, these tools come to be loved by their
owners.
operate the machine

5. pre-computer
Before computers, there wasn’t “interaction design.”
But most of the qualities we seek have been valued
through the ages.
• useful
• usable
• desirable
• affordable for the right people
• appropriately complex
• appropriately styled
• appropriately transparent in function and use
• appropriately adaptable, extensible, malleable
• overall, having “good fit” with people, context,
activity, result

7. With computers
When programmable, interactive machines first appeared, the creators of their
controls, their interfaces, emphasized the goal of “operating the machine.”
operate the machine

8. characteristic statement of the time
people are seen
as components The Five Elements of System Design
in a system of personnel selection
production personnel training
machine design
job design
environmental design

9. a current statement of the goal of
“human factors”
Rettig’s
summary Good Designs:
• design against misuse,
“minimize the unintended uses, and abuses
damage and • design for all sizes, shapes,
inconvenience” attitudes and personalities people

10. input and output: people adapt to the
machines
punch card,
80 columns, to hold 80
characters or numbers
paper tape, also encoding
characters with holes.
For fun, go make images of punch cards that say anything you want:
http://www.facade.com/legacy/punchcard

11. batch processing: feed it cards, wait
while it runs
What you used to do
punch a deck of cards; take
the cards to a little window,
hand them to the operator;
she puts them in line with
everyone else’s jobs; when
it’s your turn she puts your
cards in the hopper and
pushes “RUN”; your program
works or it doesn’t; an hour or
twelve later, you pick up your
cards and (hopefully)
printout at the same little
window.
What you do now
double-click an icon, see
what happens immediately.

12. command line interfaces
Very efficient once you
learned them. At least the
good ones were / are. Of
course they still exist, and
have finally come to your
Macintosh!
Still, the emphasis is very
much “operate the
machine.”

13. “user friendliness”
“User Friendly” was a huge
buzz phrase for years. Early
on, it meant things like
providing clear help and
easy to remember command
names. A great and still
relevant book from the time:
Paul Heckel’s Elements of
Friendly Software Design. Still
available from Amazon.

14. in the meantime, a few people were
thinking differently
mouse
Doug Englebart
1964
A landmark event in the
history of interaction design:
Doug Englebart’s 1968 demo
at SRI. He demonstrated
most of the ideas we
associate with modern desk-
top computing: the mouse
hypertext, objects in the
interface, dynamic file linking,
and even two people at
different locations
communicating over network
audio and video. This work
was done from a human-
centered point of view, and
the demo is required viewing.
Watch it, remember it’s 40
years ago, and think about
how progress is made in this
field. Wanna see the demo? sloan.stanford.edu/mousesite/1968Demo.html

15. • shift in focus from controlling the computer to
using applications and tools
• trying to make it so people have to adapt less
to use the machines’ capability
• design is still done mostly by engineers, few
specialists
• still mostly thought of as “computer human
factors”
use the software
operate the machine

16. a tool for home and small business
calculations
visicalc
Dan Bricklin
1979
Finally people had a reason
to buy a home computer
(specifically, an Apple II): so
they could use VisiCalc, the
first spreadsheet.
THE place to learn about Visicalc: www.bricklin.com/visicalc.htm
Download a working version!

17. Interface and interaction ideas that
survived 25 years (so far)
As Dan Bricklin points out, VisiCalc’s design has lived long:
“It was interactive in a WYSIWYG way:
• Point to change a value
• Instant automatic recalculation based on formulas stored in
the cells referencing other cells
• Scroll left/right/up/down
• The input, definition, formatting and output were all
merged into a natural, program-by-example interface
…
• Labels and formulas distinguished by first character typed
• Minimal-keystroke formula entry…. The goal here was to
make it worth using the first time you needed an answer in
a way that would let you benefit the next time by just
changing a few values and recalculating. If the input style
did not let you "teach" the computer by doing the
calculation, people may not have used it.
• A1, B1, SUM(A1..A7)
• Realtime scrolling
• Numeric and text formatting
• Status and formula lines”
www.bricklin.com/visicalc.htm/firstspreadsheetquestion.htm

18. a tool for writing
wordstar
Seymour Rubenstein &
John Barnaby
1979
WordStar had a very
complicated interface, but
once you invested the time
to learn it, it was very
powerful. Now there was
another reason to buy a
home computer: to create,
format, store, and edit text
documents.
Find WordStar history here: http://www.wordstar.org/wordstar/history/history.htm

19. wordstar
quick reference card
A few WordStar commands
(^ indicates one should hold
down the Ctrl key)
Interested? Purchase a WordStar command emulator
package for Microsoft Word by visiting www.wordstar.org

20. • wordstar was so complex yet so popular, it invited
both complaint and competition
• the success of Lotus 1-2-3 over Visicalc was partly
due to ease of use and appropriate power (tip o’ the
hat to Mitch Kapor); that and its enterprise-
penetrating platform, the IBM PC
• its use in large companies led to an emphasis on
ease of learning, ease of use, reduced errors, saved
time
• this eventually led to a professional emphasis on
people doing a task rather than “a tool with good
controls”
perform a task
use the software
operate the machine

21. GOMS
• Goals are what the user intends to Developed in 1983 by Stuart
accomplish. Card, Thomas P.
Moran and Allen Newell
• Operators are actions that are inThe Psychology of Human
performed to reach the goal. Computer Interaction.
• Methods are sequences of
operators that accomplish a goal.
There can be more than one
method available to accomplish a
single goal; if this is the case
• Selection rules are used to describe
when a user would select a certain
method over the others.

22. the mac taps into pent-up desire for
ease and pleasure of use
Think of a world full of command-line interfaces…
Then, during the 1984 Superbowl, you An athletic woman in colorful clothing …which she throws into the screen,
see the first commercial for the runs into the auditorium, carrying a smashing the image and voice of the
Macintosh (directed by Ridley Scott of huge hammer… status quo.
Blade Runner fame). A crowd of
solemn men is gathered in a gloomy
auditorium, listening to a ranting
bureaucrat on a huge screen.
hello.

23. All 39 pages of advertising that Apple bought in a 1984 issue of newsweek are available here:
http://www.aci.com.pl/mwichary/computerhistory/ads/macnewsweek

24. the software design manifesto
Mitch Kapor “The Roman architecture critic Vetrivius advanced the
1990
notion that well-designed buildings were those which
I don’t know that this was a
landmark event in the whole
industry’s eyes, but Mitch
exhibited firmness, commodity and delight. The same
Kapor’s Software Design
Manifesto was a clear might be said of good software. Firmness: a program
articulation of the idea that
making useful, usable,
delightful software is a design
should not have any bugs which inhibit its function.
problem, not an engineering
problem. This is only a small
extract here. The whole thing
Commodity: a program should be suitable for the
has both historical importance
and modern currency. purposes for which it was intended. Delight: the
experience of using the program should be a pleasurable
one. Here we have the beginnings of a theory of design
for software.”
www.kapor.com/homepages/mkapor/Software_Design_Manifesto.html

26. present

27. experience
live, learn, work, play
perform a task
use the software
operate the machine

28. • after twenty years of trying to help
people perform tasks, we realized
success depended on expanding the
scope of view
• most good work now involves an effort
to fit context of use, characteristics of
individuals, patterns of life
experience • most good work now attempts to go
live, learn, work, play
beyond expressed need to latent or
masked needs
perform a task
use the software
operate the machine

29. manage a
household compose music
run a business
experience
live, learn, work, play
learn math
perform a task
buy, use, &
maintain a car
use the software
immerse in a fantasy
operate the machine

30. interface
…interface design,
which is concerned
with the person in
front of the screen,
with understanding
and communication.
But interface design
often takes a fairly
static view of things…

31. interaction
When we add time,
we see the
conversation back
and forth between
people and
machines. We
design the
language for these
conversations, we
contribute
something to the
context in which
they happen.

32. design to support a person doing an
activity in context
To do a good job of interaction design, we have to
understand as much as we can about the context, the
activity, what else is going on, where people’s attention
is focused, what happens before and after, what their
goals are, and so on.

33. Now to your regularly scheduled lecture
BYE MARC!

34. From Dan’s fine book, Designing for Interaction
APPROACHES TO IXD

35. Types of Interaction Design
Table 2.1. Four Approaches to Design
Approach Overview Users Designer
User-centered design Focus on user needs The guides of Translator of user
and goals design needs and goals
Activity-centered Focus on the tasks Performers of Creates tools for
design and activities that the activities actions
need to be
accomplished
Systems design Focus on the Set the goals Makes sure all the
components of a of the system parts of the system
system are in place
Genius design Skill and wisdom of Source of The source of
designers used to validation inspiration
make products
From Dan Saffer’s Designing for Interaction

36. UCD
You’ve been
soaking in it!
Many designers don’t
think there is another
approach

37. ACD
• Activity focused design
• Activity : Purpose : Tasks
• Task analysis
• Task suggests tools; i.e.
“turn on” suggests
a switch
The gardener might have a goal (to have
a tidy yard) but the purpose of raking is
simple: to collect leaves. ACD would
focus on collecting leaves.

38. From a
McDonald’s
patent
application on
sandwich making

40. The critique of ACD: does it limit?
If I ask you to
make a vase
you might
come up
with a vast
number of
variations of
form, but it
would mostly
look like one
of these

41. design a way to enjoy flowers
But if I ask you to
think of a way to
enjoy plants and
flowers?

42. DO
TASK ANALYSIS

43. System Design
• Focus is on a system, not a user or task
• All elements are cataloged
• Relationships are defined

44. Heating System
• Goal. This is not the users’ goal, but rather the goal of the system as a whole, which can be drawn from user goals. The goal
states the ideal relationship between the system and the environment it lives in. In a heating system, an example of a goal
may be keeping your house at 72 degrees Fahrenheit.
• Environment. Where does the system “live”? Is it digital or analog or both? The environment in the heating system example
is the house itself.
• Sensors. How does the system detect changes in the environment? A heating system has a thermostat with a thermometer
(Figure 2.3) to detect temperature changes.
• Disturbances. Changes are called disturbances; these are elements in the environment that change the environment in both
expected and unexpected ways. In the heating system example, a disturbance is a drop or rise in temperature.
• Comparator. The comparator embodies the goal within the system. It compares the current state (the environment) to the
desired state (the goal). Any difference between the two is seen by the system as an error, which the system seeks to
correct. In the heating system example, the comparator can be a tiny computer or a mercury switch that compares what the
sensor tells it about the environment (for example, “72 degrees...72 degrees...72 degrees...71 degrees...71 degrees”) to the
goal (“Keep the house at 72 degrees”).
• Actuator. If the comparator says, ah, something is different (an “error”) by examining the data coming from the sensor, it
sends a command to the actuator (in this case, the boiler). Actuators are a means of making changes (output) to the
environment. In this case, the actuator makes heat.
• Feedback. With output comes feedback. Feedback is a message about whether or not a goal was achieved or maintained—
whether or not an error was detected. In this example, feedback would report either that the house is still at 71 degrees or
that is now at 72 degrees and the heater can be turned off.
• Controls. Controls are means of manually manipulating the parts of the system (except the environment). In this example,
you use a control to set the temperature you want the house to be. Another control might trigger the actuator and turn the
heat on.
From Dan Saffer’s Designing for Interaction

46. Sitepath (system) Diagramming

47. DO
WHAT IS IN YOUR SYSTEM?

48. Genius Design

49. Jonathan Ives
Intuition is compressed experience

50. This is a trick question
WHICH SHOULD YOU DO?

51. PRINCIPLES

52. Contextual Principles
• What you know about the
context/users/activity. E.g.
– Recipes must be scannable
– User should know where they are in a recipe
– Recipes allow users to find ingredients for
shopping and mise en place by listing them apart
from instructions
• You make them up

53. Tivo Tennants
• It’s entertainment, stupid.
• It’s TV, stupid.
• It’s video, dammit.
• Everything is smooth and
gentle.
• No modality or deep
hierarchy.
• Respect the viewer’s
privacy.
• It’s a robust appliance,
like a TV.

54. Universal Principles
• Direct Manipulation
• Affordances
• Feedback
• Mental Model
• Standards

55. Some Laws
• Fitts’s Law simply states that the time it takes
to move from a starting position to a final
target is determined by two things: the
distance to the target and the size of the
target.

56. Hick’s Law
the time it takes for users to make decisions is
determined by the number of possible choices they
have at one scanning. The user will scan a large list,
and discard half or more of it to focus in on their
choice.
Rule of Large Menus: one large menu is more time-
efficient than several small submenus supporting
the same choices, even if we ignore the time
overhead of moving among submenus.
Exception: very large menus of unorganized items
are harder for a user to parse and subdivide

57. The Magical Number Seven
• Is stupic

58. Law of the Conservation of Complexity
• Larry Tesler
• not stupid
• states that some complexity is inherent in
every process. There is a point beyond which
you can’t simplify the process any further; you
can only move the inherent complexity from
one place to another.

59. The Poka-Yoke Principle
• Poka-Yoke roughly translates in English to
mistake proofing: avoiding (yokeru)
inadvertent errors (poka). Designers use Poka-
Yoke when they put constraints on products to
prevent errors, forcing users to adjust their
behavior and correctly execute an operation.

60. Errors
• Prevent
• Allow fixes
• COMPASSION
• Avoid learned
Dismissal

61. AND NOW FOR SOMETHING
COMPLETELY DIFFERENT

62. Well, I didn’t expect that.

63. And the Mechanics
THE CORE LOOP

64. This is a core loop for a very simple game. I’m actually shocked we don’t map this on other projects. Amazon’s is
Seek, evaluate, buy.

65. Will Wright on Game Design: http://youtu.be/CdgQyq3hEPo Watch 30:27-33:27

66. Backyard Monsters takes the classic tower defense loop (build defense, get attacked, redo) and adds complexity
by letting you also attack and build offensive as well as defensive tools.

67. A remix
AOF WITH JOSH PORTER

68. The AOF Method
1. Defining your Activity
2. Identifying your (Social) Objects
3. Choosing your Features
Courtesy of Joshua Porter. Check out
bokardo.com!

71. 2. Identifying your
Social Objects

72. What are Social Objects?
• Social objects can be ideas, people, or physical
objects.
• By interacting through/with social objects,
people meet others they might not otherwise
know.
• Social objects can be the reason why people
have an interaction or form a relationship.
Joshua Porter (bokardo.com)

74. 3. Choosing your Features

76. DO
PICK ONE OBJECT, LIST VERBS

77. And user stories:
USE CASES

78. First, name all your use cases (or user
stories, or scanrios)

79. Example: Log in Use Case
Login
Brief Description
• This use case describes how a user logs into the Course Registration System.
Basic Flow
• This use case starts when an actor wishes to log into the Course Registration System.The system
requests that the actor enter his/her name and password.
• The actor enters his/her name and password.
• The system validates the entered name and password and logs the actor into the system.
Alternative Flows
• Invalid Name / Password
If in the Basic Flow the actor enters an invalid name and/or password, the system displays an error
message. The actor can choose to either return to the beginning of the Basic Flow or cancel the
login, at which point the use case ends.
Pre-Conditions
• None
Post-Conditions
• If the use case was successful, the actor is now logged into the system. If not the system state is
unchanged.
Next, break it into its component tasks. List positive
first, then list all the scenarios for when things go
wrong under “alternate”

80. I prefer the two column approach, with
user on one side, system on the other.
Note: I do not say “pushes button.” or
the like anywhere: save interface
design for late, just focus on interaction
User System
User inserts card Requests PIN
User enters Pin Displays choices
1. Get balance
2. Withdraw money
3. Make deposit
(1) User selects Get Balance Displays current balance
(2)User selects withdraw System ask the user for an
money amount
User enters an amount Systems checks balance. If <
balance, asks for confirmation

81. Use case tips
• Tip 1. When creating use cases, be productive without
perfection
• Tip 2. Define your use case actors
• Tip 3. Define your "Sunny Day" Use Cases (Primary Use
Cases)
• Tip 4. Identify reuse opportunity for use cases
• Tip 5. Create a use case index
• Tip 6. Identify the key components of your use case
• Tip 7. Name and briefly describe your use case
• Tip 8. Create the use case basic flow
• Tip 9. Create the use case alternate flows
• Tip 10. Produce your use case document
Writing Effective Use Cases (Examples) By Darren Levy
http://www.gatherspace.com/static/use_case_example.html

82. Homework
• One scenarios
• One task analysis
• One object, and all features (optional,
recommended)
• Write a use case
• Portfolio work: Map one key activity for your
site, visually