UI Development Process

2 UI Development process n 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 n 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 F But need to understand the vocab

4 Traditional SE process n The “Waterfall” model F 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 n 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 n Implies that you design once (and get it right) – Not really possible for UI software

7 Waterfall model n 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 n 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? n Encode into a spec that drives the next phases

9 Requirements specification n Requirements analysis is very hard in practice – user’s can’t tell you what they need n Writing down a requirements spec is not realistic in UI design n Doesn’t mean you shouldn’t find out about user’s needs

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

11 Design n UI design would be in detailed design + requirements (but iterated) n But, UI design doesn’t fit very well – this is mostly about system structure – UI design is mostly about what the user sees F often without regard to the system structure that makes it happen

12 Coding and unit testing n Actually write the code – typically the only part that you get graded on in school – only part you can’t skimp on F where the rubber meets the road – tends to get a lot of attention n Test small scale parts (units) to ensure they function right

13 An aside on unit testing n My experience: the key to good programming is unit testing – All programmers create tons of bugs F programming is just hard F requires holding more details in your head than is humanly possible

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

15 Unit testing n In reality you don’t spend your time writing programs – once you get the hang of it its tedious, but not that hard n You spend your time debugging n Unit testing is really “Preemptive Debugging”

16 Unit testing n 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 F more like square of difficulty F three cubes it, etc. – difficulty also grows non-linearly in area bug could be in

17 Unit testing n 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 n Testing that when you put the pieces together they work – even if “units” work perfectly, whole may not

20 Testing parts n Systems testing – do you think it works n Verification – does it match the spec n Validation and acceptance testing – does it work to the customer – does it meet the contract / spec

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

22 Operation and maintenance n What happens after its delivered – the next release – bug fixes – new features

23 Waterfall model doesn’t work for UI software n UI requirements and design are very hard – too hard to get right on the first try – human beings are just too complex F just don’t know enough to do it from first principles – hidden mental models n 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 n Catching on, but practices still don’t get followed as much as they should – increasing, but not there yet n Why?

26 Obstacles to user-centered iterative design n Big reason: Impractical – Iteration is expensive – Can barely afford to build it once F 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 n 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 n Value of interactions with users is misestimated – user diversity is underestimated F “I understand the users” – user diversity is overestimated F “I’ll never understand them all” F “Can’t get statistically significant info” – belief that users don’t know what they want (true, but…)

29 Obstacles to user-centered iterative design n Difficult to manage, measure, and set goals – when will the software be done F very hard to estimate for software anyway F open-ended iteration makes it harder

30 Difficulty of measurement n Dealing with users is hard n 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 F must test and redesign, but can’t do that without building n Do we give up on iterative development?

32 Do we give up on iterative development? n No n Build something less than the full system and iterate on that èPrototyping

33 Prototyping techniques n Build mockup & prototypes that allow you to see (some of; high order bits of) effects on real users n But which are cheap to build – Start very cheap (but less realistic) F so you can afford major change F “get the high order bits” fast – Move to less cheap (more realistic)

34 Aside: mockup vs. prototype n This is my terminology – not standardized, and not a firm line n I use “mockup” for non- functional (low fidelity) n “Prototype” for functional / executable (closer to final form)

35 Three dimensions of prototypes (and mockups) n Scope n Fidelity n Maturation n These are not fully independent

36 Scope n How much of the system is represented? – Often can test just one aspect n How much of the application functionality is behind the interface?

37 Fidelity n How closely does the mockup / prototype mimic the final system – Major issue: is the artifact executable and can it be “run” by the users F big increase in both fidelity and cost

38 Another aspect of fidelity: representation n 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 n 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 n Scope vs. fidelity tradeoffs – Vertical: go deep in a few critical areas (limited simulation of rest) F High fidelity within limited scope – Horizontal: wide coverage but limited fidelity F Low fidelity with larger scope – Often use some of each

41 Some specific prototyping techniques n (Simple) storyboards – sketches (on paper or screen) that indicate how things look across a scenario F no user interaction at all F but 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 n Extended storyboards – Can sketch out multiple interactive paths on paper F typically user points at things on paper, you flip to prepared sheets showing how things would change F can do part of interface separately – Again, low cost / early

43 Some specific prototyping techniques n Wizard of OZ studies “Pay no attention to the man behind the curtain” – Replace machine actions with “the man behind the curtain” F human listens / watches user, then types, pushes buttons

44 Some specific prototyping techniques n Wizard of OZ studies – Most useful for things that don’t exist yet F find out what the big issue with them will be while they can be changed F don’t wait till slow item is done to design (& iterate!) interface – Fidelity issues (particularly timing)

45 Some specific prototyping techniques n Limited functionality and/or scope executable prototypes – actual running interface of some sort F e.g. Visual Basic prototype – more costly, but more fidelity F later in process

46 Some specific prototyping techniques n Fully functional prototypes that can evolve into the real product – highest level of maturity – can do full user testing – high fidelity, high cost F last stage of prototyping

47 Warnings about iterative design n Big picture first – Its easy to get bogged down in details and miss the forest for the trees F e.g., layout, color, etc. – Get the “high order bits first” F is this the right functionality? F is this conceptual model going to work for the user?

48 Warnings about iterative design n Beware of delivering (what was supposed to be) the prototype – a lot of pressure to deliver the first thing that looks like it works F can get you in big trouble later F need 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 n Design inertia – First designs have a huge impact F 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 F why is needs to be low cost early – Explicitly consider several designs

50 Warnings about iterative design n Need to understand reasons behind usability problems – When “feature X” causes usability problems the simple thing is to eliminate X F but if we don’t understand it, we may make same mistake again, and/or make things worse

51