User Centered Design and Agile Development: The Digest

Ray Davis ray at media.berkeley.edu
Wed Oct 24 16:21:44 UTC 2007


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 spanner.)

>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:
http://www.infoq.com/news/2007/10/modifiability-panel
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 
nervous.  :)

Ray

>On Oct 23, 2007, at 11:42 AM, Ray Davis wrote:
>
>>Back from vacation and jet-lagged, I've been catching up on the Fluid
>>wiki and found a pointer to this presentation by Lynn Miller:
>>
>>http://www.usabilitycamp.org/WUD2006_UCDandAgile_lmiller.pdf
>>
>>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 for
>>easier reference. In case it's of use to anyone else, here's my summary:
>>
>>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 iterations.
>>"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. Design
>>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 feasible.
>>
>>Ray
>>
>>
>>========================
>>Ray Davis, Learning Systems Group
>>Educational Technology Services
>>University of California, Berkeley
>>
>>Phone: 510-642-8581
>>
>>_______________________________________________
>>fluid-work mailing list
>>fluid-work at fluidproject.org
>>http://fluidproject.org/mailman/listinfo/fluid-work
>
>Daphne Ogle
>Senior Interaction Designer
>University of California, Berkeley
>Educational Technology Services
>daphne at media.berkeley.edu
>cell (510)847-0308




More information about the fluid-work mailing list