Presentation is loading. Please wait.

Presentation is loading. Please wait.

User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton

Similar presentations


Presentation on theme: "User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton"— Presentation transcript:

1 User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton jpatton@acm.org www.agileproductdesign.com

2 Our goals and agenda today Goal: feel comfortable design and testing functional, usable, user interface Part 1: Understanding the users experience Understanding users goals and tasks Telling stories about the user experience Converting stories to UI components Part 2: Prototyping and testing the user interface Building a componentized paper prototype Iteratively testing and refining your prototype Improving your visual design (as time permits) (c) Jeff Patton, AgileProductDesign.com2

3 People achieve goals through interaction (c) Jeff Patton, AgileProductDesign.com3 problem or goal How Id like to feel, or what Id like to achieve Take some action action evaluation Did that action deliver the results I expected? goal evaluation Is my goal met or problem resolved? the world Information and tools (c) Jeff Patton, AgileProductDesign.com

4 problem or goal How Id like to feel, or what Id like to achieve Think of three levels: goal, task, and tool 4 the world Information and tools Take some action action evaluation Did that action deliver the results I expected? goal evaluation Is my goal met or problem resolved? goal task tool (c) Jeff Patton, AgileProductDesign.com

5 Goals, tasks, and tools apply at both a personal and organizational level 5 business processes employees, vendors, & systems business objectives tasks tools goals (c) Jeff Patton, AgileProductDesign.com

6 Barneys Getting started with a UI design problem 6 Read the Barneys Information Kiosk problem Watch for: Business goals Users and their goals The types of user tasks users would likely choose to reach their goals (5 minutes) In small workgroups (4-5 people) discuss: What are Barneys goals or pains? What types of users might use the kiosk and why? Try to talk about tasks without talking about the kiosk (tool) – this can be difficult (5 minutes) Your team (c) Jeff Patton, AgileProductDesign.com

7 What are the users goals and businesses goals? Business goals or pain points? Types of users using this system? Users goals or pains? 7(c) Jeff Patton, AgileProductDesign.com

8 What will users do with the system to reach their goals? User tasks describe the actions people take Try to name them without prescribe the tool solution 8(c) Jeff Patton, AgileProductDesign.com

9 activity User tasks are decompose to smaller tasks and organize into activities Tasks require intentional action on behalf of a tools user Tasks have an objective that can be completed Tasks decompose into smaller tasks Tasks often cluster together in activities 9 task (c) Jeff Patton, AgileProductDesign.com

10 activitymanage email User tasks are decompose to smaller tasks and organize into activities Tasks require intentional action on behalf of a tools user Tasks have an objective that can be completed Tasks decompose into smaller tasks Tasks often cluster together in activities Read an email message is a task, Managing email is an activity. 10 task read message send message create folder delete message prioritize message place message in folder (c) Jeff Patton, AgileProductDesign.com

11 task Activities have characteristics relevant to the software well choose to build some number of common tasks a general goal or purpose a primary human participant usually other human participants a physical place or location some number of tools including computers, software, electronic files, telephones, information, paper, etc.. 11 activity (c) Jeff Patton, AgileProductDesign.com

12 Be sensitive to user task altitude 12 * from Cockburns Writing Effective Use Cases Functional or Sea level Id reasonably expect to complete this in a single sitting Sub-Functional or Fish level Small tasks that by themselves dont mean much. Ill do several of these before I reach a functional level goal Activity or Kite level Longer term goals often with no precise ending. Ill perform several functional tasks in the context of an activity Too abstract Too detailed Think about user interface design at about this level (c) Jeff Patton, AgileProductDesign.com

13 Describe the user experience of the product (c) Jeff Patton, AgileProductDesign.com13

14 The essential use case is a simple way to describe experience abstractly Focusing on the interaction between user and system Avoid describing what the user specifically does by focusing on the users intention Determine the system responsibilities based on user goals and expectations (c) Jeff Patton, AgileProductDesign.com14 User IntentionSystem Responsibility Step one System response Step two System response

15 Write an Essential Use Case As a team, using supplies on the table, write an essential use case for: 15 Uuse this task: User: impatient Buyer Task: find a specific foreign film where I know the title Goal: : find it and buy it without wasting time

16 A user scenario is a simple way to think through user experience concretely A user scenario tells a story about a main character with a problem or goal Details how character reaches their goal important facts external context goals and concerns of our character include interesting plot points that help us envision important aspects of the system The scenario can gloss over uninteresting details 16© Jeff Patton, all rights reserved, AgileProductDesign.com

