1. Prototyping CS 422: UI Design and Programming
HCI is the study of how people uses computer technologies and in turn how we can design user-friendly computer technologies. HCI drives innovation at the intersection of people and computers
Prototyping

2. As of now, our Thursday class is still on
As of now, our Thursday class is still on. I will notify if things change.
In general, attendance is required in studios a.k.a. class meetings where group projects are discussed.
You will lose points in GR deliverables if you do not show up to discuss your group projects.

3. Quick stats, housekeeping, & upcoming deliverables
Enrolled students: 89 | 4 Ph.D. students, 5 graduate students
I am working on getting another TA to help you with the class.
Groups with a mix of graduate and undergraduate students are encouraged.
Register your Clickers on BB. We will use them starting next week. It will be used to gauge your class participation. Graduate students may choose not to get Clickers, but otherwise participate in class.
Problem statements due this Thursday, Jan 31
GR1 due Feb 12 (Full project proposal)
PS1 due Feb 14 (in 2 weeks)

4. More on group project One problem statement per group.
Does not mean one person will come up with an idea and others will tag along.
Brainstorm different ideas as a group and converge on one of them.
Have a couple of back-up ideas you may consider.
Remember, this is a course-long project around the problem you will be choosing. You will spend the entire semester trying to design and develop a UI around that problem. Choose wisely.

5. How to do well in this course?
We will provide some examples of course deliverables (on Piazza). Review them to understand what is expected of you.
When possible an assignment rubric will be provided in advance (on Piazza). Review them to stay informed.
For both coding and problem-solving assignments, we will compare your answers with last semester’s submission and the “Internet”. Do not ctrl + C and ctrl +V.
I do not care about length in problem-solving assignments. What I am looking for is a good argument and critical thinking.
Connect your answers with UI design principles you are learning in this class. No “I feel like it’s busy” or “it’s not efficient”. Go deeper. Why? How would you change it?
If you are not confident about your HTML/CSS/JS skills, attend the labs, ask help from your TAs. Do not wait until the day before the due date of PS2.

6. What are the three dimensions of usability?
Learnability
Efficiency
Safety

7. What is more at play when you use a command-line interface like vim?
Recognition
Recall
Both of the above
None of the above

8. What is more at play when you use a command-line interface like vim?
Recognition
Recall
Both of the above
None of the above

9. What are the three models of UI design?
System model
Interface model
User model

10. Needfinding is most relevant for which model(s) of UI design?
System model
Interface model
User model
All of the above

11. Needfinding is most relevant for which model(s) of UI design?
System model
Interface model
User model
All of the above

12. Prototyping is most relevant for which model(s) of UI design?
System model
Interface model
User model
All of the above

13. Prototyping is most relevant for which model(s) of UI design?
System model
Interface model
User model
All of the above

14. Transition
User wants her slides to transition automatically after 1 minute, except the first slide, which should disappear only after a mouse click and a beep sound.
Concrete task or Essential goal

15. Transition
User wants her slides to transition automatically after 1 minute, except the first slide, which should disappear only after a mouse click and a beep sound.
Concrete task or Essential goal
Essential goal: user wants customizable options to transition between slides

16. Snaps and Stories What is the concrete task?
What is the essential goal?

17. Prototyping

18. Things we will learn today
What is a prototype?
Paper prototyping
Computer prototyping

19. Why invest in early prototyping?
It’s cheap
It’s quick
You can test it
All of the above

20. Why invest in early prototyping?
It’s cheap
It’s quick
You can test it
All of the above

21. With prototyping Get feedback earlier, cheaper
Experiment with alternatives
Easier to change or throw away
It’s important not to commit strongly to design ideas in the early stages of design.

22. The commitment problem; and breaking away from it
Unfortunately, writing and debugging a lot of code creates a psychological sense of commitment which is hard to break.
You don’t want to throw away something you’ve worked hard on, so you’re tempted to keep some of the code around, even if it really should be scrapped.
One of the core premise of prototyping is to force you to throw the prototype away.
A paper mockup won’t form any part of a finished software implementation. This is a good mindset to have in early iterations, since it maximizes your creative freedom.
Alan Cooper, “The Perils of Prototyping”, 1994.

23. Different fidelities of a prototype
We talked about cost in last class
What prototyping features impact this cost? $ $$
$$$
$$$$

24. Prototype Fidelity: How close are we to the final product?
Fidelity of a prototyping technique is simply how similar it is to the finished interface.
Low-fidelity prototypes omit details, use cheaper materials, or use different interaction techniques.
High-fidelity prototypes are very similar to the finished product.

25. Fidelity is Multidimensional
Breadth refers to the fraction of the feature set represented by the prototype.
A prototype that is low-fidelity in breadth might be missing many features, having only enough to accomplish certain specific tasks.
E.g., a word processor prototype might omit printing and spell-checking.

26. Fidelity is Multidimensional
Depth refers to how deeply each feature is actually implemented.
Is there a backend behind the prototype that’s actually implementing the feature?
Low-fidelity in depth may mean limited choices (e.g., you can’t print double-sided), canned responses (always prints the same text, not what you actually typed), or lack of robustness and error handling (crashes if the printer is offline).

27. Which one do you think will be the focus of our class?
Breadth of a prototype
Depth of a prototype

28. Which one do you think will be the focus of our class?
Breadth of a prototype
Depth of a prototype
We will build a horizontal prototype for this class. In other classes, you may be learning to build a vertical prototype.

29. Horizontal vs Vertical prototype
A horizontal prototype is all breadth, and little depth; it’s basically a frontend with no backend.
A vertical prototype is the converse: one area of the interface is implemented deeply.

