Cooper Interaction Design Process:Dr. Cindy Corritore

Creighton University

ITM 734Fall 2005

Corritore, 2005

how long does it take?

• research –

• modeling –

• requirements definition –

• framework definition –

• visual design –

• ½ -15 days

• ½ -10 days

• ½ - 3 days

• 2 – 15 days

• 1 – 80 days

Corritore, 2005

goal-directed design

• Step 1 – research– collect data

• Step 2 – modeling– derive persona and goals from data

• Step 3 – requirements definition1. 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 definition

Corritore, 2005

Step 2: Modeling

• modeling – to create a representation or simulation of something

• persona - distillation of behavior patterns– personal details to make it seem real– more behavioral than descriptive– help focus on user needs

• one persona for each behavior pattern

Corritore, 2005

why done?

• single data points don’t mean much, but patterns of behaviors do

• lots of data – need to capture

• useful things to model– users – personas– artifacts (processes, data)– workflow among people (what happens, in

what sequence, involving whom)

Corritore, 2005

persona• almost every sentence describes something we

learned• specific to the design problem/product domain• captures

– goals– attitudes– work or activity flow– environment– skill level– frustrations

Corritore, 2005

modeling process

1. ID behavioral variables– for each role list ways in which behavior

differed as a set of behavioral variables (continuum)

• how does behavior differ?• how can this role be differentiated?• if behaviors same for two roles, are two roles really

different for our purposes?

– may include a few, if any, demographics– typically around 20-30 of these

Corritore, 2005

modeling process

2. map interviewees to variable continuums– relative to each other

Corritore, 2005

modeling process

3. ID major patterns– people who cluster around behaviors

together – consistently

• variables without much differentiation – doesn’t define persona

Corritore, 2005

modeling process• flesh out patterns

– patterns should make sense, hang together– name each one briefly and give a few related details

drawn from data• eg. casual photographer• major tasks and flow• problems with current solutions• home or work space• where they fell on each behavioral variable used• goals

• do they make sense? • some items may be poor correlations so may not be

essential to the pattern – these will be satisfied by persona needs being met

Corritore, 2005

goals• goals – get from data

– must be directly related to the product– may have one experience goal (have fun, feel smart)– rest end-goals (be proactive, not reactive; clear desk by 5)

• need 3-4 for each behavior pattern– what’s a good day?– what’s a bad day?– what are the most important things you do?– If product was magic, what would it do?– how are people behaving now?– what are they trying to accomplish?

Corritore, 2005

goals

• example

• data:

• goal: keep in touch, don’t feel lonely

• widow, 70s• lives alone in small town• sees daughter & grandkids

once/month• other family far away• keeps TV on for noise • sends lots of greeting cards &

letters

• group together, then arrange and make into goals

Corritore, 2005

goals vs tasks

• tasks– easily do this or that …..– feeling of accomplishment – task again

Corritore, 2005

what next?

• develop the persona narrative– each team – we will pick one next week– make the persona seem real – narratives, not

bullet points - more powerful• just a couple of personal details – otherwise

distracting

Corritore, 2005

finally

• classify personas– primary – must be satisfied, requires a specific

interface, satisfy them, satisfy most of others– secondary – mostly satisfied with primary’s interface

but has a/some specific additional need(s) that must be accommodated

– supplemental – completely satisfied with primary person design but retain to address stakeholder assumptions

– negative persona – definitely not designing for – if make this person happy, others unhappy

Corritore, 2005

goal-directed design

• Step 1 – research– collect data

• Step 2 – modeling– derive persona and goals from data

• 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 ….

Corritore, 2005

Requirements Def.

• product must do these to satisfy our user(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– stakeholders, executives making decisions

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 shopping

experiences– 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 give 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 – 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

Framework Definition

• four steps1. 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– 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 (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 (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.

So create key-path scenarios– incorporate data and functional elements– extension of context scenarios

• 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 thumbnail 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.

• 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

– wireframe stage

Corritore, 2005

example

Area for finding

documents

Toolbar with misc. stuff

Document display area

System status display, performance graphs, etc.

Corritore, 2005

example

Area for finding

documents:Organizer

Toolbar with misc. stuff: Toolbar

Document display area: Workspace

System status display, performance graphs, etc.: Dashboard

Name the panes

Corritore, 2005

example

Area for finding

documents:Organizer

Toolbar with misc. stuff: Toolbar

Document display area: Workspace

System status display, performance graphs, etc.: Dashboard

Show interactions – still at high level …

selection in organizer changes workspace contents

Does not change based on selection

Corritore, 2005

Framework Def.

4. Check design sketches with validation 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

our project• Milestone 1 (Nov. 14): Modeling and Requirements –describe

stakeholders, customers, users, subject matter experts, variables, persona(s) narratives, context scenarios, unit of data, data and functional needs, expectations. Post these to your team account and email the link to me. We will vote on a persona, set of context scenarios, data and functional needs, expectations to use for entire project.

• Milestone 2 (Nov. 21): For each team, the Framework Definitions, document should 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.

• Milestone 3 (Dec. 5): 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.

Corritore, 2005

Appendix

Corritore, 2005

important practices

• no designing alone

• small teams (2-3)

• defined ways of collaborating in meetings

• techniques for getting ‘unstuck’

Corritore, 2005

working alone …

• can lead to– frustration– wasting time on unproductive ideas– assumptions– incomplete work

Corritore, 2005

small teams

• more time spent on work, not organizing and communicating

• consensus easier

Corritore, 2005

ways of collaborating

• one person drives idea generation

• one person focuses on testing the idea to help it evolve and make sure it is fully defined

Corritore, 2005

getting unstuck

• 15 min. rule – if stuck for 15 min, stop and ask for a brief explanation of– who is the user– what is the user trying to accomplish– what the idea under consideration is

• ask– what’s this?– how does that work?– use ‘what-if’ scenarios (ie. how does she …)

Corritore, 2005

ways to get unstuck• pretend it is magic

– easy to get bogged down in constraints and limits thinking

– ‘what if my persona had a great personal assistant’ – what would he do?

• focus on what system should do, not can do• examples – what would these do if magic?

– TV/entertainment systems– telephone/voice mail– OS– calendar software