17 Field Manager enters daily shift performance reports 17 Field Managers Scenario 1.The shift has just ended and his reps are coming up with their totals. They have printed sheets with totals written on them. Steve quickly looks them over and signs them off. His assistant manager brings him other sheets with totals hes signed off. 2.In between visits by reps, Steve opens his Field Manager Workbench on his laptop. After logging in he sees todays date and the planned number of applications his reps should be gathering – 180 for today. 3.He also sees yesterdays numbers, and last weeks numbers, and the last 30 days in graph that shows applications relative to approval rate. Last weeks numbers were bad, and its the last week of the month, so Steve knows hes got to do well today. 4.Steve clicks enter rep performance data. He shuffles his reps performance sheets and grabs the first one. 5.The date is defaulted to today, and the shift is defaulted to morning since he hasnt yet entered info for today. Steve begins to enter the reps name, but after a few characters the system auto-completes his name. 6.The reps ID is already filled in, along with the code for the credit card promotion theyre working on today. 7.Steve fills in the shift information for his rep. He then enters the total number of applications taken. 8.It looks like from the notes on this sheet that this rep left sick two hours early. Steve adds a note about this in the system. 9.Time passes as more reps bring in their sheets and Steve completes entering them in between conversations. 10.After all the sheets are done, Steve looks at a summary screen for the day. It looks like hes close to his goal. If the next shift continues at this rate hell beat the plan by 5% or so. Thats good. 11.Steve validates that the base pay is correct at $5 per app, and that hes set an individual bonus giving reps $50 each if they reach 20 apps. Next to each rep he sees the calculated pay, base, bonus, and total pay for the day. 12.The annual sale at Macys has brought a lot of people in today. Steve chooses a sale increases mall foot traffic code to add to his shift data sheet. Frank, his boss, has pestered him to make sure he includes this type of information in his daily summaries. Steven Credit Card Marketing Field Manager Steven is a field manager working at the local shopping center. Hes in the middle of a long workday supervising 13 reps who are busy talking to people trying to convince them to apply for a credit card.

18 Imagine the user experience as a scenario Separate your team of four into pairs One person imagine the use experience of the kiosk describing it out loud to the other. Think about: Typical use, including typical problems Interesting plot points Goals and pains of your user After 5 minutes of discussion write out the scenario 18 Pair one use this task: User: casual browser Task: find the most current release for a particular artist Goal: : have fun finding something interesting Pair two use this task: User: impatient Buyer Task: find a specific foreign film where I know the title Goal: : find it and buy it without wasting time © Jeff Patton, all rights reserved, AgileProductDesign.com

19 Begin to think about the UI design © Jeff Patton, all rights reserved, AgileProductDesign.com19

20 Garrett describes the dependent layers that build up UI Jesse James Garretts Elements of User Experience 20© Jeff Patton, all rights reserved, AgileProductDesign.com

21 The surface layer describes finished visual design aspects 21 Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

22 The skeleton describes a screens layout and the functional compartments in the screen 22 Surface Skeleton Structure Scope Strategy starchvegetable entree dessert ! (c) Jeff Patton, AgileProductDesign.com

23 Structure defines navigation from place to place in the user interface 23 task panes modal dialogs modal wizards Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

24 The places in the user interface are built to support what people do – the users tasks 24 user tasks (what do people need to accomplish): enter numbers enter text enter formulas format cells sort information filter information aggregate information graph data save data import data export data print ….. Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

25 Business goals drive user constituency selection and contexts supported to form strategy 25 business goals: displace competitive products motivate sale of other integrated products establish file format as default information sharing format … user constituencies: accountant business planner housewife … usage contexts: office desktop laptop on airplane pda in car … Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

26 Garrets Elements of UX Stack Applies to the User Experience of Other Complex Products These layers of concerns apply not only to software but a variety of products. In particular, products that support a wide variety of user tasks benefit from this kind of thinking. 26(c) Jeff Patton, AgileProductDesign.com

27 Lets look at a strategy for a product we all use: the place we live 27 goals: live comfortably eat well stay clean be healthy keep up with Joness … user constituencies: me spouse child … usage contexts: near work near good schools near shopping … Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

28 What tasks might I and my family do to reach our goals? 28 user tasks: store food prepare food eat food sleep bathe store changes of clothing stay out of rain entertain guests entertain self … Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

29 Ill arranging tasks by affinity to help identify structure 29 Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

