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
> 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)
++ for full text posts
-- for no comments :)
> 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
Were you thinking of <http://www.peterme.com/archives/00000011.html
> 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