1. Ch 5 Design Yonglei Tao School of Computing and Info Systems GVSU

2. 2 Design Conceptual Design Physical Design Evaluation Techniques

3. 3 Tools for Conceptual Design Brainstorming Card sort Semantic networks Personas Scenarios Flowcharts

4. 4 Brainstorming Team activity ◦ Paper and pencil drawings, blackboards, whiteboards, and Post-it notes Generate as many ideas as possible Be as creative as possible without restrictions on the process or ideas

5. 5 Card Sort Organize the information collected in the discovery phase Define groupings for menus, controls and Web page content Generate labels for menus, buttons and navigation links

6. 6 Example of Card Sort

7. 7 Semantic Network

8. 8 Personas Identify primary stakeholders and create a description about them ◦ based on stakeholder profiles and other activities such as interviews and surveys Complete as many personally identifying attributes as necessary

9. Example: a Website Project Develop a website for a poetry journal called Circumference ◦ Serve international audience ◦ Also enable disabled users to access The journal is specialized in world poetry translation into English ◦ to date it has four published issues Stakeholders ◦ Site visitors, journal editors, and site developers

10. Example of Persona

11. 11 Scenarios A description of a typical task ◦ Basic goal ◦ Conditions that exist at the beginning of the task ◦ Activities in which the persona will engage ◦ Outcomes of those activities

12. Example of Scenarios Read poems from multiple issues Read poems of an author View videos of the last two poetry events Order one-year subscription, issue number 4, and issue number 1

13. Example of a Scenario The first thing I would do is to observe cars on the road and identify ones that I like the look of. This may take some weeks. I would also try to identify any consumer reports that will include an assessment of car performance. Hopefully, these initial activities will result in my identifying a likely car to buy. The next stage will be to visit a car showroom and see at first hand what the car looks like, and how comfortable it is to sit in. if I still feel positive about the car, then I’ll ask for a test drive. Even a short test drive helps me to understand how well the car handles, how noisy is the engine, how smooth are the gear changes, and so on. Once I’ve driven the car myself, I can usually tell whether I would like to own it or not.

14. Example: One-Stop Car Shop I want to buy a new car, so I go down the street to the local ‘one-stop car shop.’ The shop has a number of booths in it, and when I go in I’m directed to an empty booth. Inside there’s a large seat that reminds me of a racing car seat, and in front of that a large display screen, keyboard, and printer. As I sit down, the display jumps into life. It offers me the options of browsing through video clips of new cars which have been released in the last two years, or of searching through video clips of cars by make, by model, or by year. I can choose as many of these as I like.

15. I also have the option of searching through and reading or printing consumer reports that have been produced about the cars I’m interested in. I spend about an hour looking through materials and deciding that I’d like to experience a couple that look promising. I can of course go away and come back later, but I’d like to have a go with some of those I’ve found. By flicking a switch in my armrest, I can call up the options for virtual reality simulations for any of the cars I’m interested in. These are really great as they allow me to take the car for a test drive, simulating everything about the driving experience in this car, from road holding, to widescreen display, and front pedal pressure to dashboard layout. It even recreates the atmosphere of being inside the car.

16. Storyboards Often used with scenarios, bring more detail It is a series of sketches showing how a user might progress through a task using the device Used early in design

17. Storyboard for the One-Stop Shop Scenario

18. 18 Flowcharts Simple network diagrams Sophisticated diagrams

19. 19 Physical Design Considerations ◦ What it will look like ◦ What components it will require ◦ How the screens will be laid out Tools ◦ Low-fidelity prototypes ◦ High-fidelity prototypes ◦ Wireframes ◦ Functional prototypes

20. 20 What to Prototype? Technical issues Work flow, task design Screen layouts and information display Difficult, controversial, critical areas

21. 21 Types of Prototypes Horizontal and Vertical

22. 22 Low-Fidelity Prototyping Uses a medium which is unlike the final medium, e.g. paper, cardboard Quick, cheap and easily changed Examples Sketches of screens, task sequences … ‘Post-it’ notes Storyboards ‘Wizard-of-Oz’

23. Low-Fidelity Prototypes 23

24. Card-based prototypes Index cards (3 X 5 inches) Each card represents one screen or part of screen Often used in website development

25. A Card-Based Prototype for the Library Catalog System

26. Example of Prototype

27. ‘Wizard-of-Oz’ Prototyping The user thinks they are interacting with a computer, but a developer is responding to output rather than the system. Usually done early in design to understand users’ expectations >Blurb blurb >Do this >Why? User

28. 28 Low-Fidelity Prototypes Need to answer questions before getting started ◦ What feedback do you need? ◦ How much of the design should you prototype? ◦ Should you cover any area in great detail? Help define the scope of the prototype and focus on what you want to accomplish

29. 29 High-Fidelity Prototyping Use materials that you would expect to be in the final product Prototype looks more like the final system Danger that users think they have a full system

30. High-Fidelity Prototyping Menus Drop-down lists Message boxes

