Blending
            User
    Experience
     & Business
        Analysis
 thinking in the
Agile Customer
            Role...
Blending
            User
    Experience
     & Business
        Analysis
 thinking in the
Agile Customer
            Role...
Blending
            User
    Experience
     & Business
        Analysis
 thinking in the
Agile Customer
            Role...
Blending
            User
    Experience
     & Business
        Analysis
 thinking in the
Agile Customer
            Role...
PEOPLE Learn Skills in a 3-stage Progression:
 Follow / Break Away / Achieve Fluency

        Level 1:following (shu)
    ...
Today I’ll cover 3 areas

  1. What is user experience
           design?

2. Design & analysis practices
  useful for Agi...
By “Design” I mean the decisions we make regarding
        the software solution we choose to build.




© 2006-2007 Jeff ...
By “Design” I mean the decisions we make regarding
        the software solution we choose to build.

                    ...
By “Design” I mean the decisions we make regarding
        the software solution we choose to build.

                    ...
Garrett’s Elements of
User Experience Model
 describes a series of
 dependent decisions.


                     5


      ...
Software user experience is built
        from dependent layers




© 2006-2007 Jeff Patton, All rights reserved, www.agil...
Software user experience is built
        from dependent layers




      Jesse James Garrett’s Elements of User Experienc...
The surface layer describes finished visual
        design aspects

                     Surface


                     Sk...
The surface layer describes finished visual
        design aspects

                     Surface


                     Sk...
The skeleton describes screen layout
        and functional compartments in the screen


                     Surface


  ...
The skeleton describes screen layout
        and functional compartments in the screen


                     Surface


  ...
Structure defines navigation from
        place to place in the user interface

                     Surface

            ...
The “places” in the user interface
        are built to support user-task-centric scope
                                  ...
The “places” in the user interface
        are built to support user-task-centric scope
                                  ...
Business goals drive user constituencies choices
        and contexts supported to form strategy

                        ...
Garret’s Elements of UX stack can apply to the user
        experience of other complex products




© 2006-2007 Jeff Patt...
Garret’s Elements of UX stack can apply to the user
        experience of other complex products




             These la...
Let’s look at the strategy for a product we all use:
        the place we live

                                          ...
Let’s look at the strategy for a product we all use:
        the place we live

                                          ...
What might I, and my other user
        constituencies, do to reach our goals?
                                           ...
What might I, and my other user
        constituencies, do to reach our goals?
                                           ...
Arranging tasks by affinity allows me to
        think about contexts that best support tasks.
        Contexts in a home ...
Arranging tasks by affinity allows me to
        think about contexts that best support tasks.
        Contexts in a home ...
When designing a particular interaction
        context such as a “kitchen,” I optimize layout
        and tool choices to...
When designing a particular interaction
        context such as a “kitchen,” I optimize layout
        and tool choices to...
“I’m going to spend a lot of time here, I want my
        experience to be as pleasant as possible…”


                   ...
“I’m going to spend a lot of time here, I want my
        experience to be as pleasant as possible…”


                   ...
Underneath Garrett’s
 model is a simple 3
    layer model


                   18


                        18
Norman’s simple model for a human
        in pursuit of a goal




© 2006-2007 Jeff Patton, All rights reserved, www.agile...
Norman’s simple model for a human
        in pursuit of a goal




© 2006-2007 Jeff Patton, All rights reserved, www.agile...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Norman’s simple model for a human
        in pursuit of a goal

                                            problem or
   ...
Distilling this down to goals, tasks, and tools

                                            problem or
                  ...
Distilling this down to goals, tasks, and tools


                                              goal
                     ...
Distilling this down to goals, tasks, and tools


                                              goal

                    ...
Distilling this down to goals, tasks, and tools


                                              goal

                    ...
Software contains features that support a
        number of tasks and a number of goals


                                ...
Software contains features that support a
        number of tasks and a number of goals


                                ...
Software contains features that support a
        number of tasks and a number of goals


                                ...
When we think about
     quality of use
experience, we need to
re-think what we mean
       by quality.

                 ...
Don Norman explains that beauty, at least for
        products, isn’t skin deep

                                         ...
Norman explains three characteristics of design to
        observe: Visceral, Behavioral, & Reflective

                  ...
Norman explains three characteristics of design to
        observe: Visceral, Behavioral, & Reflective

                  ...
