Whenever I’m designing anything, I always keep in mind this quote from Eero Saarinen:
Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.
Whatever you’re working on isn’t an end in itself; it’s always part of something bigger. That bigger thing may be out of scope for the project, but it influences the project. When an architect designs a building, the street grid informs the structure and form of the building. Whenever I work on a navigation system for a company’s website, I must look at other websites in the industry (i.e., the company’s competitors, partners, customers, etc.)
In other words, context matters in design. Nothing ever exists in isolation, and you can’t do a proper job if you don’t consider the forces surrounding the project. This is all design 101; Saarinen’s admonition is printed on the wall in one of the IxD studios at CCA.
Plaque above the entrance to Disneyland. Photo by Cburnett via Wikimedia.
I’ve designed digital experiences for over twenty-five years. In that time, I’ve worked with many different teams. Some have succeeded, while others haven’t. Often, success comes down to leaders who can articulate the vision and direction for the project to bring clarity and alignment. I call this “The Big Picture.”
The Big Picture doesn’t have to be an actual picture; it could also be a description, with words. (Such as the plaque above.) That said, a clear diagram can move mountains. For example, one such (simple!) diagram helped save Apple from near-death at the end of the 1990s.
Many design and product teams still work without seeing The Big Picture. More often than not, they’re beset by conflicts with other groups, duplicated effort, mis-prioritization, and more. Most of these folks are excellent professionals. But lacking clear direction, they end up working at odds with each other.
That said, The Big Picture doesn’t need to come from the top. Anyone can explain their understanding through drawing. They can then show the picture to others and ask clarifying questions:
San Francisco from the hills over the East Bay, where my family and I went hiking for a late-afternoon 4th of July picnic.
The most crucial measure of success for a design project is the degree to which it serves its intended goals.
Projects come about because an organization invests time and resources in changing something in the world; it could be migrating a key system to a new platform or launching a website to sell a new product. More often than not, designers are brought in to “spruce it up.” Alas, they often join the project too late, when major decisions have been made.
It’s a mistake — but understandable. Talking about look-and-feel is easy; talking about fitness-to-purpose is hard.
This comparison offers a great illustration of a design principle we covered in the fourth edition of the polar bear book: structure changes more slowly than look-and-feel.
Visually, these two screenshots look quite different. But they express the same conceptual models: a file/folder metaphor (and object-container relationship), windows that set aside portions of the display, a menu across the top of the screen (with the same menu items, even), etc. These structural constructs have endured for decades.
However, their presentation has changed as technologies and public tastes evolved. The original Macintosh featured a 512 x 314 pixel black-and-white display, which imposed many constraints on the system’s visual style. As computer displays became more capable, designers had more leeway with the presentation layer. This is the system in the early 2000s:
Again, very different visually — but the underlying structure is recognizable. A user from 1984 would have little trouble learning the newer version three decades later.
As I’ve mentioned before, digital products don’t change uniformly; they manifest pace layers. Changing visuals is cheap; changing the underlying structures is expensive. Users accept visual changes more readily than structural changes. As a result, designers and stakeholders must take greater care when changing the structure of digital products.
A few weeks ago, I saw a meme that resonated with me. It had the format of a survey question, and it went something like this:
Who initiated your company’s digital transformation?
A) CIO
B) CTO
C) COVID-19
Cue nervous laughter: all-too-real. Our response to the pandemic has wrought major changes. For one thing, everyone who can do so is now working from home. Businesses are scrambling to figure out how to best serve their customers in this new reality. There’s also a palpable sense that many of these changes will persist after the immediate crisis passes. As a result, many companies are looking for new ways to provide value over digital channels.
Most recognize that there are two aspects to digital initiatives. On the one hand, there are technical considerations: selecting and configuring infrastructure, developing applications on that infrastructure, and so on. We can think of these as the “how” of the initiative: How will we serve these customers? Should we host systems on our premises, in the cloud, or some kind of hybrid solution? Should we develop solutions internally, or should we buy an off-the-shelf product? Etc. These types of questions have traditionally been the domain of IT teams.
Designers gather input from various sources that affect the direction of a project: There’s bespoke research around the problem space, relevant case studies, regulators (both external and internal), subject matter experts, validation sessions with end users, etc. But there’s one entity that tends to have more influence on the direction of the project than others: the client.
By “client” I mean the entity that has commissioned the design project — i.e., the person or team who is paying the designer to focus his or her attention on the problem at hand. The client has money and reputation at stake; the designer has a contractual obligation to deliver results. The client is tasked with changing the state of whatever is being designed. “We are at point A, and need to get to point Z by X date.” The designer is there to shepherd that transformation through designerly means; that is, by manifesting key decisions in ways that reflect intended changes so they can be tested against reality.
The designer has an important responsibility in creating these feedback loops, but the client ultimately owns the results. This is obvious when the designer is engaged as a consultant – i.e., not an employee of the client’s organization — but is no less true when the designer is an “innie.” Many internal design teams don’t “own” the things they’re designing; they work with counterparts in other parts of the organization who have bottom-line responsibility for the thing being designed.
Charles Eames’s sketch of the design process. Image: Eames Office.
The client-designer relationship is central to the design process. Understanding the dynamic of this relationship, and knowing what each party is expected to bring to the process, is key to success. That said, it is up to the designer to ensure that directions are clear. In architectural projects, these directions are often manifest in the form of a brief, or architectural program: a document that lays out the requirements for the project.
The content for this brief must ultimately come from the client, but is formulated in close collaboration with — and often led by — the architect. Architects shepherd what is an initially vague set of requirements towards something more specific and actionable, much like they shepherd design artifacts. The brief is a sort of meta-design artifact that is also designed. Given its importance to the project, the designer and the client must develop it together.
Successful design projects call for relationship-building among all parties involved. Few relationships are as important to the success of the project as that between the client and the designer. At best, these relationships are true partnerships, with both parties having a healthy respect for what the other brings to the project. That said, both parties can’t be expected to have the same degree of understanding of this fact. While this may be the one time in his or her career that the client will be working with a designer, the designer will work with many clients over time. Because of this, it behooves designers to understand the client-designer dynamic and create the conditions necessary for these relationships to be fruitful.
Last weekend I had the opportunity to take my kids to see an exhibit of the work of Charles and Ray Eames at the Oakland Museum of California. The Eameses are among the most famous designers ever, so little of the work on display was unfamiliar to me. Still, seeing so much of it together in one place was inspiring and enlightening.
The Eameses had a compelling mix of rigor and joie de vivre that has universal appeal. The show captures the playfulness of the resulting work. (My kids were a bit apprehensive about going to see a museum exhibit but got into it once they realized some of the items on display were toys they could play with.)
Three ideas stood out to me in this visit that I thought worth sharing. They apply to design in all domains.
Framing is a creative act
Careful composition and selection — determining what to leave out of a problem domain — opens up new ways of understanding and approaching familiar problems. As Brian Eno has written, “A frame is a way of creating a little world round something… Is there anything in a work that is not frame, actually?”
So much of the Eames’s’s work was about creative framing of ordinary things. In their myriad photographs, framing was the central (and literal) creative gesture; Powers of 10 moves the frame up and down levels of granularity to change our understanding of our place in the universe; the Case Study Houses re-frame the materials, construction techniques, and aesthetic of housing.
Accommodate a range of experiences
In the part of the show that presented the Eameses’s Mathematica exhibit, a quote from Charles Eames stood out to me; it reflected their aspirations for the exhibit. He said, “[Mathematica] should be of interest to a bright student and not embarrass the most knowledgeable.”
A physical model of a mobius strip, part of the Eameses’s Mathematica exhibit. Image by Ryan Somma CC BY-SA 2.0, via Wikimedia Commons
The idea of accommodating a range of experiences is very important, and in some cases, challenging. Sometimes we must design for users that have very different perspectives and degrees of experience. This calls for 1) a solid understanding of the problem domain, 2) maintaining a beginners mind, and 3) testing and iterating.
It’s structure all the way down
I’ve always been inspired by the breadth of the Eames Office’s output. They excelled in film, graphic design, industrial design, architecture, exhibit design, and more. Beyond the obvious joy the Eameses got from experimenting with media, materials, techniques, and craft, the unifying conceptual drive behind all of this work was an acknowledgment that it was all underpinned by structure.
A building has structure. House of Cards — a delightful toy that consists of playing cards with carefully placed slits that allow them to be interconnected with each other — has structure. So does a chair, and a film. Even given the wide scope of their work — and the fact that most people saw them as “designers” — Charles Eames saw himself as an architect. “I can’t help but look at the problems around us as problems of structure,” he said, “and structure is architecture.”
Media theorist Neil Postman (1931-2003) said communication happens in semantic environments. This is a useful concept for us to understand how people collaborate meaningfully. Let’s look at what these environments are and how they work.
Many of us think communication is something that happens like a game of table tennis: One person says something, another person listens, processes what has been said, formulates a response in their mind, and then utters the response. This restarts the process: the other person listens, processes, formulates, responds. Back and forth, over and over again.
Instead of being like table tennis, Postman says, communication is something that happens to us, much like growth happens to a plant when it’s exposed to an environment that includes sunlight, water, and nutrients. You can think of those things as the plant’s physical environment, which makes its growth possible.
Communication, too, requires an environment that has particular features. They include the social relations between the actors that participate in the communication, their goals in the interaction, and the particular vocabulary they use in that situation. Postman calls this set of conditions the semantic environment the conversation happens within.
You may have heard that dogs and cats only see in black and white. That’s wrong; these animals are dichromatic, which means they have limited color vision. What is true, however, is that their vision is different from ours. Other animals, such as some bats and rodents, are indeed monochromatic: they only see in black and white and shades of grey.
Before you start feeling smug, consider the limitations of your own sensory system. Some other animals, such as boa constrictors, can see infrared light, which is invisible to you and me. And you know about dogs’ sense of smell, which is much more refined than ours.
The point is that we don’t perceive the world as it is, we perceive it as our senses allow us to see it. Our sensory system presents to us an abstracted view of reality. (This suits me fine; our sensory system has evolved to allow creatures like ourselves to survive and thrive in environments like ours.) And on top of this already abstracted view, we layer another abstraction: language.
