Inmates Part IV: Interaction Design is Good Business

1
Inmates Part IV Interaction Design is Good
Business

• Ch. 9 Designing for Pleasure
• Ch. 10 Designing for Power
• Ch. 11 Designing for People

Goal-Directed Design
2
Designing for Pleasure Personas
3
Personas

• Develop a precise description of our user and
  what he wishes to accomplish
• How? This is where the tool becomes powerful
• The actual user is a valuable resource, but an
  ineffective persona
• They experience the problem, but they usually do
  not see the solution
• Make up pretend users and design for them
  personas
• Hypothetical archetypes of actual users
• Imaginary, but defined with rigor and precision
• Not made up, rather, discovered through
  research
• Personas are defined by their goals

4
Design for Just One Person

• Consider an automobile for soccer moms,
  carpenters, and junior executives
• Assured failure one vehicle to satisfy all
• Probable success separate vehicle for each
• The features and controls desired of one user are
  barriers to use by other users
• Making 100 of the users 50 happy is a 100
  failure
• Make 50 of the users 100 happy
• Make 10 of the users 100 ecstatic
• Create customer loyalty
• Consider the roll-aboard suitcase and sticky notes

5
The Value of Personas

• Personas allow us to see the scope and nature of
  the design problem
• Personas make it clear exactly what the users
  goals are, so we can see what the product must do
  and can get away with not doing
• The precisely defined persona tells us exactly
  what the users level of skill will be, so we
  dont get lost in wondering whether to design for
  amateurs or experts
• Do not use the concept of the user
• The elastic user does not exist

6
Specific and Hypothetical

• Be specific
• The persona becomes a real person in the minds of
  the developer
• A tangible solidity that puts design assumptions
  in perspective
• Skills, motivation, goals
• Give them a real face
• Defining a persona avoids the possibility of the
  programmer imagining that he is the user
• Hypothetical
• It is too easy to attribute to all users the
  quirks and anomalies of a specific person

7
Precision, Not Accuracy

• Precision of a persona is more important than
  accuracy
• Great and specific detail is more important than
  the persona being the precisely correct one
• Define the core, typical user and their goals
• Avoid edge cases

8
A Realistic Look at Specific Skill Mixes
Power Users
Computer Literate Users
Naïve Users
9
Personas End Feature Debates

• Programmer The user might want to print this
  out
• Interaction Designer Rosemary isnt interested
  in printing things out
• As interaction designers, resolutely insist on
  expressing all design issues in terms of named
  personas
• Never fall back into the user construct
• Eventually, programmers begin to adopt personas
  and referring to them by name
• A watershed event
• (Or, the programmers will never get it, and the
  product will suffer)

10
Cast of Characters

• Every project is unique, and has a unique cast of
  characters
• Three to twelve unique personas
• Dont design for all of them
• Identify primary personas
• Some are defined only to make it clear that we
  are not designing for them
• Create a cast of characters page containing
  personas names, pictures, job description,
  goals, and a telltale quote
• Use it in every meeting and in every deliverable
  document

11
Primary Personas

• At least one primary persona
• The individual who is the main focus of design
• Must be satisfied
• Cannot be satisfied with an interface designed
  for any other persona
• Will require a separate and unique interface
• More than three primary personas is a problem
• Trying to accomplish too much at once

12
Consider the Case Study ofSony Trans Coms
P_at_ssport
13
Designing for Power Goals

• A persona exists to achieve his goals, while the
  goals exist to give meaning to the persona

14
Goals and Tasks

• Goals are the reason why we perform tasks
• Use an interaction for a purpose
• The essence of good interaction design is
  devising interactions that let users achieve
  their practical goals without violating their
  personal goals
• Tasks are not goals
• Goal end condition
• Task process needed to achieve the goal
• Goals are relatively stable tasks change as
  technology changes
• Programming is creation of process tasks

15
Examples

• Jennifer, an office manager, wants her computer
  network to run smoothly
• Goal-directed Show status, interact on-screen
  with trouble spots