Noriaki Kano asks us to consider quality as being
        composed of objective and subjective elements




© 2006-2007 Je...
Noriaki Kano asks us to consider quality as being
        composed of objective and subjective elements

                 ...
Noriaki Kano asks us to consider quality as being
        composed of objective and subjective elements

                 ...
Noriaki Kano asks us to consider quality as being
        composed of objective and subjective elements

                 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters



...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
Kano explains three general classifications for product features:
        must-haves, one dimensionals, and delighters


 ...
When we include user
experience design into a
holistic design process,
   another model of
 problem analysis and
  solutio...
Design alternates between analyzing the problem
        context and exploring possible solutions




© 2006-2007 Jeff Patt...
Design alternates between analyzing the problem
        context and exploring possible solutions




                 time...
Design alternates between analyzing the problem
        context and exploring possible solutions


                       ...
Design alternates between analyzing the problem
        context and exploring possible solutions


                       ...
Design alternates between analyzing the problem
        context and exploring possible solutions


                       ...
Design alternates between analyzing the problem
        context and exploring possible solutions


                       ...
Design alternates between analyzing the problem
        context and exploring possible solutions

               user
    ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Design alternates between analyzing the problem
        context and exploring possible solutions
                         ...
Now let’s look at
   practices that a
customer or product
owner team users to
 move from problem
 analysis through to
  so...
Let’s look at a few of many possible
        product owner team practices




© 2006-2007 Jeff Patton, All rights reserved...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work




© 20...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Let’s look at a few of many possible
        product owner team practices

        Facilitated collaborative work

       ...
Collaborative centers around model
        building




© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesi...
Collaborative centers around model
        building




        [a model is] a description or analogy used to help visuali...
Collaborative centers around model
        building




        [a model is] a description or analogy used to help visuali...
Collaborative centers around model
        building




        [a model is] a description or analogy used to help visuali...
Collaborative centers around model
        building




        [a model is] a description or analogy used to help visuali...
Often when we verbally discuss ideas, we may
        incorrectly believe we have the same understanding




© 2006-2007 Je...
Representing our ideas as models allows us to
        detect inconsistencies in our understanding




© 2006-2007 Jeff Pat...
Through discussion and iterative model building we
        arrive at a stronger shared understanding




© 2006-2007 Jeff ...
Using that common understanding we can
        work together toward shared objectives




© 2006-2007 Jeff Patton, All rig...
Low fidelity card models are used to facilitate
        discussions and build common understanding




© 2006-2007 Jeff Pa...
Low fidelity card models are used to facilitate
        discussions and build common understanding
        Common model fo...
Low fidelity card models are used to facilitate
        discussions and build common understanding
        Common model fo...
Collaborative modeling looks like this




© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com   38
 ...
Collaborative modeling sessions follow a
        simple, repeatable structure




© 2006-2007 Jeff Patton, All rights rese...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Collaborative modeling sessions follow a
        simple, repeatable structure
     Use Collaborative Modeling Sessions to:...
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Agile Chennai Keynote by Jeff Patton
Upcoming SlideShare
Loading in...5
×

Agile Chennai Keynote by Jeff Patton

5,732

Published on

Blending User Experience & Business Analysis thinking in the Agile Customer Role presentation by Jeff Patton for Agile Chennai 2007 Conference http://agileindia.org/agilechennai07/index.htm

Published in: Business, Technology
1 Comment
22 Likes
Statistics
Notes
No Downloads
Views
Total Views
5,732
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
345
Comments
1
Likes
22
Embeds 0
No embeds

No notes for slide

