On cultivating a UX design process

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:

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

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

On the value of design education

Speaking as a Master’s degree holder, i’m biased but I’d say the advantages are primarily:

1) Cross-college connections and alumni networking, especially if you go to a “brand-name” school. Sorry to offend or seem elitist but it’s true.

2) The opportunity to do creative, exploratory projects and re-kindle the imaginative spirit that the working world may have killed off (Like Jack I went straight thru from Undergrad to Grad, for various reasons, but I remember my CMU adviser saying he liked folks who returned to school after spending a few years in the “real world” b/c they were sufficiently angry and jaded and primed to crank out amazing stuff—i’m simplifying a bit ;-)

3) The opportunity to get deep into thinking, reflecting, and diving into the theoretical and intellectual issues that enrich the practice, but we often don’t have time for when we got a 12pm deadline for a client and then a proposal due at 5pm. Spending the year or two doing that deep dive (if you really enjoy it—alot of folks admittedly don’t) may help cultivate a valuable habit that will make returning to the real world a bit more tolerable and satisfying. The intellectual fodder you gain does provide valuable perspective. At least that’s what I tell myself when engineers are clammoring for specs yesterday and I have to design for the PM’s delusional use cases :-)

4) And if you’ve been fumbling around learning it as you go along, grad school offers the chance to learn methods/approaches in a more organized guided fashion (presuming the curriculum is sound and robust!) to push yourself further…and perhaps discover something about yourself you didn’t know!

Also, in terms of career growth, AIGA and IDSA usually publish periodic studies of salary increases, etc. More and more I see job descriptions (like posted on ixda) that require or recommend Master’s…

That all said, in the end it’s a personal choice and has to be measured against your passion and what you really want to get out of the degree. And if it’s right at your stage of life, career, etc.

Good book: Inside Steve’s Brain

Inside Steve’s Brain by Leander Kahney

I’m still making my way through this relatively compact book (about 200 pages)–typical of me I tend to read multiple books at once–but so far I can say this is a fabulously compelling and insightful look at Apple’s product innovation process and philosophy, all emanating from perhaps one of the most extraordinary individuals in the business. This is not some gossip rag (although there are some admittedly juicy morsels of his temper). In fact it’s more like a business case study, with examples from Apple as well as Pixar, and references to Chiat/Day.

As the author describes, there’s a fascinating mirroring between Steve’s personality and Apple’s business/brand/design–his persona truly manifests and makes their business, perhaps unlike any other company that I can think of, short of Disney (Walt Disney), Ben & Jerry’s, or Dyson (James Dyson)! Most enjoyable (and valuable takeaways) are the “Steve’s Lessons” at the end of each chapter itemizing classic Steve-isms like “Everyone’s either a bozo or a genius” or general principles such as the obsessive drive to focus and simplify (hint, hint all you product managers chronically infected with featuritis!) or pay attention to details, even at the pixel level.

The mix of quotes and anecdotes from Jonathan Ive, Steve Jobs, and various others (including my former Cisco VTG UX boss, Cordell Ratzlaff) provide delicious fodder for those clamoring for examples/evidence to point to in the face of design skepticism at the office. Every product manager, engineer, QA engineer, and related professional engaged in hi-tech innovation simply must read this book. Every designer should read this book (particularly if you are jaded, cynical, or have given up) to re-energize your passion and imagination…and fire up the will to make “insanely great” products.

On a bit of a downer note, the author’s writing suggests that a hi-tech company desiring breakthrough products can only achieve it if the CEO truly *gets* design, users/customers, innovation, and has that amazingly innate knack for “picking a winner”. The CEO’s personality must equal the business. Which is probably why companies like HP, IBM, SAP, Microsoft, Dell, AT&T, and similar corporate behemoths whose CEO’s don’t give a damn about good design (or have at best a weak, commercially hyped sense of “user experience” as insipid lip service) will never achieve the Apple level of perceived excellence. In that regard, Apple and Steve Jobs exemplify a powerfully unique model that may never happen again in silicon valley. So soak it up now!

Insights on Apple’s design process

Some fascinating insights about the Apple design process as quoted in various articles this week:

Jonathan Ive interview

“We have a very clear focus that all the development teams at Apple share, a focus around trying to make really great products.

“That can sound ridiculously simplistic, almost naive, but it’s very unique for the product to be what consumes you completely. And when I say the product I mean the product in its total sense, the hardware and the software, the complete experience that people will have. We push each other, we’re very self-critical and we’ll take the time to get the product right.”

Apple on prototyping

It’s a process where they discover the product through constantly creating new iterations. A lot of companies will do six or seven prototypes of a product, because each one takes time and money. Apple will do a hundred — that’s how many they did of the Macbook. Steve Jobs doesn’t wake up one morning and there’s a vision of an iPhone floating in front of his face. He and his team discovered it through this exhaustive process of building prototype after prototype.

Good book: Dreaming in Code

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg

This insightful read provides an engaging and sobering look at the trials and tribulations of software development from the programmer’s perspective, by chronicling Mitch Kapor‘s unfulfilled attempt at designing & coding a novel piece of PIM software (code-named Chandler), during the last few years up in San Francisco. At times a bit tedious in the arcane coding issues, but presents in mostly layman’s terms concepts like refactoring, source control, object modularity, inheritance, etc. as well as project management debacles, heavy processes, the human dimension of it all. And it showcases so well the inherent hell of building good software…and that many top coders are more like artists than we think :-)

There’s a few chapters about UI design, but the story revealed a flawed sense of how design should intersect and coordinate with software engineering. Or even prototype-based innovation! I find it ironic that Kapor is the author of “the software manifesto” in 1990 which extols user experience as a paramount goal, yet this story shows he has no real understanding of how to propagate it throughout a software dev process. The coders are itching to code, alot of folks are simply volunteers, there’s a lone graphic designer handling it all, with constant language confusion between backend and GUI folks, etc. Plus the requirements are being written while the product is being coded… It’s quite literally the same damn story everywhere in the valley!

What I really enjoyed: the author injected notable software history as well, from Alan Kay to NATO (did you know that the first software engineering conference was held by NATO, b/c of the impending crisis of software complexity overwhelming human cognition and planning efforts? (stemmed from a failed IBM project, the RS/360) So clearly it had no effect: Windows is still many million lines of code! :-)

But the ultimate moral of the story as Kapor says it, “software is hard.” I think it’s a great lesson for designers to understand as well, and the Chandler project reveals the difficulty and pain. It might be just “pixels and code” you can tweak at a keystroke (or mouse click) but that doesn’t make it easy!