A snippet from a reply I made on the ixda list awhile back about how to get non-design teams talking in a non-design company or culture…
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 diagram or Excel chart
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 inevitably react against either passively or not.
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 and compact, but effective in communicating to non-design clients,
something to hang their hat on.
I’m suggesting something like “explore, propose, specify” for us in VTG
at Cisco…
** Don’t bind yourself to the process, it should be a guide for adaptation
Visio, Excel, MS Project almost ensure enslavement to the corporate bureaucracy in my view
…Resist! (if you can :-) I know they’re standard biz tools, can’t escape them altogether.
** For Agile to work well, the Agile team or process leader must respect and value design
This means understanding 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 dramatically (and tragically).
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.
Some more thoughts on shaping a useful design process: