Month: July 2008

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

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.