UI%20Development%20Process

1
UI Development Process
2
UI Development process

• Like UI design, this is just once over lightly
• just enough to raise your awareness
• not what this course is about, but if you dont
  know about it, your UI implementations will fail

3
UI development process

• Software engineering has developed quite a bit of
  process for software development
• The bad news is that a lot of it does not work
  well for UI software
• Traditional SE approaches are a flaming disaster
• But need to understand the vocab

4
Traditional SE process

• The Waterfall model
• Not typically advocated anymore, but terminology
  and biases remain
• Requirements specification
• Design
• Coding and unit testing
• Integration and testing
• Operation and maintenance

5
Waterfall model

• Called waterfall model because when you finish
  one phase you are not supposed to go back up
  stream

6
Waterfall model

• Implies that you design once (and get it right)
• Not really possible for UI software

7
Waterfall model

• Obsolete, but many of the parts remain in almost
  any SW process
• Biases from this traditional approach remain
• Also beware that terminology like testing
  doesnt necessarily match what we typically mean
  in UI

8
Requirements specification

• What will the system do?
• What does it need to do to meet the customers
  (users) needs?
• What does the customer (user) want?
• Encode into a spec that drives the next phases

9
Requirements specification

• Requirements analysis is very hard in practice
• users cant tell you what they need
• Writing down a requirements spec is not realistic
  in UI design
• Doesnt mean you shouldnt find out about users
  needs

10
Design

• Architectural design
• high level decomposition
• what are the big pieces, how do they fit together
  to form the whole
• Detailed design
• the littler boxes that go in the big boxes

11
Design

• UI design would be in detailed design (but
  iterated)
• But, UI design doesnt fit very well
• this is mostly about system structure
• UI design is mostly about what the user sees
• often without regard to the system structure that
  makes it happen

12
Coding and unit testing

• Actually write the code
• typically the only part that you get graded on in
  school
• only part you cant skimp on
• where the rubber meets the road
• tends to get a lot of attention
• Test small scale parts (units) to ensure they
  function right

13
An aside on unit testing

• My experience the key to good programming is
  unit testing
• All programmers create tons of bugs
• programming is just hard
• requires holding more details in your head than
  is humanly possible

14
Unit testing

• Trick is to not avoiding bugs
• helps, but at some level not possible
• But finding and fixing them before they get too
  hard to find
• before anybody finds out
• This is what unit testing is for

15
Unit testing

• In reality you dont spend you time writing
  programs
• once you get the hang of it its tedious, but not
  that hard
• You spend your time debugging
• Unit testing is really Preemptive Debugging

16
Unit testing

• Has to do with combinatorics
• one bug in a small area of code is typically
  reasonably easy to find
• two (interacting) bugs not just double
• more like square of difficulty
• three cubes it, etc.
• difficulty also grows non-linearly in area bug
  code be in

17
Unit testing

• Key is to test in small enough chunks that you
  are likely to have at most one bug
• may be very small chunks
• if there is one lesson I would give about
  programming, this is it

18
Now back to our regularly scheduled lecture...
19
Integration and testing

• Typically dont build things in school big enough
  to hit this
• Testing that when you put the pieces together
  they work
• even if units work perfectly, whole may not

20
Testing parts

• Systems testing
• do you think it works
• Verification
• does it match the spec
• Validation and acceptance testing
• does it work to the customer
• does it meet the contract / spec

21
Testing

• Notice that all that testing is about testing of
  the system
• User tests are not really there
• When you user test you find out the requirements
  and/or design were wrong

22
Operation and maintenance

• What happens after its delivered
• the next release
• bug fixes
• new features

23
Waterfall model doesnt work for UI software

• UI requirements and design are very hard
• too hard to get right on the first try
• human beings are just too complex
• just dont know enough to do it from first
  principles
• hidden mental models
• Must iterate the design

24
User centered design

• Put the needs of the user first and foremost

25
User centered design

• Put the needs of the user first and foremost
• Simple characterization
• from Gould Lewis Designing for Usability
  CACM85
• Early focus on users and task
• Measurement
• Iterative development

26
Early focus on users and tasks

• Who the users are
• The nature of the work they will do (and how they
  currently do it)
• Understand users goals as well as cognitive,
  behavioral, and organizational characteristics

27
Early focus on users and tasks

• Specifically Task analysis
• Make lists of task, objects of interest, actions
  on those objects
• Concrete and realistic task scenarios
• Do analysis
• what is likely frequency of task
• what is likely importance of task

28
Measurement

• Early, continual user testing
• Observe, record, and analyze use by real users
  doing real work
• as real as you can (see discussion of prototyping
  below)

29
Iterative development

• Recognize need for iteration and plan for it
• Cycle
• (re)design build
• test
• measure

30
User-centered approach has been around for a long
time

• Above came from 1985 paper
• many other characterizations of it, but this
  still captures it pretty well
• These practices still dont get followed that
  much
• increasing, but not there yet
• Why?

31
Obstacles to user-centered iterative design

