The relationship between designers and material

29 Jun 2010 - 11:17am
4 years ago
11 replies
1251 reads
Matt Nish-Lapidus
2007

I posted this to my blog earlier today, but I thought it would be worth contributing here as well.  Lots to discuss around the idea of material in interaction design.  

Here's the post originally seen at http://blog.emenel.ca/post/749792140/the-designers-relationship-with-materials:

 

----------------------

I read a great short post on the Frog Design blog this morning about Apple’s design process (article: http://designmind.frogdesign.com/blog/why-apple-is-the-new-master-of-craft.html thanks to Dave Malouf for sharing this in his gReader). It highlights their relationship with the materials that they use, and how integral that is to their design process.

A quote from Jonathan Ive from the article:

"The best design explicitly acknowledges that you cannot disconnect the form from the material—the material informs the form. It is the polar opposite of working virtually in CAD to create an arbitrary form that you then render as a particular material, annotating a part and saying ‘that’s wood’ and so on. Because when an object’s materials, the materials’ processes and the form are all perfectly aligned, that object has a very real resonance on lots of levels. People recognize that object as authentic and real in a very particular way."

A lot of what we do as interaction designers is still in the “annotated CAD drawing” category. We make our static boxes and text and send that off to somebody else to give it form (sometimes with our direction and/or collaboration, but not always). We never work with the materials of the final product. 

Just like industrial designers, our materials change with each project. They work with glass and steel on one project, then with plastic the next. Each time they need to learn the properties and possibilities of the materials. Sometimes we work on designs that will become html, css, and javascript; other times it will become objective c in the iPhone SDK, and the list could go on. Does this mean that we all have to become masters with all technologies we might use to implement our projects? No, not at all. What it does mean is that we should spend some time at the beginning of each project to play with the materials. Get to know their properties. This includes code, physical interface, responsiveness, symbolism, input, feedback, and more. 

The properties of a material are also aesthetic. Again, from Jony Ive:

"… we experiment with and explore materials, processing them, learning about the inherent properties of the material—and the process of transforming it from raw material to finished product; for example, understanding exactly how the processes of machining it or grinding it affect it."

Interaction designers seem to have some aversion to aesthetics, but we really need to starting thinking about how interactions feel along with how well they work. How does different material respond to different types of input, feedback, and animation? How does colour, texture, and spacing change people’s engagement with your product? Does it make them like it more? Less? Easier to use? More fun to use?

It might sound like I’m making the interaction designers job a lot bigger and more complicated… and well, in some ways I am. But, in other ways, I’m trying to bring interaction design in line with the complexities, challenges, and potential rewards of other design disciplines. There have been members of our community asking where the Jonathan Ive of interaction design is? Where is the Eames, the van der Rohe, the Rand? I think we will never get there as long as we avoid the larger challenge of designing in a holistic way. As long as others are alone responsible for the final form of our designed objects - the aesthetics, the feel, the implementation - we will never see the full potential of interaction design to make amazing things. 

We are more than wireframe jockeys. We are designers and are responsible for the output of our designs. We need to stop making piles of blueprints and CAD drawings, and start making the things that we envision. 

---------------------

 

Comments

29 Jun 2010 - 12:02pm
.pauric
2006

"We are more than wireframe jockeys. We are designers and are responsible for the output of our designs. We need to stop making piles of blueprints and CAD drawings, and start making the things that we envision."

I know that you're much more than a 'wireframe jockey' I just want to correct this statement.

If, as an IxD, you are mindlessly churning out wireframes - then you are doing it wrong.  Sketching and wireframing are design exploration tools.  They are also used to communicate design intent with the 'materials guy' and in that conversation the practicability of the proposal/solution is explored.

It's simply not practical for us to be both researchers and advocates  for the user as well as responsible for in-depth understanding of technological constraints & workarounds.  I tend to feel that those who say designers should also be coders dont understand what it means to be a truly good coder, one who can build UI's that excel. 

I would also say that the Jon Ives perspective is on the end of a very long spectrum.  Designers working on multi year, multi-release programs have a certain luxury afforded on these timescales. Two years ago I was sketching concepts without knowledge of which platform we would choose.  A year ago I was wireframing very lofi designs for the basics of the UI framework with only a passing adherence to constraints presented with Java.  Today I work so closely with the developer we could be considered the same development resource, the design is refined using whiteboard and code.  I suggest, he builds, we review. We're at a speed of iteration where it would serve no purpose for me to understand limitations, two specialists doing what each does - well.  

Do I need to know anything about Java in this landscape?  not really.  Has being a 'wireframe jockey' 1-2 years ago paid on in terms of ensuring we made the right design choices for today? absolutely.

I also object, in principle, to the idea that we must design within the constraints of our medium (although I recognise that in practice this is very It Depends)   A designer will find it harder to push envelopes if they fully understand the limitations.  By all means have an understanding of what is possible, but dont limit yourself with the details of how it is so.

/pauric

 

29 Jun 2010 - 2:06pm
Matt Nish-Lapidus
2007

I agree with most of what you said, and I wrote my original piece in the hopes of having this exact conversation, so thank you! Take all this with a grain (or pillar) of salt.

I'd like to respond/discuss a couple points specifically:

Sketching and wireframing are design exploration tools.  They are also used to communicate design intent with the 'materials guy' and in that conversation the practicability of the proposal/solution is explored.

Sketching and wireframing area absolutely design exploration tools, agreed 100%.  However, for a lot of people working in this field they are also the end product of their work, and unfortunately their involvement. 

It's simply not practical for us to be both researchers and advocates  for the user as well as responsible for in-depth understanding of technological constraints & workarounds.  I tend to feel that those who say designers should also be coders dont understand what it means to be a truly good coder, one who can build UI's that excel. 

I think you misunderstood/i miscommunicated my point a little. I don't think, in any way, that designers (we) need to be expert coders or electronics wizards. BUT, if you're designing a sensor based interaction it's very important they you understand how that sensor works - not just it's limitations, but it's possibilities. 

Also, to your point of not being able to be researcher, advocate, and understand the technology/material, I disagree. Designers throughout history have always balanced this line, and you have to be able to move around it as the work demands. Sometimes I need to focus entirely on being an advocate, or a researcher, or any number of other things, but on average I have to balance a lot of different hats all the time. I think this is just part of being a designer.. Industrial designers have to juggle material costs, manufacturing difficulty and cost, material properties, aesthetics, ergonomics, etc. 

I agree that the Ive example is on one end of a long spectrum, and most of us are not going to have months of time to explore materials for each project. However, for a lot of us the materials don't change that often, so exploring them over a few projects is entirely doable. I'm talking in a more abstract way about our practice as interaction designers, and less about the specific circumstances of each of our individual jobs and projects. Every instance will require a difference balance of all these things. 

Also, I think everybody needs to start out by doing menial design tasks, and that might mean being a wireframe jockey for a while. You need to do those types of repetitive design tasks to master craft and be able to move on to more complex things. 

Just to re-stress this point: Understanding materials (be they code, metal, wood, wires, solder, heating elements, pixels, or whatever) is not only about knowing limitations. It is about knowing possibilities. Also, you need to deeply understand the material properties of anything in order to predictably and successfully push the limits. A woodworker who can't make a perfectly square block without even thinking about it will never truly push the boundaries of wood.

29 Jun 2010 - 4:55pm
Jared M. Spool
2003
Understanding materials (be they code, metal, wood, wires, solder, heating elements, pixels, or whatever) is not only about knowing limitations. It is about knowing possibilities.

Very well put. Jared

29 Jun 2010 - 3:55pm
fj
2010

 

pauric wrote:

It's simply not practical for us to be both researchers and advocates  for the user as well as responsible for in-depth understanding of technological constraints & workarounds.  I tend to feel that those who say designers should also be coders dont understand what it means to be a truly good coder, one who can build UI's that excel.

I think it is perfectly possible to be a coder without being a master coder. I also think it is possible to actually indeed be a UX professional and a truly good coder. I'd like to think I was one, once, when I had to be both.

When I started studying UX, it wasn't even called UX, just UI Design, and where I was it was only taught as a minor in a Master's Degree for Software Engineering. So I also trained as a Software Engineer, and, in the mid-90s and onwards, while UX did not have the legitimacy it does now, I did UX work by also having to code it. I truly understand the competing requirements both professions have, and it was hard to marry them, but it can be done.

In fact, I actually do believe a UX practitioner must know the limitations of the tools their designs will eventually be implemented in, because if the UX designer does not know them up-front, they will certainly know by the time the programming team comes back with "Can't be done (at all / with this budget / in this time frame)". And either then you have an answer or you are at the mercy of what the software implementation team is pressured to do to achieve their goals, and you do not end up utilizing the underlying systems to the best of their abilities to support the end-users in their tasks.

(It does, however, give mediocre UX designers a perfect excuse for a mediocre end-result: "The software mornos couldn't implement my wonderful ideas, I am just too advanced, it is not my fault." By not engaging, you get to equivocate on your responsabilities. Ive is right: only knowing the materials will lead to their perfect use.)

I advocate knowing the tools that end up being used for front-end implementations not just for the reasons above, but also to:

  1. Be able to prototype your ideas. The notion that static wireframes can convey the richness of interaction modern users expect from their current systems, mobile or web, to the software team implementing, is really not working for me. You end up having to explain over and over to all collaborators what a quick proto would show in seconds.
  2. Be able to test whether your ideas actually work as interaction, even just testing on yourself, before any serious investment in a software team has to be made.

 

However, I totally recommend not to tell recruiters you are also a coder, and to leave all technology keywords off your resumé / CV. Most recruiters and HR people will not know what to do with you, since obviously UX people who can code have not lived and breathed only wireframes and IAs (so the thinking goes) and thus are not real UX people. This bit me on the ass hard during 2008 and 2009, until I found the one recruiter who could see my knowledge of systems was actually an asset and got me in front of the right people.

But I seriously reject the notion that people who know how to code and code well cannot be good UX people, or, as you say, it is impractical to ask UX people to know and truly understand the software their stuff will be made of to put it in front of users. I am not saying every UX person needs to be able to write production code, but I actually am really weary of UX people who cannot code up a prototype or truly do not understand the underlying systems: they are missing an important part of their toolset to get to a great result.

FJ!!

29 Jun 2010 - 2:11pm
Jack L. Moffett
2005

Hi Matt,

You're describing an approach that I've been following my entire career. Wireframes, in the strictest definition, are not part of my process, but sketches fulfill the same purpose. I do the visual design, and then I create the HTML and CSS for web work, or a detailed spec for desktop implementation environments. I wouldn't have it any other way, and I cringe every time I read a post from an Interaction Designer that thinks the visual design is in some way less important than what they do. Yes, the "qualities of the materials" are extremely important to the overall interaction design.

I think you'll find that IxD's that come from a visual design background (e.g. graphic design, industrial design) are more likely to work this way than those with other backgrounds.

Now, I agree with Pauric, we can't all do everything. So, the important point here is that if you don't have a particular skillset, such as visual design, don't dismiss it as less important and toss your designs over the wall. Rather, you need to work very closely with somebody who is good at it, as in Pauric's example, and develop enough of an understanding of the skillset to communicate and collaborate with that person.

Best,

Jack

30 Jun 2010 - 9:29am
Matt Nish-Lapidus
2007

I'm glad to hear that, Jack.  This is how I've always worked as well, but it seems far too rare in the IxD community of practice. 

I'd go even further and say that even if an IxD thinks that visual design is equal in importance but not something they have to worry about, we still have a problem. Form and function cannot be cleanly separated, nor should they be. Again, that doesn't mean that an interaction design specialist needs to be a world class visual designer.. but they should have a grasp of how colour, shape, line, flow, etc, effect the final product and have some input/control into that aspect of the final design. I'd say the same in reverse for a visual designer working on interactive products.

I also like your take on learning. It's important as a designer to always strive to improve our own craft, and expand our range of knowledge as it pertains to our craft. Learning is a key skill of any good designer.

29 Jun 2010 - 9:20pm
Dave Malouf
2005

Matt, this is a topic as you know that is near and dear to my heart. Thanx for bringing it up here.

Pauric, I think you are looking at a red herring in the "code or not to code" debate you are focusing on. I don't think that is part of Matt's debate at all. The main reason I say this is that "code" is almost irrelevant to our ability to do the types of explorations that Matt is referring to.

Let's take a step back. Industrial designers when they play w/ materials have toolsets that help them with this. Suppliers sell kits of materials in various form factors pre-packaged to help designers suss out the right feel that they are going for. IDs are expected to understand the consequences of decisions in terms of costs and functional properties like performance, ruggedness, etc. They also have tools that help them move beyond materials to look at shapes and colors as well. 3D printing for example has forever changed the way IDs work.

But enough about IDs. few of us have experience in this world so the analogs are probably not too helpful for the bulk of us. But my point is to highlight that there are tools that A we have or B we can create. What are tools that we have that help us explore that types of material that @emenel is trying to discuss:

1. Pattern libraries. especially pattern libraries like Yahoo's that is actually tied to code examples.

2. GUI frameworks. These code snippets can be easily turned into prototypes with either our own limited abilities or through partnerships. Great design shops often see the value in having some amount of hours of developer time tied to the UI Design part of the lifecycle for exploring prototypes. 

3. New tools like Flash Catalyst and Expression Blend and I'll even throw in there jQuery. These allow designers with just the smallest amount of extra effort to convert visions into interactive prototypes. Again, the stronger your partnerships are with your developers the more you can do.

4. Guidelines like Apple's Human Interface Guidelines + the appropriate device in your hand + borrowing the Android equivalents allow you to explore what has been done and create a personal language of critique that in essence becomes your own virtual (as in, in memory) exploration. This works even better w/ #1 in your back pocket.

But back to Pauric's point. I have discovered that my best students in IxD are always the ones who go the extra mile. They take the time to learn what is not expected of them and they push their peers to do the same and then much to the annoyance of following classes, what used to be unexpected is now expected. Our old way of thinking that we UXers have too much of a burden to take on doing any more, in my mind is an "old expectation". One as @trenti will attest I used to believe, but the more I see young people doing every day what I think they shouldn't be able to, I have to change my perspective and realize that just b/c I'm too old and tired to do it, doesn't mean that it can't be done. AND it doesn't mean that as a manager who doesn't have to do it any longer that I can't expect my new hires to be able to do it.

But what is it? Is it simply about knowing limits and feasibility? I think Matt's point is that it is about control. It is about taking on materiality in our craft. We need to be moving away from intangible and abstract deliverables and start dabbling in if only for ourselves what it means for an animation to tween at 2 different rates. To see it, feel it, test it, and decide based on direct experience (for example).

I also want to bring up another type of material we should be looking at as part of the IxD lexicon and that is "the future". All design is about re-imagining a new future. I think if we work less on wireframes (just even a little bit less; not throwing them away) and apply that added energy towards the creation of experience prototypes of a new possible future, we can realize the real material of work, which is impacting the lives of people.

By first imagining the new future we believe our products will create, we can also better imagine the ways of making those futures a reality. We force change on people's lives and we need to be better at structuring the systems necessary to with predictable accuracy we make manifest that reality for all who engage in those products.

THAT! is our real material as interaction designers. Matt, i think you are talking about the material of interactivity (very important, and valuable, but still different).

-- dave

30 Jun 2010 - 9:25am
Matt Nish-Lapidus
2007

Wow, Dave.  Thanks for that great response.  

As usual, I find I'm in agreement with you. That is pretty much what I'm thinking when I talk about materials.  

I'd just like to add one point/caveat.  Although I do agree that as a designer what we're actually designing is "the future," but in order for each of us to get to that level with our craft and vision we need to start with the tactical basics of what it means to design interaction. Learning to work with wood means making perfectly straight edges until you can do it without thinking, and I think we have an equivalent with our tools and materials. Visual communication is a skill that needs to be internalized by a designer, especially an interaction designer, to the point where it's just part of their core. Once that happens you're freed up to use your cognitive cycles to start thinking about larger issues, moving up and up the skill ladder until you can spend all your time thinking about "the future" instead of things like feedback timing or tweening or touch area size.

You need to put in the time at the bottom to be successful and insightful at the top.. 

30 Jun 2010 - 3:33pm
.pauric
2006

 

Great discussion, thanks Matt.

Let me start by saying my point on not coding is based in principle.  Personally, I always start a design with a blue-sky vision and as a project progresses that vision is pared back as the architecture constraints present themselves.

 

Is there wasted effort in this approach? yes.  I feel that if one jumps too quickly in to exploring within constraints, the design becomes quickly tainted and we loose sight of the vision.

 

In practical terms, of course I'm talking out of my arse.  Castles in the sky follow no rules of architecture.

 

Matt wrote: "Learning to work with wood means making perfectly straight edges until you can do it without thinking"

I'm reminded that ~50 generations ago it was possible for a single human to know everything there was to know. ~5 generations ago one doctor could know all there was to know about medicine. 1 generation ago 1 mechanic could fix any car.  Today, none of this is possible.  The same thing is happening to our field. This trend of specialisation is not showing any signs of slowing down.  The question at some point is: Do we, as IxDs, specialise in a particular technology and understand the building blocks.  Or, do we learn to work more closely with other specialists (ixd - Dev).  The proliferation and democratization of development platforms makes it harder for me to effectively take control of my materials and stay generally employable if, god forbid, desktop software isn't around in 5 years (o; 

 

With that all said, I'm not sure we're quite in the abyss just yet, but I feel it is coming.  And I'd like to balance my doom & gloom with something cool we're doing at IxDA Boston.

 

We've setup a team of developers and designers on the Processing language to explore each other's world.  We defined a Gov 2.0 project to track the flow of money between politicians and contributors and visualise that relationship within Processing (java/openGL). Developers got a good taste of design research/thinking at the start of the year when we had Mad*Pow teach us how to interview users, the interview workshop was focused on our project domain.  Then, at another event, the community of Ix Designers created prototypes to meet our requirements (based on the quantitative results from the interviews at the previous event).  This was done without knowledge of the capabilities of Processing.  Breadth first, depth second. Vision over materials.

 

Now we are down in the weeds of the code.  The developers on the team have taken over, now that we are in implementation mode, and are teaching us designers about architecture patterns, methods, apis, etc etc.  It's beautiful thing to watch both domains learn from each other.

 

I feel the real value in understanding the given material is an ability to converse with your counterpart specialist (although in this case the designers will be building a lot of the project)  Did we understand the material before we build our vision? no, did we need to? I argue no.  Would it have been better if we knew the ins and outs of Processing to aid or designing, absolutely yes.  But what happens when we work on our next project... do we shoehorn a design in to our favourite material?  Or do we create the ideal solution and find the right material to meet the needs?

Just to clarify - by all means know code. You will be a better person for it. But it's a double edge sword that's getting sharper every day.  If I were to put forward a nomination for the most important material an IxDesign to master - it's the one of Communication. Pencil & Paper, Flash or html.  Seeing design intent through to implementation with as little delta as possible is what makes a great designer.

 

30 Jun 2010 - 7:56pm
Andrei Herasimchuk
2004

"Our old way of thinking that we UXers have too much of a burden to take on doing any more, in my mind is an "old expectation". One as @trenti will attest I used to believe, but the more I see young people doing every day what I think they shouldn't be able to, I have to change my perspective"

When will you get a large format poster made of those words and send them to me signed and framed?

8^)

1 Jul 2010 - 12:24pm
Dave Malouf
2005

When's you're birthday?!? -- dave

Syndicate content Get the feed