Agile Chennai Keynote by Jeff Patton

  1. 1. Blending User Experience & Business Analysis thinking in the Agile Customer Role 1
  2. 2. Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton 1
  3. 3. Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org 1
  4. 4. Blending User Experience & Business Analysis thinking in the Agile Customer Role Jeff Patton ThoughtWorks jpatton@acm.org AgileProductDesign.com 1
  5. 5. PEOPLE Learn Skills in a 3-stage Progression: Follow / Break Away / Achieve Fluency Level 1:following (shu) Learn “a technique that works” (Success = following the technique) Level 2:breaking away ( ha ) Learn limits of the technique Learn to shift between techniques Level 3:fluent ( ri ) Shift techniques at any moment Possibly unable to describe the shifts We will use this progression throughout the course. ©Alistair Cockburn Slide 3 2005-6 2
  6. 6. Today I’ll cover 3 areas 1. What is user experience design? 2. Design & analysis practices useful for Agile customers 3. Incorporating design and analysis practices into an Agile lifecycle 3 3
  7. 7. By “Design” I mean the decisions we make regarding the software solution we choose to build. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4 4
  8. 8. By “Design” I mean the decisions we make regarding the software solution we choose to build. “The hardest single part of building a software system is deciding precisely what to build.” -- Fred Brooks In his 1987 essay “No Silver Bullet” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4 4
  9. 9. By “Design” I mean the decisions we make regarding the software solution we choose to build. “The hardest single part of building a software system is deciding precisely what to build.” -- Fred Brooks In his 1987 essay “No Silver Bullet” quot;A requirement is a relationship to a decision: If you get to make or change the decision, it's design to you; if you don't get to make or change that decision, it's a requirement to you.quot; -- Alistair Cockburn © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 4 4
  10. 10. Garrett’s Elements of User Experience Model describes a series of dependent decisions. 5 5
  11. 11. Software user experience is built from dependent layers © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 6 6
  12. 12. Software user experience is built from dependent layers Jesse James Garrett’s Elements of User Experience: http://www.jjg.net/elements/ © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 6 6
  13. 13. The surface layer describes finished visual design aspects Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 7 7
  14. 14. The surface layer describes finished visual design aspects Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 7 7
  15. 15. The skeleton describes screen layout and functional compartments in the screen Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 8 8
  16. 16. The skeleton describes screen layout and functional compartments in the screen Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 8 8
  17. 17. Structure defines navigation from place to place in the user interface Surface task panes Skeleton Structure modal dialogs Scope modal wizards Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 9 9
  18. 18. The “places” in the user interface are built to support user-task-centric scope user tasks: Surface • enter numbers • enter text • enter formulas • format cells Skeleton • sort information • filter information • aggregate information Structure • graph data • save data • import data • export data Scope • print • ….. Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 10 10
  19. 19. The “places” in the user interface are built to support user-task-centric scope user tasks: Surface • enter numbers • enter text • enter formulas • format cells Skeleton • sort information • filter information • aggregate information Structure • graph data • save data • import data • export data Scope • print • ….. Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 10 10
  20. 20. Business goals drive user constituencies choices and contexts supported to form strategy business goals: Surface • displace competitive products • motivate sale of other integrated products • establish file format as default Skeleton information sharing format • … user constituencies: Structure • accountant • business planner • housewife • … Scope usage contexts: • office desktop • laptop on airplane Strategy • pda in car • … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 11 11
  21. 21. Garret’s Elements of UX stack can apply to the user experience of other complex products © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 12 12
  22. 22. Garret’s Elements of UX stack can apply to the user experience of other complex products These layers of concern apply not only to software but a variety of products. In particular, products that support a wide variety of user tasks benefit from this kind of thinking. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 12 12
  23. 23. Let’s look at the strategy for a product we all use: the place we live goals: Surface • live comfortably • eat well • stay clean • be healthy Skeleton • keep up with Jones’s • … user constituencies: Structure • me • spouse • child • … Scope usage contexts: • suburban neighborhood • near good schools Strategy • near shopping • … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 13 13
  24. 24. Let’s look at the strategy for a product we all use: the place we live goals: Surface • live comfortably • eat well • stay clean • be healthy Skeleton • keep up with Jones’s • … user constituencies: Structure • me • spouse • child • … Scope usage contexts: • suburban neighborhood • near good schools Strategy • near shopping • … © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 13 13
  25. 25. What might I, and my other user constituencies, do to reach our goals? user tasks: Surface • store food • prepare food • eat food • sleep Skeleton • bathe • store changes of clothing • stay out of rain Structure • entertain guests • entertain self • … Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 14 14
  26. 26. What might I, and my other user constituencies, do to reach our goals? user tasks: Surface • store food • prepare food • eat food • sleep Skeleton • bathe • store changes of clothing • stay out of rain Structure • entertain guests • entertain self • … Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 14 14
  27. 27. Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15 15
  28. 28. Arranging tasks by affinity allows me to think about contexts that best support tasks. Contexts in a home have common names we all know. Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 15 15
  29. 29. When designing a particular interaction context such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 16 16
  30. 30. When designing a particular interaction context such as a “kitchen,” I optimize layout and tool choices to support tasks I’ll do there Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 16 16
  31. 31. “I’m going to spend a lot of time here, I want my experience to be as pleasant as possible…” Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17 17
  32. 32. “I’m going to spend a lot of time here, I want my experience to be as pleasant as possible…” Surface Skeleton Structure Scope Strategy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 17 17
  33. 33. Underneath Garrett’s model is a simple 3 layer model 18 18
  34. 34. Norman’s simple model for a human in pursuit of a goal © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  35. 35. Norman’s simple model for a human in pursuit of a goal © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  36. 36. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  37. 37. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  38. 38. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  39. 39. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  40. 40. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  41. 41. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  42. 42. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  43. 43. Norman’s simple model for a human in pursuit of a goal problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 19 19
  44. 44. Distilling this down to goals, tasks, and tools problem or goal How I’d like to feel, or what I’d like to achieve goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20
  45. 45. Distilling this down to goals, tasks, and tools goal goal evaluation is my goal met or problem resolved? take some action action evaluation did that action deliver that results I expected? the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20
  46. 46. Distilling this down to goals, tasks, and tools goal task the world information and tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20
  47. 47. Distilling this down to goals, tasks, and tools goal task tool © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 20 20
  48. 48. Software contains features that support a number of tasks and a number of goals goals tasks tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 21 21
  49. 49. Software contains features that support a number of tasks and a number of goals goals tasks software tools © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 21 21
  50. 50. Software contains features that support a number of tasks and a number of goals goals tasks software features © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 21 21
  51. 51. When we think about quality of use experience, we need to re-think what we mean by quality. 22 22
  52. 52. Don Norman explains that beauty, at least for products, isn’t skin deep “Attractive things make people feel good, which in turn makes them think more creatively…. making it easier for people to find solutions to the problems they encounter.” -- Don Norman © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 23 23
  53. 53. Norman explains three characteristics of design to observe: Visceral, Behavioral, & Reflective Visceral What is the products initial impact or appearance? Behavioral How does the object feel to use? Reflective What does the object make you think about? What does it say about it’s owner? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24 24
  54. 54. Norman explains three characteristics of design to observe: Visceral, Behavioral, & Reflective Visceral What is the products initial impact or appearance? Behavioral How does the object feel to use? Reflective What does the object make you think about? What does it say about it’s owner? © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 24 24
  55. 55. Noriaki Kano asks us to consider quality as being composed of objective and subjective elements © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25
  56. 56. Noriaki Kano asks us to consider quality as being composed of objective and subjective elements “Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25
  57. 57. Noriaki Kano asks us to consider quality as being composed of objective and subjective elements “Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objective- subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25
  58. 58. Noriaki Kano asks us to consider quality as being composed of objective and subjective elements “Discussions of quality have revolved around the two aspects of subjectivity and objectivity since the time of Aristotle. Embedded in this objective- subjective split is the idea that objective quality pertains to the ‘conformance to requirements’ while subjective quality pertains to the ‘satisfaction of users.’” --Noriaki Kano © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 25 25
  59. 59. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  60. 60. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  61. 61. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  62. 62. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy One dimensionals © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  63. 63. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy One dimensionals The more of this I get, the better © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  64. 64. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy One dimensionals The more of this I get, the better Delighters © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  65. 65. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy One dimensionals The more of this I get, the better Delighters I love this element of the product! © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  66. 66. Kano explains three general classifications for product features: must-haves, one dimensionals, and delighters Must-haves The products must have this features for me to be happy One dimensionals The more of this I get, the better “This car has many flaws. Buy it Delighters anyway. It’s so much fun to drive” -- from a NY Times review of the Mini I love this element of the Cooper product! © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 26 26
  67. 67. When we include user experience design into a holistic design process, another model of problem analysis and solution definition becomes useful 27 27
  68. 68. Design alternates between analyzing the problem context and exploring possible solutions © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  69. 69. Design alternates between analyzing the problem context and exploring possible solutions time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  70. 70. Design alternates between analyzing the problem context and exploring possible solutions sis aly an l em ob pr time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  71. 71. Design alternates between analyzing the problem context and exploring possible solutions sis aly an ti on l em fi ni ob de pr on ti o lu s time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  72. 72. Design alternates between analyzing the problem context and exploring possible solutions sis aly an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  73. 73. Design alternates between analyzing the problem context and exploring possible solutions sis user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  74. 74. Design alternates between analyzing the problem context and exploring possible solutions user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  75. 75. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  76. 76. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr on ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  77. 77. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em fi ni ob de pr user scenario on writing ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  78. 78. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s & goals analysis task design (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  79. 79. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  80. 80. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly research an ti on l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  81. 81. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  82. 82. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  83. 83. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  84. 84. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 28 28
  85. 85. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  86. 86. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  87. 87. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  88. 88. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  89. 89. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  90. 90. Design alternates between analyzing the problem context and exploring possible solutions task analysis (how do users achieve goals today?) user sis modeling user aly an on research user story writing ti l em user interface fi ni ob design de pr user scenario on writing ti o lu business problems s Incremental & goals analysis task design release planning (how might users better reach goals?) time  Often, design starts with a candidate solution in mind.  Exploring the problem helps validate the solution.  As time passes, problem analysis activities are replaced by solution definition activities. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 29 29
  91. 91. Now let’s look at practices that a customer or product owner team users to move from problem analysis through to solution definition 30 30
  92. 92. Let’s look at a few of many possible product owner team practices © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  93. 93. Let’s look at a few of many possible product owner team practices Facilitated collaborative work © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  94. 94. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  95. 95. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  96. 96. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  97. 97. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  98. 98. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  99. 99. Let’s look at a few of many possible product owner team practices Facilitated collaborative work Modeling business objectives Modeling Users Modeling workflow as user stories: User Story Mapping Paper prototyping and usability testing Planning & road-mapping © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 31 31
  100. 100. Collaborative centers around model building © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32
  101. 101. Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32
  102. 102. Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32
  103. 103. Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication For our purposes:  a model is any visual representation of our current understanding of a concept © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32
  104. 104. Collaborative centers around model building [a model is] a description or analogy used to help visualize something (as an atom) that cannot be directly observed - Merriam-Webster on-line A goal of a model isn’t completeness or accuracy, but communication For our purposes:  a model is any visual representation of our current understanding of a concept We’ll build models to understand our problem context, and explore solutions © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 32 32
  105. 105. Often when we verbally discuss ideas, we may incorrectly believe we have the same understanding © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 33 33
  106. 106. Representing our ideas as models allows us to detect inconsistencies in our understanding © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 34 34
  107. 107. Through discussion and iterative model building we arrive at a stronger shared understanding © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 35 35
  108. 108. Using that common understanding we can work together toward shared objectives © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 36 36
  109. 109. Low fidelity card models are used to facilitate discussions and build common understanding © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37 37
  110. 110. Low fidelity card models are used to facilitate discussions and build common understanding Common model forms include:  Affinity diagrams  Chronological models  Decompositions  Ad hoc charts © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37 37
  111. 111. Low fidelity card models are used to facilitate discussions and build common understanding Common model forms include:  Affinity diagrams  Chronological models  Decompositions  Ad hoc charts Mix and match as you see fit © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 37 37
  112. 112. Collaborative modeling looks like this © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 38 38
  113. 113. Collaborative modeling sessions follow a simple, repeatable structure © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 39 39
  114. 114. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team  Help the team to gel as an affective workgroup © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 39 39
  115. 115. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator  Documenter  Schedule & set up work session facility © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 39 39
  116. 116. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39
  117. 117. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39
  118. 118. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate  Capture model with photo and/or movie Perform  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39
  119. 119. Collaborative modeling sessions follow a simple, repeatable structure Use Collaborative Modeling Sessions to:  Build up tacit shared knowledge within the team  Build communication and collaboration skills within the team 1  Help the team to gel as an affective workgroup Prepare  Write a short statement to set goals and scope for the session  Identify participants – 4-8 is ideal  Fill These Roles:  Information Suppliers  Information Acquirers  Information Modelers  Facilitator 2  Documenter  Schedule & set up work session facility Document & Communicate  Capture model with photo and/or movie Perform  Document as necessary  Kickoff with goals and scope  Get information figuratively and literally on the table using brainstorming or discussion  Model the information to clarify, add details, distill details, and understand relationships  Close by summarizing the results, on camera if © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com possible 39 39
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×