Cooper Interaction Design Process: Requirements Definition & Framework Overview Dr. Cindy Corritore Creighton University ITM 734 Fall 2005

Corritore, 2005 goal-directed design Step 1 – research Step 2 – modeling Step 3 – requirements definition 1.expectations 2.context scenarios – scripts for main activities 3.data needs – nouns working with 4.functional needs – verbs (‘needs to be able to do’) 5.Additional requirements – laws, vision …. Step 4 – framework 1.posture & input 2.functional & data elements 3.key path scenarios, group elements, sketches 4.validation scenarios with sketches

Corritore, 2005 Requirements Def. product must do these to satisfy our persona(s) high level, big picture (like the house will have three bedrooms, how big the rooms are, etc) –don’t know exact dimensions, where windows are, etc. audience for this step are not developers

Corritore, 2005 Step 3 1.expectations 2.context scenarios – scripts for main activities 3.data needs – nouns working with 4.functional needs – verbs (‘needs to be able to do’) 5.Additional requirements – laws, vision ….

Corritore, 2005 first step 1.Expectations –how does persona think about things they are using? –ie. mental model they have about this product and it’s use fundamental conceptions basic units of data

Corritore, 2005 example expectations –influenced by real world experiences –eg. shopping app obvious how to find or return a product, or easy to find help product information immediately available or easy to ask for help way to keep track of things

Corritore, 2005 next 2. Context Scenarios –describe how persona might use the product during a session – major kinds of activities persona does all the time with product – all of the critical ones information, actions, trigger(s), sequence must be included no ‘how’ (mechanisms), no edge cases (only ‘most of the time’) avoid details of how this gets done –new, goal-directed version of what should be (not how it is done now) –2-3 of these in narrative - activities that we need to cover well to be successful –like scripts for actors (the personas)

Corritore, 2005 example Context Scenario example –wants to buy a gift for a friend who likes dogs, but doesn’t have anything specific in mind –sits down at computer in home which she shares with family –goes to website and wants to see an overview of dog- related products to get a good idea –sees a category of interest – perhaps a book - wants to explore this further –sees several items of interest that she wants to keep track of –eventually picks one and wants to purchase it – but wants to keep the other items of interest for future gifts –wants to know when it will ship and arrive what are the data objects here?

Corritore, 2005 next 3. Data Needs –basic units of data – –nouns that they think about, manipulate –mostly based on mental model and context scenario –can fill in attributes later

Corritore, 2005 next 4. Functional Needs –ID what persona must be able to do with, to, in response to data objects verbs –based primarily on context scenarios and somewhat on goals –** don’t jump to solutions (eg. keep track in a database)

Corritore, 2005 example functional needs – persona needs ability to: –keep track of items she is interested in, but may or may not buy today –find what’s on sale –see at least some information about multiple products so can compare –doesn’t want to narrow choices early on –may prioritize – things she must be able to do, other things that would be nice but aren’t deal-breakers

Corritore, 2005 next 5. Additional Requirements –not driven by scenarios but important –laws, security, environmental (eg low lights, used outside or on small screen), personal (adept with browsers), domain knowledge, reading ability –intermittent user – so must be visually obvious how to use

Corritore, 2005 Requirements Def do this as a team examples from previous projects online deliverable - document

Corritore, 2005 goal-directed design Step 1 – research Step 2 – modeling Step 3 – requirements definition Step 4 – framework 1.posture & input 2.functional & data elements 3.key path scenarios, group elements, sketches 4.validation scenarios with sketches

