Design

Elegant Simplicity

| Jorge Arango

When defining design principles for a project, someone in the design team will invariably suggest “simplicity.” The drive towards simplicity is understandable: simplicity is often cast as a desirable trait. Simple sells. Simplicity is the ultimate sophistication. Keep it simple, stupid.

But simplicity per se isn’t a good principle. Things can be simple and also inadequate — if you leave out the wrong things. Some things are inherently complex; reducing them to a simpler state can compromise their usefulness or sacrifice their essence.

In most cases what you want isn’t plain simplicity but a simplicity that is appropriate to the problem at hand. You want elegant simplicity: to do the most with the minimum resources (or components) necessary to achieve a particular outcome.

Elegant simplicity is graceful. It embodies efficiency and skill. It’s also hard, since it requires that you understand the system you’re working on and its intended outcomes. Once you do, you can ask questions: What’s essential here? Which components are critical? Where do I focus my efforts?

Appeals for elegant simplicity abound. Saint-Exupéry: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” Lao Tse: “To attain knowledge, add things everyday. To attain wisdom, remove things every day.” (Attributed to) Albert Einstein: “Everything should be made as simple as possible, but not simpler.”

These aren’t calls for us to hack about arbitrarily at problems. Instead, they speak to intelligent use of materials and ideas; to understanding the point beyond which simplification compromises desired outcomes. It’s a central principle for good design — and for life.

The Urgent Design Questions of Our Time

| Jorge Arango

George Dyson, from his 2019 EDGE New Year’s Essay:

There is now more code than ever, but it is increasingly difficult to find anyone who has their hands on the wheel. Individual agency is on the wane. Most of us, most of the time, are following instructions delivered to us by computers rather than the other way around. The digital revolution has come full circle and the next revolution, an analog revolution, has begun.

For a long time, the central objects of concern for designers have been interfaces: the touchpoints where users interact with systems. This is changing. The central objects of concern now are systems’ underlying models. Increasingly, these models aren’t artifacts designed in the traditional sense. Instead, they emerge from systems that learn about themselves and the contexts they’re operating in, adapt to those contexts, and in so doing change them.

The urgent design questions of our time aren’t about the usability or fitness-to-purpose of forms; they’re about the ethics and control of systems:

  • Are the system’s adaptation cycles virtuous or vicious?
  • Who determines the incentives that drive them?
  • How do we effectively prototype emergent systems so we can avoid unintended consequences?
  • Where, when, and how do we intervene most effectively?
  • Who intervenes?

Childhood’s End: The digital revolution isn’t over but has turned into something else

Framing the Problem

| Jorge Arango

Jon Kolko on problem framing:

The goal of research is widely claimed to be about empathy building and understanding so we can identify and solve problems, and that’s not wrong. But it ignores one of the most important parts of research as an input for design strategy. Research helps produce a problem frame.

A conundrum: The way we articulate design problems implies solutions. At the beginning of a project, we often don’t know enough to communicate the problem well. As a result, we could do an excellent job of solving the wrong thing.

Addressing complex design problems — “solving” them — requires that we define them; that we put a frame around the problem space. This frame emerges from a feedback loop: a round of research leads to some definition, which in turn focuses the next round of research activities, which leads to more definition, etc.

Framing the problem in the way described by Mr. Kolko — by using research to define boundaries and relevant context, and using the resulting insights to guide further research — is a practical way to focus ill-structured problems. It’s an often overlooked part of the design process, and — especially in complex problems — a critical one.

Problem Framing, Not Problem Finding

Four Types of Prototypes

| Jorge Arango

Prototypes are central to the design process; they’re the means by which designers establish the feedback loops that allow artifacts to evolve. But there’s a pitfall when discussing prototypes: there are different types and uses of prototypes, but only one word (“prototype”) to describe them. This unacknowledged variety can cause confusion and false expectations. Talking about prototype resolution and fidelity is as far as many designers go, but often that’s not far enough.

In a paper (PDF) published in the Handbook of Human-Computer Interaction (2nd Ed) (1997), Apple designers Stephanie Houde and Charles Hill resolve this issue by identifying four categories of prototypes, based on the dimension of the design project they’re meant to illuminate:

  • Role prototypes
  • Look and feel prototypes
  • Implementation prototypes
  • Integration prototypes

(Following quotes are from the paper.)

Role prototypes

Role prototypes are those which are built primarily to investigate questions of what an artifact could do for a user. They describe the functionality that a user might benefit from, with little attention to how the artifact would look and feel, or how it could be made to actually work.

In other words, this dimension is meant to cover the “jobs to be done” angle of the product or system. How will people use it? Would it be useful in its intended role? What other purposes could it serve for them?

Look and feel prototypes

Look and feel prototypes are built primarily to explore and demonstrate options for the concrete experience of an artifact. They simulate what it would be like to look at and interact with, without necessarily investigating the role it would play in the user’s life or how it would be made to work.

This dimension doesn’t require much explanation; these are prototypes that are meant to explore UI possibilities and refine possible interaction directions. (I sense that many people focus on this aspect of prototyping above the others; look and feel is perhaps the most natural target for critique.)