• Big reason Impractical
• Iteration is expensive
• Can barely afford to build it once
• even with high levels of resources
• Dealing with this is one of the things this class
  is about
• Good prototyping practice helps a lot

32
Obstacles to user-centered iterative design

• Competing approaches
• the power or reason and getting it right the
  first time
• CS typically teaches that you can (and should)
  get your design right

33
Obstacles to user-centered iterative design

• Value of interactions with users is misestimated
• user diversity is underestimated
• I understand the users
• user diversity is overestimated
• Ill never understand them all
• belief that users dont know what they want
  (true, but)

34
Obstacles to user-centered iterative design

• Difficult to manage, measure, and set goals
• when will the software be done
• very hard to estimate for software anyway
• open-ended iteration makes it harder

35
Difficulty of measurement

• Dealing with users is hard
• This is what Intro to HCI is all about
• Programmers dont usually get taught these
  skills

36
Chicken and egg problem

• Cant afford to build it more than once
• Cant get it right the first time
• must test and redesign, but cant do that without
  building
• Do we give up on iterative development?

37
Do we give up on iterative development?

• No
• Build something less than the full system and
  iterate on that
• Prototyping

38
Prototyping techniques

• Build mockup prototypes that allow you to see
  (some of) effects on real users
• But which are cheap to build
• Start very cheap (but less realistic)
• so you can afford major change
• get the high order bits fast
• Move to less cheap (more realistic)

39
Aside mockup vs. prototype

• This is my terminology
• not standardized, and not a firm line
• I use mockup for non-functional (low fidelity)
• Prototype for functional / executable (closer
  to final form)

40
Four dimensions of prototypes (and mockups)

• Representation
• Scope
• Fidelity (and executability)
• Maturation
• These are not independent

41
Representation

• What form is the design represented in?
• does it match the physical form?
• examples pencil and paper (static images) vs.
  storyboard vs. computerized

42
Scope

• How much of the system is represented?
• Often can test just one aspect
• How much of the application functionality is
  behind the interface?

43
Fidelity

• How closely does the mockup / prototype mimic the
  final system
• Major issue is the artifact executable and can
  it be run by the users
• big increase in both fidelity and cost

44
Maturation

• How close is this to the final design?
• Need to stay flexible (and hence low cost) early
• Typically want to increase both scope and
  fidelity as we mature
• Concentrate on big issues early work on
  details once those are right

45
Vertical vs. Horizontal prototypes

• Scope vs. fidelity tradeoffs
• Vertical go deep in a few critical areas
  (limited simulation of rest)
• High fidelity within limited scope
• Horizontal wide coverage but limited fidelity
• Low fidelity with larger scope
• Often use some of each

46
Some specific prototyping techniques

• Storyboards
• sketches (on paper or screen) that indicate how
  things look across a scenario
• no user interaction at all
• but still get an idea of what it might be like
  (and can get users involved)
• Low fidelity, low cost (use early)

47
Some specific prototyping techniques

• Extended storyboards
• Can sketch out multiple interactive paths on
  paper
• typically user points at things on paper, you
  flip to prepared sheets showing how things would
  change
• can do part of interface separately
• Again, low cost / early

48
Some specific prototyping techniques

• Wizard of OZ studies
• Pay no attention to the man behind the curtain
• Replace machine actions with the man behind the
  curtain
• human listens / watches user, then types, pushes
  buttons
• particularly useful when parts of system dont
  exist yet

49
Some specific prototyping techniques

• Wizard of OZ studies
• Most useful for things that dont exist yet
• find out what the big issue with them will be
  while they can be changed
• dont wait till slow item is done to design (
  iterate!) interface
• Fidelity issues (particularly timing)

50
Some specific prototyping techniques

• Limited functionality and/or scope executable
  prototypes
• actual running interface of some sort
• e.g. Visual Basic prototype
• more costly, but more fidelity
• later in process

51
Some specific prototyping techniques

• Fully functional prototypes that can evolve into
  the real product
• can do full use testing
• high fidelity, high cost
• last stage of prototyping

52
Warnings about iterative design

• Big picture first
• Its easy to get bogged down in details and miss
  the forest for the trees
• e.g., layout, color, etc.
• Get the high order bits first
• is this the right functionality?
• is this conceptual model going to work for the
  user?

53
Warnings about iterative design

• Beware of delivering (what was supposed to be)
  the prototype
• a lot of pressure to deliver the first thing that
  looks like it works
• can get you in big trouble later
• need to make sure everyone knows this is a
  prototype
• often want to make things look sketchy early on
  to avoid this

54
Warnings about iterative design

• Design inertia
• First designs have a huge impact
• evolutionary process like biological evolution
  can be hard to back out of decisions
• Need to be willing to make radical changes when
  maturity is low
• why is needs to be low cost early
• Explicitly consider several designs

55
Warnings about iterative design

• Need to understand reasons behind usability
  problems
• When feature X causes usability problems the
  simple thing is to eliminate X
• but if we dont understand it, we may make same
  mistake again, and/or make things worse

56
(No Transcript)