Corritore, 2005 Framework Def. 1.posture & input– attitude (rules the screen or transient (like a calculator)- impacts screen space available keyboard, mouse?

Corritore, 2005 Framework Def. 2. list functional [& data] elements based on needs –now looking for solutions (elements)– most is clear-cut (silly step but a good check) –data objects and elements about the same can add in attributes now

Corritore, 2005 Framework Def. look at functional needs and identify functional elements required –these are the visible product components that meet functional needs places to put data objects (containers – how much space needed? tools that act on data objects (widgets – how many are needed?) –now you exercise design judgment – of the possible solutions, which is most likely to accomplish user goals with least extra work best fit design principles fit this problem solution space –still general (a widget, not a drop-down list)

Corritore, 2005 example Keep track of items“items I am interested in” pane know what price an item is price display ability to select an itemproduct selection widget ability to remove itemproduct removal widget Functional Need Functional Element

Corritore, 2005 Framework Def. 3. Group and sketch elements & determine hierarchy – 2 ways to do this Approach 1: (visual thinkers) –create a sketch of this –take scenario to next level of detail (develop key path scenarios) to describe this – does it fit sketch? –see if groupings of pieces (elements) make sense – have to think about how they interact – work with scenarios?

Corritore, 2005 Framework Def. 3. Group and sketch elements & determine hierarchy – 2 ways to do this Approach 2: (verbal thinkers) –take scenario to next level of detail (develop key path scenarios) to describe this –verbally group pieces (elements) in way that puts like items together – have to think about how they interact –create a sketch of this

Corritore, 2005 Framework Def. We will walk through the Verbal approach. a. create key-path scenarios first –incorporate data and functional elements –extension of context scenarios but more detailed

Corritore, 2005 example Mary wants to buy a gift for a friend who likes dogs, but doesn’t have anything specific in mind. She goes to the website and looks at the product listing area. Initially it contains something of general interest, probably things that are on sale or otherwise featured. She sees something related to dogs and books and thinks this might be a good idea. What kinds of books are available and would make a good gift? She manipulates something in the product listing that lets her focus on dog books.

Corritore, 2005 example She sees a list of dog books with small pictures and some other information (price, title, author). It’s sorted by authors; she would rather see it sorted by price. She sees one that looks interesting and selects it in the product listing. Detail appears in the detail area. After reading more, she’s no longer interested, so she picks another from the product listing. This one looks interesting for herself but not for her friend. She wants to save it but not necessarily buy it today. She clicks a button or control in the detail area, and the shopping cart appears with the selected item in it. She continues shopping using the product listing.

Corritore, 2005 Framework Def. b. Next determine hierarchy of the functional elements – group them in way that makes sense, how they will be used –what is on screens, how many screens, etc. –start to think about views – these are screens –major state of the screen for a particular activity with particular set of tools –each context scenario gets it’s own view

Corritore, 2005 example 4 major container panes –area to put things possibly interested in –area containing related products that meet certain criteria –area for individual products with details –area where she commits to and purchases item(s) scenario and mental model – she will use first three together in sequence –multiple products –individual product –either possibly interested area or back to multiple products Finally she will commit to purchase and transact (always at end)

Corritore, 2005 example 4 major container panes –area to put things possibly interested in –area containing related products that meet certain criteria –area for individual products with details –area where she commits to and purchases item(s) scenario and mental model – she will use first three together in sequence –multiple products –individual product –either possibly interested area or back to multiple products Finally she will commit to purchase and transact (always at end)

Corritore, 2005 Framework Def. finally sketch the interaction framework –quite high level at first –rectangles (ppt) –do for each view lay out panes, name and define them, discuss relationships between them whatever gets used first goes towards top left. –state diagrams basically – picture of the screen at a particular moment in time of a given scenario –called the wireframe stage

Corritore, 2005 example Area for keeping items of interest Related Items Chosen Item Details area Purchase Committment.

Corritore, 2005 example Name the panes Area for keeping items of interest: Lister Related Items: Browser Chosen Item Details area: Details Purchase Committment.: Purchase

Corritore, 2005 example Show interactions – still at high level … Area for keeping items of interest: Lister Related Items: Browser Chosen Item Details area: Details Purchase Committment.: Purchase if selection in Detailer changes Lister contents Does not change based on selection selection Browser changes Details contents

Corritore, 2005 Framework Def. 4. Check design sketches with validation scenarios (key path scenarios) –see if design accommodates key path scenarios and persona –try to blow holes in it and fix them –check with secondary personas at this point

Corritore, 2005 remember each primary persona gets an interface!

Corritore, 2005 Iteration Next major step – purpose is to turn interaction framework into a complete, cohesive product design –add more detail to your scenarios (widget level), then use this to repeat steps 2-4 for each area of screen, working at the widget level –may need to refer back to data and functional needs again when adding detail

Corritore, 2005 Milestone 1 (Nov. 14): Modeling Definition: for each team, describe stakeholders, customers, users, subject matter experts, variables, persona(s) narratives (with goals). Post these to your team account and the link to me. We will vote on a persona and goals to use for entire project. Milestone 2 (Nov. 21): Requirements and Framework Definition: for each team, the Requirements Definition must include context scenarios, unit of data, data and functional needs, expectations for each primary persona. The Framework Definitions document must include the data and functional elements, matrix with functional needs and functional elements, framework rough sketch (rectangles view – first pass with arrows showing movement), views for each context scenario, key path scenarios. No iteration yet – just the first pass. Each team does own. Milestone 3 (Dec. 5): Iteration: for each team, show me at least half of your completed (iterated) designs (views) for each key scenario, with widgets in place, in your team account. Be able to defend your design based on the data from the research phase and validation scenarios you have run. Final Product (December 12 6:30PM): Design complete. Presentation..