Implementation prototypes

Some prototypes are built primarily to answer technical questions about how a future artifact might actually be made to work. They are used to discover methods by which adequate specifications for the final artifact can be achieved — without having to define its look and feel or the role it will play for a user. (Some specifications may be unstated, and may include externally imposed constraints, such as the need to reuse existing components or production machinery.)

These prototypes often seek to answer questions about feasibility: Can we make this? What challenges will we face in producing such a thing? How will a particular technology affect its performance? Etc.

Integration prototypes

Integration prototypes are built to represent the complete user experience of an artifact. Such prototypes bring together the artifact’s intended design in terms of role, look and feel, and implementation.

As its name suggests, this final category includes prototypes that are meant to explore the other three dimensions. Their comprehensive nature makes them more useful in simulating “real” conditions for end users, but it also makes them more difficult and expensive to build.

The authors illustrate all four categories with extensive examples. (Mostly charming 1990s-era software projects, some of them prescient and resonant with today’s world.) A running theme throughout is the importance of being clear on who the audience is for the prototype and what purpose it’s meant to serve. A prototype meant to help the internal design team explore a new code library will have a very different form than one meant to excite the public-at-large about the possibilities afforded by a new technology.

The paper concludes with four suggestions for design teams that acknowledge this empathic angle:

  • Define “prototype” broadly.
  • Build multiple prototypes.
  • Know your audience.
  • Know your prototype; prepare your audience.

Twenty-plus years on, this paper remains a useful articulation of the importance of prototypes, and a call to using them more consciously to inform the design process.

What do Prototypes Prototype? (PDF)

Structuring the Problem

| Jorge Arango

Designers are increasingly dealing with more complex problems. The systems we work with often span both digital and physical domains. Requirements and constraints are more abundant and difficult to articulate. More stakeholders are affected. The workings of the system may be opaque to our clients and us.

One of the biggest challenges of working on such projects is that the problem we’re solving for isn’t apparent. This is not out of ill-will or incompetence; some problems are just difficult to pin down. In The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin define what they call ill-structured problems:

An “ill-structured” problem is a problem where the statement of the problem depends on the statement of the solution. In other words, knowing what you can do changes your mind about what you want to do. A solution that appears correct based on an initial understanding of the problem may be revealed as wholly inadequate with more experience.

Facing an ill-structured problem is difficult and frustrating. It’s also not uncommon. Complex design projects often start with a vague understanding of what the problem is we’re designing for, or perhaps we’re solving for several problems that appear incompatible. Solutions are often implicit in the way these problems are articulated.

To do a good job, you must clearly understand and articulate the problem(s) you’re seeking to solve. Stating the problem is the starting point for all that follows; it frames the work to be done. Poorly structured problems lead to poorly structured solutions.

Structuring the problem isn’t something you can expect stakeholders to do. It’s up to you, the designer, to ensure the problem is structured correctly. How do you do it? First, you acknowledge that the initial problem statement will be vague and/or poorly structured. You assume your initial understanding of the problem will be flawed. You then move to develop a better understanding as quickly as possible.

This requires iterating through artifacts that allow both designers and stakeholders to grasp new dimensions of the problem so you can set off in the right direction. The forms these artifacts take vary depending on the type of project you’re dealing with. (Concept maps work well for the types of systems I work on.) You want to establish processes that allow these artifacts to evolve towards greater clarity and focus.

This takes courage. Stakeholders and clients want answers, not vague abstractions. The process of clarifying the problem may point away from initial project directions. Because of this, delving in the problem-definition stage of a project can produce tension. But the alternative — getting to a high degree of fidelity/tangibility prematurely — can lead folks to fall in love with solutions to the wrong problems.

Designing Your Life

| Jorge Arango

When designing things to be understandable, coherence is an important goal. Perhaps it’s the ultimate goal. It is for me. I aspire to coherence in (and between) all aspects of my life: work, teaching, writing, family. Every day I ask myself: how can they come closer together? How can one inform the other? How can I generate the most value with the least waste?

I’m currently working on the systems studio class I’ll start teaching in a few weeks. I have several other projects going in parallel: a keynote speech I’ll deliver in February, client work, this blog. They all connect somehow. Invariably, there’s tremendous energy at the connection points. Themes emerge. I press into these themes, dig deeper. (“Emerge” is the right word — this is not a top-down process. Instead, the interests lead the way. I discover them by doing, by trying out new ways of being in the world.)

The last chapter of Richard Saul Wurman’s Information Anxiety 2 is titled “Design Your Life.” The following paragraphs from this chapter speak to me:

My opening line to my students, and a recurring theme in my classes, was that the big design problem isn’t designing a house for your parents or yourself, a museum, or a toaster, or a book, or whatever. The big design problem is designing your life. It’s by the design of your life that you create the backboard off which you bounce all your thoughts and ideas and creativity. You have to decided what it is you want to do each day.

