[IxDA Discuss] UX Design Process

[Uday Gajendar]

> from corporate environments, so I'm curious if anyone out there,
> particularly those in small/medium-sized groups or teams using Agile
methodology, can share their design lifecycles.

We're in the midst of doing a similar thing here at Cisco, which  
really speaks to a broader problem of cross-cultural change  
(engineering/mkting/design) and there is no simple solution. (which is  
another discussion :-)

However, a few hi-level pointers I've learned along the way (and  
previously at places like Oracle and Adobe):

** Start with conversations, not a visio or excel template

Brainstorm and sketch it out, hash over a few beers or coffees what's  
meaningful for your team (what works for Cooper or IDEO or Adobe or  
Google might not work for you), get key players in that room and start  
talking!

** Clarify assumptions, dependencies, and expectations

(from all parties' POV's)...this will involve lots of awkward and  
blunt conversations but do it now, before false assumptions get  
hardened and you'll really be yelling (and quitting) later at delivery  
time

** The presentation of your design process matters

Convoluted visio diagrams with spaghetti lines all over, shrouded in  
obscure insular acronyms do little to shape a valuable process or  
great products, especially the UX team. Ditto for excel spreadsheets.  
Stay away from them! They bore, confuse, and alienate...and persist  
that "corporate heaviness" people react against.

Instead, sketch out on the whiteboard the core phases (~ 3-5),  
activities, deliverables, leads/players/liaisons, milestones/ 
checkpoints...that should be it! Make a compelling document out of it  
(or poster, banner)  and turn it into a concise internal UX rally  
flag, and external vehicle for communications. (and evolve it as  
things change)

The biggest challenge is the sync-ups with what Engin and QA and  
Mkting want and expect. (hint: lots of specs, which shows how little  
they typically understand about what designers do and provide) See my  
blog post about "where's the spec?" :-)

Frog has the process tagline of "discover, design, deliver"--sure it's  
cute but effective in communicating to non-design clients, something  
to hang their hat on.

I'm suggesting something like "explore, propose, specify" for us at  
Cisco...

** Don't bind yourself to the process, it should be a guide for  
adaptation

visio, excel, MS project almost ensure enslavement...Resist! (if you  
can :-) I know they're standard biz tools, can't escape them...


** For Agile to work well, the Agile team or process leader must  
respect and value design

This means understanding fairly that design is about defining the  
indeterminate, involves iteration and re-working ideas, lots of fast  
failure, some "feeling out" stuff, etc. If your Agile leader doesn't  
get that upfront and believes that designers are "lipstick artists" or  
"spec monkeys", the chances for success between UX and engineering/QA  
shrink :-(  We were extremely fortunate to have a wonderful Agile team  
leader for the company I was consulting for when I was with  
Involution. Without him and his positive attitude for design, it  
would've been much harder for all of us, client and studio alike.

I have more thoughts on shaping a useful design process on my blog:

http://www.ghostinthepixel.com/?p=78

http://www.ghostinthepixel.com/?p=71

I know these aren't at the tactical level of an Agile recipe or  
toolkit you can uptake like tomorrow, but hopefully the high level  
thoughts are still useful :-)

Thanks,


Uday Gajendar
Sr. Interaction Designer
Voice Technology Group
Cisco | San Jose
------------------------------
ugajenda at cisco.com
+1 408 902 2137