31. 31 Functional Prototypes Interactive prototypes that represent various degrees of functionality Can be created using tools such as: ◦ VC++, VB, NetBeans ◦ Adobe - Flash, Dreamweaver, and Director Rapid Prototyping ◦ Make it possible to try out ideas very early ◦ Make it possible to test, revise, test, revise, … ◦ Engage end users

32. 1-32 Evaluation An integral part of the development process Inspection techniques Walkthrough, heuristic evaluation Alternative to usability testing Allowing to begin evaluations early in the process

33. 1-33 Cognitive Walkthroughs An evaluator follows task scenarios using the flowcharts or the low-fidelity prototypes Role-plays the part of a user working with the interface and tries to accomplish user tasks ◦ Identify the user's goals for each task ◦ Act as if the interface was actually built ◦ Walk through each task Suitable for the early stages of development

34. Example of Cognitive Walkthroughs

36. A Scenario – Read Poems from Multiple Issues 1. From the Home page, click on the Issues link 2. From the Issues page, decide on an issue to look at 3. Click on the appropriate issue link 4. Scan the TOC for a poem 5. Click on the poem’s link 6. Read the poem 7. Click on the global Issues link 8. Repeat steps 2-6

37. Cognitive Walkthroughs Questions to ask at each step ◦ Will users know what to do? ◦ Will users see how to do? ◦ Will users understand from feedback whether the action was correct or not? Perform group walkthrough ◦ May involve users, developers, and usability experts ◦ Step through a task scenario ◦ Discuss and evaluate each user interface element

38. Heuristic Evaluation Experts go through an interface and evaluate each element against a list of principles ◦ Several experts evaluate on their own ◦ Follow a scenario through the design ◦ Look at design and implementation ◦ Compare findings and provide feedback ◦ Make recommendations to the design team Can be used at any time in the development process 1-38

39. Empirical Data Factor 1: Visibility of system status ◦ Feedback: keep user informed about what goes on ◦ Provide status information ◦ Feedback: show that input has been received ◦ Features change as user carries out task ◦ Feedback provided for all actions ◦ Feedback timely and accurate ◦ Indicate progress in task performance ◦ Direct manipulation: visible objects, visible results ◦ Identity cues system response vs. user’s goals ◦ Show icons and other visual indicators ◦ WYSIWYG: do not hide features ◦ What incorrect inferences are most likely

40. Empirical Data (Cont.) Factor 2: Match between system and real world ◦ Speak the user’s language ◦ Contains familiar terms and natural language ◦ Speak the user’s language ◦ Metaphors from the real world ◦ Familiar user’s conceptual model ◦ Use of user’s background knowledge ◦ Learnable through natural, conceptual model ◦ Follow real-world conventions ◦ Screen representation matches non-computer ◦ Encourage users to import pre-existing tasks ◦ Identity cues between actions and user’s goals ◦ Understand the user’s language

41. Empirical Data (Cont.) Factor 3: User control and freedom Undo and redo should be supported Obvious way to undo actions Forgiveness: make actions reversible Ability to undo prior commands Clearly marked exits Ability to re-order or cancel tasks Modeless interaction User control: allow user to initiate/control actions Modelessness: allow users to do what they want

42. Empirical Data (Cont.) Factor 4: Consistency and standards ◦ Consistency: express same thing same way ◦ Consistency: same things look the same ◦ Uniform command syntax ◦ Conform to platform interface conventions ◦ Consistent key definitions throughout ◦ Universal commands: a few, generic commands ◦ Show similar info at same place on each screen

43. Empirical Data (Cont.) Factor 5: Error prevention ◦ Prevent errors from occurring in the first place ◦ System designed to prevent errors ◦ Understand the user’s language ◦ What planning mistakes are most likely? ◦ What slips are most likely? ◦ Identity cues between actions and user’s goals

44. Empirical Data (Cont.) Factor 6: Recognition rather than recall ◦ See-and-point instead of remember-and-type ◦ Make the repertoire of available actions salient ◦ Seeing and pointing: objects and actions visible ◦ What features often missed and at what cost? ◦ Provide lists of choices and picking from lists ◦ Minimize the users’ memory load ◦ Direct manipulation: visible objects, visible results ◦ Easy or difficult to perform (execute) task? ◦ Evoke goals in the user ◦ Clearly marked exits ◦ Show icons and other visual indicators ◦ Integrated with the rest of the desktop

45. Empirical Data (Cont.) Factor 7: Flexibility and efficiency of use ◦ Accelerators should be provided ◦ Shortcuts: Accelerators to speed up dialogue ◦ User tailorability to speed up frequent actions ◦ User control: allow user to initiate/control actions ◦ System should be efficient to use ◦ User interface should be customizable ◦ Ability to re-order or cancel tasks ◦ Keyboard core functions should be supported ◦ Physical interaction with system feels natural

46. Other Heuristics Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, concrete steps to be carried out, and not be too large.

47. 47 Interface Design Standards Promote standards-based designs with a consistent look and feel ◦ Graphical libraries ◦ User interface toolkits ◦ Visual interface builders ◦ Web development tools Increase efficiency and promote learning