> 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 ------------------------------ [EMAIL PROTECTED] +1 408 902 2137 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
