Interaction Design <br />Lifecycle Models, Needs and Requirements,  and Prototyping<br />
1<br />Lifecycle models<br />2<br />Needs and requirements<br />3<br />Prototyping<br />* The contents of this presentatio...
Exercise:<br />Interactive children’s book<br />
1<br />Lifecycle models<br />
“[…] a model that captures a set of activities and how they are related.”<br />
Three examples:<br />Software engineering<br />Interaction Design<br />HCI<br />
Interaction design model<br />
Start<br />Identify needs and establish requirements<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an ...
A software engineering<br />model<br />
Requirement analysis<br />Design<br />Code<br />Test<br />Maintenance<br />
A HCI model<br />
Requirements / specification<br />Task analysis / functional analysis<br />Conceptual design / formal design representatio...
?<br />
Identifying needs and establishing requirements <br />2<br />
What are needs and requirements<br />a<br />Types of requirements<br />b<br />Data gathering for requirements<br />c<br />...
Identify needs and establish requirements<br />Start<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an ...
?<br />Needs and requirements<br />
Whybother?<br />
Involves twoaims<br />
Identifying needs:<br />“[…] to understand as much as possible about the users, their work, and the context of that work, ...
Establishing requirements: <br />“[…] to produce, from the needs identified, a set of stable requirements that form a soun...
Three activities:<br />Data <br />gathering<br />Analysis and interpretation<br />Establishment of requirements<br />
Three activities:<br />Data <br />gathering<br />Analysis and interpretation<br />Establishment of requirements<br />
Two types:<br />
Functional requirements:<br />specifies what the system should do<br />
Non-functional requirements:<br />dictated by constraints on the system and development <br />
Data requirements<br />
Environmental requirements <br />
User characteristics <br />
Usability and user experience goals<br />
Data gathering<br />for requirements<br />
Interviews<br />when you want to explore <br />
Focus groups<br />exploring different views<br />
Questionnaires<br />getting initial and general responses<br />
Direct<br />observation<br />
Indirect<br />observation<br />
Study documentation<br />
Research<br />similar products<br />
Contextual Inquiry<br />a popular method for uncovering requirements<br />
Four main principles<br />of contextual inquiry<br />Context<br />Partnership<br />Interpretation<br />Focus<br />
Data analysis and interpretation<br />moving from the collected data to clear requirements:<br />
Scenarios<br />Exploring contexts, needs, and requirements through stories of human activities or tasks <br />
Scenario example:<br />“The Thomson family enjoy outdoor activity holidays and want to try their hand at sailing this year...
Personas<br />Fictional users synthesized based on information gathered from real users<br />
Properties<br /><ul><li>Goals
Skills
Attitudes
Tasks
Environments
(Name and picture)</li></li></ul><li>Use cases<br />Detailed descriptions of user-system interactions<br />actors<br />sys...
Use cases example:<br />The system displays options for investigating visa and vaccination requirements.<br />The user cho...
Use cases example (alternative courses):<br />6. <br />6.1.<br />6.2.<br />8. <br />8.1.<br />8.2.<br />If the country nam...
Use cases diagram<br />
Essential use cases<br />retrieveVisa<br />USER INTENTIONSYSTEM RESPONSIBILITY<br />find visa requirements										reques...
Task analysis<br />Analyzing existing situations before developing new products  <br />
Hierarchical Task Analysis<br />Analyzing the tasks making up the task<br />
Hierarchical Task Analysis example<br />0. In order to borrow a book from the library<br />	1.	go to the library<br />	2.	...
Hierarchical Task Analysis example<br />plan 0: do 1-3-4. <br />If book isn’t on the shelf expected, do 2-3-4.<br />plan 2...
Hierarchical Task Analysis<br />graphical representation<br />Borrow book from the library<br />0<br />plan 0: <br />do 1-...
Datagatheringguidelines<br /><ul><li>Focus on identifying the stakeholders’ needs
Involve all the stakeholder groups
Involve more than one representative from each stakeholder group
Use a combination of data gathering techniques</li></li></ul><li>Design, prototyping and constructions<br />3<br />
What is a prototype<br />a<br />b<br />Categories of prototypes<br />c<br />Conceptual design<br />
Start<br />Identify needs and establish requirements<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an ...
?<br />What is a prototype<br />
Prototypes communicate the message <br /> “This is what it could be like.”<br />Dan Saffer<br />author of Designing for In...
Why bother?<br />
Evaluation and feedback <br />
Enables all stakeholders to<br />see, hold, interact<br />
Improves<br />team communication<br />
Prototypes answer questions, and <br />support designers in choosing between alternatives<br />
Categories of prototypes<br />
”The higher the fidelity, the more it resembles the final product”<br />Low-fidelity<br />High-fidelity<br />
Low-fidelity prototypes<br />saving time and money during the early stages of development<br />
Sketching<br />no drawing is too ugly<br />
Storyboarding<br />Illustrated stories of interfaces and interactions<br />
Generating storyboards from scenarios<br />“The Thomson family enjoy outdoor activity holidays and want to try their hand ...
Index cards<br />visualizing interaction<br />
e.g.<br />
The embedded video can be found online at<br />http://www.youtube.com/watch?v=T4o8niW5LfQ&feature=player_embedded<br />
Generating card-based prototypes from use cases<br />
Wizard of Oz<br />Simulating functionality <br />
e.g.<br />
Video example<br />
Wizard of Oz example<br />simulating voice recognition<br />
High-fidelity prototypes<br />Testing usability and technical issues during later stages of the development<br />
Time is an issue<br />
It may look finished<br />but it’s not!<br />
Testing a faulty system<br />
High-fidelity prototype example  <br />WobbleActive 2.0<br />
High-fidelity prototype example  <br />WobbleActive 2.0<br />
Testing mapping strategies<br />or<br />
Video example<br />
Compromises in prototyping<br />horizontal prototyping vs. vertical prototyping<br />
Conceptual design<br />Moving from requirements to a conceptual model<br />
Involves answering the questions: <br /><ul><li>Which interface metaphor would be suitable to help users understand the pr...
Which interaction type(s) would best support the users’ activities?
Does different interface types suggest alternative design insights or options?</li></li></ul><li>Interface metaphors:<br /...
What metaphors apply here?<br />
Balancing utility and fun<br />Should an educational application mimic school or play? <br />vs.<br />
Three steps<br />for choosing interface metaphors: <br /><ul><li>Understand functionality
Identify problem areas
Generate metaphors </li></li></ul><li>Evaluating interface metaphors: <br /><ul><li>How much structure does the metaphor p...
Upcoming SlideShare
Loading in...5
×

