Ghost in the Pixel

I’ll be back at SJSU this fall teaching an evening course on the fundamentals of interaction design for undergrad ID majors, which should be quite fun! (and tiring too…who knew teaching was so much work! But very enjoyable) I learned a ton on my first go at it last fall and have thus been re-tooling the syllabus accordingly, front-loading the theoretical content and focusing the rest of the semester on hands-on projects, connecting back to the earlier concepts. One major change is that I will be not doing one central monolithic project for all the students… instead I will have a different approach that enables greater variety of solutions and more collaboration across teams. Plus I’ll be having a few guest lectures from folks like Andrei, Cordell, and some others in the valley to provide richer/diverse perspectives on design issues like digital craft, rapid prototyping, and strategic product development.

From the syllabus introductory paragraph:

The central theme of the course is that design is a human-centric problem solving activity,
based upon the ideas of conversation and rhetoric towards achieving simple, focused, elegant solutions. Each week we will delve deeper into what this means in terms of visual design, digital interaction/behaviors, and language/content.

By the end of the semester, students will understand the overall design process, address typical interaction design problems/issues, and be able to generate compelling solutions in a variety of forms: sketches, mock-ups, and prototypes (a movie, a click-through, or more advanced per student skills). Students will also develop a basis for how to critique designs and present themselves effectively.

As you can deduce, my approach to teaching this subject is heavily influenced by my education at CMU, particularly the humanist/rhetorical approach to design as argument, informed by Dick Buchanan’s ideas. This might be a bit heavy for undergrad students but I hope to at least seed the ideas, which may come to fruition later on in their careers. They may not truly get it right away, but surely they will notice the value of the approach soon enough with the projects and critiques I’ll be giving them ;-) Either way, I look forward to advancing such ideas and helping educate another group of young designers…

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”)