daphne at media.berkeley.edu
Tue Jul 31 22:17:30 UTC 2007
Below is a description of interaction design working in agile
environments. This is a very long thread (around 50 responses...hot
topic!) but Teresa seems to express most people's experience...also
mine from previous experience. An additional challenge we have is
the highly distributed and diverse groups we have...both doing
development and design work and our user groups. I'm keeping all
this in mind as I create a straw man component design process for
discussion and review at the Fluid summit in September. I can see
how these practices mesh with a specific component's design and
development but when we start thinking about larger scope work that
may entail changing the UI architectures it becomes much more
fuzzy. The way this worked in my past experience is that we
started with needs assessment and then into conceptual design to
create a roadmap. Once the roadmap was created we began working more
in an agile fashion. The roadmap would define smaller chunks of
functionality that make up the end goal. The "chunks" were sized
right for an iteration or 2. This allowed us to create a holistic
design and focus on the details once the agile project kicked off.
After, or perhaps in parallel with the UX walkthroughs, Fluid will be
looking at improving content management in general. Several of us
are working on a plan to attack the content management work...also
for review and discussion at the summit.
I believe the needs assessment of content management will lead us to
reconceptualize the way resources are currently handled in Sakai (I
have less hypothesis around UPortal and Moodle since I have less
experience with them and their users at this point). This means
along with new components to handle specific kinds of interaction
there could be changes to the UI architecture...ah, the fuzziness.
They'll also need to be "chunked" and prioritized so we continue to
make progress while moving toward our end goal...however that gets
defined coming out of the user needs assessment phase. Since these
are production systems making the changes at a UI architectural level
are even trickier since we need to make sure what's there continues
to work with what's new. I see this as a very exciting challenge,
yet a challenge!
A bit of a ramble I know because I haven't made complete sense of
this yet myself. I'm interested in others experiences, thoughts, etc...
Begin forwarded message:
> From: Teresa Torres <ttorres at stanfordalumni.org>
> Date: February 13, 2007 10:15:41 AM PST
> To: discuss at ixda.org
> Subject: Re: [IxDA Discuss] IxD in agile environments
> I currently work in an Agile environment. I'm fairly new to it, but
> am really enjoying it. We work with a 2 week sprint cycle. The
> product team (which UED is a part of), has a high-level concept (we
> call them themes) of what will be worked on two sprints out and is
> defining and writing user stories for one sprint out. As the UED
> resource, I try to do UED research for the upcoming themes that are
> two sprints out and actual design work for the stories for the next
> sprint. By the time engineers start building, the stories are
> designed and tested, so engineers can build with confidence.
> I have definitely had to learn to work in a compressed product cycle.
> I don't have the luxury of spending a couple of weeks to do user
> research before a big project starts. Instead I have to figure out
> how to do UED research for a day or two for the next couple of weeks
> worth of work. I have found that it's a lot easier to get buy-in on
> research time when it's in smaller chunks and has immediate impact.
> But it is definitely redefining my definition of guerrilla UED
> Since Agile environments force your team to collaborate far more
> often then in a waterfall approach, I have found it to be a lot
> easier to integrate UED into the whole process. I find that in more
> traditional approaches, UED documents get created and ignored or
> research gets put off as too time-consuming. I'm sure everyone here
> has seen their research or validation time compressed due to a late
> project. I am finding this happens far less often in an agile
> environment, as long as I am willing to adapt my approach. I find
> myself doing more UED work and less evangelism than in any of my
> prior positions.
> Instead of creating a ton of documentation, I disseminate my
> knowledge to the whole team as we build. We do use personas and
> scenarios, but we don't use a lot of other traditional UED
> deliverables. I rarely create site maps or process flows - they would
> just be out of date after two weeks. I haven't written a behavioral
> spec since I started here. But I do help write user stories and my
> mockups definitely add constraints to existing user stories.
> Instead of writing formal usability reports, I maintain a design
> library where I include before and after screenshots, list design
> notes which include any validation metrics or usability findings that
> either influenced the change or supported not making a change. This
> is all done on our corporate wiki and is nothing like formal
> It's definitely required a lot of flexibility, but I see it paying
> off. I'm an integrated part of the product cycle, not just a resource
> that allows our company to say we have a user-centered design
> process. I'm a big fan so far.
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work