Lifecycle Models, Needs and Requirements, and Prototyping

3,799

Published on

Published in: Education
1 Comment
3 Likes
Statistics
Notes
  • I like this one. It can explain the difference between Needs and Requirements.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
3,799
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
75
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide
  • Even though we only have one lecture together this time around the procedure will be just like for the workshop you had with Olga.TherearesomereadingsI’llbetalking for a while. I’llaspire to make it as short as possible so youcangetgoin with the exerciseWhichlike the oneyougotduring the workshop is performed in groups and successfuldeliverynecessary in order to pass the course.
  • Agenda:
  • Id like to briefly introduce the exercisebeforewe start you have to work with a lot of the conceptsintroducedduring the lecturetherefor I thoughthat it mightbe a goodidea for you to keep the assignment in the back of your mind whileIm rantingLast time elderlypeople, this thime kids and parentsProduce a design of an interactivechildrens book whichfacilitates a sharedexperiencebetween the child and parent(s)Youalso have to produce a lowfidelity prototype of this design
  • What is a conceptual model?“[…] a model that captures a set of activities and how they are related. Sophisticated models also incorporate a description of when and how to move from one activity to the next and a description of the deliverables for each activity.
  • The reason why such models are popular is that they allow developers, and particularly managers, to get an overall view of the development efforts so that progress can be tracked, deliverables specified, resources allocated, targets set, and so on.”“[…] a structured process is used to provide a more stable framework for creativity.” So, thinking about how the process will unfold shouldn’t be regarded as a burden, but rather as a device that provides freedom.
  • Thereexist numerous models (you can find more in chapter 9 of the book). For the sake of brevity I’m just going to outline three, one of them being the lifecycle model you’ve already been breifly introduced to.
  • - Incorporates iteration and encourages user focus- The model does not explicitly define what each activity should amount to. It is for you to fill in the details. Initially needs are identified and used to establish requirements (these may be the outcome of the evaluation of an existing product)2) Subsequently alternative designs are generated in an attempt to meet these needs and fulfill the requirements, are generated.3) Interactive versions of one or more of these designs may be produced and evaluated.4) This may entail that the requirements and needs have to be altered (the evaluation may have given rise to new requirements or made the designers aware of new needs). Alternately the design team may continue elaborating on the existing design or redesigning it altogether.
  • Waterfall model (example of a software engineering model):
  • First life-cycle model to become generally know and it is still employed today. As you can see it is linear model meaning that each step has to be performed before the following one. What is the issue with this model? Requirements may change over time (e.g. as a consequence of testing or external changes such as changes in the environment where the product is supposed to be used)Some level of iteration is incorporated into this version of the model however the focus on users involvement is not explicit
  • The Star lifecycle model (example of a HCI life-cycle model):
  • Star model:- Emphasizes flexibility- No order in which to perform activities is specified (you can move from any one activity to another provided that you first perform some form of evaluation.- So all activities are in fact completed with some form of evaluation - Evaluation at its core
  • Which one is best?That depends on the task at hand and whether you want to prescribe to a user-centered approach.I encourage all of you (and particularly the ones of you who are interested in management) to study the models introduced in the text book.A please consider this when doing you project as Olga said the four central activities in the interaction design model make up for a great check list.
  • Fourmaintopics
  • Just to make it painstakingly obvious. This is the activity in the lifecycle we are dealing with.
  • What is the difference between needs and requirements?A need is something pertinent to the userWhereas a requirement is something we specify or establish to the system we are developing“A requirement is a statement about an intended product that specifies what it should do or how it should perform.”That is why we talk about identifying needs (they are out there to be identified)And establishing requirements. We establish these based on the needs amongst other things
  • Why bother identifying needs and establishing requirements:It is quite simple… otherwise you’ll be designing blindlyErrors are significantly more expensive (time consuming) to fix later in the process. In your case you probably won’t even have time to make major changes later on in the process.
  • Identifyingneeds and establishingrequirmentsOBVIOUSLYinvolvetwoaimsTo:Identifyingneeds and establishingrequirments
  • It is important that requirements are:Specific, unambiguous, and as clear as possible.Specific: Load time should be less than 5 secUnspecific: The game should be fun (unclear and needs more research)
  • This process includes data gathering, analysis, interpretation and presentation and ultimately amount to findings which can be expressed as a set of requirements. So:Data gatheringData analysis and interpretation 1+ 2) While gathering and analyzing data that we acquire an understanding of - user needs and capabilities, - tasks and goals, - the conditions under which the product will be used, - and constraints on the product’s performance.Establishment of requirements
  • The process is however not linear as the process is iterative. The data analysis may lead to the realization that more data gathering is needed. The list of requirement may in fact be viewed as dynamic in the sense that requirements evolve and develop as the stakeholders interact with designed prototypes. REMEMBER that it is part of a general process which is iterative and thus is performed repeatedly.
  • Reguirements can generally be divided into two categories:Functional requirementsNon-functional requirements
  • Functional requirements: This category specifies what the system should do. So what functionality should the product provide
  • Non-functional requirements: What constraints are there on the system and its development (e.g. the it has to run on platform, development time, physical size, color, resolution etc)This in turnmeanthatthis type of requirementscanbedividedintonumerous sub categories.
  • Data requirements: Requirements pertaining to the data used by the system (type, accuracy etc)
  • Environmental requirements (context of use): Refers to the circumstances in which the system is expected to operatePhysical environment: Light conditions, noise, need for particular clothing, how crowded is the environmentSocial environment: Will the product be used by multiple users in the same location or spread over a larger area for e.g. collaboration or sharing of information and should this sharing be synchronous or asynchronous.Organizational requirements: How will the product enter into an organization? Will user be able to get help / support and how does the product fit into the organization infrastructureTechnical environment: Will the use of the product be dependent on some particular technology (e.g. does it need to run on a particular platform and will it need to be compatible with other existing types of technology)
  • User characteristics: What are the key attributes of the intended users? E.g. level of skill or ability (novice, intermediate pro) and frequency of use,nationality, educational background, preferences, personal circumstances, physical and mental disabilities etc. Based on such information it is possible to create a so-called user profile.
  • Usability goals and user experience goals:Usability goals: How well should it perform - Effectiveness, efficiency, safety, utility, learnability and memorabilityDoes boot fitsetcUser experience goals: Fun, enjoyable, pleasurable, aesthetically pleasing and motivatingWas it funplaying the game. Was the opponents toogood. Does the userlikefootball in the firstplaceRelated: No fun playing if boots doesn’t fit
  • Data gathering is necessary in order to establish requirementsThe data gathering activity includes the investigation of: what tasks the users currently perform and their associated goals, the context in which the tasks are performed.It is common to use multiple data gathering techniques (triangulation), but there are no rules specifying which ones to choose that all depends on what you are developing. The decision may for an instance be influenced by whether you are improving an existing product or creating something new altogether.
  • OVERVIEW OF SOME COMMON TECHNIQUES:Interviews: Good for making people explore issues. Semi-structured and unstructured interviews are often used early on to elicit scenarios. Both interviews with actual users and other stakeholders may be of relevance.
  • Focus groups:Good for getting a consensus view and highlighting areas of conflict and disagreement during the requirement activity. Another benefit is that it enables discussion amongst the different stakeholders (e.g. people with angle injuries and physiotherapist) since these might have a very different view of issues.
  • Questionnaires: May be used to get initial responses as a way of selecting the people to include in future interviews. Questionnaires may also be used to assess whether members of the target group actually finds a particular concept to be a viable solution and to get comments on the proposed concept. Reach a wider population.
  • Direct observation: Observation of participants in their natural environment is used to understand the nature of the task and the context in which it is performedThe exercise: Observe a child and parentreadining a regular booktogether
  • Indirect observation: Diaries and interaction logging are a good source of information about the steps involved in an activity and any regulations governing a task. May provide valuable information about how the activity is being performed in “real” life
  • Studying documentation: A manual may provide valuable information about:the steps involved in a particular task the rules associated with the use of such a product.
  • Researching similar products: It may be beneficial to study similar products (state of the art) since it may provide information about what features and interaction these products facilitate. This information may in turn help generate functional requirements.
  • Contextual inquiry is a popular method for uncovering requirements and particular requirements relating to the context of use. It follows the apprenticeship model implying that the designer works as an apprentice to the user.
  • Contextual inquiry rests on the four main principles:Context: It is important to go to the environment where the activity (potential interaction) takes place e.g. the work place of the userPartnership: The developer and user should collaborate in understanding the tasks and goals associated with the activity (e.g. work). So, understanding is developed through cooperation.Interpretation: Observations needs to be interpreted and not taken as gospel truth. E.g. Somebody developing a tool that would make me more efficient.When I work I tend to leave my desk a lot and walk around. This might seem like I am being lazy or my chair is uncomfortable, but the truth is that I think better when leaving the desk and my office. So if the designer had asked me he or she might end up thinking of ways to help me support this way of thinking say giving me a note pad instead of concluding that I am in need of discipline or a better chair.Focus: During data gathering one should remain focused on the goal. It is easy to get sidetracked during interviews or observations for that matter.
  • Moving from the collected data to clear requirements:There exist numerous ways of getting a better overview of the gather data and get an understanding of the user tasks and goals.In the course book four are described: Scenarios, Use cases, Essential use cases and task analysis.
  • An informal narrative description. So, it is essentially a story describing human activities or tasksScenarios can be used throughout the process of interaction design, but during the requirement activity it is a good idea for scenarios to emphasize:the context, the usability and user experience goals, and the tasks the user is performing and the associated goals. rather than a detailed description of how the technology functions. Does not have to be objective description of a course of events but may include references to the emotions experienced while performing an activity. May be used in combination with personas. May alsobeusedduring design to describeinteractionbetween the user and the product
  • Example:Story of a familiyinteracting with an travel plannerUser experiencegoals: outdooractivitiyholidyaysEnvironment: The travel organizer is located in a quiet corner of the agents’ office with cofortable seatsSocial activity
  • A tool for making user profiles more readily transparent to the designer. Personas are rich descriptions of typical users of the product under development that the designer can focus on and design the product for. They do not describe real users but are synthesized based on information gathered from real users. it is important to note that a persona describes a particular individual and not a class of individuals.
  • Persona properties: goals, skills, attitudes tasks and environment (a name, personal details and picture is oftentimes also included). It may also be a good idea to describe the user experience goals of the individual persona.Develop multiple personas
  • A use case is describes different ways of using a system. Use cases also focus on user goals, but emphasize the user-system interaction rather than the task itself. A use case is associated with an actor, and it is the actor’s goal in using the system that the use case wants to capture.
  • Here is an examplerealted to the holiday planner scenario from the bookYoucanseethathow it is an excangebetweenuser and system 1 is user 2 is system and so on…If you look at point 4 and 5:User enters country nameThe system checks if it is validThis could have more thanoneoutcome, thereforuse cases include alternative to 6
  • Here it is specifiedwhat the system doesif the name is invalid
  • Use case diagrams are a common way of graphically representing a use case. Actor (user) outside the box (the system) and the system may include other actors.Bubblesspecifiesthe differentgoalsthat the usersmight haveWhen creating a use case one starts with identifying the actors and then considers the goals they wish to achieve when using the system. Each of these goals may then become a use case !!!!
  • Developed to combat what they see as limitation of scenarios and use cases.:- Essential use cases represent more general abstractions compared to scenariosthey represent a more general case and try to avoid assumptions about the interaction e.g. that there is a system in the first placeAn essential use case is a structured narrative consisting of three parts 1) a name that expresses the overall intention, 2) a stepwise description of user actions and 3) a step wise description of the system responsibilities.Great for clarifying how tasks performed by the user and system tasks relate.Notice that: the steps are more general than those in the use case allowing form multiple alternate solutions. May be developed prior to actual use cases which describe the interaction in more detail.
  • Primarily used to investigate existing situation not for new products. Used to analyze the what people are doing, what are they trying to achieve, and why and how do they do soGood for establishing new requirements to design new tasks. May be used to investigate cognitive processes and physical actions at a high level of abstraction and in minute detail. The most commonly used approach is Hierarchical Task Analysis
  • One type of taskanalysisHierarchical Task Analysis (HTA):Involves breaking a task down into subtasks and then into sub-subtasks and so on. HTA focuses on the physical and observable actions that are being performed and includes non-software-related actions. The starting point is the user goals and then the tasked performed in order to achieve that goal are then identified and subtasks may then be identified if necessary.
  • Here yousee an example of the howtask of borrowing a book at the librarycanbebrokendownintosubactivities
  • As was the case with the use casesHierarchical Task Analysis include alternatives
  • And theymayberepresentedgraphicallyPLAN 0: Whathappensif the book isn’tthere 1, 3, 4If it is not there 2 is performed, whichinvolves a number of sub-sub-tasks.
  • Finish this part of with some general DATA GATHERING GUIDELINES FOR ESTABLISHING REQUIREMENTS (p. 500)Focus on identifying the stakeholders’ needsInvolve all the stakeholder groupsWhosaysthat the boss in a companywants the same as his employésInvolve more than one representative from each stakeholder groupDon’t just talk to oneusercausepeoplearediffernt and wantdifferntthingsUse a combination of data gathering techniquesCalled triangulation and Olga will talk more about inlaterlectures
  • ??
  • In case there is anydoubttheseare the activitieswearegoing to betalkingabout (well in part alsoevaluationsince prototypes areused in evaluation9Niels will talkeven more aboutthese steps as well
  • An artifact which allows stakeholders to interact with an envisioned product, to gain, some experience of using it in a realistic setting, and to explore imagined users.
  • Dan Saffer has put forththisdescription of what a prototypedoes:So a prototypecanbealmostanything:a series of screen sketchesa storyboard, i.e. a cartoon-like series of scenes a Powerpoint slide showa video simulating the use of a systema lump of wood (e.g. PalmPilot)a cardboard mock-upa piece of software with limited functionality written in the target language or in another language
  • Wedon’tknowif the usercan or willuse the productuntilthey have tried it!“[…] users can’t tell you what they want, but when they see something and get to use it, they soon know what they don’t want.”(p. 530)
  • Evaluation and feedback are central to interaction design
  • Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing
  • Prototypesfunction as a devicethatmayfurthercommuniction
  • Prototypes answer questions, and support designers in choosing between alternatives
  • Different types of prototypes may be useful for different purposes. - A paper mock up may be useful when gathering user feedback while a - simple implementation may be used to assert the technical feasibility of the product.
  • It is common to destinguishbetweenlow and highfidelity prototypesThe more the productresembles the real thing the higher the fidelity
  • So, Low fidelity prototypes Does not necessarily look a lot like the final product and need not be made of the same materials (e.g. an images on a screen may be represented by paper or cardboard). Low-fidelity prototypes are useful because they are easy and cheap to produce and thus easy and cheap to modify. Therefore, these are used during the earlier stages of production when multiple alternate designs need to be created. Low-fidelity prototyping techniques include:
  • Sketching is a common way of producing prototypes:Sketching does as the name implies simply refer to the activity of drawing (you do not need to be good a drawing in order to make a good sketch). Simple boxes and stick figures make up great sketches.
  • Storyboarding: Oftentimes used in conjunction with scenarios. - A series of sketches showing how a user might progress through a task using the product under development. The sketches may both illustrate the graphical user interface and/or the physical interaction with the device.
  • GENERATE FROM SCENARIOSA scenario is a story about how a product may be used to achieve the task. Therefore it is rather straightforward to generate a storyboard from a scenario.The storyboard provides yet another devise for improving communication amongst designers and with users. It also forces the designers:to consider aspects of the design which wasn’t explicated previously, such as what input devices are used (keys and mouse, touchscreen), thus offering a new layer of detail. So it helps you to explore the design, consider alternatives and prompts new questions.
  • Index cards:- Small cards or pieces papaper, each card representing one screen or a screen element, -a great tool for visualizing interaction. When used for evaluation, the user is then able to use the prototype by pretending to perform tasks while interacting with the cards.
  • Example of a prototype of aniPadapp ”mind mappingappliction”
  • Generating card-based prototypes based on use casesGiven the focus on interaction when using card based prototypes, use-cases form a great basis for the creation of this type of low-fidelity prototype.Also forces the designer to consider previously unexplored design issues. What type of screen elements should be used (buttons, drop down menus etc)where should they be placed. How should it look.
  • Last type of Low fidelity Wizard of Oz: Assumes that you have a software-based prototype, that is, such prototypes are at a higher fidelity level than say a storyboard. - The user interacts with the a system with limited functionality-the missing functionality is then simulated by another human.
  • 7th semester projectbased on Wizard of Oz prototyping: lets start with the video
  • Here yousee a screen capture from a testWe made people perform a simple task (not exactlylike in the final game) and in thatwayevaluatedmappingstrategies
  • When the REAL soldier enters the roomhe has to give the person displayed on the walldifferentinstructionsThe group did for variousreasons not implementvoicerecognition (but made the soldiersbelievethat it worked)Wizard hiddenbeind screen controlling the responses to soldierscommands.
  • As opposed to their low-fidelity counterpart, high-fidelity prototypes bears greater semblance with the actual product, that is, it may be made up of materials one would expect the final product to made up of and more of the actual functionality. High-fidelity prototypes are useful for selling ideas and for testing technical issues, but limitations do exist.
  • Limitations pertaining to high-fidelity prototypes include:They take too long to build and corrections are harder to make
  • Reviewers and testers tend to comment on superficial aspects rather than contentsComments on things e.g. graphics which you know you will improve are less useful
  • Limitations pertaining to high-fidelity prototypes include:One error may hamper the test
  • The second large iteration of the wobbleactiveprojectI introduced the firstday of the semesterThegoalwas still to motivateindividuals in need of anklerehabilitaiton by leveraging games potential as a source of intrinsic motivationWeredesignedphysical interface and created a new game
  • We made use of high-fidelityprototypingonce the system wasalmost doneIn case you dont remeber. Users controlled a Ufo on screen by means of a wobbleboard
  • ONE EXAMPLE OF A TEST involving a highfidelity prototype wasTest of differentmappingstrategiesBecause itwas in 3D we had the problem of figurering out howusershouldcontol the UFO
  • Here yousee a screen capture from a testWe made people perform a simple task (not exactlylike in the final game) and in thatwayevaluatedmappingstrategies
  • TO CONCLUDE THE TALKABOUTPROTOTYPINGPrototypingalwaysinvolvescompromisesbecauseyouaren’ttesting a final productDistingishbetweenHorizontal prototyping: providing a wide range of functionality but with little detailVertical prototyping: providing limited, but detailed, functionalityCompromises in prototyping (functionality breadth vs. depth):Both provide different info and maybeused for differentthings. E.g. start whith horisontal so youcanfigure out whatfuntionality to includeThe usevertical to test the differentwaysthisfunctionalitymaybedesigned
  • Conceptual design refers to the process of transforming the user requirements/needs into a conceptual model.Conceptual model: - “an outline of what people can do with a product [functional requirements] -what concepts are needed to understand how to interact with it[depends on e.g. who the users are, what kind of interaction will be used, what kind of interface, terminology, metaphors, application domain etc.]”
  • Devising a conceptual model involves answering three questions: Now I’ll talk a bit about interface methaphors and interaction types and how to design them
  • Interface metaphors: “combine familiar knowledge with new knowledge in a way that will help the user to understand the system” E.g. the desktop methaphor which you are familiar with whether you know it or not
  • Canyouthink of some of the metaphorsused in the design of iPad and iPhone?It makesuse of many
  • Selecting menu options is made intuitive by means: On/off switches and slidersChoosing numbers is made intuitive by means of a Combination padlock methaphorUnlocking the phone is made intuitive by means of a Slide lock
  • Choosing the correct metaphor is a balancing game with utility and “fun” on either side of the scale.Think of who is using the product. What are they familiar with (will make it easy to understand) vs. (what do they enjoy). Interactive book example (educational):A classroom metaphor (teacher at blackboard) might be used for an educational system for teaching six-year-olds about math, but would they find this fun. They would probably find a metaphor related to a particular game or entertainment, say the circus, more enjoyable. Three step process for choosing a good interface metaphor:
  • In the book theydescribethree steps thataregood to go throughwhenchoosingmetaphors:Understand functionality: Understand what he system will do (what are the functional requriements?)Identify problem areas: What parts of the system are likely to cause problems? (what tasks and subtasks are critical or complicated) The metaphor should support these tasks…Generate metaphors: These may be based on the descriptions of the tasks the users perform while are involved with an activity
  • The metaphors need to be evaluated. For this it may be worth considering the answers to the following 5 questions:How much structure does the metaphor provide? (Does it provide a logical and familiar structure)How much of the metaphor is relevant to the problem? (Will the metaphor make the user “over interpret” the metaphor. Word processors were originally based on a type writer metaphor: granddad using the key “enter” for line break) Is it easy to represent? How easy is the metaphor to represent say on screen?Will the audience understand it? How extensible is it? Is it possible to extend the metaphor to other areas of the interface.
  • The second thing to consider when devising a conceptual model was as previously mentioned what interaction types to employThere is also interface types, but youcanreadaboutthat in the book
  • In the text book four general interaction types are introduced: Instructing: The user instructs the system to perform in some particular way (e.g. by typing in commands, selecting from a menu)Conversing: The user has a conversation with the system so to speak (e.g. help menuor search engines)Manipulating: The user manipulates virtual objects (opens, closes, moves them e.g desktop)Exploring: The user moves through virtual (e.g. 3d environments) or physical space principles also apply here
  • Conceptual models may include multiple interaction types (and metaphors). What about the iPad or iPhone? Can you think of any interaction types used: - Instructing: you select icon from the main menu you instruct it to open an applicaition- Conversing: it has search function which qualifies as coversing; - Manipulating: rearranging the icons in the main menu; Exploring: Not really an iPad exclusive feature, but When you use google maps you may exploreRemember that the interface may be more than what takes place on screen. When the system is controlled by manipulating physical objects these objects are also part of the interface.
  • Once the initial conceptual model has been devised you will be able to continue expanding it. This activity involves answering the following three questions:
  • 1) What function will the product perform?It is essential to understand the tasks the product will support when expanding the conceptual model, but it is equally as important to consider in details what functions the product will perform (I.e. how are the task divided between the system and the user).If the cognitive load is too high for the user, then the device may be stressful to use and conversely if the products takes on to many tasks it will be inflexible and remain unused.Developing scenarios, essential use cases and use cases will help clarify this.
  • 2) How are the functions related to each other?- Tasks may be related temporally (in sequence or in parallel) or in terms of categories (tasks may be grouped according to categories). - You do in other words need to consider whether some tasks are dependent on other tasks having been performed before. In this case it might be an idea to restrict the user’s ability to perform certain tasks before other tasks have been performed.If task analysis has been performed prior to the creation of the conceptual model this should be relatively straightforward.
  • 3) What information needs to be available?Finally it is essential to consider:What information the user needs while performing a given taskhow the system is to represent said data.
  • This waswhat I had for youtodayREAD DESCRIPTION! Uploaded on website and I’llbearound to helpyou out until 1 where Jon and I’llbe meeting with the groups.
  • Lifecycle Models, Needs and Requirements, and Prototyping

    1. 1. Interaction Design <br />Lifecycle Models, Needs and Requirements, and Prototyping<br />
    2. 2.
    3. 3. 1<br />Lifecycle models<br />2<br />Needs and requirements<br />3<br />Prototyping<br />* The contents of this presentation has been adapted from chapters 9, 10 and 11 of <br />Interaction Design: beyond human-computer interaction (2nd edition) by Sharp, Rogers and Preece<br />
    4. 4. Exercise:<br />Interactive children’s book<br />
    5. 5. 1<br />Lifecycle models<br />
    6. 6. “[…] a model that captures a set of activities and how they are related.”<br />
    7. 7.
    8. 8. Three examples:<br />Software engineering<br />Interaction Design<br />HCI<br />
    9. 9. Interaction design model<br />
    10. 10. Start<br />Identify needs and establish requirements<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an interactive version<br />
    11. 11. A software engineering<br />model<br />
    12. 12. Requirement analysis<br />Design<br />Code<br />Test<br />Maintenance<br />
    13. 13. A HCI model<br />
    14. 14. Requirements / specification<br />Task analysis / functional analysis<br />Conceptual design / formal design representation<br />Prototyping<br />Implementation<br />Evaluation<br />
    15. 15. ?<br />
    16. 16. Identifying needs and establishing requirements <br />2<br />
    17. 17. What are needs and requirements<br />a<br />Types of requirements<br />b<br />Data gathering for requirements<br />c<br />Data analysis and interpretation<br />d<br />
    18. 18. Identify needs and establish requirements<br />Start<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an interactive version<br />
    19. 19. ?<br />Needs and requirements<br />
    20. 20. Whybother?<br />
    21. 21. Involves twoaims<br />
    22. 22. Identifying needs:<br />“[…] to understand as much as possible about the users, their work, and the context of that work, so the system under development can support them in achieving their goals” <br />
    23. 23. Establishing requirements: <br />“[…] to produce, from the needs identified, a set of stable requirements that form a sound basis to move forward into the thinking about design”<br />
    24. 24. Three activities:<br />Data <br />gathering<br />Analysis and interpretation<br />Establishment of requirements<br />
    25. 25. Three activities:<br />Data <br />gathering<br />Analysis and interpretation<br />Establishment of requirements<br />
    26. 26. Two types:<br />
    27. 27. Functional requirements:<br />specifies what the system should do<br />
    28. 28. Non-functional requirements:<br />dictated by constraints on the system and development <br />
    29. 29. Data requirements<br />
    30. 30. Environmental requirements <br />
    31. 31. User characteristics <br />
    32. 32. Usability and user experience goals<br />
    33. 33. Data gathering<br />for requirements<br />
    34. 34. Interviews<br />when you want to explore <br />
    35. 35. Focus groups<br />exploring different views<br />
    36. 36. Questionnaires<br />getting initial and general responses<br />
    37. 37. Direct<br />observation<br />
    38. 38. Indirect<br />observation<br />
    39. 39. Study documentation<br />
    40. 40. Research<br />similar products<br />
    41. 41. Contextual Inquiry<br />a popular method for uncovering requirements<br />
    42. 42. Four main principles<br />of contextual inquiry<br />Context<br />Partnership<br />Interpretation<br />Focus<br />
    43. 43. Data analysis and interpretation<br />moving from the collected data to clear requirements:<br />
    44. 44. Scenarios<br />Exploring contexts, needs, and requirements through stories of human activities or tasks <br />
    45. 45. Scenario example:<br />“The Thomson family enjoy outdoor activity holidays and want to try their hand at sailing this year. There are four members of the family: Sky who is 10 years old, Eamonn who is 15 years old, Claire who is 35, and Will who is 40. While out on a shopping trip they call by at the travel agents in their local town to start exploring the possibilities ... The travel organizer is located in a quiet corner of the agents’ office, where there are comfortable seats and play things for young children. They all gather around the organizer and enter their initial set of requirements—a sailing holiday for four novices. The stand-alone console is designed so that all members of the family can interact easily and comfortably with it. The system’s initial suggestion is that they should consider a flotilla holiday, where several novice crews go sailing together and provide mutual support for first-time sailors…”<br />
    46. 46. Personas<br />Fictional users synthesized based on information gathered from real users<br />
    47. 47. Properties<br /><ul><li>Goals
    48. 48. Skills
    49. 49. Attitudes
    50. 50. Tasks
    51. 51. Environments
    52. 52. (Name and picture)</li></li></ul><li>Use cases<br />Detailed descriptions of user-system interactions<br />actors<br />system<br />
    53. 53. Use cases example:<br />The system displays options for investigating visa and vaccination requirements.<br />The user chooses the option to find out about visa requirements.<br />The system prompts user for the name of the destination country.<br />The user enters the country’s name.<br />The system checks that the country is valid.<br />The system prompts the user for her nationality.<br />The user enters her nationality.<br />The system checks the visa requirements of the entered country for a passport holder of her nationality.<br />The system displays the visa requirements.<br />
    54. 54. Use cases example (alternative courses):<br />6. <br />6.1.<br />6.2.<br />8. <br />8.1.<br />8.2.<br />If the country name is invalid:<br />The system displays an error message.<br />The system returns to step 3.<br />If the nationality is invalid:<br />The system displays an error message.<br />The system returns to step 6.<br />
    55. 55. Use cases diagram<br />
    56. 56. Essential use cases<br />retrieveVisa<br />USER INTENTIONSYSTEM RESPONSIBILITY<br />find visa requirements request destination and nationalitysupply required information obtain appropriate visa infoobtain copy of visa info offer info in different formatschoose suitable format provide info in chosen format<br />
    57. 57. Task analysis<br />Analyzing existing situations before developing new products <br />
    58. 58. Hierarchical Task Analysis<br />Analyzing the tasks making up the task<br />
    59. 59. Hierarchical Task Analysis example<br />0. In order to borrow a book from the library<br /> 1. go to the library<br /> 2. find the required book<br />2.1 access library catalogue<br /> 2.2 access the search screen<br /> 2.3 enter search criteria<br /> 2.4 identify required book <br /> 2.5 note location<br />3. go to correct shelf and retrieve book<br /> 4. take book to checkout counter<br />
    60. 60. Hierarchical Task Analysis example<br />plan 0: do 1-3-4. <br />If book isn’t on the shelf expected, do 2-3-4.<br />plan 2: do 2.1-2.4-2.5. <br />If book not identified do 2.2-2.3-2.4.<br />
    61. 61. Hierarchical Task Analysis<br />graphical representation<br />Borrow book from the library<br />0<br />plan 0: <br />do 1-3-4. <br />If book isn’t on the shelf expected, do 2-3-4.<br />go to the library<br />find required book<br />retrieve book from shelf<br />take book to counter<br />3<br />2<br />1<br />4<br />plan 2: <br />do 2.1-2.4-2.5.<br />If book not identified from information available, do 2.2-2.3-2.4-2.5<br />access catalogue<br />access search screen<br />enter search criteria<br />identify required book<br />note location<br />2.1<br />2.2<br />2.3<br />2.4<br />2.5<br />
    62. 62. Datagatheringguidelines<br /><ul><li>Focus on identifying the stakeholders’ needs
    63. 63. Involve all the stakeholder groups
    64. 64. Involve more than one representative from each stakeholder group
    65. 65. Use a combination of data gathering techniques</li></li></ul><li>Design, prototyping and constructions<br />3<br />
    66. 66. What is a prototype<br />a<br />b<br />Categories of prototypes<br />c<br />Conceptual design<br />
    67. 67. Start<br />Identify needs and establish requirements<br />Evaluate<br />(Re)Design<br />Final <br />product<br />Build an interactive version<br />
    68. 68. ?<br />What is a prototype<br />
    69. 69. Prototypes communicate the message <br /> “This is what it could be like.”<br />Dan Saffer<br />author of Designing for Interaction<br />
    70. 70. Why bother?<br />
    71. 71. Evaluation and feedback <br />
    72. 72. Enables all stakeholders to<br />see, hold, interact<br />
    73. 73. Improves<br />team communication<br />
    74. 74. Prototypes answer questions, and <br />support designers in choosing between alternatives<br />
    75. 75. Categories of prototypes<br />
    76. 76. ”The higher the fidelity, the more it resembles the final product”<br />Low-fidelity<br />High-fidelity<br />
    77. 77. Low-fidelity prototypes<br />saving time and money during the early stages of development<br />
    78. 78. Sketching<br />no drawing is too ugly<br />
    79. 79. Storyboarding<br />Illustrated stories of interfaces and interactions<br />
    80. 80. Generating storyboards from scenarios<br />“The Thomson family enjoy outdoor activity holidays and want to try their hand at sailing this year. There are four members of the family: Sky who is 10 years old, Eamonn who is 15 years old, Claire who is 35, and Will who is 40. While out on a shopping trip they call by at the travel agents in their local town to start exploring the possibilities ... The travel organizer is located in a quiet corner of the agents’ office, where there are comfortable seats and play things for young children. They all gather around the organizer and enter their initial set of requirements—a sailing holiday for four novices. The stand-alone console is designed so that all members of the family can interact easily and comfortably with it. The system’s initial suggestion is that they should consider a flotilla holiday, where several novice crews go sailing together and provide mutual support for first-time sailors…”<br />
    81. 81. Index cards<br />visualizing interaction<br />
    82. 82. e.g.<br />
    83. 83. The embedded video can be found online at<br />http://www.youtube.com/watch?v=T4o8niW5LfQ&feature=player_embedded<br />
    84. 84. Generating card-based prototypes from use cases<br />
    85. 85. Wizard of Oz<br />Simulating functionality <br />
    86. 86. e.g.<br />
    87. 87. Video example<br />
    88. 88. Wizard of Oz example<br />simulating voice recognition<br />
    89. 89. High-fidelity prototypes<br />Testing usability and technical issues during later stages of the development<br />
    90. 90. Time is an issue<br />
    91. 91. It may look finished<br />but it’s not!<br />
    92. 92. Testing a faulty system<br />
    93. 93. High-fidelity prototype example <br />WobbleActive 2.0<br />
    94. 94. High-fidelity prototype example <br />WobbleActive 2.0<br />
    95. 95. Testing mapping strategies<br />or<br />
    96. 96. Video example<br />
    97. 97. Compromises in prototyping<br />horizontal prototyping vs. vertical prototyping<br />
    98. 98. Conceptual design<br />Moving from requirements to a conceptual model<br />
    99. 99. Involves answering the questions: <br /><ul><li>Which interface metaphor would be suitable to help users understand the product?
    100. 100. Which interaction type(s) would best support the users’ activities?
    101. 101. Does different interface types suggest alternative design insights or options?</li></li></ul><li>Interface metaphors:<br />“combine familiar knowledge with new knowledge in a way that will help the user to understand the system” <br />
    102. 102. What metaphors apply here?<br />
    103. 103.
    104. 104. Balancing utility and fun<br />Should an educational application mimic school or play? <br />vs.<br />
    105. 105. Three steps<br />for choosing interface metaphors: <br /><ul><li>Understand functionality
    106. 106. Identify problem areas
    107. 107. Generate metaphors </li></li></ul><li>Evaluating interface metaphors: <br /><ul><li>How much structure does the metaphor provide?
    108. 108. How much of the metaphor is relevant to the problem?
    109. 109. Is it easy to represent?
    110. 110. Will the audience understand it?
    111. 111. How extensible is it? </li></li></ul><li>Interaction types<br />
    112. 112. Instructing<br />Conversing<br />Manipulating<br />Exploring<br />
    113. 113. What interaction types apply?<br />Instructing?<br />Conversing?<br />Manipulating? <br />Exploring?<br />
    114. 114. Expanding the conceptual model<br />
    115. 115. What function will the product perform?<br />What tasks will the product will support and how are they divided between the user and the system?<br />
    116. 116. How are the functions related to each other?<br />Are the tasks performed in sequence or in parallel? <br />
    117. 117. What information needs to be available?<br />What information does the user need in order to perform given tasks and how should the system represent it?<br />Afghanistan<br />Africa<br />Albania<br />Algeria<br />American Samoa<br />Andorra<br />Angola<br />Anguilla<br />Antarctica<br />Antigua & Barbuda<br />Antilles, Netherlands<br />Arabia, Saudi<br />Argentina<br />Armenia<br />Aruba<br />
    118. 118. Exercise:<br />Interactive children’s book<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×