ENG 206 Final, Fall 2004

American University of Beirut · Technical English · 9 pages

All ENG 206 files
ENG 206 Final, Fall 2004, page 1

Stuck on a question? A tutor can walk you through it.

ENG 206 Final, Fall 2004, page 2 ENG 206 Final, Fall 2004, page 3 ENG 206 Final, Fall 2004, page 4 ENG 206 Final, Fall 2004, page 5 ENG 206 Final, Fall 2004, page 6 ENG 206 Final, Fall 2004, page 7 ENG 206 Final, Fall 2004, page 8 ENG 206 Final, Fall 2004, page 9

More ENG 206 files

Show the text of this final exam
OO en te tee 7 Le a LIBKARY OF BEIRGT ENGLISH 206 FINAL EXAM Fall 2004 - 2005 Name: Section: Instructor: Time Allowed: 2 % Hours Passage A 5 Things to Know About Users "Know Your Users" is the mantra of any good designer. Yet, what should you actually know about your users? Over the years, we've studied the usability of hundreds of product and web site designs. We've seen designs that were incredibly effective for users and designs that fell tremendously short. One emerging pattern in our ongoing research is that design teams that know a lot about their users are more likely to produce user experiences that are usable, effective, and pleasing. When a design team fails to answer a user’s questions, the problem is usually that the team doesn’t know anything about the user. They need to know why a user is coming to the site (his/her 'intentions'). They also need to know that he/she'd, for example, had just come upon a huge sum of money (his/her 'context'). The team also needs to know what a user knows about investing (his/her 'knowledge’), what he/she is capable of doing himself/herself (his/her 'skills'), and the nature of the financial management he/she'd done in the past (his/her 'experience’). The user's intentions, context, knowledge, skills, and experience are the essential things that every designer needs to know. Without this, the team is going to design something that seems useful, but they'll never know if it actually helps the user. Unfortunately, these five things are beyond what normal markct research can tell us. Market research can tell us age groups, income levels, geographic regions, even purchase behavior. But it can't tell us the key things we need to know. Intentions are key, because they tell us what the user is trying to accomplish. They dictate the tasks on the site. A high school senior who is shopping around for the right college has different intentions than the student who is ready to apply for early admission. Both of these intentions dictate different design requirements. Context is also important. Someone who is faced with putting their first PowerPoint presentation together will interact with the application's features differently if the presentation slides are due in 3 weeks than if they need to be ready for a board meeting this afternoon. For example, they'd be less likely to explore all of the application's chart customization capabilities when rushed and therefore need the defaults to be acceptable for important meetings. They wouldn't play with a how-to tutorial or try lots of ambiguous menu options, just to see what they do. Knowledge, skills, and experience are also critical. The user's knowledge dictates the terminology and concepts that they are familiar with. Someone with a medical background will know the difference between hypoglycemia and hyperglycemia. EMGAN ORIVERSIT LIBRARY | OF bree However, a parent of a newly diagnosed child with diabetes might confuse these two life threatening (and very different) conditions. Designers might choose terms like "Low Blood Sugar" and "High Blood Sugar” if they understand the user's existing knowledge. The user's skillset also dictates design decisions. When designing an intranet procurement process, the designers would create different screens for those materials procured by seasoned buyers, who have been doing purchasing for decades, than for the occasional employee who needs a new computer or office supply. Finally, the user's experience is a design factor. An experienced business traveler would know to avoid certain airports at certain times of the year, like Chicago's O'Hare in the winter, because of likely weather delays. A clever reservation system might recommend an alternate hub, such as Charlotte or Dallas, which doesn't run into the same problems. Excerpted and adapted from Spool, Jared M. (2002, December 2). 5 things to know about users. User Interface Engineering. Retrieved from http://www.uie.com/articles/five_things to_know/ Passage B Field Studies: The Best Tool to Discover User Needs Field Studies in Action: Over the years, we've conducted many field studies for our clients. In each study, we've learned amazing things about how people behave, giving us incredible insight into how we should design interfaces for use. ¢ We've watched people shopping in malls, giving us insight into how they manage shopping lists and purchase items on impulse. From this we've learned a lot to guide successful e-commerce designs. We've spent weeks sitting alongside system administrators, watching how they interact with software documentation as they solve problems and maintain systems. We garnered new perspectives on the roles of printed and online documentation, helping us understand the unique problems that each medium favors. We've followed paperwork through large manufacturing facilities, seeing who touched it and what they needed from it. From this, we learned the subtleties of the manufacturing information and how the seemingly minor actions of one person in the factory (such as leaving an ‘unimportant’ field blank) can have dramatic affects on the efficiency of other people later on. Seeing how people interacted with each other using the paperwork gave us a greater understanding of the intricacies of implementing enterprise-wide information systems. The Power of Field Studies: Even a short field study, such as two or three half-day visits, can yield information of tremendous value on what users do and how do they talk about it, on their context i.e. the external forces that will impact the design such as deadlines, and the commonalities that appear across environments, along with the variations that will impact design decisions (such as providing switches, options, and optional features). Field studies give the advantage of delivering the team information they just can't get in any other way. For instance, ‘intuitive’ interfaces are easier to build when designers have a deep understanding of the users’ context, terminology, and processes. However, the biggest downside to field studies is the cost to the organization. Scheduling the visits, taking team members out of the office for several days, and finishing the analysis can have a huge impact on a project's resources. Nevertheless, the most successful organizations look beyond the current project, realizing that the value from the information learned will feed into future projects for years to come. Excerpted and adapted from: Spool, Jared M. (2003, August 6). Field studies: The best tool to discover user needs. User Interface Engineering. Retrieved from http://www.uie.com/articles/field_studies/ Passage C Designing Products That Work the Way People Work: An Interview with Kate Gomoll Kate Gomoll is a recognized expert in the area of Field Research and Usability Testing. UIE's Christine Perfetti recently had the opportunity to talk with Kate about how she and her team at Gomoll Research & Design conduct field studies. Here is what Kate had to say about her experiences. UIE: Many of our clients say they stay away from conducting field research projects because they are too expensive and time-consuming to implement. Why should designers invest the time and resources in field studies? Kate Gomoll: Nothing replaces the power of direct observation. Designers can gain so much information from watching people in their actual work environment and capturing a user's unarticulated needs. The work we conduct takes place in the participant's environment — such as home, work, stores, banks, and hospitals. Our findings are based on realities, not preconceptions. As a result, design teams can get much closer to their customers. Users will “show and teil” them things they would incorrectly consider unimportant in a focus group, interview, or usability test. Also, in our experience, what people say rarely matches what they do. People don't remember the steps of a process, especially if it's something they do all the time. They may tell you something is easy, but when you actually observe users doing that task ina field study, you can see all the problems and inefficiencies they didn't recall or couldn't articulate. In your full-day seminar at UI9, you and Ellen Story will demonstrate how to plan and conduct a field study. Can you describe the major steps involved? Before the field visit, we develop a participant screener to ensure that the people we are visiting are representative users. We always make sure that key stakeholders agree on the mix of participants we will visit so there is no debate about the appropriateness of the participants after the data analysis. We also create a detailed study plan with the session script and all of the materials we need for the study. A typical site visit lasts 1.5 — 2 hours. We spend the first part of our visit asking users to prioritize their most important and frequent tasks. We then observe them completing their most high-priority tasks. As we watch the user, we capture the steps, constraints, and tools needed to accomplish their tasks and any social interactions that take place. We also note any process inefficiencies or opportunities for improvement. Our sessions are a blend of interview and observation. We observe the user as much as possible, but we also gather data from contextual interviews. We have a basic script for the session, with interview questions and observation opportunities. But, we move around in the script, asking questions when they are relevant and weaving observation opportunities between questions. That's the best way to make sure we get as much data as possible for our efforts. Do you have any tips for conducting the contextual interviews with users? My colleague, Ellen Story, and I have worked out a really good approach to “tag-team interviewing.” We have a study script that we work from, but we are quite flexible with it. Ellen will ask a question, and while the participant is answering her question, I will look through the script for the next logical question, based on the participant's response. This helps the session feel more natural and informal. It also speeds things up, because we can do the same thing with our observation opportunities. Having our questions worked out ahead of time and reviewed by stakeholders also helps us avoid asking leading questions. Of course, the ability to work with people and draw out their honest responses takes some practice and finesse. The more we do this kind of work, the better researchers we become. How many customers do you recommend visiting in the field? We recommend 5-8 participants within a segment. So, the total number depends on how the design team decides to create segments. How do you determine how many user segments are necessary? Before we determine the user segments and the number of participants, we typically ask the clients to assemble a group of key stakeholders. This group typically includes people from the development team, marketing, engineering, usability/user interface, and domain experts. We make sure that this group has input and buys into the definition of a segment, as well the criteria for recruiting. There are three main questions we ask stakeholders: 1. How many different user groups are there in your target market? 2. How do you distinguish the user groups from each other? 3. How greatly do you think the usage patterns and preferences will differ among groups? Before we conduct any of the field visits, we gain agreement from all of the key stakeholders about the sites and people we visit, so that when the data rolls in, nobody is telling us "you visited the wrong people." Many design teams have tried field research but are unsuccessful when the time comes to interpret the piles of data they've collected. How do you go about analyzing the data gathered from field observation? At Gomoll Research & Design, we follow a 3-stage design process of Investigation, Analysis and Design. During the Investigation Phase , we create user profiles and personas and visit customer sites to understand the goals, attitudes, and workplace of the intended users. This is the stage where the field research process fits. When we're developing our site visit materials, we think about what deliverables we plan to develop after the study. For example, a typical field study will yield scenarios, user profiles, storyboards / task maps, incremental reports, and a summary report. During the Analysis Phase, we're looking for patterns in the data. We focus our efforts on finding these key usage patterns and prioritizing design opportunities. We create deliverables that will highlight the patterns and Opportunities in a compelling way. This phase includes Workflow Modeling, Task Analysis, and Usability Benchmarks. Finally, during the Design Phase , we use an iterative process to develop user models and begin prototyping. We gather user feedback and conduct usability tests to help us evaluate and revise our designs. During each phase, we're careful to gather and incorporate user feedback so that we design products that work the way people work. That is the key. Can design teams gather insights from field visits they can't uncover with usability testing? By making direct observations, design teams can discover product opportunities they may never have imagined if they had only conducted usability tests. We observe users doing teal work in real time, which enables us to paint an accurate picture of the how users interact with a product or process. For example, we worked with Sonic Solutions to design MyDVD 4, the leading DVD creation software, to better understand how people create DVDs today. To accomplish this, we conducted observational research in Sonic's customers' homes. By observing their customers firsthand, we uncovered common user goals, behaviors, task flows, and the critical problems users encounter when creating DVDs. What led Sonic Solutions to want to conduct field research? When we initially met with Sonic's executives, they were already aware of the power of field research. Their biggest challenge was deciding what kind of users to study. The design team believed that the majority of their users were *early adopters* of DVD creation technology, willing to do whatever it takes to become technically proficient with relevant video and PC hardware and software. For the next generation MyDVD, they wanted to target a larger mass market. But they weren't sure how well field research on early adopters would help with a design for mass market users. How hard was it to find customers who would let you in their homes? To find customers, we sent emai! messages to registered customers. As is typical, our acceptance rate was approximately 10%. Since the list of registered customers in our target locale was quite large, the recruiting was fairly easy. We are often surprised at how willing people are to invite us into their homes. In this case, most of our participants were anxious to show us their DVDs because they were so proud of them. They were also eager to positively impact the next release of MyDVD and to get a few usage tips. Were there any findings that surprised the team? One of the biggest surprises was that the design team's assumptions about early adopters were not always accurate. We visited users representing a variety of profiles, from a professional videographer, to a teenager whose parents purchased a more powerful PC and related video equipment just to get a VHS tape of his grandfather archived for perpetuity. Most users had a keen interest in video or film media, but little of the supposed relevant technical expertise of an early adopter. Can you share some of the design improvements that came from the research? Our research findings led to immediate product design improvements, such as the creation of a ““MyDVD Tutorial” to help new users understand the technology, the product, and the DVD-creation process. Our analysis made it clear that all user profiles would benefit from this tutorial, and that the tutorial should cover many aspects of the DVD creation process, even those not directly supported by MyDVD. Perfetti, Christine. (2004, September 17). Designing products that work the way people work: An interview with Kate Gomoll. User Interface Engineering. Retrieved from http://www.uie.com/articles/ gomoll_interview/ English 206 Final Exam Fall 2004- 2005 Name: Section: Instructor: Time Allowed: 2 '? Hours 1, You work for Gomoll Research and Design and serve on the same field research team as Kate Gomoll. You have conducted several site visits as part of your field research work for Sonic Solutions on their MYDVD 4 software, and you have just finished interpreting your results. Address a progress report to Sonic Solutions’ manager of Information Technology, Scott Stewart, indicating the status of your work. Use the relevant ideas in passages A, B and C to write your report. Use your discretion to supplement this information with needed details from your general knowledge. 1.1 Before writing the report, analyze the situation by answering the following questions briefly. (10 pts.) 1.1.1 Identify two possible secondary readers for your progress report. Justify your answer. (5 pts.) 1.1.2 What would be an ethical concern 1.1.2.1 related to the implementation of the field study ? (2.5 pts.) 1.1.2.2. related to the writing of the progress report itself? (2.5 pts.) 1.2 Write your report in the memo format on pages 3 and on. (Use the back of the sheets for drafting if needed. You will not be given extra sheets of paper for drafts.) (50 pts.) 2. Write the email that you and your team sent to recruit participants in the initial stages of the field study (mentioned in passage C). After analyzing the situation and considering your audience, use the appropriate approach, style and tone and include all necessary details. 2.1, Write your email on page 8. (Use this page for drafting.) 2.2. Send the email to a list of registered customers (as mentioned in passage C). (40 pts.)