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

RE: [agile-usability] Re: plugging the big picture hole

Expand Messages
  • Hugh Beyer
    ... From: William Pietri [mailto:william@scissor.com] ... Well, I think it s an intrinsically difficult problem, no matter what representations you use,
    Message 1 of 81 , Aug 27, 2004
    • 0 Attachment
      -----Original Message-----
      From: William Pietri [mailto:william@...]

      > On another point, I think your example illustrates the difficulty with
      > keeping the "whole product" concept coherent when your only
      > representation is story cards and UIs. If you don't have a physical
      > artifact to check, it's easy to overlook connections across the parts.

      Well, I think it's an intrinsically difficult problem, no matter what
      representations you use, especially given that any single representation
      necessarily discards a great deal of information.  
      Absolutely, and you're giving us a success case here... I'm not saying we could have done better, only playing with the issues.
      Personally, I like
      something as obviously inadequate as the cards. With a 200-page spec,
      people often yield responsibility to the spec. With a stack of index
      cards, it's clear who has the answers: the team.

      But perhaps I'm using the wrong representations. Let me give you the
      full details and you can suggest a representation that would have found
      the problem sooner and at a lower cost.

      The feature in question was a very simple content management system that
      controlled the pages of static content on our site. E.g., who we are,
      what we do, the FAQ, our terms and conditions, and so on. It was
      scheduled not for the upcoming release, but the one after that.

      While we were implementing one of the stories related to payment, a
      programmer noticed that we needed more explanatory text on one of the
      UIs to convey the full terms. But it was really more text than would
      fit, and the best thing to do was to give a short message to satisfy
      most users, and link to the terms and conditions for the few that wanted
      the details.

      The static content story, though, was scheduled in the following
      release. So we, as a group, spent perhaps ten minutes talking over
      alternatives. Eventually, we split the story in two, putting the
      necessary part of it in this release and the fancier features in the
      Total cost of this change was perhaps one person-hour of discussion, and
      perhaps two minutes updating our artifact. The HTML mockups were
      ignored; they're only kept fresh when the designer is thinking hard
      about the future or when they're the best way to communicate the details
      of a feature we're building that week.

      What representation would have you used to detect this scheduling error
      sooner, and at lower cost?
      Our approach to this is through what we call a software floorplan or User Environment design. It shows all user-visible features and how they are arranged into coherent screens/windows/pages. When we're planning releases (haven't used this in an agile project) we do cuts across the floor plan and run a discussion of whether the cuts are coherent--each delivers complete, useful function and can be delivered independently. So in theory, running such a process would have identified the problem.
      In practice, such a discussion takes a good deal more than an hour. Besides, this was an additional need discovered during implementation--we might have found it up front, but might not.
      What I'm wondering about is whether maintaining such a "floorplan" could be useful for keeping design coherence on the user experience side. So in your case, you would have walked to the floorplan on the wall, which might have been marked in colors to show what was being delivered in this release and the next. You'd make your decision, and draw a box to represent your detailed terms box, in the color for this release. If any other user-visible features were affected by moving the static content work into this release, you'd change the color on those. Then you'd split the story and be done. 
      Benefit is that the next person who's looking at what's happening in this release--maybe another team member discovers another change that depends on some static content work--only has to go glance at the plan to see what you've done.
      Does that seem potentially useful?
    • Cecilia Haskins
      ... one ... having ... company, ... this jives with my experience as well -- cheers, Cecilia
      Message 81 of 81 , Aug 31, 2004
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "Ron Vutpakdi"
        <vutpakdi@a...> wrote:

        > On the other hand, the core problem wasn't one of which development
        > process was used during the implementation. The core problem was
        > of poor management. I still believe that the toughest part of
        > a successful project isn't the design (internal or interaction), it
        > isn't the development, and it isn't the testing: it's the human
        > element of working with each other, management, others in the
        > customers, and users.
        > Ron

        this jives with my experience as well -- cheers, Cecilia
      Your message has been successfully submitted and would be delivered to recipients shortly.