From Use     to User Interface
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

From Use to User Interface

  • 4,686 views
Uploaded on

From Use to User Interface- This 3-4 hour tutorial describes a practical approach to translating the goals users would like to achieve and the tasks they wish to accomplish into user interface......

From Use to User Interface- This 3-4 hour tutorial describes a practical approach to translating the goals users would like to achieve and the tasks they wish to accomplish into user interface designs that effectively support those goals and tasks.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,686
On Slideshare
4,673
From Embeds
13
Number of Embeds
2

Actions

Shares
Downloads
266
Comments
0
Likes
11

Embeds 13

http://www.slideshare.net 12
http://wildfire.gigya.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Jeff Patton [email_address] www.AgileProductDesign.com Please join a work group of 4-6 people – thanks. from Use to User Interface Collaboratively designing and testing user interface that help your users succeed Copyright is held by the author/owner(s). OOPSLA 2007, October 21–25, 2007, Montréal, Québec, Canada. ACM 07/0010. from Use to User Interface
  • 2. © Alistair Cockburn 2005-6 PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency Level 1: following ( shu ) Learn “a technique that works” (Success = following the technique) Level 2: breaking away ( ha ) Learn limits of the technique Learn to shift between techniques Level 3: fluent ( ri ) Shift techniques at any moment Possibly unable to describe the shifts
  • 3. We’ll be using a process miniature to explore and practice product design techniques
    • We’ll practice each technique in an abbreviated manner
    • You’ll get just enough time to feel what the technique is like to practice – but not enough to practice it well
    • Practicing it well, takes… practice
    • Pay attention to what’s working and what’s troublesome for you about the technique
  • 4. Section 1: Starting With Use
    • 13:30 – 15:00
    • User Experience Distilled Using Garrett’s Elements Model
    • Exploring Use
      • Elements of Use: User, Goal, Context
      • Use Cases, Task Models, User Scenarios
    • The User Story
    • Identifying User Needs as Canonical Components
    • The Interaction Context & Component Placement
  • 5. User Experience is Built From Dependent Layers
    • Jesse James Garrett’s Elements of User Experience
  • 6. The Surface Layer Describes Finished Visual Design Aspects Surface Skeleton Structure Scope Strategy
  • 7. The Skeleton Describes Screen Layout and Functional Compartments in the Screen Surface Skeleton Structure Scope Strategy
  • 8. Structure Defines Navigation from Place to Place in the User Interface task panes modal dialogs modal wizards Surface Skeleton Structure Scope Strategy
  • 9. The Places in the User Interface are Built to Support User Tasks
    • user tasks:
    • 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
  • 10. Business Goals Drive User Constituencies and Contexts Supported To Form Strategy
    • 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
  • 11. 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.
  • 12. Let’s Look At a Product We All Use: The Place We Live
    • goals:
    • live comfortably
    • eat well
    • stay clean
    • be healthy
    • keep up with Jones’s
    • user constituencies:
    • me
    • spouse
    • child
    • usage contexts:
    • suburban neighborhood
    • near good schools
    • near shopping
    Surface Skeleton Structure Scope Strategy
  • 13. What might I do to reach my goals?
    • 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
  • 14. Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy
  • 15. When designing a particular interaction context – a kitchen for instance – I optimize layout and tool choices to support tasks I’ll do there. Surface Skeleton Structure Scope Strategy
  • 16. I’m going to spend a lot of time here, I want my experience to be as pleasant as possible… Surface Skeleton Structure Scope Strategy
  • 17. Understanding the relationship between goals, tasks, & tools is critical Software Product Goals Tasks Tools Features one or more users engaged in many tasks in support of a common high level goal is often referred to as workpractice Surface Skeleton Structure Scope Strategy
  • 18. Garrett’s model provides helpful guidance for tool builders Goals Tasks Tools
    • Business Goals
    • User Model with User Goals
    • Architectural Goals Based On Context of Use
    • User Tasks & Activities, or Use Cases
    • Technology Independent
    • Navigation Map
    • Page Wireframes
    • UI Design Guidelines
    Surface Skeleton Structure Scope Strategy
  • 19. Today we’ll place our focus on tool-building: the structure, skeleton, & surface User Interface Prototyping Activities Surface Skeleton Structure Scope Strategy
  • 20. Getting started with a UI design problem
    • Read the Barney’s Information Kiosk problem on pages 35-36
    • Begin thinking about:
      • Business goals
      • Users and their goals
      • The types of user tasks users would likely choose to reach their goals
      • A kiosk tool that might support those tasks
      • (5 minutes)
    • As a workgroup discuss the users, goals, and most likely tasks performed on the kiosk
      • Try to talk about tasks without talking about the kiosk (tool) – this can be difficult
      • (5 minutes)
    Barney’s
  • 21. To design a tool, we first need to understand use – the preceding layer
    • Elements of Use:
    • A Type of User
      • Actor
      • User Role
      • User Profile
      • User Persona
    • User Goal
      • If I as a user accomplish this goal, I’ll consider myself successful.
      • Look for goals that motivate the use of software
    • Context of Use
      • Where and when will I be when I’m trying to accomplish this goal?
      • What other activities might I be engaged in when I attempt this goal?
  • 22. Modeling Use
    • Various types of models are used to capture what we understand about users engaged in tasks in pursuit of a goal.
      • Workflow Model
      • Use Case
      • User Task Model
      • User Scenario
      • User Story
  • 23. User Interface Designers Often Use “User Tasks” to Describe What People Do
    • Tasks require intentional action on behalf of a tool’s user
    • Tasks have an objective that can be completed
    • Tasks decompose into smaller tasks
    • Activities are used to describe a broader goal, one that might use many tasks, any may or may not ever be completed.
    • “ Read an email message” is a task, “Managing email” is an activity.
    activity task task task task task
  • 24. Use Cockburn’s goal level to understand the abstraction level of a user task Start to think about user interface design at sea level or above. * from Cockburn’s Writing Effective Use Cases
  • 25. A Agile User Story Might Model Use... It’s Easier to Design User Interface if it Does
    • 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:
    [achieve some goal ] so that I can [perform some task ] I want to [type of user ] As a purchase it quickly, leave, and continue with my day. so that I can locate a specific CD in the store I want to harried shopper As a
  • 26. User stories may describe user tasks or the tool that supports them User Story Software Product Goals Tasks Tools More task-centric : More tool-centric : locate a specific CD in the store I want to harried shopper As a enter a CD title into the search box and initiate a search I want to harried shopper As a
  • 27. 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
  • 28. Constantine & Lockwood’s Essential Use Case or “Task Case” is an easy way to begin to describe tool use
    • A use case 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
    System response System response Step one Step two System Responsibility User Intention
  • 29. Activity: Write an Essential Use Case
    • Review the business problem from your handouts (4-5 minutes)
    • As a team, using supplies on the table, write an essential use case for:
      • User: Casual Browser
      • Task: Find most current release for a particular artist
      • As a casual browser
      • I want to find the most current release for a particular artist
      • so that I can get more information to make a buying decision.
      • (10 minutes)
  • 30. Begin to envision a solution by writing a user scenario
    • A user scenario tells a story about a main character with a problem or goal
    • The scenario describes how our character reaches their goal using the proposed product
    • The scenario includes important facts, external context important to use, and goals and concerns of our character
    • The scenario should include interesting plot points that help us envision the more important aspects of the system
    • The scenario can gloss over uninteresting details
  • 31. User scenario: Field Manager enters daily shift performance reports
    • 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.
    • 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.
    • 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.
  • 32. Leveraging your task workflow model, write a user scenario for your focal user
    • Begin to think of a kiosk that will make the life of your focal user better
    • Tell a story of typical use
    • Include interesting plot points
    • Include goals and pains of your user
    • Describe how the system helps the user overcome problems or achieve goals
  • 33. Identifying UI tools that allow the system to meet its responsibilities to its user 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
    Container : contains and presents information. Action : allows execution of an action. Actionable Container : contains and presents information and allows the information to be acted on through selection or manipulation.
  • 34. Exercise: Identify the abstract components in your essential use case
    • Using post-it notes, identify abstract components to support your essential use case, and the essential use case in your handouts.
    • Give each component a descriptive name that suggests its responsibility.
    • (10 minutes)
    Selectable List
  • 35. Interaction Contexts Gather Tools to Support Tasks
    • An Interaction Context is an abstract “place” in your software that supports a number of tasks.
    • When the goal of a user changes, it’s grounds for an interaction context change.
    • For our design problem possible contexts might be:
    Starting Point: give the user a clear starting point for starting a search for titles in the store. Search Return: Evaluation: help the user decide if the searched for items were the items she was looking for or an easy way to reinitiate the search if not. Also aid in the quick decision to buy any successfully found item.
  • 36. Exercise: Build Up Interaction Contexts
    • As a group decide on and name your interaction contexts.
    • Use a name that suggests the type of tasks the context supports.
    • For each interaction context set aside a sheet of paper or card stock.
    • Relocate your post-it note abstract components to each context. If components belong in more than one context, write more post-it notes.
    • (10 minutes)
  • 37. From Use to User Interface Jeff Patton [email_address] www.AgileProductDesign.com
  • 38. Section 2: Designing & Validating For Use
    • 15:30 – 17:00
    • Building a Paper UI Prototype
    • Testing the Paper Prototype
    • Usability vs. Visual Design
    • Williams’ Simple Visual Design Heuristics
  • 39. Paper Prototyping Basics
    • Tools
      • 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)
    • Team approach
      • 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?
  • 40. Paper Prototyping Kit Demonstration
  • 41. Finished prototypes are pieced together from moveable and removable paper components
  • 42. Exercise: Build Your Prototype
    • As a team within the short time-box, build your prototype to support the two user stories:
      • As a casual browser
      • I want to find the most current release for a particular artist
      • -and-
      • As an impatient buyer
      • I want to find the location of a specific CD quickly
    • Suggestions:
      • One or more people build components
      • One or more assemble the prototype using the components
      • Someone use the task cases to validate the UI supports these user stories
    • (15 minutes)
  • 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
  • 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 you’d change.
  • 45. Testing In Action
  • 46. Exercise: Test Your Paper Prototype
    • (10 minutes)
      • casual browser, find the most current release for a particular artist
      • -and-
      • impatient buyer, find the location of a specific CD quickly
    • 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.
  • 47. Exercise: Fix Issues
    • As a team decide on which of the issues you discovered to fix.
    • Adjust your prototype to prepare for you next test.
    • (10 minutes)
  • 48. Exercise: Re-test Your Prototype
    • (10 minutes)
      • casual browser, find the most current release for a particular artist
      • -and-
      • impatient buyer, find the location of a specific CD quickly
    • 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.
  • 49. This isn’t just the right way to test, it’s RITE
    • Traditional usability testing focuses on:
      • Identifying repeatable user misteps errors
      • UI concerns that may make the software difficult to learn, or learned behavior hard to maintain
      • Reporting those errors back along with suggestions for correcting problems
    • The RITE method: Rapid Iterative Testing and Evaluation
      • First documented by Microsoft (Medlock, Wixon, Terrano, Romero, and Fulton)
      • Rather than focusing on number of errors identified, 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
  • 50. 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 mis-steps
    • 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.
  • 51. Layer in user interface concerns – like a layer cake
    • Start with usefulness:
      • Utility first
      • Usability second
      • Follow on with design esthetics
    • Defer user stories about design esthetics until after the software is useful
    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
  • 52. 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
  • 53. William’s 4 Basic Design Principles Visual Design Basics Robin Williams’ The Non-Designer’s Design Book
  • 54. Good Visual Design Observes 4 Simple Principles
    • Learn the principles
    • Recognize when you are and aren’t using them
    • Apply them to help users achieve their goals
    C R A P Contrast Repetition Alignment Proximity
  • 55. Proximity
    • Proximity communicates affinity – distance communicates lack of affinity.
    • Group related items together.
    • “ Clumps” of items can feel like one item.
  • 56. Alignment
    • 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
  • 57. Repetition
    • 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.
  • 58. Contrast
    • 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.
  • 59.  
  • 60.  
  • 61.  
  • 62.  
  • 63.  
  • 64. From Use to User Interface Jeff Patton [email_address] www.AgileProductDesign.com
  • 65. User Experience Words
    • User Centered Design
      • refers to a class of methodologies where design decisions are based on some tangible user model. That user model must be based on the research of the users of the application.
    • Interaction Design
      • refers to the specific choices of user interactions we make to allow users to meet their goals in the software. Interaction Designers are generally User Centered Designers.
    • Visual Design
      • refers to the design of the visual appearance of software, advertising, or other commercial products. Visual Design focuses a bit more on esthetics. Visual Designers are often NOT User Centered Designers.
  • 66. User Experience Words
    • Usability
      • Usability refers to the ability of a specific type of user to be able to effectively carry out a task using a product.
      • Usability is usually measured through testing. Given a number of test subjects that reflect the type of user that will use the application:
        • how many successfully complete a task.
        • on average how quickly do they complete that task.
        • on average how many user errors are made while attempting to complete that task.
    • Usability Engineering
      • refers to the practice of usability. Usability Engineers often have much in common with testers. While they may design the user interface, often their emphasis is on evaluating the user interface and making recommendations for improvement. Usability Engineers are generally User Centered, but they may not be Designers.
  • 67. User Experience Words
    • Information Architecture
      • refers to the structuring of information so that it best supports the consumption by its target users. An IA professional is often considered a counterpart to an Interaction Designer where Interaction Designers focus on how people use computers to accomplish work, and Information Architects focus on how people leverage information to support goals.
    • HCI or CHI
      • Human-Computer, or Computer-Human interaction refers to the study of how humans and computers interact. An HCI professional may be a researcher, a designer, a psychologist, or anyone who might focus on human-computer interaction as part of their work or study.
  • 68. User Experience Words
    • User Experience
      • refers to the overall experience a user has with a product. This experience doesn’t stop at the use of the product but starts with the advertising and presenting of the brand through the purchase to the use and the day-to-day feeling the user carries with them about the product.
    • User Experience Professional
      • may refer to any of the roles already discussed. Someone whose day-to-day practice focuses on improving some or all aspects of user experience.
      • We are all directly or indirectly User Experience Practitioners… how professional we are at it may be up for discussion.
  • 69. 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
  • 70. 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
  • 71. From Use to User Interface Jeff Patton [email_address] www.AgileProductDesign.com