9/28/2017

Programmer VS User

GOAL-ORIENTED
INTERACTION DESIGN
FENTY EKA MUZAYYANA AGUSTIN

• Programmers are good at designing the in

side of software, interaction designers sho
uld design the outside.
ALLPPT.com _ Free PowerPoint Templates, Diagrams and Charts

Interaction Design VS Interface Design interaction design basics

• design:
• Interface design suggests an interface b – what it is, interventions, goals, constraints
etween code on one side and users on t • the design process
– what happens when
he other side, passing messages between • users
them. It gives programmers a licence to – who they are, what they are like …
code as they please, because the interfac • scenarios
– rich stories of design
e will be slapped on when they are done • navigation
. – finding your way around a system
• Interaction design refers to function, be • iteration and prototypes
– never get it right first time!
haviour, and final presentation.

interactions and interventions

design interactions not just interfaces

not just the immediate interaction
e.g. stapler in office – technology changes interaction style
• manual: write, print, staple, write, print, staple, …
• electric: write, print, write, print, …, staple what is design?

designing interventions not just artefac

ts
not just the system, but also …
• documentation, manuals, tutorials
• what we say and do as well as what we make

1
 9/28/2017

what is design? golden rule of design

achieving goals within constraints

understand your materials
• goals - purpose
– who is it for, why do they want it
• constraints
– materials, platforms
• trade-offs

for Human–Computer Interaction The process of design

understand your materials what is

wanted scenarios
task analysis
guidelines precise
• understand computers interviews
ethnography
principles specification
analysis
– limitations, capacities, tools, platforms

understand people
design
what is there
• vs. implement
what is wanted and deploy
– psychological, social aspects
dialogue
– human error notations architectures

and their interaction …

evaluation documentation
• heuristics prototype help

Steps … … but how can I do it all ! !

• requirements
– what is there and what is wanted …
• limited time ⇒ design trade-off

• analysis
– ordering and understanding • usability?

• design – finding problems and fixing them? 

– what to do and how to decide
– deciding what to fix?

• iteration and prototyping • a perfect system is badly designed
– getting it right … and finding what is really
– too good ⇒ too much effort in design
needed!

• implementation and deployment

– making it and getting it out there

2
 9/28/2017

Goal-oriented Interaction Design Goals VS Tasks

• There may be multiple ways of achieving a
goal
• Designing software based on an un • Tasks are not Goals
derstanding of human goals. – Goal: Get something to eat.

• What is a goal? – Task : Go to the restaurant around the corner. Or

–
• A goal is a final purpose or aim, an
Task : Call the pizza deliver y ser vice. Or

– Task : Go to the supermarket, buy ingredients, an

objective. d cook for myself.

• Tasks are particular ways of accomp • Tasks are a means to an end, not an end in t
hemselves.
lishing a goal. • Tasks change with technology, goals do not

Task VS Technology Personal and Corporate Goals

• Tasks change with technology, goals

do not:
• Year 2000 Year 3000
– Goal: Get to work. * Goal: Get to work
– Task: Take the tram. * Task: Press The
– Task: Take a taxi. teleport Button • Both are the highest expression of goals for
– Task: Drive in traffic * Task: Fly with the their respective owners (both must be taken
jet pack into account).
• But people are doing the work, and their pe
rsonal goals will always take precedence (alt
hough they are rarely discussed, precisely b
ecause they are personal).

System Centered Design

The Interaction Design Process
• System Centered Design 1. Interview users
– What can be built easily on this platform? 2. Create personas
– What can I create from the tools available? 3. Define their goals
– What do I as a developer find interesting to
work on? 4. Create concrete scenarios
– What do I as a developer think users need? 5. Move to a design solution

3

The Design Team
Two designers in core team:
• Designer: generates ideas, leads the
process.
• Design Communicator: articulates
half-formed ideas, writes design spec
. • The term “user” is elastic and is liable
Personas
• Definisi Personas (prototypical user)
 very specific user.
– An imaginary, but very specific, example
of a particular type of user.
– Not “real”, but hypothetical.
• A persona is used to role-play throu
gh an interface design and check if t
he design would meet the needs of s
uch a user.
Finding Primary and Secondary
Define the Persona Precisely
• Specify a name, age, face, and quirky,
believable detail.
• For faces, use stock photos from CD-RO
M or the internet, or photographs taken
during user interviews.
• It is more important to define the perso
na in great and specific detail, so that it
cannot wiggle under the pressure of de
velopment, than that the persona be ex
actly the right one.
9/28/2017
User Centered Design
• The design is based upon a user’s:
– abilities and needs
– Context
– Work
– Tasks
to be bent and stretched by the progr
ammer to the needs of the moment.
A Good Persona
• A good persona is not “average”, but t
ypical and believable.
• If the set of users interviewed were so
mehow plotted according to their char
acteristics as a cloud of points, the be
st ones to base personas on would be
the ones around the edges.
• If our design satisfies the hard cases a
round the edges, the ones in the mid
dle should be able to use the interfac
e as well.
Personas
• Start off with a larger set of personas.
• Combine or throw out redundant per
sonas.
• A primary persona will not be satisfie
d with a design for someone else.
– If there are multiple personas with radica
lly dierent needs, there are multiple prim
aries.
– Each primary gets their own interface.
• A secondary persona is mostly satisfi
ed with a primary’s interface, but has
a specific additional need.
4
 9/28/2017

Contoh Persona Contoh Secondary Persona

Contoh Device Contoh Desain

Defining Scenarios for each

Defining Goals for each Persona Persona
• A scenario is a precise description of a per
• Goals and personas co-exist. A pers sona using an interface to achieve a goal.
ona exists to achieve his goals, a g – Daily Use Scenarios : the primar y actions the

oal exists to give meaning to a pers

user will perform. These need the most robu
st design.

ona. – Necessary Use Scenarios : More occasional, i

nfrequent actions, which are necessar y from t

• Define the goals of each persona. ime to time.

– Edge Case Scenarios : Loved by programmer

s, these can largely be ignored during the de
sign process.

• As the design progresses, play act the pers

onas through the scenarios to test the vali
dity of the design.

5
 9/28/2017

Moving to a Design Solution

Parallel Design
• If time and resources
allow, explore design
alternatives.
• Have several design
teams work indepen
dently, then compare
draft designs