Loading ...
Sorry, an error occurred while loading the content.

1161RE: [agile-usability] zooming, porpoising, and goal level

Expand Messages
  • Rob Keefer
    May 3, 2005
      I'd like to take Hugh's analogy to the painter a step further. 'Master' painters will work out the intricate details of a painting in a sketchbook. (XPers call this a spike solution.) Once they have figured out the detail, it is then applied to the main composition.
       
      I wonder if this is what is going on when we look at the clam level. Working out details with particular users helps find solutions to particular problems that can then be placed in a larger context.
       

      Hugh Beyer <beyer@...> wrote:

      Jeff Patton: "This idea of goal level, or abstraction level, and the comparison of goals
      at a high level to the smaller goals at another level seems pretty critical
      to what we're doing.  The idea that upper level goals are validated against
      real world observation of the activities people are doing and the context
      they do them also seems critical [ . . . ] I'm not very well read, but in the
      few books I have read, and the few people I have worked with, I don't recall
      anyone drawing attention to this concept as critical.  Is it too obvious, or
      did I overlook the message when I heard it?�

       

      It�s an important distinction, and I�d be surprised if it didn�t show up in some form or other. We talk about developing a design the way a painter develops an oil painting�rather than working on the hand in detail, then an eye, then the other hand, then an ear, the painter sketches in the whole painting in rough�gets all the parts in right relationship to each other�then goes in and fills in the detail. In our process, this is the role of visioning�to sketch the overall high-level vision (kite to giraffe level, depending on the project) which can then be refined in detail.

       

      Alistair Cockburn: �The opposite statement of the above is that with good facilitation, and

      if the requirements gathering people are alert, there are lots of clues

      spoken out loud in every meeting that tell you what's going on at the

      clam level --- Mind, I recognize that this is doing the clam-up work

      real-time within the group discussion and while driving home, but still

      I claim the information is on the table.�

       

      So just to clarify what the points of disagreement are, you are agreeing that the analysis has to be clam-up, just disagreeing on what technique is necessary for doing that analysis? I�d argue in fact that any user-centered design process must be clam-up or it�s not UCD. After all, if you�re not starting with individual users� work, you�re not starting with users, you�re starting with some abstraction.

       

    • Show all 23 messages in this topic