Cooper Interaction Design Process: Requirements Definition & Framework OverviewDr. Cindy Corritore

Creighton University

ITM 734Fall 2005

Corritore, 2005

goal-directed design• Step 1 – research• Step 2 – modeling

• Step 3 – requirements definition1. expectations2. context scenarios – scripts for main activities3. data needs – nouns working with4. functional needs – verbs (‘needs to be able to do’)5. Additional requirements – laws, vision ….

• Step 4 – framework1. posture & input2. functional & data elements3. key path scenarios, group elements, sketches4. 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 31. 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 – framework1. 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 item product selection widget

ability to remove item product 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

exampleName the panes

Area for keeping items

of interest: Lister

Related Items: Browser

Chosen Item Details area: Details

Purchase Committment.: Purchase

Corritore, 2005

exampleShow 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 Browserchanges 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 email 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. .