Category: General Stuff

Below is based upon a reply I made to the ixda list awhile back re: listening to customers (or when not to!)…

I always take user research findings (quantitative or qualitative) with many grains of salt. It’s supplementary data to help a designer understand, empathize, interpret, and then make a “good” decision. Designers are informed visionaries, not “short-order cooks” doing simply what the user asks b/c often users often don’t know what they want, nor how to express exactly what they want. If they did, we wouldn’t have jobs :-) Designers must exercise their best judgment (comes with years of experience, I fully realize) to use or dismiss that data accordingly per the project needs.

Also, what’s the project goal?

1) Breakthrough innovation: It’s important to note that no user specifically asked for a Wii, iPod, Prius, Dyson or flickr, but once manifested, then users wanted them. Discovery activities, asking users their motives/reasons, assessing broader social/tech trends, defining various scenarios might help…but again, take salt with what you find!

2) Incremental clean-up: But if it’s minor tweak for the next point release, listening to those 500 complaints on your forum about the wrong button label might be good :-) Then again, if there’s a valuable opportunity to introduce an innovative UI or behavior, then try it, get a pulse on your users’ reaction (with beta testing or other approaches), and then decide how to proceed.

For other resources on this issue, I’d suggesting googling the following folks: Larry Keeley (Chicago ID), Vijay Kumar (Chicago ID), Roger Martin (Rotman), and Craig Vogel (Cincinatti)–all academics but with practical understanding how breakthrough innovation happens in large corps like Motorola, Ford, Whirlpool, etc. while leveraging customer feedback and testimonials.

But I’d say: Gather some user info, question what’s said, reflect on it, create a solution per your design abilities, evaluate and iterate. (and don’t forget the salt!)

Just realized that this month (July) marks my 7th year working in Silicon Valley (and being in “the real world”), as a designer of various digital products (software, websites, devices, etc.). Yep it’s been quite a run so far! I’m incredibly grateful for the advice, opportunities, mentors, and projects all along the way that got me where I am now…and guiding me further to the next level of my growth. Still a tremendous amount to learn and absorb!

In particular I’d highlight the following as the most instrumental in my career so far:

1. Drive, ambition, passion: You’ve got to want to create the best.

As Steve Jobs once said, “to put a ding in the universe.” He goes further: “Unless you have a lot of passion about this, you’re not going to survive. You’re going to give it up. So you’ve got to have an idea or a problem or a wrong that you want to right that you’re passionate about; otherwise you’re not going to have the perseverance to stick it through. I think that’s half the battle right there.”

2. The “social”: the friends, mentors, conversations, conferences, events, networking

(and yes, location has played a valuable role for me in this regard; being in Silicon Valley has been just extraordinary with the vibrant population of designers, techies, biz folks…and all the different places to do design in this area, and thus learn from the diverse process/culture/strategy approaches)

3. I realize it’s not popular to say this, but I’ll just say it: talent. I’m incredibly grateful for the talent I have (and evolved over the years through all the projects and mentors) which has helped me greatly in my career. I would not be honest if I didn’t acknowledge that.

(more on the value of talent and why it matters more than ever to designers today…also on “talent vs. process” which is sure to ruffle some feathers! :-)

I’m still amazed that people in this field get such fundamentally core concepts confused. Makes me wonder if those who get confused about this should even be practicing interaction design! It’s like a surgeon confusing muscle and bone–seriously.

Wireframe: a static skeletal structure of content, drawn to proportion for your screen dimensions & resolution. Lacking any meaningful stylistic treatment (just basic gray shades), it’s a relatively quick and lightweight stepping stone to visual mockups/comps.

Prototype: a behavioral representation of the final product, at varying degrees of fidelity (from skeletal to rich). There may be “feature prototypes” to explore specific behaviors in a tightly constrained, almost sandboxed fashion. And there may be a “functional (or master) prototype” which comprehensively covers the behaviors and use cases so thoroughly and realistically so as to be confused for the actual live code. The key thing is demonstration of behavior in some fashion. (Not sure if Jeff Hawkins’ famous “block of wood in my pocket” qualifies, seems more like a model which is kinda splitting hairs…) But ultimately a prototype is something behavioral to explore the usage/behavior issues, identify & work through those type of problems, and suggest directions for other alternatives, ultimately feeding that virtuous cycle of iterate/design/test, etc.

(BTW, the film “Sketches of Frank Gehry” by the late, great Sydney Pollack features a great portrayal of bonafide “paper prototyping” to explore various structural and formal possibilities, with scissors and construction paper–even some Scotch tape!)

A snippet from a reply I made on the ixda list awhile back re: some import/export metaphors in the UI…

Aren’t all metaphors inherently “broken”? In the sense that no metaphor is 100% verisimilitude, but a language device to achieve a necessary, yet sufficient level of understanding to basically grok a concept, make it just *meaningful* enough to act on it given a certain context and situation. (and overcome difficulties in interpretation, as a sense-making device). I can’t move real office windows around, i normally don’t duplicate physical files and folders with a finger stroke, and animal mice don’t have buttons. But i know through learned behavior, observation and cultural convention the computer “equivalents” work in specific ways (and evolve over time, like “spring loaded” folders and “wheel mice”) and mean certain things.

(More on language & design in the chapter I wrote for Jon Kolko’s book “Thoughts on Interaction Design”)

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