Know the user
Upcoming SlideShare
Loading in...5
×
 

Know the user

on

  • 535 views

Lecture notes on understanding the user's role in interface design and underlining the need to better appreciate the concerns of users.

Lecture notes on understanding the user's role in interface design and underlining the need to better appreciate the concerns of users.

Statistics

Views

Total Views
535
Views on SlideShare
519
Embed Views
16

Actions

Likes
0
Downloads
7
Comments
0

1 Embed 16

http://jkwp.itsligo.ie 16

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Ackroyd study of an expert system installed in a police department in Northern England. Purpose of system was to help them identify possible suspects in unsolved criminal cases. It allowed details of a crime to be entered at a special dedicated computer terminal and would then search through criminal records and suggest names of people to investigate further. System was not popular with detectives, and received very little use. This was an unexpected outcome, because the system performed reliably according to the specification drawn up for it. However, its design did not fit well with the organisation of the detective ’ s day. Detectives often interrupted 4 times during 90 minute period and can be see interrupting other members of the force at least once. Expert system required users to leave their desks and go to the terminal room, log in to the system, set up the details of the unsolved case, and then spend enough time at the terminal to scan the names it produced. Detectives however felt obliged to be at their desks, available to take messages and handle emergencies. Other study concerns the unexpected usefulness of a system for generating reports of crime statistics. In the police department where it was installed, its main purpose was to provide management with up-to-date statistics so that they could make strategic decisions about resource allocations according to crime trends. After some initial teething troubles had been resolved, it became a useful adjunct to the department ’ s information systems. One of its unexpected uses was in supporting detectives during certain kinds of interviews. From time to time, detectives encountered suspects who are confessing to crimes and willing to plea-bargain. Detectives used system to check the details of the confessed crimes. Often interview was moved to the data-entry room which itself was found conducive to confessing! Detectives weren ’ t concerned by their absence from their desks as they were getting rapid results.
  • Users encounter difficulties of many kinds. Routing use of office software, for example, may involve problems such as these: The size of documents are measured in bytes, not pages or words. Finding a document involves remembering a file name such as jhb-8-29-94.txt, not a location in a file-cabinet drawer. Entering simple data, such as a date, may involve translation into an obscure format, for example, 29 th August 1994 may become 940829.
  • University self-service cafeteria Functional: The system will calculate the total cost of purchases Data: The system must have access to the price of products in the cafeteria Environmental: Cafeteria users will be carrying a tray and will most likely be in a reasonable rush. The physical environment will be noisy and busy, and users may be talking with friends and colleagues while using the system. User: The majority of users are likely to be under 25 and comfortable dealing with technology. Usability: The system needs to be simple so that new users can use the system immediately, and memorable for more frequent user. Users won ’ t want to wait around for the system to finish processing, so it needs to be efficient and to be able to deal easily with user errors. Nuclear Power Plant Functional: The system will need access to temperature readings Data: The physical environment is likely to be uncluttered and to impose few restrictions on the console itself unless there is a need to wear protective clothing (depending on where the console is to be located. User: The user is likely to be a well-trained engineer or scientist who is competent to handle technology. Usability: Outputs from the system, especially warning signals and gauges, must be clear and unambiguous. Distributed Design Teams Functional: The system will be able to communicate information between remote sites. Data: The system must have access to design information that will be captured in a common file format. Environmental: Physically distributed over a wide area. Files and other electronic media need to be shared. The system must comply with available communication protocols and be compatible with network technologies. User: Professional designers, who may be worried about technology but who are likely to be prepared to spend time learning a system that will help them perform their jobs better. The design team is likely to be multi-lingual. Usability: Keeping transmission error rate low is likely to be of high priority.
  • Gaver et al (1999) Three different groups: Oslo, Amsterdam, Pisa. Materials: 8-10 postcards: “ Tell us a piece of advice or insight that has been important to you ” ; “ What is your favourite device? ” ; “ What is the role of art in your life? ” 7 maps: Mark sites where they meet people; or to be alone; to daydream. Mark places they ’ d like to visit in the world Disposable camera: First person they see that day.; something desirable; photo album: tell stories with pictures media diary: record use of radio and tv Amsterdam: proposed network of computer displays for communication Oslo: community-wide conversation led by elders about social issues, with questions published in e-Kiosks for the public to answer Pisa: social and pastoral radio-scapes to create flexible comms networks. Side benefit: provoked elderly to consider their role and the pleasure they experience, hinting possible future roles. Contextual Enquiry Contextual Enquiry (CE) is a technique for examining and understanding users and their workplace, tasks, issues and preferences. CE can be used to produce user needs analyses and task analyses. The results of a CE feed directly into the design process. Although CE is time-consuming, it uncovers a wealth of invaluable data. When is CE appropriate? CE is appropriate whenever you need to develop or communicate an understanding of the users of an existing or proposed system. How is a CE conducted? A contextual enquiry consists of visiting several users on site, observing them carrying out their tasks, and analyzing and documenting the resultant data. How many people are needed? Two people should be involved in any site visits, if possible. It is not possible to capture all the available information, but using two people maximizes the data returned. At least two people should be involved in analyzing the data. Site visit materials When carrying out site visits, you will need the following materials: A list of representative users. Include both expert and novice users in your visits. Logging sheets. Expect to make copious notes. You may consider audio- or video-recording; however the unpredictable nature of the activity often makes this difficult. Demographic questionnaire for user profiling. User satisfaction questionnaire. How do you analyze the data? Immediately after each site visit you should enter your data into a word processing program. Your notes should be at the lowest possible level of granularity. Number each note, and print them out on labels or cards. Use a system that allows you to trace every individual note to its source (for example, 'User 1, Note 57'). Use the notes in sequence to construct sequence models of the tasks carried out.Use affinity diagramming to group all related issues. Site Visit guidelines Remember that the purpose of site visits is to learn from your users. Ensure you obtain appropriate approvals from management and employee organizations. Try to minimize disruption. However, try not to accept a time-slot that will not enable you to see the work being done in a typical fashion. Avoid preconceptions about the users and their tasks. Ensure that you do not give negative signals to the users, either verbally or by your body language. Do not prompt users to carry out tasks differently, or in an order other than the one they use normally. Do not rely on users' recollection of how they carry out tasks. Instead, ask them to carry out the actual tasks while you are on site. Listen and watch attentively. Remember that the users are the only domain experts. Be respectful of your users, their employers and colleagues. Be flexible. It is common to arrive on site to find that users' expectations do not match your plan, no matter how much effort you may have put into communicating your requirements. Be prepared to make the most of available resources. Guidelines for data analysis Avoid unsupported conclusions. If a conclusion appears to be correct but unsupported, re-examine the data and your method to see whether you have missed anything. As a rule of thumb, plan for four hours of analysis time for every one hour on site. Be prepared to contact users by phone to verify any observations which are doubtful.
  • A scenario is a description of a person's interaction with a system. Scenarios help focus design efforts on the user's requirements, which are distinct from technical or business requirements. Scenarios may be related to 'use cases', which describe interactions at a technical level. Unlike use cases, however, scenarios can be understood by people who do not have any technical background. They are therefore suitable for use during participatory design activities. When are scenarios appropriate? Scenarios are appropriate whenever you need to describe a system interaction from the user's perspective. They are particularly useful when you need to remove focus from the technology in order to open up design possibilities, or when you need to ensure that technical or budgetary constraints do not override usability constraints without due consideration. Scenarios can help confine complexity to the technology layer (where it belongs), and prevent it from becoming manifest within the user interface. How do you write scenarios? To write a scenario, you need a basic understanding of the tasks to be supported by the system. You also need to have an understanding of the users and the context of use. Scenarios can be derived from data gathered during contextual enquiry activities. If you do not have access to such data, you can write scenarios based on prior knowledge or even 'best guess', provided the scenarios will be subject to review by users prior to being used as a basis for making design decisions. To write a scenario, describe in simple language the interaction that needs to take place. It is important to avoid references to technology, except where the technology represents a design constraint that must be acknowledged. Include references to all relevant aspects of the interaction, even where they are outside the current scope of the technology. Such references may include cultural and attitudinal issues. For example, the fact that Jane is continually interrupted by telephone calls may be just as relevant as the software platform she uses. After you have written a scenario, review it and remove any unwarranted references to systems or technologies. For example, the statement 'the customer identifies herself' is appropriate, whereas 'the customer types her 4-digit PIN' is not (unless the PIN is a non-negotiable system constraint). You should also have the scenario reviewed by users to ensure that it is representative of the real world. How do you use scenarios? Use scenarios during design to ensure that all participants understand and agree to the design parameters, and to specify exactly what interactions the system must support. Translate scenarios into tasks for conducting walk-through activities and usability tests. Example The following is a sample scenario describing a customer withdrawing money from an automated teller machine (ATM). It's Friday afternoon and Joe is flying to Sydney. He doesn't have enough money for a taxi to the airport, and he's running late. He goes to the local ATM and identifies himself. He specifies that he wants $100 from his savings account. He'd like the money in $20 notes so that he can give the taxi driver the correct change. He doesn't want a printed receipt, as he doesn't bother keeping track of transactions in this account. Note that this description specifically avoids references to transaction cards and PINs. This leaves open the possibility of considering a variety of identification and authorization regimes. Be prepared to review scenarios based on feedback from users. In particular, be prepared to modify or even abandon any unrealistic or unrepresentative scenarios.

Know the user Know the user Presentation Transcript

  • Know the User John Kelleher IT Sligo
  • Designing for the user
  • Basic Activities of Interaction Design
    • Identifying needs and establishing requirements [Part 2]
    • Developing alternative designs [Part 3]
    • Building interactive versions of the designs [Part 3]
    • Evaluating designs [Part 4]
  • Overview of Needs Identification
    • The importance of requirements
    • Different types of requirements
    • Data gathering
    • Task descriptions: Scenarios Use Cases
    • Task analysis: HTA
    • Task analysis techniques focus on:
      • understanding users' tasks
      • breaking them down into tasks and actions
    • It clarifies and organizes user ’s knowledge about a system.
    • Work-flow patterns are identified
      • Frequency of different tasks performed
      • What tasks are done with what tasks
      • Order of work tasks
      • Communication pathways
      • Exceptions – when is task A not done?
    Information Gathered from Task Analysis
  • Why do Requirements?
    • Uncovered information may lead to:
      • abandoning a bad idea
        • video-phones, recipe management programs
      • very good ideas
        • Window usage matches a working set model – E.g. Rooms
      • basis for driving design
        • protects from building a useless program
    • Often assumptions designers have about users and interface are wrong
    • E.g. Ackroyd study of English Detectives
  • Information Gathered
    • Users ’ conceptual model
      • What is the external representation that is used to do the task - worksheets, patient charts
      • What organization or model do users keep in their head as they are doing the task?
    • Interrelationships among objects & tasks
      • Task specificity of various task objects - eraser for removing marks on a page
      • Organization of objects into larger task objects,
        • page->section->chapter->book->library
  • SharpReader Conceptual model derived from user ’ s knowledge of Outlook
  • Information Gathered
    • Use of other systems and/or applications
      • Use of accelerator keys
      • Use of command-based rather than GUI applications
      • Use of telephones, voice mail systems and fax machines
    • User Characteristics
      • Task experience and knowledge of the domain.
      • System experience
      • Application experience, e.g., other WPs
      • Computer literacy
    • 50:34 Controller: Scandinavian 515 route direct to Detling.
    • 50:42 SK515: Roger, direct Detling, SK515.
    • 51:14 [Controller takes phone call] ... If you like.. OK.
    • 51:49 Controller: SK515, descend now to flight level 100, one-five miles before Detling.
    • 52:00 SK515: Roger, level 100 to be level fifteen miles before Detling, SK515.
    • 52:04 Controller: ’kyou.
    • [Controller sorts flight strips]
    • 53:22 [Controller to assistant] Ferry 201 ... is Ferry 201 past?
    • 53:27 Controller: Air Ferry 201 continue with Amsterdam 125 decimal 7, good-day.
    • 53:34 BAF201: 125 er 7, good-day.
    • [Discussion with other controllers]
    • 55:21 Controller: SK515, what ’s your present heading?
    • 55:25 SK515: Roger, ’ding 240, SK515.
    • 55:28 Controller: Roger, turn left, heading 220, keep you clear of the danger area.
    • 55:25 SK515: Roger, heading 220, Scandinavian 515.
    • [Controller sorts flight strips]
    • 55:47 Controller: Speedbird 723, you can turn, er, for Lambourn, descend when ready to flight level 150.
    • 55:56 BA723: Roger, recleared, when ready level 150 and turning direct for Lambourn, Speedbird, er, 723.
    Transcription of 6 minutes of an ATC exchanges with flights traversing a sector in the London area
  • Establishing requirements
    • What do users want? What do users ‘ need ’ ?
      • Requirements need clarification, refinement, completion, re-scoping
      • Input : requirements document (maybe)
      • Output : stable requirements
  • Different kinds of requirements
    • Functional:
        • What the system should do
        • Historically the main focus of requirements activities
    • (Non-functional: memory size, response time... )
    • Data:
        • What kinds of data need to be stored?
        • How will they be stored (e.g. database)?
  • Different kinds of requirements
    • Environment or context of use:
        • physical: dusty? noisy? vibration? light? heat? humidity? …. (e.g. OMS insects, ATM)
        • social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients
        • organisational: hierarchy, IT department ’ s attitude and remit, user support, communications structure and infrastructure, availability of training
    • Users – who are they?
  • Different kinds of requirements
    • Usability:
      • learnability, effectiveness, flexibility, utility, memorability, efficiency, safety.
      • Note that user requirements and usability requirements refer to different things
  • Kinds of requirements
    • What factors (environmental, user, usability) would affect the following systems?
      • A system for use in a university ’ s self-service cafeteria that allows users to pay for their food using a credit system.
      • A system to control the functioning of a nuclear power plant
      • A system to support distributed design teams, e.g. for car design
  • Define goals for your application
      • Can be learned in less than 2 minutes
      • User will perform 2 error-free purchases per session
      • The error rate will be lower than 2 per 10 operations
      • Tasks will be performed in 30% of the time it takes using the competitor ’s system
    • Users will have a high satisfaction with the system as measured by a survey.
    • Explicit, specific, measurable metrics.
    • Tradeoffs, so have to pick relevant metrics e.g. learnability versus efficiency
  • Categories of Users
    • Mandatory
    • Discretionary
    • Intermittent
    • Level of Expertise
      • Novice
      • Intermediate
      • Expert
  • Level of Expertise
    • Novice
        • frequent feedback;
        • actions prompted by choices
        • safe exploration supported - robust
        • easy undo
        • selective disclosure
    • Intermediate
        • knowledge of broad aspects
        • need easy access to the details
        • can be amalgam of novice and expert
          • Also true of novice and expert.
  • Levels of Expertise (contd.)
    • Experts
      • critical help system user
      • lower, more subtle support and feedback
      • accelerators required
      • customisability desired to facilitate cross-application usage
      • only assumption – experts less risk-averse in usage pattern
  • User categories ( anecdotal )
    • Novice user someone who is afraid if they touch the keyboard they will break the system.
    • Intermediate user someone who has broken the computer and doesn ’ t know how to fix it.
    • Expert user someone who breaks other people ’ s computers.
  • Data gathering techniques (1)
    • Questionnaires
      • Keep the number of questions low
        • Only questions with answers that you can ’t get other ways
        • Only questions that will have a direct impact on functional requirements
        • Avoid asking for everything
      • Ask clear questions
      • Ask questions that users can answer validly and reliably
        • Does the user store information in this way?
        • Does the user remember such information?
        • Will the user be inclined to answer your question truthfully?
      • Good for answering specific questions from a large, dispersed group of people
  • Data gathering techniques (2)
    • Interviews:
      • Forum for talking t o people
      • Structured, unstructured or semi-structured
      • Props, e.g. sample scenarios of use, prototypes, can be used in interviews
      • Good for exploring issues
      • But are time consuming and may be infeasible to visit everyone
  • Data gathering techniques (3)
    • Workshops or focus groups:
      • Group interviews
      • Good at gaining a consensus view and/or highlighting areas of conflict
  • Data gathering techniques (4)
    • Naturalistic observation:
      • Spend time with stakeholders in their day-to-day tasks, observing work as it happens
      • Gain insights into stakeholders ’ tasks
      • Good for understanding the nature and context of the tasks
      • But, it requires time and commitment from a member of the design team, and it can result in a huge amount of data
      • Ethnography is one form
  • Data gathering techniques (5)
    • Studying documentation:
      • Procedures and rules are often written down in manuals
      • Good source of data about the steps involved in an activity, and any regulations governing a task
      • Not to be used in isolation
      • Good for understanding legislation, and getting background information
      • No stakeholder time, which is a limiting factor on the other techniques
  • Data gathering techniques (6)
    • Contextual Enquiry
      • Way of understanding users ’ needs and work practices
      • Master – apprentice model allows customer to teach us what they do!
        • master does the work & talks about it while working
        • we interrupt to ask questions as they go
      • The Where, How, and What expose the Why
    • Presence Project 1
    1 Gaver et al (1999) Cultural probes. ACM Interactions Magazine, January and February, 21-29 Cultural Probes
  • Task descriptions
    • Scenarios
      • an informal narrative story, simple, ‘natural’, personal, not generalisable
      • illustrate using storyboards
        • sequences of sketches showing screens & transitions
      • good to demonstrate to management, marketing and customers
      • can replace much textual specification
      • similar to Use Cases in Software Engineering
      • See Brad Meyers at 0:46.05
  • Scenario for shared calendar Victoria is a bright young college student looking for a gift for her younger sister, who is turning 16 in two weeks. Like most college students, Victoria is on a tight budget, but wants to get something memorable and useful for her sister on this important birthday for a young girl. She ’ s heard some of her friends talk about ebirthdayz.com, and so she decides to check it out. On the ebirthdayz.com homepage, she sees that the Web site has a gift recommendation feature. Victoria finds the recommendations screen and sees gifts based on her sister ’ s age and general interests, as well as her own limited finances. The site shows some suggestions, and Victoria chooses a popular favourite and buys it, including gift-wrapping. Total time spent: 20 minutes. ”
  • Scenarios (cont.)
    • Scenarios are design specific , tasks aren ’t
    • Scenarios force us to
      • show how various features will work together
      • settle design arguments by seeing examples
        • only examples  sometimes need to look beyond
    • Show users storyboards
      • sequences of sketches showing screens
      • actions users can take
      • get feedback
  • Storyboards
  • Task analysis
    • Task descriptions are often used to envision new systems or devices
    • Task analysis is used mainly to investigate an existing situation
    • It is important not to focus on superficial activities
      • What are people trying to achieve?
      • Why are they trying to achieve it?
      • How are they going about it?
    • Many techniques, the most popular is Hierarchical Task Analysis (HTA)
    • GOMS is also used
  • Hierarchical Task Analysis
    • Involves breaking a task down into subtasks, then sub-sub-tasks and so on. These are grouped as plans which specify how the tasks might be performed in practice
    • HTA focuses on physical and observable actions, and includes looking at actions not related to software or an interaction device
    • Start with a user goal which is examined and the main tasks for achieving it are identified
    • Tasks are sub-divided into sub-tasks
  • Example Hierarchical Task Analysis 0. In order to borrow a book from the library 1. go to the library 2. find the required book 2.1 access library catalogue 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3. go to correct shelf and retrieve book 4. take book to checkout counter
  • Example: Hierarchical Task Analysis (plans) plan 0: do 1-3-4. If book isn ’ t on the shelf expected, do 2-3-4. plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4.
  • Example Hierarchical Task Analysis (graphical) Borrow a book from the library go to the library find required book retrieve book from shelf take book to counter 3 2 1 4 0 access catalogue access search screen enter search criteria identify required book note location plan 0: do 1-3-4. If book isn ’ t on the shelf expected, do 2-3-4. plan 2: do 2.1-2.4-2.5. If book not identified from information available, do 2.2-2.3-2.4-2.5 2.1 2.2 2.3 2.4 2.5
    • Group info & find relations between groups
    • Post-Its on large surfaces
      • haptic UI
      • immersive
      • persistent
      • brainstorming
    • Also used for creating web info architecture
    Affinity diagramming Reprinted by permission from Contextual Design by Hugh Beyer & Karen Holtzblatt, InContext Enterprises, http://www.incent.com, © Morgan Kaufmann, 1998
  • Summary
      • Getting requirements right is crucial
      • There are different kinds of requirement, each is significant for interaction design
      • The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation
      • Scenarios, and use cases can be used to articulate existing and envisioned work practices.
      • Task analysis techniques such as HTA help to investigate existing systems and practices
  • Exercise
    • Appreciate tacit knowledge of users
    • Mechanical syringe design
      • Doses may be in range 0 – 9999
      • Draft a prototype
  • Automatic syringe 1 3 6 7 2 6 5 4 3 2 1 0 1 4 7 2 + + + - - - + - Before consulting users After consulting users 7 8 9
  • Further Reading
    • Interaction Design, Preece et al, Chapter 7
  • Readings
    • Lewis C. & Rieman J., “ Getting to know users and their tasks ” , Shareware book.
    • Gould J. (1988), “ How to design usable systems ” . In Baecker et al.
    • Web Sites
      • Beyer, Hugh, " Getting Started with Contextual Techniques "
        • http://www.incent.com/connection.indx/techniques.html
    • Norman D. & Draper S. (eds.) (1988), “ User Centred System Design ” .