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

Re: [agile-usability] how would design practice change if we focused on frequent release?

Expand Messages
  • Adrian Howard
    Belated response (gosh darn that work stuff) On 20 Nov 2006, at 23:20, Jeff Patton wrote [snip] ... [snip] Of course this then leads to a tedious discussion
    Message 1 of 2 , Nov 25, 2006
    • 0 Attachment
      Belated response (gosh darn that "work" stuff)

      On 20 Nov 2006, at 23:20, Jeff Patton wrote
      [snip]
      > One of the concerns about agile development is that the user
      > experience might change too often, and that users hate that. I'd
      > submit users had bad changes, and don't mind good changes.
      [snip]

      Of course this then leads to a tedious discussion to define what
      "good" means :-)

      [snip]
      > (yes I finally have a blog)
      [snip]

      Subscribed!
      ++ for full text posts
      -- for no comments :)

      [snip]
      > My big assertion here is that designers in the web product world have
      > figured out some tricks that allow them to release change more
      > frequently. I'd hard a story a while back that when eBay has big
      > changes to make, that they'll actually break that big change up into
      > lots of little changes they can make, and release, incrementally over
      > time.
      [snip]

      Were you thinking of <http://www.peterme.com/archives/00000011.html>
      perchance?

      [snip]
      > So, the real question is: what user experience design tactics allow
      > you to release more frequently? If you have tactics that have worked
      > for your organization, please share on or off line if you can.

      Off the top of my head:

      * Not trying to design all of the user experience up front. Just
      developing enough to get the next feature out well - trusting that
      your development team is producing software flexible enough to
      improve quickly over time. Produced the best possible UI for the
      application that exists now, not the application that will exist in
      six months time.

      * Keeping all the non-code artifacts as low-fi and short term as
      possible and still get the job done. I don't want to have to update
      40 hi-fi viseo wireframes for approval every time I tweak the UI.

      * Democratising the user experience work as much as possible so that
      we don't have individuals acting as constraints (which harks back to
      your lean post quite nicely)

      * Automating as much of the UI related testing as possible.

      * Reflecting the user-experience design decisions in the code design,
      rather than just being a hand tweaked layer of paint on top. This
      makes global changes far more reliable.

      * Bringing the production of things like training manuals in-house so
      they can be kept in sync with the software more easily. I often see
      objections to gradual change one-removed from the end-users. It's not
      the people using System X, but the people employing the people who
      use System X. Things like the training manual they produced getting
      out of date, etc. is annoying.

      * Having the user-interface be independent of the release. So you can
      present the v1.0 interface to existing users even when they're on
      v1.5, while giving the new improved UI to your new users. The
      existing users can then upgrade at their own pace. (However I'm
      unsure of whether the added code complexity makes this a bad thing in
      the long term).

      * Logging what the users do (I love web apps!) so you get feedback
      all of the time so you can quickly see if something is helping or
      hindering.

      Any more?

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