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

Re: [agile-usability] Re: Today's article on UseIt.com

Expand Messages
  • George Dinwiddie
    ... OK, I m just catching up with this thread. I just got around to reading http://www.useit.com/alertbox/agile-methods.html and the statement For a project
    Message 1 of 76 , Nov 28, 2008
    • 0 Attachment
      aacockburn wrote:
      > I thought Nielsen's article was notable enough to comment on point
      > by point. Not much to disagree with, but I hope a few things of
      > note for both programmers and UX/UI specialists.
      > http://alistair.cockburn.us/Nielsen+on+agile+and+usability

      OK, I'm just catching up with this thread. I just got around to reading
      http://www.useit.com/alertbox/agile-methods.html and the statement "For
      a project to take interaction design and usability seriously, it must
      assign them 'story points' (i.e., resources) on an equal footing with
      the coding" jumped out at me. I see that Alistair has also touched on
      this. I like Alistair's response, but I'd like to approach this from a
      different direction.

      First of all, story points do not represent resources applied. They're
      an estimate of the work required to accomplish a small but measurable
      increment of functionality. This work has never been just "coding." At
      the very least it includes testing and acceptance by the Customer. If
      the functionality includes a change to the UI, then figuring out what
      that UI change should be is also part of it.

      Many shops don't have UI experts, so figuring out that UI change falls
      to the developer and the Customer having a discussion and making a
      decision. Yes, this sometimes results in a terrible UI from a usability
      point of view. The good news is that, if you're working in small
      increments in an iterative fashion, you can always revisit this and
      change it. If it's bad enough, this usually happens.

      When there is a UX/UI designer, their work is too-often treated as an
      up-front requirements definition phase, handed to the development
      process as a /fait accompli/ to be developed without any further
      discussion. The problem with this is not that it's not "Agile," it's
      that it sabotages the benefits that people seek when they adopt Agile.
      The Customer might have made some subtle adjustments to the
      functionality of the story, and the pre-designed UI might no longer be
      so appropriate. The precisely-defined UI might be really expensive to
      develop, and a much cheaper approach might be approximately as good.
      And, if the story is never scheduled for development, this up-front
      design is completely wasted.

      It appears to me that the only way to get the Agile benefits of
      balancing needs and costs to get the best bang for the buck, is to move
      this UX/UI design work into the incremental, iterative development
      cycle. That doesn't mean to create a separate story card for UI design,
      and then another for implementation. The completion of the story
      includes the UI design, the implementation, the testing, and the
      acceptance by the Customer.

      "But," some designers protest, "we need to do usability testing with
      mockups to know which is the best design." Well, perhaps. On the one
      hand, with enough experience you might be able to design a "good enough"
      UI without this step, particularly if you know it can be changed in the
      future. Doing the usability testing with live code, rather than a
      mockup, might provide better feedback because it tests the concept
      as-implemented, rather than as-conceived.

      Sometimes, of course, we just won't know enough to jump right to code.
      This happens with coders, too, and we have a tool to deal with this
      situation. That tool is a "spike." This is a time-boxed exploration to
      learn what we know we don't know. For a coder, it may be coding up an
      alternative implementation to see if it will work, or if it will provide
      advantages. For a UI/UX designer, it may be creating and testing a
      low-fidelity prototype. It's time-boxed because it's not directly
      producing value--it's producing knowledge that we must then leverage to
      produce value. Our goal is to answer some questions, not produce the
      best possible prototype.

      Hmmm... This is getting a bit long for an email. I'll finish it on my
      blog: http://blog.gdinwiddie.com/2008/11/28/agile-usability/

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • Desilets, Alain
      ... that ... one ... http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivit y- ...
      Message 76 of 76 , Jan 9, 2009
      • 0 Attachment
        > > There are other studies (I don't have the exact quote) that show
        > > the difference between a top-notch developer and a run-of-the-mill
        > > is a factor of 10 or so.
        > The back up for that is here :-

        Thx James. I always assumed that this was indeed supported by actual
        studies, but still had a small nagging doubt that it might be one of
        those urban legends that start with "studies show that ...." ;-). This
        is a good reference which eliminates that doubt.

      Your message has been successfully submitted and would be delivered to recipients shortly.