CS160 Midterm ReviewAssignments ConcernsAdministriviaDesign QuestionHuman-Centered DesignIterate!PersonasSlide 8Slide 9What Should Tasks Look Like?ScenariosTask ≠ ScenarioStoryboardContextual InquiryPrinciples: ContextMaster-Apprentice modelPrinciples: PartnershipPrinciples: interpretationPrinciples: FocusCaveats of User-Centered Design TechniquesFidelity in PrototypingWhy Do We Prototype?Why Use Low-fi Prototypes?Hi-fi Prototypes WarpAdvantages of Low-fi PrototypingWizard of Oz TechniqueTeamsCommon purposeGoal settingBuilding teams: UrgencyBuilding teams: Select for SkillSetting rules of behaviorSet a few immediate goalsBring in fresh facts and ideasSpend time togetherPositive FeedbackDiscount Usability EngineeringSlide 38Other budget methodsHeuristic EvaluationHeuristic Evaluation ProcessHow to Perform EvaluationRevised HeuristicsResults of Using HE (cont.)Why Model Human Performance?Model Human ProcessorMHP BasicsPrinciples of Operation (cont.)Slide 49Slide 50Stage TheoryMemoryRecognition over RecallStructural vs. Functional ModelsMetaphorMetaphor: DifficultiesComposite MetaphorsConceptual ModelsGood luckCS160 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 anotherDesignPrototypeEvaluatePersonas•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.”StoryboardContextual 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
View Full Document
Unlocking...