There’s an Eddie Murphy movie in which he plays a soothsayer, and he makes the comment that you only have about 75 summers, 75 falls, 75 winters, and 75 springs. You only have 75 of everything, so you better make good use of them. Time is your only commodity — what else do you have?

If we are able to design our lives, wouldn’t the best result — the best measure of success, ultimately — be that every day is interesting? Most people don’t have enough interesting things in their lives, so in place of interest they try to accumulate money and power. But I think you’re going to be a better businessperson if you look at your life as a collection of hobbies, a collection of interests, not a matter of things you do during the day and things you do in the evening — or what you do during the day and what you do during the weekend. Think of everything you do as driven by and connected to your real interests, and it will affect everything you do.

Thinking about it as a design problem, as Wurman suggests, gives us agency. There are variables at play; our lives are ongoing prototypes of different configurations. Resistance — fear — manifests as habits we must overcome. Sometimes the work is a slog. The converse — joy, flow — is a clue to being on the right track.

Prototypes and the Used Universe

| Jorge Arango

The first Star Wars movie—now known as EPISODE IV: A NEW HOPE—came out in 1977. It was a blockbuster, with crowds lining up for blocks to see it. Part of its success was due to its mythologically sound story. But its aesthetic was also an essential element in its popularity. Two elements in particular stand out: its excellent (for the time) special effects and the richness of its environments. I’m particularly interested in the second of these.

Before A NEW HOPE, most “space” movies looked “new”; their props and ships and clothes all looked clean and “modern.” Think of the most artistically successful pre-Star Wars space movie—2001: A SPACE ODYSSEY—and its antiseptic “NASA” aesthetic. Star Wars didn’t look clean; it looked crufty. Its sets, costumes, and props looked as though they’d been around for a long time. The movie’s creator, George Lucas, described it as a “used universe.”

Take a look at C-3PO, one of the two robots at the center of the movie: Continue reading →

Hugh Dubberly’s Approach to Understanding Problems

| Jorge Arango

I’m a fan of Hugh Dubberly and the work of Dubberly Design Office. Not only have I learned much from Mr. Dubberly throughout my career, I’ve also had the honor of having him write the foreword for Living in Information and the privilege of teaching alongside him at CCA. A post on the Design Practices & Paradigm’s blog summarizes his career and approach to design, and includes this amazing list:

Dubberly’s approach to understanding problems is heavily influenced by Horst Rittel’s definition of simple and wicked problems. They key traits are listen here:

  • Simple problems (problems which are already defined) are easy to solve, because defining a problem inherently defines a solution.
  • The definition of a problem is subjective; it comes from a point of view. Thus, when defining problems, all stake-holders, experts, and designers are equally knowledgeable (or unknowledgeable).
  • Some problems cannot be solved, because stake-holders cannot agree on the definition. These problems are called wicked, but sometimes they can be tamed.
  • Solving simple problems may lead to improvement—but not innovation. For innovation, we need to re-frame wicked problems.
  • Because one person cannot possibly remember or keep track of all the variables (of both existing and desired states) in a wicked problem, taming wicked problems requires many people.
  • These people have to talk to each other; they have to deliberate; they have to argue.
  • To tame a wicked problem, they have to agree on goals and actions for reaching them. This requires knowledge about actions, not just facts.
  • Science is concerned with factual knowledge (what-is); design is concerned with instrumental knowledge (how what-is relates to what-ought-to-be), how actions can meet goals.
  • The process of argumentation is the key and perhaps the only method of taming wicked problems.
  • This process is political.
  • Design is political.

The whole post is worth your attention.

The “Magic” Behind the Curtain: Understanding the Design Process of Hugh Dubberly

High and Low Fidelity Prototypes

| Jorge Arango

One of the most challenging things about creating a prototype is determining what its level of fidelity should be. By “fidelity” I mean how closely it approximates a real artifact that end users would interact with. Lower fidelity prototypes are more abstract; they require greater leaps of imagination from people who interact with them. On the other hand, higher fidelity prototypes fill in the details, leaving little to the imagination. You’d expect the latter to be the best option, but that’s not always the case.

In his classic book Understanding Comics, Scott McCloud discusses the ability of the comics medium to harness the power of abstraction:

Something like this happens when you interact with a low fidelity prototype. Your mind starts filling in the details; you make the thing your own. This can be very valuable, especially in the early stages of a project when the design team only has a high-level understanding of their objectives. At this stage, the team is working in ambiguous conditions​; a low fidelity prototype can help the team reduce the ambiguity. On the flip side​, a high fidelity prototype is more likely to elicit feedback on the formal aspects of the experience: what it looks and feels like.

Determining the right level of fidelity for a prototype requires thinking about the objectives it’s expected to serve. With a lower fidelity prototype, you’re more likely to focus on the “big idea,” since there are few details to distract your attention. The challenge is that lower fidelity artifacts are more abstract, and many people have trouble with abstraction. A prototype can be of such low fidelity that people have a difficult time even imagining it as a thing in the world, at which point its usefulness is limited. You want a level of fidelity that’s appropriate for the stage of the process you’re in, and the sort of feedback that would help you at this stage.