It is common to hear that people in organizations resist change. In reality, people do not resist change; they resist having change imposed on them.
– Fritjof Capra and Pier Luigi Luisi, The Systems View of Life
Every design project is a change initiative. Some are overtly so, while others are more subtle. In the more overt ones, organizational change is a stated objective/driver of the project. In the subtle ones, the work is a manifestation of an organizational change.
Consider a project for a website redesign. The redesign is motivated by a desire to change something about what the organization does or how it works. Perhaps the company is reorganizing, launching a new product, or rebranding. All entail change.
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.
Designers — at least the good ones — have a rare superpower: they can leap several levels of abstraction in a single bound. Among other things, this allows them to look at the form of a thing (a building, a kettle, a website) and get a sense of its constituent parts, the relationships between those parts, how those relationships help serve particular functions, and what those parts, relationships, and functions say about the goals of the entity that commissioned the thing — all without getting hung up on its “look and feel.” In other words, good designers can look beyond the tangible forms of things to the conceptual models they manifest. Some designers can even map out these models in ways that make sense to the rest of us.
Working with models is a key skill — perhaps the key skill — in 21st Century design. Today’s most important design challenges deal with complex, evolving systems. The parts of these systems we see and interact with (such as user interfaces) are only surface manifestations of deeper structures. It’s essential to understand the connection between these structures, the forces that call them forth, and the user interfaces that manifest them. You can’t skillfully intervene by acting solely on the surface.
However, many designers (and most stakeholders) want to work with screens, not models. Screens are things they can test and critique. Models? Not so much. It takes practice to see the tangible forms latent in an abstract diagram. Most of us lack the patience to acquire the practice. We’re drawn to screens because we can draw screens; they’re familiar, things we deal with every day. Models, on the other hand, are abstractions. They can be ambiguous and subjective and unfamiliar. This makes them hard to communicate. How do we begin to draw such a thing?
And yet, draw them we must. Only by understanding models can we effectively deal with fitness-to-purpose and second- and third-order effects, and thereby ensure design directions are strategically and ethically sound. Of course, this doesn’t mean we won’t work on screens at all. As I said, we can’t test models without manifesting them as tangible artifacts. But these artifacts must be rooted in a clear understanding of the underlying models, not the other way around. The ability to jump back-and-forth between models and their expression as UI requires training and practice. It’s an essential skill for today’s designers, and one I’m increasingly focused on learning and teaching.
Sometime during my school years, I learned how to write an outline. We’d been tasked with writing an essay. Our teacher showed us that we could either write from start to finish or think about what we wanted to write first. By considering the main points first, and what sequence they should be in, our essays would be more coherent and compelling.
It was hard. Putting words down as they came to us seemed easier; this outline business slowed us down. I resisted at first. With time, as we were assigned longer writing projects, the benefits of outlining became clearer. Writing an outline allowed us to see we were missing important points or had them in the wrong sequence. Outlining also helped us face the fact there were things about our subjects we didn’t yet understand; we had to do more research.
I re-learned the lesson of outlining during my final year of university when I took an elective oil painting studio course. I’d dabbled with different painting media throughout my life, and had always thought of oils as “grown-up” paints. I was excited to learn how to do it.
Students often want to know if they’re doing things the “right” way. They want to learn the “standard” way of making sitemaps, wireframes, storyboards, etc. Many are anxious about doing these things “wrong.” I tell them that although there are best practices, there are no strict rules for many of these things. The purpose of making any design artifact is to clarify and communicate intent. What’s “right” is what best articulates what they’re trying to do.
Recognizing what’s right requires practice, and that takes time. As professors, we aim to provide feedback so students can improve over time. Still, I suspect it’s no comfort to answer the question of how to do things “right” with “it depends.” Speaking with a student this week, I thought of a good analogy for what I’m trying to get across: Orwell’s six rules of writing.
A product may be redesigned for various reasons: competitive pressure, integrating an exciting new feature, a change in leadership, etc. Some of these reasons (such as the new feature) are integral to the product’s content. Others (such as the change in leadership) are part of the frame around the product. As a force in influencing the project’s direction, the frame can be as powerful as the challenge’s substance.
A metaphor for the frame’s power: Late last fall, I decided to lose weight. Coincidentally, my family needed to replace some broken bowls. I realized that IKEA sold bowls similar to the ones we use at home, but smaller. I bought some of the small bowls and started using them — along with a smaller spoon — for my breakfast. These subtle tweaks helped me trick my brain into eating smaller portions. With patience, exercise, and mindful eating, I eventually lost the weight.
Was it all thanks to the smaller bowl? No. But the bowl made it easier. My eyes measure the amount of food relative to the size of the bowl. Using a smaller bowl led me to see my “normal” portions differently. Food — the substance of the meal — is framed by the bowl. Smaller bowl = more food, even if the portions are actually smaller. The frame around a problem changes how we see the problem. When undertaking a design challenge, consider its frame along with its content.
As haphazard as lots of the design is, there does appear to be a goal: driving up in engagement. That makes sense, but where the real joy comes from is the batshit way this is approached.
The article highlights two features ostensibly designed to drive engagement: LinkedIn’s canned responses, which, according to the author, have produced “a terrifying world filled with reams of identikit comments that come across as inhuman and deeply insincere,” and its “add hashtag” feature. Most of the article focuses on the latter.
Being a designer, what you really signed up for is caring. I did a lecture for the Cooper Hewitt about their collection. When I looked at the collection, I thought, What do all these disparate objects have in common? I realized the common denominator is caring. What makes a design product different from other things is that people care more about the user as an individual, not as a consumer, but as a citizen.
Once you care about a person, you can’t not care about their context, right? You can’t have a healthy, vibrant person in a toxic community. And by extension, you have to care about their environment. You can’t have a thriving community in a toxic ecology.
We shift the idea of what design is about from the object and the immediate outcome to life itself—life-centered design, which is an understanding that we are not the center of the universe.
That’s really is it, isn’t it? The quality of the work will be completely different if designers truly care about the people they’re designing for.
Note this isn’t about being “user-centered.” It’s about understanding that our “users” exist in societies and ecosystems. If the thing we design serves user and business needs, but compromises their contexts, then it’s no good. Alas, we focus too much on the design of the parts and not enough on the whole. We value craft over philosophy – even though we, too, live in the same societies and ecosystems.
This interview is in support of Mr. Mau’s new book, MC24. I’m finding much inspiration in its pages; it’s a good salve for these dark times.
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.