30 Ill optimize layout and tool choices to support tasks 30 Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

31 Im going to spend a lot of time here, I want my experience to be as pleasant as possible… 31 Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

32 The goal-task-tool model maps to Garretts elements model 32 Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com

33 Surface Skeleton Structure Scope Strategy The goal-task-tool model maps to Garretts elements model 33 goals tasks tools © Jeff Patton, all rights reserved, AgileProductDesign.com

34 Surface Skeleton Structure Scope Strategy The goal-task-tool model maps to Garretts elements model 34 User Interface Prototyping © Jeff Patton, all rights reserved, AgileProductDesign.com

35 Identify tools as abstract UI components For each system responsibility, what sort of tool will the system need to offer to meet that responsibility to the user? Preliminarily decide on tools as abstract components. An abstract component (describe by Larry Constantine) refers to a general type of component with a certain responsibility 35 Information or Material: contains and presents information. Action or Tool: allows execution of an action. Actionable Material: contains and presents information and allows the information to be acted on through selection or manipulation. Larry Constantine © Jeff Patton, all rights reserved, AgileProductDesign.com

36 Exercise: Identify the abstract components in your user scenario Using post-it notes, identify abstract components the user experience youve described Give each component a descriptive name that suggests its responsibility Look for: Information: information that displayed on the screen such as author, document title, status. People using the system will need information to orient themselves, and make decisions. actions: allow those using your system to tell the system to do something, or navigate somewhere. Typical actions include: save, send, or home. actionable information: includes form fields that allow entry and editing of information and items like lists of information that when clicked can be edited. 36© Jeff Patton, all rights reserved, AgileProductDesign.com

37 Part 2: Prototyping and testing the user interface Building a componentized paper prototype Iteratively testing and refining your prototype Improving your visual design (as time permits) 37© Jeff Patton, all rights reserved, AgileProductDesign.com

38 Build prototypes from moveable and removable paper components You may also choose to print and cut apart existing user interfaces or data from an existing system 38 Build a prototype from bits of paper and cardstock Tools youll need: Card Stock (use for screen backgrounds and cut up for components) Index Cards (lined cards make great lists) Scissors or Xacto knife Cello tape Repositionable tape Pencils Sharp felt tip pens Transparency film (great to write on) © Jeff Patton, all rights reserved, AgileProductDesign.com

39 In small teams, build up paper prototypes a component at a time 39 Use a team approach to build up a componentized paper prototype: 1.Someone direct traffic 2.Various people build components 3.Someone assemble the user interface from the components 4.Someone continuously review whats being assembled against your use case – will it work? © Jeff Patton, all rights reserved, AgileProductDesign.com

40 We build the prototype from components so we can play the role of a computer during testing 40© Jeff Patton, all rights reserved, AgileProductDesign.com

41 Joes suggests we also use a recording of the prototype as documentation 41© Jeff Patton, all rights reserved, AgileProductDesign.com

42 Exercise: Build Your Prototype As a team within the short time-box, build your prototype to support these two user tasks: Work as a team: One or more people build components One or more assemble the prototype using the components Someone use the task cases or scenarios to validate the UI supports these user stories Your UI design must support both this task: 42 User: impatient Buyer Task: find a specific foreign film where I know the title Goal: : find it and buy it without wasting time © Jeff Patton, all rights reserved, AgileProductDesign.com

43 Preparing to Testing Your Paper Prototype Identify test subjects Should match the characteristics and skills of our your target user constituencies Actual end users or stand-ins Identify tasks to test Assemble your test team facilitator computer observers Coach the test team on the testing personalities: flight attendant sports caster scientist Decide on test approach – single or paired subjects Setup your testing facility 43© Jeff Patton, all rights reserved, AgileProductDesign.com

44 Run Your Usability Test Facilitator introduces the team. Facilitator introduces tasks to perform and goals, then invites test participants to think out loud and begin. Facilitator plays sports-caster; keeps subject talking, narrating when necessary. Observers record data – use post-it notes to make downstream analysis move faster. When the test is complete observers may ask test participants questions. Thank test participants. Consolidate data. How many issues did you detect? Consider issues as items youd change. 44© Jeff Patton, all rights reserved, AgileProductDesign.com

45 Watch as each participant plays their role during light weight usability testing 45 Note each role: Facilitator Paired test subjects Observer Notice participants paying attention to the testing personalities: Flight attendant letting participants know the rules and making sure theyre safe Sports caster making sure participants keep talking going so we know what theyre thinking Scientists working hard not to bias the results by giving users hints © Jeff Patton, all rights reserved, AgileProductDesign.com

