designing structure: interaction design

82
Designing Structure Interaction Design

Post on 17-Oct-2014

9.268 views

Category:

Design


4 download

DESCRIPTION

This is a lecture I gave to my User Experience class at General Assembly on Interaction Design. It covers a brief history, and the various approaches that are being used. I borrowed from other sources to a degree, which I have cited extensively.

TRANSCRIPT

Page 1: Designing Structure: Interaction Design

Designing Structure

Interaction Design

Page 2: Designing Structure: Interaction Design
Page 3: Designing Structure: Interaction Design

interaction design history in a teeny little nutshell and shrunk teenier and remixed by christina

By marc rettigmarcrettig.com

Then edited by christina

Originally presented atcarnegiemellonuniversityon 2 april 2004

By [email protected]

http://www.slideshare.net/mrettig/interaction-design-history

Page 4: Designing Structure: Interaction Design

operate the machine

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.

Page 5: Designing Structure: Interaction Design

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

Page 6: Designing Structure: Interaction Design
Page 7: Designing Structure: Interaction Design

operate the machine

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

With computers

Page 8: Designing Structure: Interaction Design

The Five Elements of System Designpersonnel selection personnel training

machine design job design

environmental design

characteristic statement of the time

people are seen as components in a system of production

Page 9: Designing Structure: Interaction Design

Good Designs:• design against misuse,

unintended uses, and abuses

• design for all sizes, shapes, attitudes and personalities people

a current statement of the goal of “human factors”

Rettig’s summary

“minimize the damage and inconvenience”

Page 10: Designing Structure: Interaction Design

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

Page 11: Designing Structure: Interaction Design

batch processing: feed it cards, wait while it runs

What you used to dopunch 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 nowdouble-click an icon, see what happens immediately.

Page 12: Designing Structure: Interaction Design

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.”

Page 13: Designing Structure: Interaction Design

“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.

Page 14: Designing Structure: Interaction Design

in the meantime, a few people were thinking differently

mouseDoug Englebart1964

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

Page 15: Designing Structure: Interaction Design

• 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

Page 16: Designing Structure: Interaction Design

a tool for home and small business calculations

visicalcDan Bricklin1979

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.htmDownload a working version!

Page 17: Designing Structure: Interaction Design

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

Page 18: Designing Structure: Interaction Design

a tool for writing

wordstarSeymour Rubenstein & John Barnaby1979

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

Page 19: Designing Structure: Interaction Design

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

Page 20: Designing Structure: Interaction Design

operate the machine

use the software

perform a task

• 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”

Page 21: Designing Structure: Interaction Design

GOMS

• Goals are what the user intends to accomplish.

• Operators are actions that are performed to reach the goal.

• 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.

Developed in 1983 by Stuart Card, Thomas P. Moran and Allen Newell inThe Psychology of Human Computer Interaction.

Page 22: Designing Structure: Interaction Design

the mac taps into pent-up desire for ease and pleasure of use

Then, during the 1984 Superbowl, you see the first commercial for the Macintosh (directed by Ridley Scott of Blade Runner fame). A crowd of solemn men is gathered in a gloomy auditorium, listening to a ranting bureaucrat on a huge screen.

Think of a world full of command-line interfaces…

An athletic woman in colorful clothing runs into the auditorium, carrying a huge hammer…

…which she throws into the screen, smashing the image and voice of the status quo.

hello.

Page 23: Designing Structure: Interaction Design

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

Page 24: Designing Structure: Interaction Design

the software design manifesto

“The Roman architecture critic Vetrivius advanced the notion that well-designed buildings were those which exhibited firmness, commodity and delight. The same might be said of good software. Firmness: a program should not have any bugs which inhibit its function. Commodity: a program should be suitable for the 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

Mitch Kapor 1990

I don’t know that this was a landmark event in the whole industry’s eyes, but Mitch Kapor’s Software Design Manifesto was a clear articulation of the idea that making useful, usable, delightful software is a design problem, not an engineering problem. This is only a small extract here. The whole thing has both historical importance and modern currency.

Page 25: Designing Structure: Interaction Design
Page 26: Designing Structure: Interaction Design

present

Page 27: Designing Structure: Interaction Design

use the software

perform a task

experiencelive, learn, work, play

operate the machine

Page 28: Designing Structure: Interaction Design

use the software

perform a task

experiencelive, learn, work, play

• 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

• most good work now attempts to go beyond expressed need to latent or masked needs

operate the machine

Page 29: Designing Structure: Interaction Design

operate the machine

use the software

perform a task

experiencelive, learn, work, play

compose music

run a business

learn math

manage a household

immerse in a fantasy

buy, use, & maintain a car

Page 30: Designing Structure: Interaction Design

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…

Page 31: Designing Structure: Interaction Design

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.

Page 32: Designing Structure: Interaction Design

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.

