HCI Flashcards

Question

5 tips for bridging the gulf of evaluation

Answer 1

1. Give feedback constantly. Don't automatically wait for whatever the user did to be processed in the system before giving feedback. Give them feedback that the input was received. Give them feedback on what input was received. Help the user understand where the system is in executing their action by giving feedback at every step of the process. 2. Give feedback immediately. Let the user know they've been heard even when you're not ready to give them a full response yet. If they tap an icon to open an app, there should be immediate feedback just on that tap. That way, even if the app takes awhile to open, the user knows that the phone recognized their input. That's why icons briefly grey out when you tap them on your phone. 3. Match the feedback to the action. It might seem like this amount of constant immediate feedback would get annoying and if executed poorly it really would. Subtle actions should have subtle feedback. Significant actions should have significant feedback. 4. Vary your feedback. It's often tempting to view our designs as existing solely on a screen and so we want to give the feedback on the screen. But the screen is where the interaction is taking place, so visual feedback can actually get in the way. Think about how auditory or haptic feedback can be used instead of relying just on visual feedback. 5. Leverage direct manipulation. We talk about this a lot more, but whenever possible, let the user feel like they're directly manipulating things in the system. Things like dragging stuff around or pulling something to make it larger or smaller are very intuitive actions. Because they feel like you're interacting directly with the content. Use that. Again, we talk far more about this in another lesson, but it's worth mentioning here as well. By loading these things into your short-term memory several times, we hope to help solidify them in your long-term memory. And that relationship is actually something we also talk about elsewhere in this unit.

Answer 2

1. How easily can one determine the function of the device? 2. How easily can one tell what actions are possible? 3. How easily can one determine the mapping from intention to physical movement? 4. How easily can one actually perform physical movement? 5. How easily can one tell what state the system is in? 6. How easily can one tell if the system is in the desired state? 7. How easily can one determine the mapping from system state to interpretation?

Answer 3

design that considers the needs of the user throughout the entire design process

Answer 4

1. Design is based upon explicit understanding of users, tasks and environments 2. Users are involved throughout design and development 3. Design is driven and refined by user centered evaluation 4. Process is iterative 5. Design addresses the whole user experience 6. Design team includes multi-disciplinary skills and perspectives

Answer 5

* The user themselves is what we call the primary stakeholder. They're the person who uses our tool directly. * Secondary stakeholders are people who don't use our system directly, but who might interact with the output of it in some way. * Tertiary stakeholders are people who never interact with the tool or even interact with it's output, but who are nonetheless impacted by the existence of the tool.

Answer 6

