1. Harry Hochheiser
Department of Biomedical Informatics
University of Pittsburgh
harryh@pitt.edu
Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Attribution-ShareAlike
CC BY-SA
From Models to Design
2. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
The modeling process
● Interpretation session for each interview
● Draw models
● Build shared design
● Consolidation of models
● Affinity diagram – hierarchical categorization of notes from interpretation sessions
● Consolidated diagrams – synthesis of salient components of diagrams from individual
interviews
3. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Consolidated Models for data
driven design – Flow Model
● Flow model
● Eliminate redundancy -automate or eliminate roles, Organize roles,
support task switching, reassign responsibilities or roles, support
communication between roles, define new roles and job responsibilities
● Sequence Model
● Eliminate steps that are not key, render goals or subgoals irrelevant,
account for all secondary intents, redesign activities that are constrained
by artifacts that might be changing – look at the why, not the what.
● Use models to identify opportunities for improvement
4. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Alternative Approaches -
Scenario-Based Design (Rosson & Carroll 2001)
● Tasks Analysis – like sequence flows, but hierarchical
● Summary of themes
● Hypothetical stakeholders
● Series of increasingly-detailed scenarios
● Refine towards design
● Claims Analysis – pros and cons of various features.
● Scenarios also good for communicating research results-
● SearchTogether
5. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Scenarios - claims analysis
• Review scenarios to identify implications of contents
• +/- pros/cons of content
6. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Problem scenario: visit to a
science fiction club meeting
Rosson & Carroll 2002
• “ Sharon is a busy third-year psychology student at Virginia Tech. Even though she
has a biology exam tomorrow morning, she has been looking forward to her science
fiction club meeting for several days, so she decides to go and stay up late to study
when she gets back. She remembers that they were planning to talk about Asimov’s
Robots and Empire, and she has a new theory about the timeline for first detection of
the Zeroth Law.
• The meeting is scheduled for 7pm at their usual room in the town library. But she is late
getting back from dinner with her room-mate, so she misses her regular bus and arrives 15
minutes late. The meeting is already underway; she notes that they have a relatively small
group tonight, but is happy to see Bill and Sara, who are the real experts on Asimov. She is
even more delighted to see that these two are already having a heated discussion about the
Zeroth Law. But she is cannot immediately tell what points have been made, so she sits back
a while to catch the drift of the conversation. At a break, Bill greets her and asks her
what she thinks about Faucian’s insight. She replies that she isn’t sure about how
central he is to the plot, but that she has a new theory about the timeline. They
promise to hear her proposal in a few minutes, then resume the argument.”
7. BIOINF 2121 Fall 2014Harry Hochheiser, harryh@pitt.edu
Problem scenario analysis: claim 1
Face-to-face interaction with club members at a meeting
+ ensures that both non-verbal and verbal communication contribute to the conversation
+ leverages many years of experience with communication protocols and conventions
- but may introduce distracting or irrelevant personal information about partners
- but inhibits parallel communication activities (among multiple parties at once)
8. BIOINF 2121 Fall 2014Harry Hochheiser, harryh@pitt.edu
Problem scenario analysis: claim 2
A regular physical space used for club meetings
+ promotes a feeling of familiarity and intimacy among established members
+ simplifies the planning and execution process for arriving at meetings
- requires members to travel to the site for interaction
- physical locations are valuable resources that might be shared
Later: use these claims to drive activity and interaction design
9. BIOINF 2121 Fall 2014Harry Hochheiser, harryh@pitt.edu
Revise and refine scenariosCarroll and Rosson 2002
10. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Other perspectives:
Value-Proposition Design
Osterwalder, et al. 2014
• Customer Profile
• Contextual inquiry and scenario
activities identify
• gains
• pains
• jobs
11. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Value-Proposition Design
Osterwalder, et al. 2014
• Identify
• gain creators
• pain relievers
• Solve users’ problems.. and
your tool might be successful
12. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Which of these approaches to use?
• All of them?
• Whichever make sense?
• Goal - build understanding
• inform design
13. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Validity Concerns
● Goal – analysis should reflect reality..
● If it doesn't, there's a problem
● Where could we go wrong?
● How to address validity?
14. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Validity
● If multiple researchers agree consistently, we can't be far off.
● Quantitative
● Agreement
● Inter-rater reliability
● Qualitative
● Consensus – discuss and revise until convergence
● Verify completeness - minimize unused content.
● Member checking - review with participants and/or stakeholders
● Alternative hypotheses -
● Consider and reject
15. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Checklist: Model Development
1. Select types of models, as needed to describe and collect key
observations
2. Develop models at appropriate levels of granularity: Broad flows belong
in flow diagrams while detailed steps are included in sequence diagrams.
3. Model exceptions, breakdowns, and difficulties where applicable.
4. Avoid cherry-picking: Incorporate all observations, including those that
might be inconsistent with your model or otherwise contradictory
5. Consider alternate models, particularly in case involving contradictions
6. Review with informants, to insure validity
16. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
After Interpretation
Data Collection
Analysis and
Interpretation
Design Activities
Before designing..
How do you know
you've got it all,
and got it right?
Review with
Stakeholders
17. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Moving toward design
• Goal - common understanding informing design
• “Wall walk” team members walk the wall of the affinity diagram
• read notes/structure
• Identify issues that must be addressed
• Write down hot ideas
• review diagrams - post ideas
18. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Visioning
Beyer & Holtzblatt 2014
• Tell story of new design and how it will change thing
• Analogous to activity scenarios
• Don’t evaluate- brainstorm
• Don’t worry about details
• don’t do screen design
• Multiple visions
19. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Visioning
Beyer & Holtzblatt 2014
Critique:
what works, what doesn’t
• Lack of fit to user
• Technical difficulty
20. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Design
• What do users do - “Practice Design” , “Activity scenarios”
• How does it work - interaction design
• screen layouts, buttons, etc.
• User experience design - how does it tie together in terms of sequences
and tasks?
• What does it look like? Visual design
21. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Storyboards
● Cartoonish depictions of interaction designs/visions
● Design to communicate ideas
● Particularly for stakeholders
● Tell the story graphically – graphical scenarios..
22. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Storyboards
● Amal Dar Aziz – Guide to storyboarding
● http://hci.stanford.edu/courses/cs147/assignments/storyboard_notes.pdf
23. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Prototypes
● User Environment Design - informs interface design
● Two challenges
● How to do the design
● How to use prototypes to engage users and validate design
24. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Prototypes
Wizard-of-Oz
Storyboard
Video Prototype
Rapid Prototype
Working System
Low Cost, Low
Fidelity
High Cost, High
Fidelity
Paper prototype
Computer Animation
Rosson & Carroll, 2002
26. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Prototypes evolve
H. Beyer & K. Holtzblatt, Contextual
Design. ACM Interactions, 1999
• Explore with users
• Modify on the fly
• Insights inform
• Redesign
• Revision of earlier findings
• New visions
• Iterate
• Other forms
• More detailed mockup
• “Wizard-of-Oz”
• Don't get too pretty too quickly
•Discourages feedback
27. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Prototypes as means, not ends
Paper Mockup of Stembook
Das, et al. 2008 Linked Data in a
Scientific Collaboration Framework
www.stembook.org
28. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
The Prototype Paradox
● Prototypes are supposed to be throw-away, but...
● ..they tend to take on a life of their own
● Especially when presented as (possibly minimally) working software
● Another argument for staying with paper as long as possible
● Try multiple prototypes to explore broader range of ideas
29. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
User Environment Design
● Storyboards and scenarios are not necessarily complete
● Tie them together in some coherent whole?
● System-level view
● System-level diagrams to try to layout relationship between activities how well
does it hang together.
● Analogy -architectural floor plan?
30. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Floor plans as inspiration...
● Show overview of how things fit together – not too much detail
● S. Wood 2003 Using a Floor Plan as a Metaphor for Design: Is your product a dream house, or a
construction nightmare? http://incontextdesign.com/articles/using-a-floor-plan-as-a-metaphor-for-
design-is-your-product-a-dream-house-or-a-construction-nightmare/
31. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
User Environment Design
● Focus areas with functions, link, objects.
● Defines overall structure of how things will get done
● Built up from storyboards
● Can guide development – one “room” or focus area at a time...
● Not UML Design
32. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Testing and iteration
• Field interviews with paper prototypes
• Like contextual inquiries
• Users manipulate prototypes and revise immediately.
• Revise
• iterate - 3 rounds?
• Consider multiple alternative designs.
33. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Contextual Design and Agile
Development
● The Agile Manifesto (www.agilemanifesto.org)
● Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
● Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
● Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
● Business people and developers must work together daily throughout the project.
● Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
34. Harry Hochheiser, harryh@pitt.edu Baobab Health, February 2015
Contextual Design and Agile
Development
● The Agile Manifesto (www.agilemanifesto.org)
● The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
● Working software is the primary measure of progress.
● Agile processes promote sustainable development.
● The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
● Continuous attention to technical excellence and good design enhances agility.
● Simplicity--the art of maximizing the amount of work not done--is essential.
● The best architectures, requirements, and designs emerge from self-organizing teams.
● At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.