• Task-directed set up network, monitor
  performance, reconfigure
• Television news
• Goal-directed always have a presentable news
  cast, then tweak it continuously
• Task-directed build a news cast piece-by-piece

16
Personal and Practical Goals

• Personal goal Ted does not want to feel stupid
• Practical goal Use all those cool features
• Principle of commensurate effort
• Once the interaction makes Ted feel good, he is
  willing to put more effort into tasks because he
  knows he will get extra rewards for it

17
Personal Goals

• Not feel stupid
• (not an easy one for apologists to discuss)
• Not make mistakes
• Get an adequate amount of work done
• Have fun (or at least not be too bored)
• etc.
• Personal goals are simple, universal, and
  personal
• Personal goals always take precedence over any
  other goal

18
Corporate Goals

• Increase profit
• Increase market share
• Defeat competition
• Hire more people
• Offer more products or services
• Go public
• etc.
• The corporation is not doing the work, people are
• Their personal goals are dominant

19
Practical Goals

• Avoid meetings
• Handle the clients demands
• Record the clients order
• Create a numerical model of the business
• etc.
• Bridge the gap between company objectives and
  individual user objectives
• For example, handling clients demands connects
  corporate goal of higher profits to users
  personal goals of being productive
• Of course, software has to have features to
  achieve corporate goals, and users must perform
  tasks
• But if a user fails to achieve users personal
  goals, she cannot achieve the corporate goals
• Happy, satisfied workers are more effective
  workers

20
False Goals

• False goals protect the programmer or the
  computer, or they have to do with tasks,
  features, and tools instead of goals
• Save memory
• Save keystrokes
• Run in a browser
• Be easy to learn
• Safeguard data integrity
• Speed up data entry
• Increase program execution efficiency
• Use cool technology or features
• Increase graphic beauty
• Maintain consistency across platforms
• etc.

These may be tasks toward some goal, but they are
not goals
21
Computers are Human, Too

• Humans react to computers in the same way that
  they react to other humans
• To our human minds, computers behave less like
  rocks and trees than they do like humans, so we
  unconsciously treat them like people, even when
  we believe it is not reasonable to do so
• So, if we want users to like our software, we
  should design it to behave like a likeable person
• Software should be polite

22
Polite Software

• Is interested in me
• Is deferential to me
• Is forthcoming
• Has common sense
• Anticipates my needs
• Is responsive
• Is taciturn about its personal problems

• Is well informed
• Is perceptive
• Is self-confident
• Stays focused
• Is fudgable
• Gives instant gratification
• Is trustworthy

23
Consider the Case Study of Elemental Drumbeat
24
Designing for People Task Scenarios
25
Scenarios

• A scenario is a concise description of a persona
  using a software-based product to achieve a goal
• Play the personas through the scenario to test
  the validity of the design and assumptions
• Like actors reading a script think the way the
  persona thinks
• As we develop scenarios, we need to seek out and
  eliminate unnecessary tasks
• Scenarios need to be complete in breadth (start
  to finish) more than depth

26
Focus on Daily Use and Necessary ScenariosAvoid
Edge Case Scenarios

• Daily use scenarios primary actions that the
  actor will perform, typically with the greatest
  frequency
• One or two is typical
• Robust interaction support, including built-in
  teaching, shortcuts, customization
• Necessary use scenarios actions that must be
  performed, but not performed frequently
• Robust interaction, but without the shortcuts and
  customization of frequent use
• Edge case scenarios tasks that are not necessary
  and are not frequent
• Rough interaction design is acceptable

27
Other Useful Design Concepts

• Personas, goals, and scenarios are the main
  elements of the interaction design toolbox
• Others of use are
• Inflecting the interface put the controls and
  data needed for the daily use scenarios
  prominently in the interface, while moving all
  others to secondary locations
• Perpetual intermediates
• Vocabulary
• Brainstorming
• Lateral thinking

28
Consider the Case Study for the Logitech Scanman