Design processes...

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

-Daphne

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  
> tactics.
>
> 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  
> documents.
>
> 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.
>
> Teresa
>
>
> ________________________________________________________________
> 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

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070731/1b336767/attachment.htm>