30. Horizontal prototypes are more common in UI design
In user interface design, horizontal prototypes are more common, since they address usability risk.
But if some aspect of the application is a risky implementation - you’re not sure if it can be implemented to meet the requirements - then you may want to build a vertical prototype to test that.
A scenario shows how the frontend would look for a single concrete task. After you arrive at a set of user requirements a.k.a. essential goals, you will then use them to come up with scenarios before prototyping.

32. More Dimensions of Fidelity
Look: appearance, graphic design
Sketchy, hand-drawn
Feel: input method
Pointing & writing feels very different from mouse & keyboard
Can we test for look and feel with sketches or paper prototypes?
No.
Then why do paper prototyping?

33. Paper Prototypes
Paper prototypes are an excellent choice for early design iterations. A paper prototype is a physical mockup of the interface, mostly made of paper. It’s usually hand-sketched on multiple pieces, with different pieces showing different menus, dialog boxes, or window elements.

34. Paper Prototypes Interactive paper mockup Interaction is natural
Sketches of screen appearance
Paper pieces show windows, menus, dialog boxes
Interaction is natural
Pointing with a finger = mouse click
Writing = typing
A person simulates the computer’s operation
Putting down & picking up pieces
Writing responses on the “screen”
Describing effects that are hard to show on paper
Low fidelity in look & feel
High fidelity in depth (person simulates the backend)

35. Why Paper Prototyping? Faster to build Easier to change
Sketching is faster than programming
Easier to change
Easy to make changes between user tests, or even during a user test
No code investment - everything will be thrown away (except the design)
Focuses attention on big picture
Designer doesn’t waste time on details
Customer makes more creative suggestions, not nitpicking
Non Programmers can help (think users..)
Only kindergarten skills are required

36. Tools for Paper Prototyping
White poster board (11”x14”)
For background, window frame
Big (unlined) index cards (4”x6”, 5”x8”)
For menus, window contents, and dialog boxes
Re-stickable glue
For keeping pieces fixed
White correction tape
For text fields, checkboxes, short messages
Overhead transparencies
For highlighting, user “typing”
Photocopier
For making multiple blanks
Pens & markers, scissors, tape
More in the reading…

37. Tips for Good Paper Prototypes
Make it larger than life
Make it monochrome
Replace tricky visual feedback with audible descriptions
Tooltips, drag & drop, animation, progress bar
Keep pieces organized
Use folders & open envelopes

38. How to Test a Paper Prototype
Unit testing?
Black box testing?
No.
Testing a paper prototype is an important task in user-centered design. Why?

39. What is/are the core principle(s) in user-centered design?
Focus on the user(s)
Provide many functionalities
Iterate, iterate, iterate
All of the above

40. What is/are the core principle(s) in user-centered design?
Focus on the user(s)
Provide many, many functionalities
Iterate, iterate, iterate
All of the above

41. How to Test a Paper Prototype

42. How to Test a Paper Prototype
Once you’ve built your prototype, you can put it in front of users and watch how they use it.
Roles for design team
Computer
Simulates prototype
Doesn’t give any feedback that the computer wouldn’t
Facilitator
Presents interface and tasks to the user
Encourages user to “think aloud” by asking questions
Keeps user test from getting off track
Observer
Keeps mouth shut, sits on hands if necessary
Takes copious notes

43. What Can we Learn from a Paper Prototype
Conceptual/ Interface model
Do users understand it?
Functionality
Does it do what’s needed? Missing features?
Navigation & task flow
Can users find their way around?
Are information preconditions met?
Terminology
Do users understand labels?
Screen contents
What needs to go on the screen?

44. What Can’t we Learn Look: color, font, white space, etc
Feel: efficiency issues
Response time
Are small changes noticed?
Even the tiniest change to a paper prototype is clearly visible to user
Exploration vs. deliberation
Users are more deliberate with a paper prototype; they don’t explore or thrash as much

45. Computer Prototypes Interactive software simulation
High-fidelity in look & feel
Low-fidelity in depth
Paper prototype had a human simulating the backend; computer prototype doesn’t
Computer prototype may be horizontal: covers most features, but no backend

46. What You Can Learn From Computer Prototypes
Everything you learn from a paper prototype, plus:
Screen layout
Is it clear, overwhelming, distracting, complicated?
Can users find important elements?
Colors, fonts, icons, other elements
Well-chosen?
Interactive feedback
Do users notice & respond to status bar messages, cursor changes, other feedback
Efficiency issues
Controls big enough? Too close together? Scrolling list is too long?
Computer prototypes help us get a handle on the graphic design and dynamic feedback of the interface.

47. Why Use Prototyping Tools?
Faster than coding
No debugging
Easier to change or throw away
Don’t let your UI toolkit do your graphic design

48. Computer Prototyping Techniques
Storyboard
Sequence of painted screenshots
Sometimes connected by hyperlinks (“hotspots”)
Form builder
Real windows assembled from a palette of widgets (buttons, text fields, labels, etc.)
Wizard of Oz
Computer frontend, human backend

49. Wizard of Oz Prototype
Software simulation with a human in the loop to help
“Wizard of Oz” = “man behind the curtain”
Wizard is usually but not always hidden
Often used to simulate future technology
Speech recognition
Learning
Issues
Two UIs to worry about: user’s and wizard’s
Wizard has to be mechanical

50. Wizard of Oz Prototype

51. All members of a group must be present in class.
Next class
Project proposal discussions
All members of a group must be present in class.