Information & Interaction Design Fall 2005 Bill Hart-Davidson Session 7: teams present research plan + a sequence diagram from phase 2 homework; Affinity diagrams; Preview: object-oriented modeling

Today in Class Be ready to share… –Your Research Plan –Your Sequence diagram We’ll talk about affinity diagrams as a way to analyze data from your CD interviews We’ll talk about consolidated sequence diagrams Key OO modeling concepts

Tell us about your Research Plan The research focus - what does your team need to know? The interviews/observations you will do broken down by roles The approach you will take in each of these How you will deal with the challenges your project poses

Affinity Diagrams & Consolidated Work Models Affinity diagrams and consolidated work models are tools for making inductive reasoning from multiple data sources systematic by: 1.Creating concrete representations of work practices 2.Granting “ownership” of the representation and subsequent designs to the whole team 3.Emphasizing patterns vs. anecdotes

What is an Affinity Diagram? Simply put, it is a issue- categorized, prioritized list of the insights that come from interpretation sessions. n

Affinity Diagram: Structure sum. points sum. points sum. points sum. groups point Built from the bottom up, categories emerge from the specifics of your observations. NOT a “sorting” task.

Example… weekly reports focus on production goals and customer quality metrics all users routinely print And file customer s customer contact records are important, but informal

Innovating w/ the Affinity As patterns emerge, the team’s job is to link these with design goals…bringing your expertise IT systems to bear on the data sum1 Customer-relationship management point sum2 point

The Affinity tells users’ stories We do it routinely… Customer-relationship management is vital to our business file Call back sheets But inconsistently…

The Affinity gives you a way to check design direction w/ users “We have noticed that maintaining relationships with customers is important to you. You spend a great deal of time during the day doing this sort of work: creating or updating records, responding to , logging and returning calls. You also evaluate your staff using metrics that relate to this work, and yet much of it is done ad- hoc and informally…what we would like to do for you is…

Consolidated Work Models Like Affinity Diagrams, consolidated work models tell stories of how work happens in ways that 1.Allow the whole team to see and understand work practices 2.Highlight design issues and opportunities

Consolidating = move from individual  organizational patterns Flow models: move from understanding individual workers’ practice to patterns of work by “role” Sequence models: move from understanding instances of work to the structure of the work, including reasons for differences observed

Consolidated sequence diagrams: UML/swimlane studentteacher Assign paper peer Draft paper Draft paper Exchange & Review papers Check reviews Note all user roles involved in a task are represented ; artifacts are in blue; trigger in red Cont.

Sequence consolidation: grading Instructor skims whole report quickly, no more than 2-3 seconds per page Instructor returns to P1, begins reading Instructor flips through document, lingers on heading on p. 3 Returns to p.1, reads abstract Flips through all pages again quickly Returns to P1, begins reading

Nominating the action: “triage” Instructor skims whole report quickly, no more than 2-3 seconds per page Instructor returns to P1, begins reading The fact that the instructor encountered no serious problems in this instance made the purpose of this action hard to detect

Consolidation reminders When you give a generic name to a role, an action, an influencer (in the cultural model), a tool (in the artifact or physical model), or a space (in the physical model)…verify it with users! These generic names will be very important in our next phase of the design, OO modeling, as they will frequently become the shorthand for system features including user environments (metaphors, screens), data objects & states, actions, and of course, user roles.

OO modeling Object-oriented modeling provides a way to coordinate the design work with development work by using similar terms to express the priorities of each group. We speak, in OO modeling, in terms of User Roles that do specific Actions through the use of Objects.

Views A view is the way a given object appears to a user. Views can focus the attention on a single object, or provide a way to see, understand, and interact with many objects at once.

2 Views of the Buddy Object in AIM Buddy name, status in “buddy list” Buddy details in “buddy info”

Object/View Instances Objects spawn “instances” of themselves that users interact with. This allows the same basic object to carry context-specific details. Views also have instances, which tend to be “sessions,” reflecting the time, place, and task conditions.

Object States Most objects a user interacts with have a lifecycle, a series of “states” it can go through. At any given time, an object is occupying some state and may be poised to move to another (usually as the result of something the user does).

Next time… Artifact and Physical Models –Exercise 2, build a consolidated Artifact or physical model Representing design concepts w/ OO modeling techniques Guidelines for Phase 2 presentations