Know the user
•Descargar como PPT, PDF•
1 recomendación•956 vistas
The document discusses various techniques for gathering requirements in interaction design, including interviews, questionnaires, focus groups, task analysis, and scenarios. It emphasizes the importance of understanding user needs through methods like contextual inquiry, hierarchical task analysis, and identifying different types of users and requirements. The goal is to uncover users' mental models of tasks, work practices, and needs to design systems that meet functional and usability requirements.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Similar a Know the user
Similar a Know the user (20)
Último
Último (20)
Know the user
- 1. Know the User John Kelleher IT Sligo
- 2. Designing for the user
- 8. SharpReader Conceptual model derived from user ’ s knowledge of Outlook
- 29. 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. ”
- 31. Storyboards
- 34. 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
- 35. 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.
- 36. 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
- 40. 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
Notas del editor
- 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.