Page 33: Designing Structure: Interaction Design

BYE MARC!Now to your regularly scheduled lecture

Page 34: Designing Structure: Interaction Design

APPROACHES TO IXDFrom Dan’s fine book, Designing for Interaction

Page 35: Designing Structure: Interaction Design

Types of Interaction DesignTable 2.1. Four Approaches to DesignApproach Overview Users Designer

User-centered design Focus on user needs and goals

The guides of design

Translator of user needs and goals

Activity-centered design

Focus on the tasks and activities that need to be accomplished

Performers of the activities

Creates tools for actions

Systems design Focus on the components of a system

Set the goals of the system

Makes sure all the parts of the system are in place

Genius design Skill and wisdom of designers used to make products

Source of validation

The source of inspiration

From Dan Saffer’s Designing for Interaction

Page 36: Designing Structure: Interaction Design

UCDYou’ve been soaking in it!

Many designers don’t think there is another approach

Page 37: Designing Structure: Interaction Design

ACD

• Activity focused design• Activity : Purpose : Tasks• Task analysis• Task suggests tools; i.e.

“turn on” suggestsa 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.

Page 38: Designing Structure: Interaction Design

From a McDonald’s patent application on sandwich making

Page 39: Designing Structure: Interaction Design
Page 40: Designing Structure: Interaction Design

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

Page 41: Designing Structure: Interaction Design

design a way to enjoy flowers

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

Page 42: Designing Structure: Interaction Design

TASK ANALYSISDO

Page 43: Designing Structure: Interaction Design

System Design

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

Page 44: Designing Structure: Interaction Design

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

Page 45: Designing Structure: Interaction Design
Page 46: Designing Structure: Interaction Design

Sitepath (system) Diagramming

Page 47: Designing Structure: Interaction Design

WHAT IS IN YOUR SYSTEM?DO

Page 48: Designing Structure: Interaction Design

Genius Design

Page 49: Designing Structure: Interaction Design

Intuition is compressed experience

Jonathan Ives

Page 50: Designing Structure: Interaction Design

WHICH SHOULD YOU DO?This is a trick question

Page 51: Designing Structure: Interaction Design

PRINCIPLES

Page 52: Designing Structure: Interaction Design

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

Page 53: Designing Structure: Interaction Design

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.

Page 54: Designing Structure: Interaction Design

Universal Principles

• Direct Manipulation• Affordances• Feedback• Mental Model• Standards

Page 55: Designing Structure: Interaction Design

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.

Page 56: Designing Structure: Interaction Design

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

Page 57: Designing Structure: Interaction Design

The Magical Number Seven

• Is stupic

Page 58: Designing Structure: Interaction Design

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.

Page 59: Designing Structure: Interaction Design

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.

Page 60: Designing Structure: Interaction Design

Errors

• Prevent• Allow fixes• COMPASSION• Avoid learned

Dismissal

Page 61: Designing Structure: Interaction Design

AND NOW FOR SOMETHING COMPLETELY DIFFERENT

Page 62: Designing Structure: Interaction Design

Well, I didn’t expect that.

Page 63: Designing Structure: Interaction Design

THE CORE LOOPAnd the Mechanics

Page 64: Designing Structure: Interaction Design

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.

Page 65: Designing Structure: Interaction Design

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

Page 66: Designing Structure: Interaction Design

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.

Page 67: Designing Structure: Interaction Design

AOF WITH JOSH PORTERA remix

Page 68: Designing Structure: Interaction Design

The AOF Method

1. Defining your Activity2. Identifying your (Social) Objects3. Choosing your Features

Courtesy of Joshua Porter. Check out bokardo.com!

Page 69: Designing Structure: Interaction Design
Page 70: Designing Structure: Interaction Design
Page 71: Designing Structure: Interaction Design

2. Identifying yourSocial Objects

Page 72: Designing Structure: Interaction Design

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)

Page 73: Designing Structure: Interaction Design
Page 74: Designing Structure: Interaction Design

3. Choosing your Features

Page 75: Designing Structure: Interaction Design
Page 76: Designing Structure: Interaction Design

PICK ONE OBJECT, LIST VERBSDO

Page 77: Designing Structure: Interaction Design

USE CASESAnd user stories:

Page 78: Designing Structure: Interaction Design

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

Page 79: Designing Structure: Interaction Design

Example: Log in Use CaseLoginBrief 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• NonePost-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”

Page 80: Designing Structure: Interaction Design

User System

User inserts card Requests PIN

User enters Pin Displays choices1. Get balance2. Withdraw money3. Make deposit

(1) User selects Get Balance Displays current balance

(2)User selects withdraw money

System ask the user for an amount

User enters an amount Systems checks balance. If < balance, asks for confirmation

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

Page 81: Designing Structure: Interaction Design

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

Page 82: Designing Structure: Interaction Design

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