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

1835Re: just one bug's enough to make a program useless

Expand Messages
  • Jeff Patton
    Jan 3, 2006
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "Desilets, Alain"
      <alain.desilets@n...> wrote:
      > How can we usabilitists catch these blind spots in design, before they
      > lose us customers?
      > -- Alain:
      > Sorry for late response... Catching up on pre-Xmas break email.
      > By their nature, bugs cannot be caught by design. They can only be
      > caught after the buggy implementation has been implemented. This is
      > of the great advantage of early delivery and TDD....
      > ----

      Looking up to Phlip's original post, I was seeing the bug reported as
      not supporting multiple levels of undo. Then we found there was a
      history panel - an alternatively named feature that accomplished
      similar results to undo. It appears all these features performed as
      the publisher expected - so none of these were bugs. Practices like
      TDD don't catch things like this.

      There's a couple things going on here that caught my eye/brain:

      I like that Phlip referred to this as a blind spot in _design_. One of
      my pet peeves is the use of the word design to refer almost strictly to
      the technical junk under the UI. In this case the word design refers
      to the decision to include or exclude a feature. This is the sort
      of /design/ work that's aften called "requirements" work in many

      Others already gave answers to the "how do you catch these blind
      spots?" question. Test. But test doesn't refer to anything automated,
      or something a tester does to make sure a feature works as designed,
      but rather observe users actually trying to do the stuff they want to
      do with the application.

      So, recapping, the two things that popped for me:
      * design is something that occurrs before code is written as part of a
      process to choose features. [That's no news for the UCD community,
      possible big news to requirements engineers.]
      * a process or methodology that's concerned with the usability of it's
      product should include some form of usability testing - that is
      observation of target users using the product to accomplish real work -
      not bug detection.

      So, if there's an agile approach that's usability friendly, it's gunna
      have these sorts of concepts stitched in.


    • Show all 23 messages in this topic