User Centered Design and Agile Development: The Digest
ray at media.berkeley.edu
Wed Oct 24 18:58:15 UTC 2007
At 11:24 AM 10/24/2007, Mara Hancock wrote:
>Ray, not sure what you mean about hiwire jumping (Unicycle and all).
>Can you make it more concrete? Are you simply saying that working in
>this model requires the ability to focus on a single project at a time?
What, that wasn't clear? :) What I meant was that in our current
circumstances we _can't_ seem to come up with a way to focus on a
single project at a time.
We're all pretty much in agreement that a tightly focused project
team with frequent milestones is usually the best way to deliver
functionality to users.
But we also all recognize that the existing _contexts_ of the
projects we're involved with require tending (or massive
re-landscaping). There are basic UX issues in Sakai that can't be
dealt with purely by delivering a new screen's worth of
functionality, just as there are basic scalability and
maintainability issues in Sakai that can't be dealt with purely by
fixing a bug.
Because we don't have enough skilled people to fully dedicate to all
these areas, and because the areas overlap, we have to jump back and
forth between "principles" and "frameworks" and "projects" more often
than is typically the case in software development. So, like I say, a
high-wire act. (I just had two new wires added to mine this morning. :) )
>On Oct 24, 2007, at 9:21 AM, Ray Davis wrote:
>>At 07:44 PM 10/23/2007, Daphne Ogle wrote:
>>>Great summary Ray!
>>>I've heard her present this and similar content a few times
>>>now. She was one of the presenters at the all day UX in agile
>>>environment SIG I attended a few months back. There were over a
>>>dozen organizations represented. Even Google and Yahoo have small
>>>groups trying to work in agile ways. Autodesk, where Lynn is from,
>>>is very happy with their process. An important note is that they
>>>are working on an existing system so incremental improvements work
>>>well -- they already have their high level design framework in place.
>>Yep, that leapt out at me, too. Ideally, a framework (UI,
>>authorization services, DB architecture) should be able to evolve
>>gradually over many releases. Un-ideally, most of us on this list are
>>faced not only with legacy systems but with legacy _promises_, which
>>throws a spanner in the works. (Or, given the relative sizes of agile
>>iterations and legacy frameworks, throws a factory on top of the
>>>The biggest challenge / complaint from the group (mostly UX folks)
>>>was the lack of time for creating a comprehensive UI framework. I
>>>think this is much more relevant to new products. The discussion
>>>and work we did at the SIG meeting acknowledged that it doesn't make
>>>sense to spend a ton of time doing detailed design of an entire app
>>>or large part of it -- we learn so much by building it and getting
>>>it front users & things change so quickly. What's missing is the
>>>global understanding of the system which helps design the UI
>>>framework -- what pages are there and in each page what panes do we
>>>need -- to create a holistic user experience. In outlook this
>>>is: Pages - email, tasks, address. Panes include - navigation,
>>>global view, detailed view. The consensus seemed to be that
>>>iteration 0 may need to be extended depending on the project.
>>Much of what "Phase 0" involves may depend on the team's past
>>experience. Also while jetlagged yesterday I listened to this
>>programmer-centric panel discussion:
>>It had too much padding for my tastes, but one point strongly pressed
>>by one of the most impressive panelists, Fred George, was that in
>>real life, successful "agile" projects actually operate with a lot of
>>shared expert knowledge (or, if you prefer, dogmas) already in mind.
>>If we start from a completely blank slate, pretending that (for
>>example) we've never heard of database transactions or encapsulation
>>or extensibility, we're unlikely to move successfully past the
>>prototype phase. Witness the many research projects which wither
>>after the grants disappear.
>>Given the traditional influence wielded by UX on academic and open
>>source projects (not much), there's a lot of shared "conventional
>>wisdom" to build. Fluid is helping make that happen with UX design
>>pattern and component libraries. The difficulty is how to handle such
>>efforts _in parallel_ with rapid delivery of real solutions. So far
>>as I can see, quickly hopping from one hirewire tightrope to another
>>(on a unicycle while juggling fireballs, of course) is the strategy
>>we've come up with. I can't improve on it, but it does keep me very
>>>On Oct 23, 2007, at 11:42 AM, Ray Davis wrote:
>>>>Back from vacation and jet-lagged, I've been catching up on the
>>>>wiki and found a pointer to this presentation by Lynn Miller:
>>>>Her points so directly address some of the issues we've struggled
>>>>with locally -- and that I'm about to start struggling with again :)
>>>>-- that I've copied the highlights from PDF slides into text form
>>>>easier reference. In case it's of use to anyone else, here's my
>>>>The model assumes two groups rather than a single inter-disciplinary
>>>>team, but the coordinated development cycles are kept short (two
>>>>weeks) and cross-talk is frequent.
>>>>Cycle 0: Interviews, usability tests, other research. Get 20 issues,
>>>>rank them, decide on top 5 to be tackled in the first two
>>>>"No detailed requirements. No designs."
>>>>Cycle 1 for Programming group: Underlying architecture; critical
>>>>functionality with bare-bones UI.
>>>>Cycle 1 for UX group: Design, create prototypes, usability test,
>>>>iterate. Get more target user data for Cycle 3.
>>>>Cycle 2 for Programming group: Make verified prototypes live.
>>>>Cycle 2 for UX group: Usability test of Cycle 1 functionality.
>>>>for Cycle 3. Get more target user data for Cycle 4.
>>>>... continue until everyone's put on another project ...
>>>>Key points that distinguish this from traditional "waterfall"
>>>>functional specifications, and from a less-than-optimal "water
>>>>balloon" UX + Agile hybrid:
>>>> * Interface designs are completed Just-In-Time rather than weeks
>>>>(or months!) in advance.
>>>> * Slim deliverables from UX to Programming.
>>>>Since her outline somewhat resembles processes I've seen project
>>>>teams improvise under pressure, I'm inclined to find it fairly
More information about the fluid-work