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

top down, or bottom up?

Expand Messages
  • Jeff Patton
    Hi group - we ve been silent for a while, but having talked to a few of you personally, I know you re still out there. A design/requirements specific thing has
    Message 1 of 36 , Apr 22, 2005
      Hi group - we've been silent for a while, but having talked to a few of
      you personally, I know you're still out there.

      A design/requirements specific thing has been bouncing around my head for
      the last couple weeks. Let me see if I can tell a story, then eventually
      arrive at a question for this group:

      The first approach I learned to user centered design [and still my most
      leveraged] was Constantine and Lockwood's Usage Centered Design. One
      important element in U-CD is the User Task, or Essential Use Case.
      Basically it's a use case with a form and some constraints around it that
      make it more useful for UI design. That's not the interesting bit - the
      interesting bit was how we came up with these in the class I took from
      Larry and Lucy, and how I've subsequently done it in practice for the last
      several years.

      *We used a brainstorming technique to come up with as many user tasks as

      These tasks tend to be a mixture of fine grain tasks like "look up a
      customer" or "discount an item" - mixed with course grain tasks like "ring
      up a sale." - but mostly fine grained tasks. I do this collaboratively
      with users and business experts - and I don't ask them for fine grained
      tasks - that's just what comes out when they brainstorm. We then do some
      affinity clustering and other workflow models with the task names to model
      user workflow and software structure.

      I taught this in a tutorial to another UCD professional who used more of a
      goal decomposition approach - get top level goals then decompose those to
      smaller goals, then finally to smaller process steps. He felt pretty
      twitchy about my approach that didn't start with top level goals in mind
      and decomposing - but rather built up from the bottom. [I tend to capture
      user goals as part of user role modeling and let task goals emerge from
      task modeling - so actually I kind of meet the goals in the middle.]

      The story picks up when I had the pleasure or working with Alistair
      Cockburn, who as some would expect, is thee master of use cases. He
      writes use cases using a top down approach as well. I really like the way
      he expresses use case goal level using at an altitude metaphor: cloud
      level, kite level, sea level, fish level, clam level - where sea level
      goals are things a user might sit down and do in a singe sitting generally
      without interruption - like "ring up a sale at POS." I think you get the
      picture. He felt twitchy about me gathering all my detailed tasks - like
      fish level use cases then building up to sea level, kite level, etc..

      Finally the last chapter if the story happened with taking Holtzblatt &
      Wood tutorial on Contxtual Design. Karen placed an emphasis on gathering
      real details from contextual interviews then using affinity diagramming to
      let the bigger ideas/concepts emerge. She really leaned on this approach
      being bottom up rather than top down. While in this tutorial I recalled
      being in Cooper's tutorials and seeing them focus on compiling interview
      data with similar ideals in mind - directed at persona creation of course.

      Now workflow and interview data aren't exactly the same thing... but I
      feel the concepts are similar. I feel like I'm more likely to catch
      little things if I model from the bottom up rather than from the top down.
      No one usually forgets the big things - but people often overlook
      critical little details. I worry that a top down approach is more likely
      to over-emphasize the big things - or how the process /should/ go vs. how
      the process /really/ goes.

      To some degree the agile approach of story writing is also bottom up -
      lots of little things knit together to form a big picture. Although, my
      general criticisms of some agile practitioners are that they fail to
      assemble any big picture from details till too late... you really do need

      So, let me see if I can ask a question here: For those of you praciticing
      some UCD approach think about the techniques and thought processes you
      lean on. Are they mostly top down, or bottom up? Do you see an advantage
      to thinking mostly one way or another? [Understanding of course that it's
      never all or nothing - we all do a bit of both I suspect - except for
      Alistair ... ;-) ] Finally, am I way out in left field for thinking about

      thanks - and wake up group! What's been going on out there?


      Jeff Patton
      (801) 910-7908

      XP 2005 (Sheffield, UK) Agile User Experience Tutorial: http://www.xp2005.org

      UPA Agile-UCD Tutorial:

      UPA Agile-Usability Workshop:

      Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
      Tutorial: http://www.agile2005.org/

      "There is nothing that saps one's confidence as the knowing how to do a

      --Mark Twain
    • Glen B Alleman
      Alistair, Crystal has a variety of options. Others are narrower. Few are as broadly based as your approach. I m more focused on specific development method
      Message 36 of 36 , May 8, 2005

        Crystal has a variety of options. Others are narrower. Few are as broadly
        based as your approach. I'm more focused on specific development method that
        move outside their "sweet spot" leaking into other areas - off the sweet
        spot. I see this not as an issue of the method but it's application. Mis
        applied CMMI, mis applied XP, mis applied TOC.


        -----Original Message-----
        From: agile-usability@yahoogroups.com
        [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        Sent: Sunday, May 08, 2005 10:46 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] Re: elite methods

        I'm sure you mean "almost" everyone, Glen --- I've been researching
        and publishing on the topic of selecting methods for over a decade
        now, have a PhD, three books, a dozen articles and most of a website
        on the question of selecting a process. I'm not alone: that aspect of
        my PhD wasn't considered novel at all but rather as fully established
        in the research community; Capers Jones talks about it in his
        benchmarking book; RUP and the UP are all about that; Boehm has a
        book and articles about it, there are others.

        By this late date, the notion of a single methodology as a silver
        bullet is severely outmoded.


        --- In agile-usability@yahoogroups.com, "Glen B Alleman"
        <glen.alleman@n...> wrote:
        > Jon,
        > The problem of deciding how to apply a processes to a problem
        domain is
        > nearly universal. Ranging from heavy to light. I've experienced
        > applied CMMI to poorly applied XP and everything in between. No
        one seem to
        > want to approach the "improvement" process from an external point -
        as you
        > suggest - selecting the right process for the problem. I'm
        searching though
        > for the solution - none found so far. Everyone's got a silver
        bullet looking
        > for the werewolf to shoot ;>)
        > Glen B. Alleman
        > <http://www.niwotridge.com> www.niwotridge.com
        > www.niwotridge.com/Blog
        > _____
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 6:36 PM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        > i don't think there is any indication that anyone meant that all
        > processes are to hide incompetence.
        > however, i submit there are at least a few reasons for introducing
        > - because someone has a good set of steps worth repeating (good
        teams do
        > this automatically)
        > - because someone wants to ensure a set of steps are done and
        may not
        > trust the doer at knowing what to do (bureaucracies are good at
        doing this)
        > i hope i left wiggle room in my original post for applying the
        right process
        > for the right reasons. my flippant remarks are intended to jolt
        people into
        > thinking if they are applying the right level of process. a
        > process (such as might be applied in your NQA-1 example) applied to
        > mediocre business app is probably not an effective use of resources.
        > also, i have seen people conduct process steps "just because" --
        > because they cannot think for themselves, or that they are dis-
        incented to
        > not follow process, or they are naive, or they do not care if they
        > wasting resources (money and time).
        > but, for a mission critical app, i hope the right process is
        followed... as
        > it is in almost every "hard" engineering discipline i ever worked
        > -- jon
        > Glen B Alleman said the following on 5/6/2005 8:54 AM:
        > Jon,
        > Mission critical can be applied outside man rated as NASA uses that
        > Mission critical can be applied to a brad variety of system from
        > control, to supply chain management. Pacemakers are 21CFR,
        petrochem is OSHA
        > 1910.119, rod control for a reactor is NQA-1, the ground mission
        > and dispatch for air defense has another framework.
        > The comment (now seen a flippant) that poor developers hide behind
        > ceremony struck me a uninformed about those working in the high
        > development envirnemnt that also use agile methods. Thy are not
        > exclusive
        > Glen
        > _____
        > From: <mailto:agile-usability@yahoogroups.com>
        > agile-usability@yahoogroups.com [mailto:agile-
        usability@yahoogroups.com] On
        > Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 5:17 AM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        > please define mission-critical...
        > man-rated, mission critical systems are a different story.
        > always attach the right level of rigor and process as needed...
        > software for an embedded pacemaker is different than making an
        > mortgage loan application system.
        > -- jon
        > Glen B Alleman said the following on 5/5/2005 11:40 AM:
        > As one who leads CMMI IPPD development this is likely not true in
        > practice...but simply conjecture on the part of those not
        practicing heavy
        > processes in a mission critical environment.
        > Glen B Alleman
        > -----Original Message-----
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        > Sent: Thursday, May 05, 2005 9:35 AM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] Re: elite methods
        > At least, they will defend them because it's easier to hid :-)
        > --- In agile-usability@yahoogroups.com, "Cummins, Darin"
        > <mailto:Darin_Cummins@a...> <Darin_Cummins@a...> wrote:
        > > If you twist this one more time, does that imply that incompetent
        > > developers choose heavy processes because it's easier to hide? ;-)
        > >
        > _____
        > Yahoo! Groups Links
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/agile-usability/
        > * To unsubscribe from this group, send an email to:
        > agile-usability-unsubscribe@yahoogroups.com
        > <mailto:agile-usability-unsubscribe@yahoogroups.com?
        > * Your use of Yahoo! Groups is subject to the Yahoo!
        > <http://docs.yahoo.com/info/terms/> Terms of Service.

        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.