Hacking the Physical World:
What we taught software designers, and what they're trying to teach us
By Carl Alviani

I attended a conference in the suburbs of Portland last month, hosted jointly by local chapters of the Project Management Forum and the Product Design and Management Association. The topic was collaboration—a broad and encompassing theme that had the effect of attracting a satisfyingly wide cross-section of skilled professionals from across Portland's high-tech industries. And as is becoming more and more the case with such events, there were designers and planners present who work in both the physical and virtual worlds: industrial designers, software developers, project managers who deal with new airplanes and tractor-trailers, and those who deal with Java and Ruby. It makes for interesting conversation usually, but it placed me in an awkward semantic situation I've seen many times before: having to put an untoward amount of energy into convincing people that I design actual things.

I've found over the course of several years, and several conferences and business functions, that if I stop with the first sentence ("I design products."), the next question is often something like "Oh, on what platform?"

The statistical imbalance has something to do with it. Reflecting the apparent ratio in the population at large, there were around three designers of the virtual for every one of the "real" (I put "real" in quotes not out of doubt, but out of deference—software obviously has real use and value, and nothing seems to irritate software developers more than to imply that what they spend 9 to 6 creating isn't an actual product). With the rise of a creative economy comes an emphasis on the ephemeral: applications, interfaces, brands, strategies, code, data; the fraction of commerce that concerns itself with things that can be touched with a finger has shrunk, or fled to less expensive countries. I'm in a minority in these situations, and have resorted to answering the question "So what do you do?" with something blunt and explicit: "I design products. Like, physical objects. That you can pick up with your hands."

 

Re-Building the Real World
It's not a strategy born of indelicacy. I've found over the course of several years, and several conferences and business functions, that if I stop with the first sentence ("I design products."), the next question is often something like "Oh, on what platform?" Distinguishing the design of physical goods from virtual ones is a necessary step, and substituting "consumer goods" doesn't seem to make things any clearer. This isn't a huge problem either, confined as it is to these specific and predictable situations; and designers of the virtual are usually downright charmed to meet someone who does something as quaint as deal with entire atoms, and not just the electrons flowing between them.

It raises a deeply interesting question though: why the confusion in the first place? It's not like tailors have trouble distinguishing themselves from carpenters, or actuaries from hedge fund managers, even though some of the skills and thought processes are shared in each case. That's the obvious explanation—shared skill sets, or at least similar ways of looking at the work. A piece of code or an application is very clearly designed, and there is a certain balance of the creative and the pragmatic that spans these creative disciplines, from graphics and web pages to JavaScript and injection molding.

The cheap physical prototype is the ID equivalent of publishing an application every month, and has the encouraging corollary of convincing clients to accept things like IDEO's cobbled together sketch models, made of markers, clothespins and Scotch tape, as reliable examples of real conceptual progress. It's doubtful that this type of rough equivalence would have been acceptable output before the advent of digital design taught decision-makers that the abstract can be as useful as the real.

A more subtle but maybe more useful explanation is that digital creation has borrowed heavily from physical creation's paradigm. Part of what attracts so many clever minds to work in the digital realm is that so much there is unprecedented. The modern computer didn't exist until the 1970s, and most of the jobs held by my fellow conference attendees didn't have names until the 90s; that's common understanding. What's less apparent is that this generates an endless queue of new applications needing names, modes of interaction and understandable descriptions, and one of humanity's enduring characteristics is its tendency to describe the new in terms of the old.

The clearest example of this might be the Desktop paradigm that governs practically every PC's GUI since 1984: information is sorted into "documents," which are "filed" into "folders," unless they're thrown in the "trash," and so on. On a functional, circuit-based level, none of this is actually happening, but it sounds so much nicer than saying "these bits get their values changed to this," and it's more useful to the humans using them. The fact that a computer doesn't have a desktop and a video document isn't actually a printed piece of paper is kind of beside the point. This tendency to borrow extends far beyond operating systems. Re-purposed terminology is pervasive enough in information technology that we can easily forget that an "object" once had to occupy physical space, "hardware" was used to hold houses together, and an "engineer" was someone who built war machinery. On top of this, it's worth remembering that terminology is not just names. Any anthropologist can attest to the power language has to shape thought processes and behaviors, and that it is not just a way of communicating, but a way of perceiving.

Language-based perceptions are shared ones, and have proven ever useful in the development of virtual tools; especially interfaces. Some smart interface designers have noted that no interface is really intuitive; it can only be familiar. Since intuition is based primarily on past experience rather than any inborn sense of how things work, creating a virtual world that works in a recognizable fashion, similar to the physical one, is by far the most logical choice.

The digital world is not like the real, of course, and the degree to which it resembles the real is purely a function of the labors of its designers. Where this gets us into trouble is when we try to take the analogy too far, or forget that it is an analogy to begin with.

Software Developers Don't Have to Cut Steel
The digital world is not like the real, of course, and the degree to which it resembles the real is purely a function of the labors of its designers. Where this gets us into trouble is when we try to take the analogy too far, or forget that it is an analogy to begin with. In the case of the conference I was attending, this became crystal clear in two ways: the above-mentioned semantics problem of describing my job, and later on when trying to speak in universal terms about the design process. The assumption that the creative process is the same in the digital and physical worlds is pervasive.

In many respects, it's a correct assumption. As an industrial designer I'm frequently called upon to summarize the steps our studio goes through in developing a new product, and I usually give something like this as an answer:

1. Examine the user and the use
2. Define the constraints on possible solutions
3. Get all the ideas in your head down on paper
4. Flesh out the most promising ideas, prototype and review them
5. Improve these designs based on review
6. Pick the best, detail it and build it

Describing this process to, say, a software developer elicits nods of understanding, because this is quite close to how most of the ones I've met describe their own process, even down to the terms used. Web developers make prototypes. A software development cycle is a "build." What these processes share at their core is a flow of concept from general to specific, in which the designer starts the process needing to generate a multitude of unproven ideas and winnows them down to a workable solution through constant review and refinement. This is the heart of any design process, this hand-off from imagination to logic. The idea that it's truly universal only falters under deeper scrutiny.

June's conference was an excellent environment for employing this sort of scrutiny, since much of it consisted of small group discussions among designers of both camps. A good example of the limitation might be an informal presentation one software QA guy gave on Agile: a broad-sounding but actually very specific method of project management based on frequent production and continuous self-adjustment. Agile is initially a terribly exciting concept, lush with the promise of taking the mundane process of daily development issues and recasting them in the exuberant light of a sprint to a gleaming future. Those attendees who had experience using it spoke knowingly of the difficulties in convincing hidebound management of the good sense of Agile, but also enthusiastically of its success and joy once adopted. It was presented not explicitly as a software development tool, but as a general method of design process management, and I was enthralled. My mind skipped through my own process as he spoke, trying frantically to find the linkage points between my work projects and the techniques being outlined for me.

They were few and disappointing. The fundamental idea behind Agile is publishing a complete new product every month, and then modifying it continually. Desirable new features are added to a list, which is regularly re-prioritized, pushing the most coveted to the top and leaving things we want but can't afford or have time for languishing at the bottom. This works in software development because the "product" is a virtual entity that can be repeatedly created and released on the world, then modified and re-released at a future date.

Industrial designers and those in related disciplines will immediately see where this starts breaking down when you try and apply it to the physical world. Unlike software, web sites or applications, the step between a finalized concept and a manufactured good is a very large one—frequently the largest in the entire development cycle. Going into a production plan that relies upon a mantra of "finalize then modify" costs too much. The development of physical products has a virtual portion, of course, larger these days than at any point in the past. Sketches, 2D renderings, surface models, CAD, and production drawings are all weightless in the same sense that software is: although they embody value due to the skilled labor that went into their development, they are endlessly modifiable, at no greater cost than what went into their initial creation.

Physical products require physical assets though, and therein lies a significant difference. There is no equivalent in the digital world of "cutting steel," a loaded and slightly fearsome phrase for those industrial designers who dirty their hands with the realities of manufacturing and production. Conversely, there's no equivalent in the hard goods world of a window popping up on your screen, informing you that an update is ready to download. So while digital and physical design both reach a point of virtual finality, the industrial designer's is merely a representation of the real one to follow, sometimes many months and hundreds of billable hours later.

The necessity of a hard, expensive transition from the virtual to the real is only one of many significant ways in which ID differs from virtual design, but the trend toward erasing these distinctions is popular.

A state of slight denial
Much of this is obvious stuff to Core readers, I suspect, and yet we all seem to dwell in a state of slight denial—Agile is just the latest of many improvements that have been presented as having potential in both the concrete and weightless worlds. The presenter at the PDMA-PMF conference, when queried more directly, offered that he'd certainly heard of physical product development utilizing Agile, but couldn't come up with an example. This sequence is all too common: the optimistic assessment that a solution is broad, followed by disillusionment once we get down to brass tacks.

It's very seductive to try and draw these disparate disciplines together. At its most visceral, this appeals to the human desire to cast the new and complex in terms of the older and recognizable, and so it is comforting to think of the software engineer and the GUI guru as modern manifestations of Da Vinci with his pen or Eiffel poring over his drawings. The analogy is apt, but limited, and in my own experience, limiting. As modern economies become ever more weightless, replacing industry with technology and service, it's important to remember that what's true of the younger may not be true of the elder.

The necessity of a hard, expensive transition from the virtual to the real is only one of many significant ways in which ID differs from virtual design, but the trend toward erasing these distinctions is popular. Interface design is another decent example, in which the toolbar on an application is considered equivalent as a design challenge to the interface bezel on a microwave oven. Texts on good application and web design are full of warnings against taking too many design cues from the physical world, and rightly so. One of the hallmarks of good virtual interface is a recognition that things are possible digitally that aren't possible elsewhere, and that a sophisticated user is ready to take advantage of that. Coming to that conclusion takes a leap of understanding based on long use of virtual applications; an understanding that no matter how many paradigms we try to borrow from the physical world, the virtual one feels different. The tragedy is that the ones who do the actual designing understand how different they are, but those hiring them and directing them may not.

Interaction Design has sidestepped many of the pitfalls by focusing on the one element that is truly common to both physical and digital interaction: the user.

Learning to Let Go
This doesn't remove the possibility that the influence can move in the opposite direction. As virtual design seeks to maximize the advantages of being freed from the constraints of the physical, lessons are discovered that have bearing in the accelerating physical world. Agile, for example, while not generally applicable to industrial design, does have a parallel in the recently popular strategy of "getting physical fast," wherein product designers are encouraged to move to physical prototypes early in the development cycle rather than later.

This is the sort of move that would have been economic suicide a generation ago, but with the advent of relatively cheap rapid prototyping it's becoming an accepted part of the ID canon. The cheap physical prototype is the ID equivalent of publishing an application every month, and has the encouraging corollary of convincing clients to accept things like IDEO's cobbled together sketch models, made of markers, clothespins and Scotch tape, as reliable examples of real conceptual progress. It's doubtful that this type of rough equivalence would have been acceptable output before the advent of digital design taught decision-makers that the abstract can be as useful as the real.

Another clever child of this courtship is the young field usually known as Interaction Design. IxD has sidestepped many of the pitfalls of assumption mentioned above by focusing on the one element that is truly common to both physical and digital interaction: the user. Where industrial designers might try to shoehorn a physically appropriate interface onto a digital product, and software developers do the opposite, interaction designers are trained to look at a process independent of its physicality or virtuality, at least at first. By recognizing that neither side of the divide is going to get it right every time, IxD can frequently offer more elegant and effective solutions to a cross-disciplinary team than a more traditional designer would.

In a broader analysis then, there is good use in reversing the direction of paradigm borrowing, or at least there will be in the near future. It's a kind of payback in the most positive sense, if you think about it: where once physical manufacturing showed digital the value of emulating the real world, now the digital can show the physical the potential in detaching from it.

 

 

Carl Alviani is an industrial designer and design journalist, after spending his rowdy youth as a structural engineer, Peace Corps Volunteer, high school science teacher, materials researcher and art furniture builder, in roughly that order. He's since moved to Portland, Oregon, where he indulges to excess in the legendary local beer and produce, commutes on his Bianchi 9-speed, and works on projects large and small as a staff designer for product consultancy FlatHED, Inc. He can be reached at carl[at]flathed[dot]com.