UI Development Process

2

UI Development process

Like UI design, this is just once over lightly with HCI/UI SW spin– just enough to raise your awareness– not what this course is about, but

important issues

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 disasterBut need to understand the vocab

4

Traditional SE process

The “Waterfall” modelNot 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”

Requirements specification Design

Coding and unit testing Integration and testing Operation and maintenance

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” doesn’t necessarily match what we typically mean in HCI

8

Requirements specification

What will the system do?– What does it need to do to meet the

customer’s (user’s) 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 – user’s can’t tell you what they need

Writing down a requirements spec is not realistic in UI design

Doesn’t mean you shouldn’t find out about user’s 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 + requirements (but iterated) But, UI design doesn’t 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 can’t 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 hardrequires 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 don’t spend your 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 difficultythree cubes it, etc.

– difficulty also grows non-linearly in area bug could 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 don’t 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 doesn’t 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 don’t 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

Etc… … Will leave this for Intro and other

HCI classes

25

User-centered approach has been around for a long time Catching on, but practices still

don’t get followed as much as they should– increasing, but not there yet

Why?

26

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

27

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

28

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

“I’ll never understand them all”“Can’t get statistically significant info”

– belief that users don’t know what they want (true, but…)

29

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

30

Difficulty of measurement

Dealing with users is hard This is what Intro to HCI is all

about– “Programmers” don’t usually get

taught these skills

31

Chicken and egg problem

– Can’t afford to build it more than once– Can’t get it right the first time

must test and redesign, but can’t do that without building

Do we give up on iterative development?

32

Do we give up on iterative development? No Build something less than the

full system and iterate on that Prototyping

33

Prototyping techniques

Build mockup & prototypes that allow you to see (some of; high order bits 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)

34

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)

35

Three dimensions of prototypes (and mockups) Scope Fidelity Maturation

These are not fully independent

36

Scope

How much of the system is represented?– Often can test just one aspect

How much of the application functionality is behind the interface?

37

Fidelity

How closely does the mockup / prototype mimic the final system– Major issue: is the artifact executable

and can it be “run” by the usersbig increase in both fidelity and cost

38

Another aspect of fidelity: representation What form is the design

represented in?– does it match the physical form?– examples: pencil and paper (static

images) vs. storyboard vs. computerized

39

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

40

“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 fidelityLow fidelity with larger scope

– Often use some of each

41

Some specific prototyping techniques (Simple) storyboards

– sketches (on paper or screen) that indicate how things look across a scenariono user interaction at allbut still get an idea of what it might be like (and can get users involved)

– Low fidelity, low cost (use early)

42

Some specific prototyping techniques Extended storyboards

– Can sketch out multiple interactive paths on papertypically 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

43

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

44

Some specific prototyping techniques Wizard of OZ studies

– Most useful for things that don’t exist yetfind out what the big issue with them will be while they can be changed

don’t wait till slow item is done to design (& iterate!) interface

– Fidelity issues (particularly timing)

45

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

46

Some specific prototyping techniques Fully functional prototypes that

can evolve into the real product– highest level of maturity– can do full user testing– high fidelity, high cost

last stage of prototyping

47

Warnings about iterative design

Big picture first– Its easy to get bogged down in details

and miss the forest for the treese.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?

48

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 workscan get you in big trouble laterneed to make sure everyone knows this is a prototype

– often want to make things look “sketchy” early on to avoid this

49

Warnings about iterative design Design inertia

– First designs have a huge impactevolutionary process & like biological evolution can be hard to back out of decisions

– Need to be willing to make radical changes when maturity is lowwhy is needs to be low cost early

– Explicitly consider several designs

50

Warnings about iterative design

Need to understand reasons behind usability problems– When “feature X” causes usability

problems the simple thing is to eliminate Xbut if we don’t understand it, we may make same mistake again, and/or make things worse

51