Inmates Part III: Eating Soup with a Fork

1
Inmates Part III Eating Soup with a Fork

• Ch. 6 The Inmates are Running the Asylum
• Ch. 7 Homo Logicus
• Ch. 8 An Obsolete Culture

2
The Inmates are Running the Asylum

• Our products share a common frustration-inducing
  unpleasantness
• This recurrent pattern is due to the inadvertent
  hijacking of the industry by technical experts
• Despite all the marketing rhetoric, the form of
  our products is really determined by those people
  least equipped to do so

3
Driving from the Backseat

• No matter how early in the development process
  specifications are drafted, they cannot
  substitute for interaction design
• No matter how hard they try, programmers cannot
  consistently arrive at a successful design
• Methods, training, and aptitude are wrong for the
  job
• Conflict of interest between serving the users
  needs and making their programming job easier

4
Computers Versus Humans
Computers
Humans

• Incredibly fast
• Error-free
• Deterministic
• Apathetic
• Literal
• Sequential
• Predictable
• Amoral
• Stupid

• Incredibly slow
• Error-prone
• Irrational
• Emotional
• Inferential
• Random
• Unpredictable
• Ethical
• Intelligent

5
Development of a Culture

• It used to be that computers were small,
  expensive, slow and weak
• Programmers focused on maximizing the
  productivity of the mainframe
• Now, computing is cheap and should be used for
  the user
• But the programmer still focuses on the computer

6
Cannot Do Both

• The inside of software must be written with
  technical expertise and sensitivity to the needs
  of the computer
• Programmers
• The outside of software must be written with
  social expertise and sensitivity to the needs of
  people
• Interaction Designers
• It is nearly impossible for a person to be
  effective in the literal-deterministic-sequential
  behavior of computers and also in the
  irrational-unpredictable-emotional world of
  humans
• Every software engineer thinks that he can do
  both
• This is simply not true
• A successful product must be engineered AND
  designed

7

• Software engineers have a poor track record in
  making software powerful and pleasurable
• Engineering methods cannot solve the problem
• Engineering methods are one of the root causes of
  the problem

8
Homo Logicus
9
Homo Logicus

• Programmers Homo logicus are a species
  distinctly different from Homo sapiens
• They trade simplicity for control
• They exchange success for understanding
• They focus on what is possible to the exclusion
  of what is probable
• They act like jocks

The Jetway Test
10
Trade Simplicity for Control

• Programmers control is their goal, and
  complexity is the price they will pay for it
• Normal humans simplicity is their goal, and
  relinquishing control is the price they will pay
• For software-based products, control translates
  into features
• Example Windows Find File function
• Programmers options allow optimization of search
• Normal humans options allow opportunity for
  failure
• The extra compute time is not an issue

11
Trade Success for Understanding

• Did you ever take a clock apart to see how it
  worked?
• Did you ever get it working, again?
• Was the experiment a success?
• The goal of Homo logicus is to understand how
  their clock works
• Willing to sacrifice a working clock to achieve
  that goal
• The goal of Homo sapiens is to know what time it
  is
• Willing to forego knowing what makes the clock
  tick

12
Implementation Model vs. User Model

• Programmers drive to understand makes them
  instinctively create interaction that closely
  follows the internal functioning of the product
• Comfortable for them when they understand how
  the software works, they will understand how to
  use it
• Implementation Model
• Normal users want to see the software reflect
  their goals
• Do not need to understand how it works
• Implementation model interfaces impose an
  unnecessary burden of understanding

13
What is Possible, not What is Probable

• Programmers must deal with all possibilities
• Boundary conditions, exceptional cases
• Fanatic preparation for the possible has the
  inevitable consequence of obscuring the probable
• Programmers tend to crowd their products with
  features that might, someday, sometime be useful
• They crowd out the features that will, everyday,
  always be useful

14
Programmers Act Like Jocks

• Jock strength and capability, but immaturity,
  egotism, and competition
• Programmers are zealous competitors, and really
  good programmers are as cutthroat as any Olympic
  hopeful
• The physical jock learns that physical prowess
  does not work in the business world
• They become mature, good citizens
• The mental jock learns that the ability to
  mentally dominate another person gains tremendous
  power in the adult world of the information age
• There is no maturing process to temper their
  exercise of power
• They see nothing wrong with humiliating users
  with dauntingly complex products
• They laugh at the lusers

15
An Obsolete Culture
16
Reusing code

• Engineers value programming efficiencies more
  than user needs
• Use it because it exists, not because it is right
• For example, our desktop software has so many
  menus and dialog boxes because the operating
  system and development tools provide pre-written
  code modules for these functions
• Direct manipulation is more user-effective, but
  there is little pre-written code

17
The Common Culture

• The culture of software development has a
  reverence for technical skill
• And it is reinforced by development managers, who
  were once programmers
• Example the Microsoft Explorapedia development
• Fred Moody, I Sing the Body Electronic
• Programmers disdain for designers
• There are programmers and there are lesser
  people, and those lesser people cannot possibly
  hope to influence the product development cycle
• Microsoft is successful
• But one cannot copy its success by copying its
  culture

18
Cultural Isolation

• Programmers rarely interact with normal users
• They interact with power users
• Product managers rarely interact with normal
  users
• They interact with beginners
• Technical support usually interacts with normal
  users
• But tech support are lesser people
• Programming is an isolated activity with a lot of
  responsibility
• They do not see that others also have skin in the
  game
• They dismiss design and design processes

19
The Process is Dehumanizing, Not the Technology

• Technology is not dehumanizing
• It is the people who administer the technology
  who dictate the effect
• Interactive systems do not have to be
  dehumanizing
• We have to revamp our development methodology so
  that the humans who ultimately use them are the
  primary focus
• Design our interactive products completely before
  any programming begins
• Turn the responsibility for design over to
  trained interaction designers

20
Enough with the complaining. What should we do?

• Interaction Design is Good Business
• Ch. 9 Designing for Pleasure
• Ch. 10 Designing for Power
• Ch. 11 Designing for People
• Getting Back into the Drivers Seat
• Ch. 12 Desperately Seeking Usability
• Ch. 13 A Managed Process
• Ch. 14 Power and Pleasure