46 Exercise: Test Your Paper Prototype 1.Facilitator introduces the team. 2.Facilitator introduces tasks to perform and goals, then invites test participants to think out loud and begin. 3.Facilitator plays sports-caster; keeps subject talking, narrating when necessary. 4.Observers record data – use post-it notes to make downstream analysis move faster. 5.When the test is complete observers may ask test participants questions. 6.Thank test participants. 7.Consolidate data. How many issues did you detect? Consider issues as items youd change. 46 Support these tasks: User: casual browser Task: find the most current release for a particular artist User: impatient Buyer Task: find a specific foreign film where I know the title © Jeff Patton, all rights reserved, AgileProductDesign.com

47 This isnt just the right way to test, its RITE Traditional usability testing focuses on: Identifying repeatable user missteps UI concerns that may make the software difficult to learn, or learned behavior hard to maintain Then reporting those errors with suggestions for correcting problems The RITE method: Rapid Iterative Testing and Evaluation Rather than focusing on number of errors, emphasize number of errors fixed Required the capability to correct errors between iterative tests For higher-fidelity prototypes or working code, this requires developer participation 47 See Getting Software RITE: http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf © Jeff Patton, all rights reserved, AgileProductDesign.com

48 Unraveling Usability Concerns From Visual Design Concerns Usability is a measured characteristic of your software. Typical usability tests measure: Task completion frequency Task completion time Errors or missteps Professionals [and novices] can give their subjective evaluation on usability, but you cant really be sure until you test [or ship]. Paper Prototype usability testing helps identify usability issues before the software is built. Visual design adds look and feel that may affect usability. Dont assume those skilled at visual design are also skilled at usability. 48© Jeff Patton, all rights reserved, AgileProductDesign.com

49 Layer in user interface concerns – like a layer cake Start by making useful software Choose appropriate utility first Usability second Defer design esthetics until after the software is useful 49 utility (does the software offer functionality to support my goals?) usability (can that functionality easily learned, and effectively used?) design esthetics (is the software fun, pleasant, exciting – what is my emotional response?) usefulness © Jeff Patton, all rights reserved, AgileProductDesign.com

50 Test First – Building Confidence into Software Development Agile developments test-first technique doesnt just apply to code. Use paper prototyping and usability testing to validate that your user interface requirements are accurate and the software you intend to build can be effectively used. Iteration and testing of user interface using low- fidelity prototyping is faster than working code. Iterate to learn in the fastest medium available 50 See the StickyMinds.com article: Test Software Before You Code: http://www.stickyminds.com/s.asp?F=S11104_COL_2 © Jeff Patton, all rights reserved, AgileProductDesign.com

51 Jeff Patton jpatton@acm.org www.agileproductdesign.com User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI

52 Williams 4 Basic Design Principles Visual Design Basics Robin Williams The Non-Designers Design Book

53 Visual design that communicates effectively four simple principles Learn the principles and use them intentionally to improve your design. Analyze existing user interface design to see how these principles were leveraged or neglected. 53 CRAPCRAP Contrast Repetition Alignment Proximity © Jeff Patton, all rights reserved, AgileProductDesign.com

54 Proximity communicates affinity Proximity communicates similarity – distance communicates lack of similarity. Group related items together. Clumps of items can feel like one item visually. Minimize the number of clumps to help make a screen look simple. Q: Does your page have a minimal number of small clumps where each clump contains items that are of the same type or for the same purpose? 54© Jeff Patton, all rights reserved, AgileProductDesign.com

55 55

56 Alignment communicates association Nothing should be placed on the screen arbitrarily. Every item should have a connection with something else on the screen – after all if its on the same screen its associated. 3 Horizontal Alignments: Left Center Right Center alignments are visually the weakest The fewer alignment axis the better Q: Are there a minimal number of strong alignment axis? 56© Jeff Patton, all rights reserved, AgileProductDesign.com

57 57

58 Repetition helps calm and unify a design Repeated elements blend in. Repeat some aspects of the design throughout the entire application. Repetition can be thought of as consistency. Appropriate repetition makes the application appear cohesive. Elements that repeat each page become static – or visually persistent. As users move from place to place in your software, they need only observe whats changed. Q: does repetition help calm and unify the design? 58© Jeff Patton, all rights reserved, AgileProductDesign.com