(it's pretty general and subsumes many other life cycles) 1. Needfinding: In Needfinding, we gather a comprehensive understanding of the task the users are trying to perform. That includes who the user is, what the context of the task is, why they're doing the task, and any other information related to what we're designing. 2. Develop multiple design alternatives. These are very early ideas on the different ways to approach the task. It's important to develop multiple alternatives to avoid getting stuck in one idea too soon. 3. Prototyping. We take the ideas with the most potential and we build them into prototypes that we can then actually put in front of a user. Early on we might do this in very low fidelity ways like with a paper and pencil, or even just verbally describing our ideas. But as we go on we refine and improve. 4. Most importantly, we perform user evaluation. We take our ideas that we prototyped and put them in front of actual users. We get their feedback, what they like and what they don't like, what works and what doesn't work, and then the cycle begins anew. The feedback we gain from the users, as well as our experience with these prototypes and design alternatives, improves our understanding of the problem. We now know new areas of the problem we might need to explore with some more need finding. Now we might have some new ideas for design alternatives, or some new ways of expanding the designs that we already have.

Answer 7

* also referred to as categorical data. We observe the # of instances of different categories. * Single-nominal vs multi-nominal: can a person be in more than one category at the same time? * Binary vs non-binary: 2 options vs more than 2 options. Important to know because the statistical tests we do with binary data are different.

Answer 8

* similar to nominal but there is some explicit ordering to the categories. * Ordinal can also be multi-ordinal, but Dr. Joyner hasn’t seen a compelling example of it. * Also as binary and non-binary, just like nominal data. In the binary example, we interpret an implicit ordering between fail and pass.

Answer 9

* data: we do know the exact difference between values (unlike in ordinal data) * We know the intervals between the numbers, but we don’t know their ratios. E.g., 8AM is 4 hours later than 4AM, but it’s not “twice as late”. * Dr. Joyner says interval data use is relatively rare. * Tests used for interval and ratio usually the same. Same goes for nominal and ordinal data. * In Interval and Ratio, there’s also a distinction between discrete and continuous * Discrete means something countable (how long is your average commute in minutes?) with a whole number. Not expecting something like 15.257 minutes. * Continuous: (sensors in people’s cars timing how long their commute is) This distinction, just like binary/non-binary, sometimes informs the statistical tests we perform on the data.

Answer 10

* just like interval data, except it has a 0-point. | * We know that a commute of 30 minutes is twice as long as a commute of 15

Answer 11

usually much more closely integrated with the way in which they were generated - Transcripts - Field notes - Artifacts: reviews left from interfaces or the existing interfaces themselves - Etc.

Answer 12

* strong because it paints a richer picture, but with that strength comes costs: * More expensive to analyze * More prone to interpretation biases * Therefore, we often code it to quantitative data

Answer 13

* process of taking free-form qualitative data, and boiling it down into numeric categories. Typically these categories are nominal, which allows us to do whatever statistical tests we’d normally do on nominal quantitative data. * During this process, we lose some of that rich data, but we gain a numeric representation we can use in new ways. Plus, we don’t really lose our rich data, it’s just not part of the output, so we can go back and look at it if we need to. * The other thing that comes out of this process is a documented methodology for coding the qual to quant data, allowing us to argue that our interpretations aren’t biased, but actually rigorous analyses.

Answer 14

* Before we start our need-finding exercises, we also want to enter with some understanding of the data we want to gather. * These are the questions we ultimately want to answer. That's not to say we should be answering them every step of the way, but rather, we want to gather the data necessary to come to a conclusion at the end. Now, there are lots of inventories of the types of data you could gather, but here's one useful list: 1. Who are the users? What are their ages, genders, levels of expertise? 2. Where are the users? What is there environment? 3. What is the context of the task? What else is competing for users' attention? 4. What are their goals? What are they trying to accomplish? 5. Right now, what do they need? What are the physical objects? What information do they need? What collaborators do they need? 6. What are their tasks? What are they doing physically, cognitively, socially? And seven, what are the subtasks? How do they accomplish those subtasks? When you're designing your need finding methods, each thing you do should match up with one or more of these questions.

Answer 15

* Where is the task occurring, what else is going on, what are the user's explicit and implicit needs?

Answer 16

1. Confirmation bias is the phenomenon where we see what we want to see. We enter with some preconceived ideas of what we'll see, and we only notice the things that confirm our prior beliefs. Try to avoid this by specifically looking for signs that you're wrong, by testing your beliefs empirically, and by involving multiple individuals in the need finding process. 2. Observer bias, when we're interacting directly with users, we may subconsciously bias them. It might be more helpful, for example, with users using the interface that we designed compared to the ones that other people designed. On surveys, we might accidentally phrase questions in a way that elicits the answers that we want to hear. Try to avoid this by separating experimenters with motives from the participants. By heavily scripting interactions with users, and by having someone else review your interview scripts and your surveys for leading questions. 3. Social desirability bias, people tend to be nice. People want to help. If you're testing an interface and the participants know that you're the designer of the interface, they'll want to say something nice about it to make you happy. But that gets in the way of getting good data. Try to avoid this by hiding what the socially desirable response is by conducting more naturalistic observations and by recording objective data. 4. Voluntary response bias, studies have shown that people with stronger opinions are more likely to respond to optional surveys. You can see this often in online store reviews. The most common responses are often fives and ones. For us, that means if we perform quantitative analysis on surveys, we risk over sampling the more extreme views. Avoid this by limiting how much of the survey content is shown to users before they begin the survey and by confirming any conclusions with other methods. 5. Recall bias, studies have also shown that people aren't always very good at recalling what they did, what they thought, or how they felt during an activity they completed in the past. That can lead to misleading and incorrect data. Try to avoid this by setting tasks in contexts by having users think out loud during activities or conducting interviews during the activity itself.

Answer 17

1. Take notes. Don’t just sit around watching for a while. Be prepared to get a targeted information and observations about what you see. 2. Start specific and then abstract. Write down the individual little actions you see people doing before trying to interpret or summarize them. If you jump to summarizing too soon, you risk tunnel vision. 3. Spread out your sessions. Rather than sitting somewhere for two hours one day and then moving on, try to observe in shorter 10 to 15 minute sessions, several times. You may find interesting different information, and your growing understanding and reflection on past exercises will inform your future sessions. 4. Find a partner. Observe together with someone else. Take your own notes and then compare them later so you can see if you all interpreted the same scenarios or actions in the same way. 5. Look for questions. Naturalistic observations should inform the questions you decide to ask participants in more targeted need-finding exercises. You don't need to have all the answers based on observation alone. What you need is questions to investigate further.

Answer 18

experience a task for ourselves ow we do have to be careful here though. Remember you are not your user. When you're working as a participant observer, you can avail useful insights, but you shouldn't over represent your own experiences. You should use this experience as a participant observer to inform what you ask users going forward.

Answer 19

* We need to get inside users heads a little more to understand what they're thinking and doing. If you're trying to design interfaces to make existing tasks easier, one way to research that is to look at the hacks that users presently employ. * How do they use interfaces in non-intended ways to accomplish tasks or how do they break out of the interface to accomplish a task that could have been accomplished with an interface?

Answer 20

Interviews and focus groups can be very helpful 1. Focus on the six W's when you're writing your questions. Who. What. Where. When. Why and hoW. Try to avoid questions that lend themselves to one world or only yes or no answers, those are better gathered via surveys. Use your interview questions to ask open-ended, semi-structured questions. 2. Be aware of bias. Look at how you're phrasing your questions and interactions, and make sure you're not predisposing the participant to certain views. If you only smile when they say what you want them to say, for example you risk biasing them to agree with you. 3. Listen. Many novice interviewers get caught up in having a conversation with a participant rather than gathering data from the participant. Make sure the participant is doing the vast majority of the talking. And don't reveal anything that might predispose them to agree with you. 4. Organize the interview. Make sure to have an introduction phase. Some lighter questions to build trust and a summary at the end so the user understands the purpose of the questions. Be ready to push the interview forward or pull it back on track. 5. Practice. Practice your questions on friends, family, or research partners in advance. Rehearse the entire interview, gathering subjects is tough so when you actually have them you want to make sure to get the most out of them.

Answer 21

* Think-aloud protocols are similar to interviews in that we're asking users to talk about their perceptions of the task. But with think-aloud, we're asking them to actually do so in the context of the task. So instead of bringing Morgan in to answer some questions about listening to audiobooks while exercising, I'll ask her to actually think out loud while listening to audiobooks and exercising. If this was a different task like something on a computer, I could have her just come into my lab and work on it. But since this is out in the world, what I might just do is give her a voice recorder to record her thoughts while she's out running and listening. Now think aloud is very useful, because it can help us get at users thoughts that they forget when they are no longer engaged in the task. * But it's also a bit dangerous by asking people to think aloud about their task, we encourage them to think about it more deliberately and that can change the way they actually act. * So while it's useful to get an understanding of what they are thinking, we should check to see if there are places where what they do differs when thinking out loud about it. * We can do that with what's called a post-event protocol, which is largely the same, except we wait to get the user's thoughts until immediately after the activity. That way, the activity is still fresh in their minds, but the act of thinking about it shouldn't affect their performance quite as much.

Answer 22

1. Less is more. The biggest mistake that I see novice survey designers make is to ask way too much. That affects the response rate and the reliability of the data. Ask the minimum number of questions necessary to get the data that you need and only ask questions that you know that you'll use. 2. Be aware of bias. Look at how you're phrasing the questions. Are there positive or negative connotations? Are participants implicitly pressured to answer one way or the other? 3. Tie them to the inventory. Make sure every question on your survey connects to some of the data that you want to gather. Start with the goals of the survey and then write the questions from there. 4. Test it out. Before sending it to real participants, have your co-workers or colleagues test out your survey. Pretend they're real users and see if you would get the data you need from their responses. 5. Iterate. Survey design is like interface design, test out your survey, see what works and what doesn't and revise it accordingly. Give participants a chance to give feedback on the survey itself, so that you can improve it for future iterations.

Answer 23

Be clear, concise, specific, expressive, unbiased, usable

Answer 24

* functionality, what the interface can actually do, * usability, how certain user interactions must work, * learnability, how fast the user can start to use the interface, and * accessibility, who can use the interface. * We might also have some that are generated by external project requirements, like: * compatibility, what devices the interface can run on, * compliance, how the interface protects user privacy, * cost, how much the final tool can actually cost, and so on.

Answer 25

the principle that the user should feel as much as possible like they're directly controlling the object of their task.

Answer 26

* Whether through using direct manipulation, through innovative approaches to shrinking these gulfs or through the user's patience and learning, our ultimate goal is for the interface between the user and the task to become invisible. * What this means is that even though there is an interface in the middle, the user spends no time thinking about it. Instead, they feel like they're interacting directly with the task rather than with some interface.

Answer 27

* Good design: * Interfaces that are metaphorically invisible. * Bad design: * Interfaces that are literally invisible. Well, kind of, just your base interfaces are in one sense literally invisible. That's actually why it's so important to give great feedback. Because otherwise, it's tough to gauge the success of a gesture interaction.

Answer 28

1. Use affordances. We talk more about affordances when we discuss design principles and heuristics. But affordances are places where the visual design of the interface is just how it's supposed to be used. Buttons are for pressing. Dials are for turning. Switches are for flicking. Use these expectations to make your interface more usable. 2. Know your user. Invisibility means different things to different people. Invisibility to a novice means the interactions are all natural. But invisibility to an expert means maximizing efficiency. Know for whom you're trying to design. 3. Differentiate your user. Maybe you're designing something for both novices and experts. If that's the case, provide multiple ways of accomplishing tasks. For example, having copy and paste under the Edit menu keeps those options discoverable. But providing Ctrl C and Ctrl V as shortcuts keep those actions efficient. 4. Let your interface teach. When we think of teaching users how to use our software we usually think of tutorials or manuals. But ideally the interface itself will do the teaching. For example, when users select Copy and Paste from the Edit menu, they see the hotkey that corresponds to that function. The goal is to teach them a more efficient way of performing the actions without requiring them to already know that in order to do their work. 5. Talk to your user. We'll say this over and over again, but the best thing you can do is talk to the user. Ask them what they're thinking while they use an interface. Note especially whether they're talking about the task or the interface. If they're talking about the interface, then it's pretty visible.

Answer 29

Chunking Recognition vs. Recall Cognitive load Chunking = grouping together several bits of information into one chunk to remember

Answer 30

* Procedural is how to do something. That can be doing work on a computer, playing sports, playing a musical instrument. It's a task in which you're engaged or an activity you are performing, it's something that you do. * Declarative learning is knowledge about something. It's what you know in your head. It's what you can answer when asked. So if I asked you, what's the hotkey for paste? I'm asking for a declarative knowledge.

Answer 31

1. Use multiple modalities. Most often, that's going to be both visual and verbal. But when only one system is engaged, it's natural for it to become overloaded while the other one becomes bored. So describe things verbally and also present them visually. 2. Let the modalities complement each other. Some people will take that first tip and use it as justification to present different content on the two modalities. That actually increases cognitive load because the user has to try to process two things at once, as you just noticed when Amanda put something irrelevant up while I said that. Instead, focus on letting each modality support, illustrate or explain the other, instead of competing with the other. 3. Give the user control of the pace. That's more pertinent in educational applications of cognitive load, but oftentimes interfaces have built-in timers on things like menus disappearing or selections needing to be made. That dictates the pace, induces stress, and it raises cognitive load. Instead, let the user control the pace. 4. Emphasize essential content and minimize clutter. The principal of discoverability says we want the user to be able to find the functions available to them, but that could also raise cognitive load if we just give users a list of 500 different options. To alleviate that, we can design our interfaces in a way that emphasizes the most common actions, while still giving access to the full range of possible options. 5. Offload tasks. Look closely at what the user has to do or remember at every stage of the interface's operation. And ask if you can offload part of that task on to the interface. * For example, if a user needs to remember something that they entered on a previous screen, show them what they entered. If there's a task they need to do manually, see if you can trigger it automatically.

Brainscape's Knowledge GenomeTM

HCI Flashcards

Brainscape's Knowledge Genome^TM