The Limits of Control

The Limits of Control

I'm ashamed to say it but when I wrote my previous post, I hadn't finished reading Adam Greenfield's insightful essay on the false trappings of "experience design". It is a must read for anyone calling themselves an experience designer.

When I was first exposed to the term interaction design, IDEO was doing some consulting work for my group at Sony. Their design solution was great but I remember hearing one of their interaction designers explain that it was called interaction design because they believed in designing, "the way people interact with a product rather than just the interface." This bothered me.

I was an early member of the Experience Design Group at the AIGA. I really enjoyed meeting about what was then a very new concept. There were two general themes to the early discussions… the specifics and practice of design in the related fields of interface, usability and web design, and the expanding responsibilities of the “experience designer”. It was this theme that led some members to talk about designing and controlling the whole experience. I remember debating this with a couple of members. My experience at Sony was reflecting a larger role for design. I was working on several Internet-enabled products that had physical product, user interface and websites/services attached to them. But my experience was more struggle than omnipotent control. Influencing all of these process areas (and co-workers) to arrive at an innovative product was truly a difficult challenge. I had no pretense that my work would control the user’s entire experience as I was too busy trying to influence the internal teams. In the end my primary design goal was that the product be simple and usable.

I’m not sure where I read it but I thought I heard Bill Moggridge (author of the excellent book, "Designing Interactions") describe the origin of the term interaction design as being more about the interaction of various parts of a system rather than the user’s experience. The example I remember is the design of an interface / control panel for a paper copier. The scope of the design brief was limited to the control panel but they quickly figured out that some of the problems they were trying to solve were unsolvable unless they could influence the design of other parts of the system (internal functions, paper feeder, collater, etc.). So what they were really saying is that in order to create a simple user interface, the entire system has to be designed to be simple.

This meaning of Interaction Design is much closer to my beliefs and experience as a designer. In product development (as in life) there are things you can control and things you can't. How people will use a product is not something you can typically control which is why usability tests can be so eye opening. But as the copier example illustrates, there are almost always internal issues to the project that are not under your direct control. So being a good product developer, whether engineer, designer or business person, involves identifying these issues early so you can either fix them or design around them. Years of experience teach you to spot these issues and to collaborate beyond your domain in fixing them. I like calling myself an interface designer because I have significant and tangible impact in that area… even if I sometimes have influence on business issues as well.

It’s important not to get too hung up on semantics. Call yourself an interaction designer or an experience designer as long as you don't take yourself too seriously and think you’re capable
of controlling the complete experience. As Adam has so expertly pointed out, most efforts in this direction end up disappointing the very users we're trying to please. There’s an old Irish prayer... "God grant me the Courage to change the things I can change, the Serenity to accept those I cannot change, and the Wisdom to know the difference." I think that says it all and the author wasn’t even an experience designer.