59 59

60 60

61 Contrast communicates importance Use contrast to focus the users attention, to guide him/her through the application. Contrast, or dont. If two items are not exactly the same, make them different – really different. Subtle difference isnt contrast, its perceived by users as tension in the screen and often looks like a mistake. Q: are the highest contrast items in the UI the items I want people to see? 61© Jeff Patton, all rights reserved, AgileProductDesign.com

62 62

63 Usability Refers To The Ability of a User To Effectively Execute A Task Using a Tool While Visual Design certainly can affect usability, its quite possible for a product to have pleasing visual design, but intolerable usability. 63 Don Normans The Design of Everyday Things © Jeff Patton, all rights reserved, AgileProductDesign.com

64 Nielsens 10 Usability Heuristics 1.Visibility of system status (keep the user informed) Be forthcoming - dont hide information 2.Match between system and real world (user language and real world conventions) Watch your language 3.User control and freedom (easy exits, undo and redo) padded corners, hand rails, and safety nets 4.Consistency and standards same thing the same way 5.Error prevention 6.Recognition rather than recall (reduce remembering with visible options, actions, and instructions) 7.Flexibility and efficiency of use (customization and support for advanced users) 8.Aesthetic and minimalist design (reduce irrelevant or rarely needed information) 9.Help in recognizing, diagnosing, and recovering from errors 10.Good help and documentation 64 Jakob Nielsens Usability Engineering © Jeff Patton, all rights reserved, AgileProductDesign.com

65 Jeff Patton jpatton@acm.org www.agileproductdesign.com User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI

66 * Kent Beck coined the term user stories in Extreme Programming Explained 1 st Edition, 1999 An Agile User Story Might Model Use... Its Easier to Design User Interface if it Does As a [type of user ] I want to [perform some task ] so that I can[achieve some goal ] 66 Originally eXtreme Programming described a user story as a small amount of text written on an index card to function as a reminder for a conversation between developer and customer. From Wikipedia: A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. The user story form credited to Rachel Davies in Cohns User Stories Applied combines user, task, and goal: As aharried shopper I want to locate a specific CD in the store so that I canpurchase it quickly, leave, and continue with my day. © Jeff Patton, all rights reserved, AgileProductDesign.com

67 user story In practice user stories may be written to describe user tasks or the tools that support them 67 software tasks features goals As aweekend gardener I want to dig a hole so thatI can plant a tree More task-centric: As aweekend gardener I want a shovel so thatI can [dig a hole to] plant a tree More tool-centric: (or feature-centric) © Jeff Patton, all rights reserved, AgileProductDesign.com

68 user story In practice user stories may be written to describe user tasks or the tools that support them 68 software tasks features goals As aweekend gardener I want to dig a hole so thatI can plant a tree More task-centric: As aweekend gardener I want a shovel so thatI can [dig a hole to] plant a tree More tool-centric: (or feature-centric) © Jeff Patton, all rights reserved, AgileProductDesign.com

69 Ideally well write task-centric user stories to defer user interface design decisions – the tool decisions 69 hole (to put the flower in) dig hole hold options open © Jeff Patton, all rights reserved, AgileProductDesign.com

70 Understand what users are trying to accomplish, defer specific UI decisions till the last responsible moment 70 hole (to put the flower in) dig hole © Jeff Patton, all rights reserved, AgileProductDesign.com

71 Designing user interface specifically for a single iteration-level story often doesnt work Why doe you suppose that is? (Jeff pause here for participants to answer) Because Users think in terms of activities and functional tasks User stories are often written to build much smaller pieces of functionality Therefore Design user interface based on use Use that UI design as a blueprint. Each story implements a piece of that blueprint. The higher the goal-level of the user interaction, the lower the fidelity of UI design 71© Jeff Patton, all rights reserved, AgileProductDesign.com

72 Favor user task-centric stories to base UI design on Especially during early scoping and release planning project stages Especially before prototyping and testing proposed user interfaces Be prepared to split task-centric user stories as necessary to: defer expensive-to-implement user interactions for future release. to break up large user interface construction into more manageable pieces. Stories may become more tool-centric over time, and closer to development time Defer tool-centricity to the latest responsible moment 72© Jeff Patton, all rights reserved, AgileProductDesign.com

73 Usage to User Interface Collaboratively designing and testing great UI Jeff Patton jpatton@acm.org www.AgileProductDesign.com


Download ppt "User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton"

Similar presentations


Ads by Google