1CS160 Midterm ReviewMatthew KamMar 3, 2003Assignments ConcernsAdministrivia• Thursday (Mar 6, 2003) office hours shifted to Tuesday (Mar 4, 2003)– 6:30-7:30pm, couch and exhibit area outside 306 Soda – Note time and venue change!– Run as last-minute Q&A session– Covered by Hesham Kamel– I’m out of town at U. of Washington, Seattle from Tuesday to Saturday for user studyDesign Question• Review assignment handouts• Understand why each section has to be part of assignment report• Understand how to carry out task for each section• Easy if each group member had contributed to every part of projectHuman-Centered Design• Who is going to use the system?• What are their characteristics, goals and desires? • Choose representative tasks and analyze them• Rough out a design (plagiarize as needed)• Rethink the design• Create a prototype• Test it with users• Iterate• Build a production version (and ship it!)• Track use• Evolve the designIterate! • Testing will expose problems with various severity• You can then attack those problems in order of severity - and work on features in order of value• Beware of interactions between design elements -fixing one may break anotherDesignPrototypeEvaluate2Personas• Personas are concrete* representations of the user group as individuals. • Things to strive for in a good persona:– Attributes (age, gender, occupation)– Likes, dislikes– Values and desires (or life’s goals)• A good persona is generative (of ideas) – a good fictional character.* Concrete representation is the opposite of abstract representation – it widens the designer’s perspective while abstraction narrows it. Personas• Why use personas?– Avoids the “elastic” user• Programmers bend, stretch and adapt the software for the user, not user bending and adapting to software• Makes it difficult for programmers to distort the users’ goals and needs– Communication within team• End feature debates– Negative personas• Someone you explicitly don’t want to design forPersonas• “The essence of good interaction design is devising interactions that let users achieve their practical goals without violating their personal goals.”• Goals vs. tasks– A goal is an end condition– A task is an intermediate process required to achieve the goal– Tasks change as technology changes, but goals tend to remain stable– Programmers do task-directed designWhat Should Tasks Look Like?• Say what the user wants to do, but not how the user would do it– allows comparing different design alternatives• They should be very specific– forces us to fill out description w/ relevant details– say who the users are (use personas or profiles)• design can really differ depending on who• name names (allows getting more info as necessary)• characteristics of the users (job, expertise, etc.)• Some should describe a complete job– forces us to consider how features work togetherScenarios• Produce scenarios for each task– what user has to do & what they would see– step-by-step performance of task• 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 takeTask ≠ Scenario• Task e.g.:“It’s 1 PM, you just had lunch, and you are now at your Political Science 2 lecture. The professor is explaining about the cult of personality, and because you were phasing out for a few seconds, you missed his main points, and you are now confused. Hoping he will clarify what he means by cult of personality, you decide to send feedback that this part of lecture is hard to understand.”• Scenario e.g.:“It’s 1 PM, Mark has just had lunch, and is now at Political Science 2 lecture. ... Hoping that the professor will clarify what he means by cult of personality, Mark decides to inform the professor that this part of lecture is hard to understand. He looks for the drop-down box for lecture feedback on the upper right-hand corner of his Tablet PC screen, and taps on it to reveal a list of options. He scans them visually until he finds “confused,” and taps on it to send his feedback.”3StoryboardContextual Inquiry• Way of understanding users’ needs and work practices• Design happens in teams– design team: programmer, marketing, quality assurance, producer, more..– user teams: the customers are also part of a team that does somethingPrinciples: Context• Go to the workplace & see the work as it unfolds• People summarize, but we want details• Keep it concrete when people start to abstract– “We usually get reports by email”, ask “Can I see one?”• Look for skipped steps, askthe user to fill them in.Master-Apprentice model• 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– Each step reminds the user of thenext– Skill knowledge is usually tacit(cant put it in books)– Studying many tasks, thedesigner can abstract away– Sometimes literal apprenticeshipworks (Matsushita “Home Bakery”)!Principles: Partnership• Stick with master-apprentice relationship; avoid lapsing into other models, i.e. – avoid interviewer/interviewee (stops work), expert/novice (set expectations at the start)– partnership allows more apprentice interaction: its OK to be a designer and interrupt!– … but go back “in role”:– alternate between watching& probing (withdrawal & return)Principles: interpretation• Good facts are only the starting point– designs based on interpretations• Validate & rephrase– run interpretations by the user to see if you are right– share ideas to check your reasoning (walk the chain back)– people will be uncomfortable until the phrasing is right– need to be committed to hearingwhat the customer is really saying (“Huh?”, “Umm…”, “Yes, but…”)4Principles: Focus• Interviewer needs data about specific kind of work– “steer” conversation to stay on useful topics• Respect triggers (flags to change focus – changing understanding)– shift attention (some one walks in)– surprises (you know it is “wrong”)– treat every utterance by thecustomer as a potential clue tosomething
View Full Document
Unlocking...