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

how would design practice change if we focused on frequent release?

Expand Messages
  • Jeff Patton
    All: I wanted to get from this group some tactical ideas on changing the user interaction of software more frequently. Let me see if I can say concisely what
    Message 1 of 2 , Nov 20, 2006
    • 0 Attachment
      All: I wanted to get from this group some tactical ideas on changing
      the user interaction of software more frequently. Let me see if I can
      say concisely what I mean.

      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. If you've
      been reading this list on line for a couple years, you'll notice the
      user experience has changed quite a bit over the past few years - but
      not allways all at once in a big version change. Most often there are
      little unanounced changes that [hopefully] improve things.

      I blogged about this here:
      http://www.agileproductdesign.com/blog/consider_changing_your_products_ui_more_frequently.html
      (yes I finally have a blog) I don't want to promote the blog so much
      as to draw your attention to that entry and what I had to say about
      lean manufacturing's continuous flow idea.

      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. If there's an ebay person listening in please contradict or
      correct this statement. But, if the statement is true, that
      represents a possible tactic for releasing change more frequently, and
      coping with big changes in particular.

      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.

      thanks,

      -Jeff
    • 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 2 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.