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

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

Expand Messages
  • Hugh Beyer
    May 3 12:14 PM
    • 0 Attachment

      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.

       

      Alistair Cockburn: “Perhaps you can post a couple of the most interesting surprises you've
      uncovered in the clam-up analyses you've run?  Of course, what Jeff
      and I discovered is that lots of things look obvious after they've been
      named. Our analysis should cover exactly what bits of discussion
      amongst the analysts triggered the discovery of those items.”

       

      You ask a fair question… on the one hand every project reveals such surprises, on the other most of it belongs to our clients. Others have offered good answers to this, but here’s two quick examples off the top of my head.

       

      On practically the first project we worked on as a business, the user population consisted of system managers, who uniformly reported that 60-70% of their work was focused on diagnosis and troubleshooting of failing systems. CI field interviews revealed that maybe 10-20% of their work was diagnosis and troubleshooting. Most of their time was spent on routine maintenance tasks. We’ve found this is typical—users can’t tell you how they allot their time really—they put too much emphasis on what is the “real” job, the interesting, valuable, knowledge work, and overlook the time spent on “unimportant” parts of the job.

       

      On another project, we were studying chip fabrication. We were told how rigid all their requirements were for handling the wafers and how carefully they were followed. But when we observed, we saw people doing something called “roll transfers”—tossing a stack of wafers from one carrier to another without using the machine that was especially designed for the purpose—in violation of procedure. We might, with good facilitation have discovered that people break the rules this way. We would not, I think, have understood why people risk their jobs (or at least their performance appraisals) to do this kind of transfer when they don’t have to.

       

      Alistair Cockburn: “In fact it's pretty much a tautology that weak practitioners produce

      weak outcomes, regardless of the process; and any successful project

      builds its success on the competent and experienced people present.

      There is no distinction available here for agile / waterfall / UCD /

      bottom-up / top-down etc.”

       

      Very true, but it’s possible to take the argument too far. A sawmill, table saw, and jigsaw can all injure you but they vary greatly in the amount of damage they’re likely to do and the speed at which they’ll do it.

       

      I’m currently working with a client who spent two months traveling around the world spending days with over 80 users. I guarantee you that even an untrained designer or even (horror of horrors) developer would, after such an experience, design a much more suitable system than one who had only conducted focus groups. In the same way a rapid-iteration agile process will make it much harder to develop the wrong system without knowing it.

       

                  Hugh

       

      Hugh R. Beyer, CTO
      InContext
      Ph: 603 966-7188
      Email: beyer@...

       

    • Show all 23 messages in this topic