Jeff Patton jpatton@acm.org www.agileproductdesign.com User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton jpatton@acm.org www.agileproductdesign.com
Our goals and agenda today Goal: feel comfortable design and testing functional, usable, user interface Part 1: Understanding the user’s experience Understanding user’s 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.com
People achieve goals through interaction problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation Is my goal met or problem resolved? Take some action action evaluation Did that action deliver the results I expected? the world Information and tools (c) Jeff Patton, AgileProductDesign.com (c) Jeff Patton, AgileProductDesign.com
Think of three levels: goal, task, and tool From User Story to User Interface Think of three levels: goal, task, and tool problem or goal How I’d like to feel, or what I’d like to achieve goal Take some action action evaluation Did that action deliver the results I expected? goal evaluation Is my goal met or problem resolved? task the world Information and tools tool (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Goals, tasks, and tools apply at both a personal and organizational level From User Story to User Interface business objectives tasks tools goals business processes "The problem is all inside your head", she said to me The answer is easy if you take it logically I'd like to help you in your struggle to be free There must be fifty ways to leave your lover She said it's really not my habit to intrude Furthermore, I hope my meaning won't be lost or misconstrued But I'll repeat myself at the risk of being crude There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Ooo slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free She said it grieves me so to see you in such pain I wish there was something I could do to make you smile again I said I appreciate that and would you please explain About the fifty ways She said why don't we both just sleep on it tonight And I believe in the morning you'll begin to see the light And then she kissed me and I realized she probably was right There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free employees, vendors, & systems (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Getting started with a UI design problem From User Story to User Interface Getting started with a UI design problem Barney’s Read the Barney’s 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 Barney’s 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 (c) Jeff Patton, AgileProductDesign.com Your team Jeff Patton, jpatton@acm.org www.agileproductdesign.com
What are the user’s goals and businesses goals? From User Story to User Interface What are the user’s goals and businesses goals? Business goals or pain points? Types of users using this system? User’s goals or pains? For business goals or pains: Why would the business pay for this software to be built? What outcome is expected that will compensate for the cost of building the software? Identify types of users as: Actor User Role User Profile User Persona For each type of user, what goals or pains motivate the use of the product? If I as a user accomplish this goal, I’ll consider myself successful. Look for goals that motivate the use of software (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
What will users do with the system to reach their goals? From User Story to User Interface 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 For business goals or pains: Why would the business pay for this software to be built? What outcome is expected that will compensate for the cost of building the software? Identify types of users as: Actor User Role User Profile User Persona For each type of user, what goals or pains motivate the use of the product? If I as a user accomplish this goal, I’ll consider myself successful. Look for goals that motivate the use of software (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
User tasks are decompose to smaller tasks and organize into activities From User Story to User Interface Tasks require intentional action on behalf of a tool’s user Tasks have an objective that can be completed Tasks decompose into smaller tasks Tasks often cluster together in activities activity task task (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
User tasks are decompose to smaller tasks and organize into activities From User Story to User Interface User tasks are decompose to smaller tasks and organize into activities Tasks require intentional action on behalf of a tool’s 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. activity manage email read message task send message task prioritize message task task create folder task place message in folder delete message task (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Activities have characteristics relevant to the software we’ll 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.. activity task (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Be sensitive to user task “altitude” From User Story to User Interface Be sensitive to user task “altitude” Too abstract Activity or “Kite level” Longer term goals often with no precise ending. I’ll perform several functional tasks in the context of an activity Think about user interface design at about this level Functional or “Sea level” I’d reasonably expect to complete this in a single sitting Sub-Functional or “Fish level” Small tasks that by themselves don’t mean much. I’ll do several of these before I reach a functional level goal Too detailed * from Cockburn’s Writing Effective Use Cases (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Describe the user experience of the product (c) Jeff Patton, AgileProductDesign.com
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 user’s intention Determine the system responsibilities based on user goals and expectations User Intention System Responsibility Step one System response Step two (c) Jeff Patton, AgileProductDesign.com
Write an Essential Use Case From User Story to User Interface Write an Essential Use Case As a team, using supplies on the table, write an essential use case for: 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface 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 © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Field Manager enters daily shift performance reports From User Story to User Interface Steven Credit Card Marketing Field Manager Steven is a field manager working at the local shopping center. He’s 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. The date is defaulted to today, and the shift is defaulted to ‘morning’ since he hasn’t yet entered info for today. Steve begins to enter the reps name, but after a few characters the system auto-completes his name. The rep’s ID is already filled in, along with the code for the credit card promotion they’re working on today. Steve fills in the shift information for his rep. He then enters the total number of applications taken. 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. Time passes as more reps bring in their sheets and Steve completes entering them in between conversations. After all the sheets are done, Steve looks at a summary screen for the day. It looks like he’s close to his goal. If the next shift continues at this rate he’ll beat the plan by 5% or so. That’s good. Steve validates that the base pay is correct at $5 per app, and that he’s 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. The annual sale at Macy’s 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. Field Manager’s Scenario 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 he’s signed off. In between visits by reps, Steve opens his Field Manager Workbench on his laptop. After logging in he sees today’s date and the planned number of applications his reps should be gathering – 180 for today. He also sees yesterday’s numbers, and last week’s numbers, and the last 30 days in graph that shows applications relative to approval rate. Last week’s numbers were bad, and it’s the last week of the month, so Steve knows he’s got to do well today. Steve clicks “enter rep performance data.” He shuffles his reps performance sheets and grabs the first one. Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Imagine the user experience as a scenario From User Story to User Interface 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 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Begin to think about the UI design © Jeff Patton, all rights reserved, AgileProductDesign.com
Garrett describes the dependent layers that build up UI From User Story to User Interface Garrett describes the dependent layers that build up UI Jesse James Garrett’s Elements of User Experience © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
The surface layer describes finished visual design aspects From User Story to User Interface Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface The skeleton describes a screen’s layout and the functional compartments in the screen From User Story to User Interface Surface starch vegetable Skeleton dessert! entree Structure Scope Strategy (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Structure defines navigation from place to place in the user interface From User Story to User Interface Surface task panes Skeleton Structure modal dialogs Scope modal wizards Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface The places in the user interface are built to support what people do – the user’s tasks From User Story to User Interface 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Business goals drive user constituency selection and contexts supported to form strategy From User Story to User Interface 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Garret’s 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. (c) Jeff Patton, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Let’s look at a strategy for a product we all use: the place we live From User Story to User Interface goals: live comfortably eat well stay clean be healthy keep up with Jones’s … 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
What tasks might I and my family do to reach our goals? From User Story to User Interface 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
I’ll arranging tasks by affinity to help identify structure From User Story to User Interface Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
I’ll optimize layout and tool choices to support tasks From User Story to User Interface Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface I’m going to spend a lot of time here, I want my experience to be as pleasant as possible… From User Story to User Interface Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
The goal-task-tool model maps to Garrett’s elements model From User Story to User Interface The goal-task-tool model maps to Garrett’s elements model Surface Skeleton Structure Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
The goal-task-tool model maps to Garrett’s elements model From User Story to User Interface Surface Skeleton Structure tools tasks Scope goals Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
The goal-task-tool model maps to Garrett’s elements model From User Story to User Interface The goal-task-tool model maps to Garrett’s elements model Surface Skeleton Structure User Interface Prototyping Scope Strategy © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Identify “tools” as abstract UI components From User Story to User Interface 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 Information or Material: contains and presents information. Larry Constantine 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. © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Exercise: Identify the abstract components in your user scenario From User Story to User Interface Exercise: Identify the abstract components in your user scenario Using post-it notes, identify abstract components the user experience you’ve 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. © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
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) © Jeff Patton, all rights reserved, AgileProductDesign.com
Build prototypes from moveable and removable paper components From User Story to User Interface Build prototypes from moveable and removable paper components Build a prototype from bits of paper and cardstock Tools you’ll 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) You may also choose to print and cut apart existing user interfaces or data from an existing system © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
In small teams, build up paper prototypes a component at a time From User Story to User Interface In small teams, build up paper prototypes a component at a time Use a team approach to build up a componentized paper prototype: Someone direct traffic Various people build components Someone assemble the user interface from the components Someone continuously review what’s being assembled against your use case – will it work? © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface We build the prototype from components so we can play the role of a computer during testing From User Story to User Interface © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Joe’s suggests we also use a recording of the prototype as documentation From User Story to User Interface © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Exercise: Build Your Prototype From User Story to User Interface 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: 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Preparing to Testing Your Paper Prototype From User Story to User Interface 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 © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Run Your Usability Test From User Story to User Interface 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 you’d change. © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Watch as each participant plays their role during light weight usability testing 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 they’re safe Sports caster making sure participants keep talking going so we know what they’re thinking Scientists working hard not to bias the results by giving users hints © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Exercise: Test Your Paper Prototype From User Story to User Interface Exercise: Test Your Paper Prototype 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 you’d change. 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
This isn’t just the right way to test, it’s RITE From User Story to User Interface This isn’t just the right way to test, it’s 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 See “Getting Software RITE”: http://www.agileproductdesign.com/writing/ieee/patton_getting_software_rite.pdf © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Unraveling Usability Concerns From Visual Design Concerns From User Story to User Interface 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 can’t 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. Don’t assume those skilled at visual design are also skilled at usability. © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Layer in user interface concerns – like a layer cake From User Story to User Interface Start by making useful software Choose appropriate utility first Usability second Defer design esthetics until after the software is useful design esthetics (is the software fun, pleasant, exciting – what is my emotional response?) usability (can that functionality easily learned, and effectively used?) usefulness utility (does the software offer functionality to support my goals?) © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Test First – Building Confidence into Software Development From User Story to User Interface Test First – Building Confidence into Software Development Agile development’s test-first technique doesn’t 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 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 Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Jeff Patton jpatton@acm.org www.agileproductdesign.com User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton jpatton@acm.org www.agileproductdesign.com
William’s 4 Basic Design Principles Visual Design Basics From User Story to User Interface William’s 4 Basic Design Principles Visual Design Basics Robin Williams’ The Non-Designer’s Design Book Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Visual design that communicates effectively four simple principles From User Story to User Interface 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. Contrast Repetition Alignment Proximity C R A P © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Proximity communicates affinity From User Story to User Interface 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? © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Alignment communicates association From User Story to User Interface 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 it’s on the same screen it’s 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? © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Repetition helps calm and unify a design From User Story to User Interface 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 what’s changed. Q: does repetition help calm and unify the design? © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Contrast communicates importance From User Story to User Interface Contrast communicates importance Use contrast to focus the users attention, to guide him/her through the application. Contrast, or don’t. If two items are not exactly the same, make them different – really different. Subtle difference isn’t contrast, it’s 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? © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Usability Refers To The Ability of a User To Effectively Execute A Task Using a Tool “While Visual Design certainly can affect usability, it’s quite possible for a product to have pleasing visual design, but intolerable usability.” Don Norman’s The Design of Everyday Things © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Nielsen’s 10 Usability Heuristics From User Story to User Interface Nielsen’s 10 Usability Heuristics Visibility of system status (keep the user informed) Be forthcoming - don’t hide information Match between system and real world (user language and real world conventions) Watch your language User control and freedom (easy exits, undo and redo) padded corners, hand rails, and safety nets Consistency and standards same thing the same way Error prevention Recognition rather than recall (reduce remembering with visible options, actions, and instructions) Flexibility and efficiency of use (customization and support for advanced users) Aesthetic and minimalist design (reduce irrelevant or rarely needed information) Help in recognizing, diagnosing, and recovering from errors Good help and documentation Jakob Nielsen’s Usability Engineering © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Jeff Patton jpatton@acm.org www.agileproductdesign.com User-Centered Design for Better Human Interfaces Collaboratively designing and testing great UI Jeff Patton jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface An Agile User Story Might Model Use... It’s Easier to Design User Interface if it Does From User Story to User Interface 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 Cohn’s User Stories Applied combines user, task, and goal: * Kent Beck coined the term user stories in Extreme Programming Explained 1st Edition, 1999 As a [type of user] I want to [perform some task] so that I can [achieve some goal] As a harried shopper I want to locate a specific CD in the store so that I can purchase it quickly, leave, and continue with my day. © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface In practice user stories may be written to describe user tasks or the tools that support them software tasks features goals More task-centric: As a weekend gardener I want to dig a hole so that I can plant a tree user story More tool-centric: (or feature-centric) "The problem is all inside your head", she said to me The answer is easy if you take it logically I'd like to help you in your struggle to be free There must be fifty ways to leave your lover She said it's really not my habit to intrude Furthermore, I hope my meaning won't be lost or misconstrued But I'll repeat myself at the risk of being crude There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Ooo slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free She said it grieves me so to see you in such pain I wish there was something I could do to make you smile again I said I appreciate that and would you please explain About the fifty ways She said why don't we both just sleep on it tonight And I believe in the morning you'll begin to see the light And then she kissed me and I realized she probably was right There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free As a weekend gardener I want a shovel so that I can [dig a hole to] plant a tree © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface In practice user stories may be written to describe user tasks or the tools that support them software tasks features goals More task-centric: As a weekend gardener I want to dig a hole so that I can plant a tree user story More tool-centric: (or feature-centric) "The problem is all inside your head", she said to me The answer is easy if you take it logically I'd like to help you in your struggle to be free There must be fifty ways to leave your lover She said it's really not my habit to intrude Furthermore, I hope my meaning won't be lost or misconstrued But I'll repeat myself at the risk of being crude There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Ooo slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free She said it grieves me so to see you in such pain I wish there was something I could do to make you smile again I said I appreciate that and would you please explain About the fifty ways She said why don't we both just sleep on it tonight And I believe in the morning you'll begin to see the light And then she kissed me and I realized she probably was right There must be fifty ways to leave your lover Fifty ways to leave your lover You just slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just get yourself free Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free Slip out the back, Jack Make a new plan, Stan You don't need to be coy, Roy Just listen to me Hop on the bus, Gus You don't need to discuss much Just drop off the key, Lee And get yourself free As a weekend gardener I want a shovel so that I can [dig a hole to] plant a tree © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Ideally we’ll write task-centric user stories to defer user interface design decisions – the tool decisions hole (to put the flower in) dig hole hold options open © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Understand what users are trying to accomplish, defer specific UI decisions till the last responsible moment hole (to put the flower in) dig hole © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
From User Story to User Interface Designing user interface specifically for a single iteration-level story often doesn’t 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 © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Favor user task-centric stories to base UI design on From User Story to User Interface 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 © Jeff Patton, all rights reserved, AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com
Usage to User Interface Collaboratively designing and testing great UI From User Story to User Interface Jeff Patton jpatton@acm.org www.AgileProductDesign.com Jeff Patton, jpatton@acm.org www.agileproductdesign.com