Design and engineering
By Ian Curry
Photo: Cyrill, sxc.hu
My dad is an engineer. Typical of his kind, he is also a collector of small, practical curiosities. As a kid, I would go through his desk and marvel at these: a bolt from the Golden Gate bridge; a lug of silicon; a vacuum tube from an old radio. The most fascinating was a wafer of circuits from some facility he'd visited in the '80s. This was back before chips receded into sub-micron depths, and I remember staring, as if into space, at the labyrinth of tiny circuitry. To think that anyone could have planned something so complex and well-ordered was awe inspiring. I had no real awareness of design at the time; it was years before I came to think of myself as a designer, and even more time before I realized that there are other kinds of designers that do things like lay out circuits. While these two breeds of designer are often seen to be no more akin than two random Smiths, I believe there's more to it. As anyone who has ever tinkered with an old BMW engine or looked out on to the wing of a jet can attest, near pure response to engineering requirements can sometimes deliver just as much pleasure as a more intentionally aesthetic design process. Clearly there are differences between engineering and visual design in terms of both the work, and ways of working. As a designer with a relationship mostly to the tradition of visual design, I have recently begun to wonder what exactly those differences are.
As anyone who has ever tinkered with an old BMW engine or looked out on to the wing of a jet can attest, pure response to engineering requirements can sometimes deliver just as much pleasure as a more intentionally aesthetic design process.
Given the longstanding intellectual border war between art and design, it's curious that there is not an equal amount of discussion on the overlap between design and engineering. In part, this may be because the difference between design and engineering is seen to be largely a settled matter: designers make things look good; engineers make them work. In this neatly divided world, the designer descends from the artist. Tibor Kalman framed this view eloquently back in 1990, declaring the designer as "the representative almost a missionary, of art, within the world of business.1" As much as I've always wanted that phrase on my business card, Kalman's view of design here is Romantic, both in its contrast of art to commerce, and in its suggestion of the near holy sanctity of the designer's "missionary" creative spirit. Just as this traditional view creates a stark contrast between the designer and business, it also sets apart the designer and the engineer, who presumably descends from the scientist. Ultimately, the traits that are seen to divide engineering and visual design are based in foundational stories about the irrational and rational sides of human nature itself. The professions are avatars of the right-brain, left-brain split; Apollo and Dionysius; Othello and Iago. While these are powerful archetypes, I believe that after years of close coexistence, their DNA has begun to blend. And in mutation, there is hope.
As such, the places where visual design and engineering overlap are the best spots to study what both unites and divides them. It's in places like this that you'll find people (few as they are) like Peter Rice. Rice was the celebrated building engineer who worked with Renzo Piano, Ove Arup, and others to make possible an uncanny number of the world's most unique structures, including the Sydney Opera House and Centre Pompidou. His brilliant autobiography, An Engineer Imagines, provides one of the most considered looks at the role of an engineer operating in close proximity to visual (or in this case architectural) design. Written just before Rice passed away in 1995, An Engineer Imagines is one of those very rare books that succeeds in conveying a certain retrospective clarity and wisdom that only comes at the end of a life like Rice's—a life of constant learning and exploration near the boundaries of his profession.
Subjective vs. objective responses to a problem
Renzo Piano, perhaps Rice's closest collaborator, once described Rice as "like a pianist who can play with his eyes shut; he understands the basic nature of structures so well that he can afford to think in the darkness about what might be possible beyond the obvious.2" Rice was trusted for a certain genius that created design possibilities. Far from the notion that engineering robotically enacts what is asked of it, Rice's engineering plays nearly as strong a role in the form of the buildings as Piano's designs. Rice describes being often called an "Architect Engineer," (Rice, 71) but while he acknowledges the accolade, he also resists it as a flawed definition. The title, Rice explains, ignores the fact that there are fundamental differences between the tasks and processes of designers versus engineers. Designers, in Rice's view, "work essentially from within themselves. They respond to a design challenge by seeking to understand how they respond to the context and essential elements of the problem: their response is essentially subjective." Conversely, "...the engineer, when faced with a design challenge, will transform it into one that can be tackled objectively. As an example, an engineer might seek to change the problem into an exploration of how to exploit a particular material completely within the context of architecture. Thus, the Lloyd's of London building became an exploration of the use and properties of concrete. And the engineer's contribution was to try to make the structure an essay on expression in the use of concrete." (Rice, 70-71)
Rice describes engineers often receiving solutions fully formed after a period of rumination. In Rice's account, this owes to a fundamental characteristic of engineering process: engineers are trained to begin not by thinking of solutions, but constraints; successive constraints are applied until only one solution is possible. A good solution owes at least as much to the proper design of constraints as to the eventual solution they imply.
As Rice returns to repeatedly, arriving at that point where a problem can be "tackled objectively" is the essential art of being an engineer; it is the ability to set boundary conditions and properly frame the problem. As a result of focusing on objectivity, however, Rice describes engineers often receiving solutions fully formed after a period of rumination. In Rice's account, this owes to a fundamental characteristic of engineering process: engineers are trained to begin not by thinking of solutions, but constraints; successive constraints are applied until only one solution is possible. A good solution owes at least as much to the proper design of constraints as to the eventual solution they imply. The process is not that foreign to a visual designer who might evaluate a UI idea by client requirements, user needs, testing results, and the burden of design convention. It does often seem that the way the cat eventually gets skinned really is the best way, if not quite objectively than at least defensibly. However, while constraints may eventually come strongly into play, few visual designers would focus on constraints before exploring possibilities. More commonly, the "funnel" approach is applied, in which a very broad brainstorm is eventually filtered down.
Of course, no engineering solution is truly objective. It's likely that even two engineers of equivalent skill might come up with different but equally valid solutions to a problem. The situation is further complicated when engineers become responsible for engineering towards subjective requirements. When I worked at frog, we once had a client send the whole project team a box of HP-12c calculators because he liked the solid, responsive feel of the buttons, and wanted to see something similar on the product we were developing. Within hours, I remember seeing the venerable Robert Curtis, head of our engineering group, disemboweling the 12C and divining the importance of each gasket and post in creating the calculator's distinct feel. Engineering "feels" is probably not something commonly part of the engineering school curriculum—it is, essentially being able to add emotional response as a fourth vertex on the traditional "iron triangle" (cost, time, and quality) that commonly frames engineering requirements. Likewise, when Rice describes creating the floor trusses for Pompidou, the solution is structurally sound, appropriate in terms of weight, but also visually appealing in allowing more light to come through than an alternative design of equivalent strength but greater visual bulk. Subjectivity itself, in the sense of an end user's perception, is a requirement for visual designers in a similar way that cost is a factor for engineers.
Subjectivity, in the sense of an end user's perception, is a requirement for visual designers in a similar way that cost is a factor for engineers.
While initially framed as a fight, I believe the more recent tendency of design's relationship with engineering is that of mutual seduction. At places like the Brooks Engineering Design Center at Cooper Union, the stated mission is to "create a synergy of powerful computers, good software and people: students, faculty, engineers from industry, business people, artists, architects and even poets.3" On the other side of the aisle are systematic architects and visual designers like Joshua Prince-Ramus—who in a recent TED talk described the design of the Seattle Public Library in terms of what he calls a "hyper-rational" approach4. As an example of his approach, Prince-Ramus first shows a diagram developed with the library design committee that apportions space and priority to each intended function of the library. In the following slide, he shows a blocky prototype of the final building. The prototype is essentially a giant bar graph; the sizes of the various levels corresponding directly to the library's priority graph. The building so directly and transparently reflected the library's priorities that when the public accused the architects of designing based on whim and ego, the librarians came forward to defend the building as an accurate reflection of both their own needs, and the anticipated needs of the library's users. Hyper-rationality, essentially an engineering approach to design, attributes an almost inevitable quality to its products. This is reassuring to both designers and clients. Of course, one doesn't go from a bar graph to a building without a robust measure of creativity, but it becomes hard to argue with a building whose design is based on such lucid logic.
The focus on constraint and logic familiar to the engineering process
presents inspiring possibilities for visual designers. And from there,
it's a short step to the even more fascinating possibility of designing
the rules themselves. During the "Information Aesthetics" lecture
series several years ago; I remember being struck by Pentagram's Lisa Strausfeld
describing her interest in assembling RFPs for just this reason. Giving
consideration to how much rules ultimately influence solutions makes rules
themselves interesting. Rice's work strikingly illustrates how the creativity
of solutions is often proportional to the difficulty of the task's constraints.
I'm sure the designer of that wafer of circuits on my dad's desk faced
a set of rules that were no less daunting. As e.e. cummings wrote: "Always
the beautiful answer who asks a more beautiful question.5"
1 Tibor Kalman and Karrie Jacobs. "We're Here to be Bad." Print Magazine. Jan./Feb. 1990
2 Rice, Peter. An Engineer Imagines. London: ellipsis london limited, 1996. 179.
5 cummings, e.e. Poems 1923-1954. NY: Harcourt, Brace and World, Inc. 1954. Note: also, reportedly a favorite quote of Joshua Prince-Ramus: fastcompany.com/magazine/95
Ian Curry is an Interaction Designer at Local Projects. Formerly at frog design, Ian has also recently taught courses in interaction design at Parsons and Pratt. His dad, Joseph J. Curry Ph.D., is an engineer.