At last night's NYC IxDA event this topic came up in the conversation. In almost every other design discipline the foundations are taught for many reasons, but one reason is "to know your materials"; to master your materials and be able to employ craft against the canvas.

I presented a strong case that one of the things keeping IxD back is our lack of craft in general, but specifically in the materials we work with.

There are many reasons for this, but it those reasons don't negate that this is an issue that we need to start handling in our education and practice as interaction designers.

It's such an extreme example, but I love pointing to this early Picasso to illustrate the value of knowing your materials so you can better exploit them.

After 14 years of being a designer/developer and keeping up with the latest management method of the day, I have to say "it depends".

So we switched our thinking/ The approach we take is iterative and self-learning. We don't have the luxury of doing research for research's sake, so we incorporate learning into each project.

We begin with assembling a cross-functional team during the pitch process. As the project progresses, we adjust the team members if:
a) they need to bring in an expert
b) they can learn it themselves
c) they should work with someone else
This exposes everyone to every aspect of the process. From project to project we build up on our shared experience. Individually we learn 'how to learn'. Thus giving us the confidence to move forward with ambiguous requirements.

Our learning tools have gotten much better (bookstores, videos, blogs, automated testing, online help, etc) that it's becoming easier to bring in new perspectives.

@daveixd, I agree, though I wouldn't say it's holding back IxD; rather it's holding back some IxD's.

Donald Schon famously described design as “a conversation with materials", which I think characterizes the conversation brilliantly.

There's an interesting analog in the world of industrial design that may be a way forward. One of the things they have that we don't is a good workflow where an ID's design renderings can then be used as a starting point for the 3d databases for manufacturing.

I know this is the thinking behind Microsoft Expression and Adobe Thermo/Flash Catalyst. I sure have a lot of hope for this vision, but I'm not sure we're their yet.

I haven't had a chance to check out Flash Catalyst, and when I last tried them, the Microsoft tools were a too slow to even contemplate using for day-to-day rendering and exploration of design ideas. We're still compelled to sketch things in Fireworks (or One Note) first.

@daveC (had to differentiate somehow)

When you say "Some interaction designers" are you saying:
A) some IxDers can get away w/o knowing materials?
B) some IxDers actualy DO know their materials?

As for Blend, I can speak to the HUGE fail here in this regard.

Ted Booth and I brought Blend into Motorola Enterprise Mobility exactly b/c we work in an industrial design studio that moves from Alias to Pro-E exactly the way you describe above. We immediately understood and were excited about the analog and have every since been kicking ourselves ever since. (Well, mostly me b/c Ted left b4 he had to deal with it for real.)

My point being is that the ideal so far at least is not playing to reality of the tools. Lots more to explain here, but I think this is my way to say, I agree w/ you.

But I think we are focusing on "tools" incorrectly in this conversation. B/c "code" is not REALLY our material, but rather the building blocks of dialogs of interactions within specific (technology, space, service, etc.) contexts.

The last decade of IxD has been focused on the science of evaluation. I think the exciting happening of the next period of IxD will be on defining the aesthetics and foundations of interaction design.

The question I asked last night (slides here: http://is.gd/ba3n) was "What is our clay?"

The other thing that is becoming clear to me is that the conversation level needs to advance. We need to change the actual tone, and style of discourse we are having to adequately address the intricacies and complexity that is interaction design. What we need to do is not simple and the modes of conversation need to reflect that. How we do that, I'm not sure.

Hi Tim,

first off many thanks to you and your colleagues sharing your thoughts in this blog. I enjoy reading a lot! The most important sentence in this post is "There are good arguments on both sides of this issue, and there’s no one right answer." Or let's put it that way: "it depends." I'm working in the German R&D office of an American software company, I'm not a developer, I can hardly write a line of code but after being a user of our products myself for years and then joining the company going through many different positions, starting as a test engineer and later manual writer, I ended now up being an interaction designer before even having ever heard the word before. I do believe that it can be an advantage not being sucked in to the technical detail of things too deep. The material, the "clay" as David puts it is the actual use case, the user story, the anticipation of the moment someone fires up the thing and wants to actually DO something with it. If this is a software developer using a programming environment it does make sense when an interaction designer with development experience had been involved in the design of the programming environment. But when you're creating e.g. software for musicians, you better know how these cute little mostly tech-phobic creatures think and if you design interaction for a website that's supposed to sell furniture to seniors you better forget anything you had known about code before and start climbing out of your box. In so many cases I have witnessed that being tech-savvy themselves keeps people from making the right decision because they didn't see the wood for the trees. So how about this: Being also a skilled developer can definitely help being a good ID but it's not necessary, it depends on the product. I'm playing devil's advocate here, I have to, I can't program. :)

"Reality bats last" - not sure if Mr. Cooper himself said that, but it's the way I work.

Unfortunately, it's often the case that reality is a Babe Ruth hitter - my bank asks me to "enter the transfer amount in cents" - so the build happened before the design.

Lar Veale, I just had a look at your blog and this sentence says it all: "But here’s the thing, we don’t need to know how the engine works to be able to drive a car." Thanks for that.

@Wolfram

That sentence does say it all. It says that users shouldn't have to know how a computer works to use it. But are there automotive designers who come up with a design for a fossil-fuel-powered car who don't provide for exhaust from the first iteration because they don't know how an internal combustion engine works, and they stay purposefully ignorant to "not constrain themselves" in the design?

@daveixd, I most vigorously meant

B) some IxDers actually DO know their materials?

And absolutely NOT

A) some IxDers can get away w/o knowing materials?

Though I also think its possible to know your materials without spending all day writing code.

You're right, Sandy, I think there aren't any. Still, when we're talking interaction design, the interaction here takes place in the cockpit, not the engine or the exhaust. Could someone come up with the three basic concepts of a steering wheel, pedals and shifter for driving a car without knowing how to put together the parts or the combustion engine? (Hopefully still using an adequate metaphor here?)

I think it is important to have a team with a broad spectrum of designers. Having some designers that understand the "engine" to keep things feasible and others that "never looked under the hood" to fight the implementation model. I think it's the conversation of those polarized perspectives (and those in between) that will create the usable middle ground.