[ 3] Evenson, Shelley. “Designing for Service: A Hands-On Introduction.” Presentation at CMU’s Emergence Conference, Pittsburgh, Pa., September 2006.

[ 4] Rheinfrank, John. “The Philosophy of (User) Experience.” Presentation at CHI 2002/ AIGA Experience Design Forum, Minneapolis, Minn., May 2002.

September + October 2008

[ 5] Dubberly, Hugh, and Paul Pangaro. Joint course development, Stanford. 2000–2008.

facturing, and distribution. A mistake in design multiplied thousands of times in manufacturing is difficult and expensive to fix.

The realities of manufacturing led to certain practices and in turn to a set of values or even a way of thinking. In the “modern” era, design practice adopted something of the point of view or philosophy of manufacturing—a mechanical-object ethos.

Now as software and services have become a large part of the economy, manufacturing no longer dominates. The realities of producing software and services are very different from those of manufacturing products.

The cost of software (and “content”) is almost entirely in planning, preparation, and coding (the cost of design). The cost of tooling, materials, manufacturing, and distribution is small in comparison. Delaying a piece of software to “ perfect” it invites disaster. Customers have come to expect updates and accept their role as an extension of developers’ QA teams, finding “bugs” that can be fixed in the next “patch.”

Services also have a different nature from hardware products. “Services are activities or events that create an experience through an interaction—a performance co-created at point-of-delivery [ 3].” Services are largely intangible, as much about process as final product. They are about a series of experiences across a range of related touch points.

Just as manufacturing formed its own ethos, software and service development is also forming its own ethos. The realties of software and service development lead to certain practices and to a set of values or even a way of thinking. Emerging design practice is adopting something of the point of view or philosophy of software and service development—an organic-systems ethos.

resenting qualities or dimensions, which change across each era and characterize it.

The eras are framed as stark dichotomies to characterize the nature of changes. But experience is typically more fluid, resting along a continuum somewhere between extremes.

John Rheinfrank provided a broad summary of the change, which may serve as an introduction and an overview [ 4]. He described a change in worldview, similar to the change in ethos described above.

From (escape the past) Mechanistic worldview

Landscape depletion Surface novelty Detached expert Tangible assets Consolidation

To (invent the future) Ecological-evolutionary worldview

Landscape renewal
Evocative structures
Collaboration
Intangible assets
Flow

Adapted from John Rheinfrank

We may expand Rheinfrank’s model to describe how things come to be and the role of designers and their clients in the process.

interactions

Models of Change

Several critics have commented on facets of the change from mechanical-object ethos to organic-systems ethos. This article brings together a series of models outlining the change and contrasting each ethos.

The models are presented in the form of an “era analysis.” Two or more eras (e.g., existing-emerging eras or specified time periods) are presented as columns in a matrix with rows rep-

Mechanical-object Organic-system

Economic era Industrial age Information age Paradigm author Newton Darwin

Metaphor Clockworks Ecologies

Values Seek simplicity Embrace complexity Control Top-down Bottom-up Development From outside From inside

Externally- Self-assembled organizing

Made Grown

Author Facilitator

Deciding Building agreement Owner Steward

Request for approval Conversation

Almost perfect Good enough for now

More deterministic Less predictable Completed Adapting or evolving Editions Continuous updating

Adapted from Hugh Dubberly and Paul Pangaro [ 5]

Designer as
Designer’s role
Client as
Relationship
Stopping
condition
Result
End State
Tempo