how would design practice change if we focused on frequent release?
- 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:
(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.
- Belated response (gosh darn that "work" stuff)
On 20 Nov 2006, at 23:20, Jeff Patton wrote
> One of the concerns about agile development is that the user[snip]
> experience might change too often, and that users hate that. I'd
> submit users had bad changes, and don't mind good changes.
Of course this then leads to a tedious discussion to define what
"good" means :-)
> (yes I finally have a blog)[snip]
++ for full text posts
-- for no comments :)
> My big assertion here is that designers in the web product world have[snip]
> 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
Were you thinking of <http://www.peterme.com/archives/00000011.html>
> So, the real question is: what user experience design tactics allowOff the top of my head:
> you to release more frequently? If you have tactics that have worked
> for your organization, please share on or off line if you can.
* 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