1. The Nature of Problems

    Of course you should be skeptical of anyone who says they know anything about problems, but let’s back up a moment, and start at an obvious, and unfortunately often-forgotten place: that problems themselves have problems with them, because we forget the nature of problems. Problems are a material for design—graphic, industrial, interactive, etc., or even just straight up planning, like normal people would call it—and most of our preparation is to respond to or avoid problems. And despite all of this, those problems still, unfailingly, show up. There’s no such thing as a perfect plan. So, we roll with the problems. They have a grain: affordances and directions they want to be taken, so problems are worth thinking about from a high level. I’d like to try to do that by describing some of the mistakes I make when thinking about problems, and by expressing that the best way to go about working with problems is to try to corral them, rather than dominating them. The best approach is a willingness to be responsive to the nature of problems.

    Mistake #1: We forget there are two kinds of problems.

    The first kind are problems that reach full, reasonable, and logical solutions, because their answers are conclusive. Two plus three is always five, because it can be proven so. Better yet, the answer remains the same and context doesn’t really matter. That’s why math works and you can figure out calculations for physics in space while on Earth with a reasonable amount of certainty. Then, naturally, you shoot people into orbit in a tin can and get photos like this. I call these concrete problems. Aristotle, in all his writing about logic, called this domain a place where things can not be other than what they are. They’re consistent. Fixed. Concrete.

    But, most problems are not concrete, and must be addressed in a less than conclusive fashion. Context matters, and it’s best one understands it. For example, consider how difficult it would be to make a design for someone in a culture much different than your own. Chances are whatever you make isn’t going to fly, unlike that tin can that got launched into space.

    Aristotle’s described this other domain as a place where things can be other than what they are. They’re multidimensional. They shift and mutate. Things vary, because context matters. For instance, diplomatic negotiation strategy for one country doesn’t necessarily work with other nations. Internal communication software may work on one project and completely fail on a different project, even though it is the same company and people. I like to call these problems squishy ones. There is probably a better, more descriptive term, but I like squishy, because getting a hold of these problems is like trying to get a firm grip on a wet fish. It’s a temporary hold, and the problem has a will of its own, wriggling around all slimy and gross, trying to get away from you. Welcome to design.

    Mistake #2: Aspects of a problem are a little bit concrete and a little bit squishy, and we mistake one for the other.

    There’s another problem with problems: they usually are not totally concrete or squishy; they’re a mixture of both, and it’s damn hard to figure out which aspects are which. Out of all the disagreements I’ve had in work environments, I’d say half are from inefficient or unsuccessful communication (happens to the best of us), and the other half is from a disagreement or misunderstanding over whether a certain aspect of the job was squishy or concrete. I’ll use developing digital products as an example, since I’ve been working on that for the past couple years.

    Working with information on computers is a grab bag of problems. Concrete criteria determine whether or not the technology functions. Does the code run? Is there a bug? Squishy criteria determines whether or not that technology is “useful” and “works.” Is the code elegant? Did it feel right? Did it provide enough value for the $5 the customer paid?

    I suppose one of the biggest misconceptions about this sort of work and its problems is that development problems are strictly concrete and design’s are squishy. Sure, they’re weighted towards one quality or the other, but each is a combination of both. Developers make choices about database structure, development tools, and general programming approaches that are even more squishy than lots of design choices, because it’s an abstraction on top of an abstraction on top of another. Designers, on the other hand, have a set of concrete concerns that don’t get much mention: for instance, I had to change the value of a blue I was using in a comp last week because its contrast wasn’t high enough to be easily read by our visually-impaired users.

    Where I (and I bet lots of other people) get in trouble is mistaking one kind of problem for the other. For instance, it’s foolish to assume that choosing a database’s structure is a solution to pick up fully-formed rather than a nuanced decision to develop. I had to learn that the hard way after a lot of kind hand-holding from a patient developer. It’s more complicated than looking at performance and choosing the fastest way forward. It’s also about future-extensibility, human-readability, and all sorts of other stuff that I don’t know about. It’s a murky choice, just like most my design choices—a squishy choice I mistook for being concrete.

    On the other hand, I also got into trouble in the past for thinking concrete problems were squishy. Let’s revisit that blue comp I mentioned earlier. I thought color was a squishy choice tied up in emotions and branding, and they are to a certain extent, but an aspect of them is definitely concrete: either it has enough contrast for accessibility’s sake or it doesn’t. If it doesn’t, the aesthetic quality of the palette doesn’t matter much, because our team agreed early on that what we’re building needs to be accessible to as many people as possible.

    Anyway, watch out for the squishy/concrete flip-flop. I still constantly fall for this.

    Mistake #3: We think there are solutions when there are none.

    Allow me to rant for a moment.

    We’re a culture that values logic, resolution, and our own self-efficacy, so when we mistake a squishy problem for a concrete one, we then assume that the problem has a solution. The trouble is that squishy problems don’t have solutions.

    The presumption of an available solution is all over the place, and spreads the full gamut from supremely important problems to terribly mundane ones. One of the origins for this, as far as I can tell, is a certain brand of marketing: a classic way to sell a product is inventing a problem, then presenting your product as its solution. Once the sale is done, you’re absolved of responsibility, because all you had to do was make the sale.

    This method is hilarious when the problems are truly mundane, and obviously not problems. The informercial is the most ready example of this. For instance, check out some of these fail gifs taken from informercials. There’s a Tumblr blog full of them.

    The idea of having a solution for these problems is laughable here, but the same line of thinking has a middle ground: corporate communication and marketing.

    While infomercials are mostly harmless, and the worst marketing speak can do is waste money, this line of thinking can be damaging when more is at stake. For instance, look at this headline on NBC from just a few days ago:

    From race relations to gun violence, presidents often seek solutions after tragedies

    Now, this is an opinion piece without actual commentary by President Obama, but I still think it’s an accurate assessment of our culture’s view of problems: the problems are there, and they can be fixed, if we only could find the thing to do it. What kind of hubris makes one believe that they could ever do something to “solve” race relations and gun violence? Don’t get me wrong here: large amounts of work must be done to improve both of these damaged situations. And sure, this might seem like being nit-picky over words that mean the same thing, but I think words become clues to describe the way we think. And thinking a solution is necessary, instead of a response, does two really, really bad things:

    • It presumes that the most effective response to the problem comes from one place, and downplays that the issues are truly complex, with many stakeholders and influences which must be considered and included.
    • It presumes that the correct response is a one-and-done action—a silver bullet—rather than a communicative, iterative process.

    In my opinion, both assumptions undermine the success of whatever you do, because it immediately sets you off in the wrong direction, looking for something that doesn’t exist. Then, you give up when the search goes too long without bearing any substantial results. I’m no public policy expert, but my lack of expertise should speak to the severe disadvantages of this approach.

    Concrete problems have answers that are solutions, but the best one can hope for with a squishy problem is a temporarily successful response. Of course, no one wants to hear this from a politician about big ticket issues. I’m no dummy: a hearty portion of politics is marketing and telling people what they want to hear, but there’s also an obligation to reality and the truth that seems to have gone away. Big problems are squishy problems because they involve huge, complex systems, culture, and most importantly, people. The way those problems operate require separate ways of thinking and different metrics for success. Even if you hit the bullseye, the bullseye moves out from under you because the context changes. People’s opinions evolve. Culture adapts. Needs shift. What’s possible grows, and the world turns a little bit under your feet.

    Again, back to Aristotle: things can be other than what they are. If your work is good, it changes the space around it and how people come to it, and that change undermines the successfulness of what you’ve already built. It means that for complicated endeavors, our actions more closely resemble steering things in the right direction, rather than fixing a problem and making it go away. There are no conclusive answers like a math problem, so your work becomes a constant call-and-response game of Marco Polo with the shifting nature of the problems. A successful response requires fostering and shepherding. You’re never done, per se, you simply choose an acceptable time to re-access your actions—hopefully, a time where the situation is improved, rather than as things get worse.

    Mistake #4: We forget that our responses to problems create more problems.

    One of the results of our reverence for solutions is that we have a tendency to forget that our responses to problems typically create more problems. That oversight can make us blind to the thing we actually need to do to more successfully respond to the problem. Worst case, that blindness can actually have a person act in a way that makes the original problem worse. Let me explain by giving an example. It’s about our email. (I’m sorry.)

    Remember technology’s original promise of saving time and freeing us to do the things we always wanted to do? “Email makes sending messages quick and convenient. You can finish your correspondence by 3 and go sailing!” Well, the easier it is to do something, the more indiscriminate you can be in doing it. So, we sent more messages. And then more. Then we got robots to send us messages. And the pile of messages got bigger, until we couldn’t handle it any more. Some people went crazy.

    Things have changed since paper letters and memos (and I’d argue things have gotten better, in general), but now we have a whole other problem with correspondence that’s possibly even worse than the original, because things are quicker, cheaper, and easier to send. So we’re writing alternate email clients, apps, and opinionated messaging services to help us deal with the glut of communication.

    It implies that our best idea is to use technology to fix the problems amplified by technology. Should we laugh or cry about this? I’m not saying these approaches won’t work short-term, but long-term, it seems to only exacerbate the issue by asking people to be even more efficient in handling even more quantities of information. That doesn’t seem like a good way forward. Instead, we should try something we can do now, without inventing anything: recalibrate our expectations of one another, and educate each other of the demands placed on us. What if you could only change how you act? How far will you get if you simply reply back to people and ask them to send less email, because you get a lot of it already? I know that doesn’t work for everyone, but at least you’re trying to kill the root instead of pruning the branches.

    One of the problems with the prevalence of solutions is it overvalues invention and undervalues behavior. We look for a gizmo, when changing how we act can have the desired effect. It seems like we’ve been hoodwinked into a trap of technological dependency.

    But, technology is only as good or bad as what we use it to do, and I don’t think anyone who works in tech gets into the field with malice as their intent. In fact, usually the opposite, which is why I like this business. Hell, I’m one of the the folks in technology, so none of this criticism excludes me—I only suggest we stop looking at technology as the primary way to fix problems, and stop turning a blind eye to its negative consequences and to the new problems it produces.

    Obviously, unexpected new problems are not limited to only technology: look at oil, look at the automotive industry, look at agri-business, and all the issues that orbit global warming. People are problem factories, which means we need to get just as good at thinking about problems and organizing ourselves to respond to them as we are at producing them.

    I think it’s worth recognizing that the things we invent will probably create new problems of their own, and if we follow the same methods we’ve used in the past, it’s quite likely we’re only going to make things worse. That’s why we need to understand a problem for what it is, not for what we want it to be. We need to think ahead, talk to each other, stay on our toes, be responsive, and follow the problem. We can’t necessarily make the problems totally go away, but I’ll be damned if we can’t make things better for one another in a responsible, diligent, and elegant fashion.

    That’s why I got into this, and maybe why you did, too. It’s also why I thought it’d be worth the time to sit down and think about all the mistakes I make when dealing with problems. I’m trying to improve, and I hope you will, too. So much depends on it.

  2. Waste Need Not Waste

    When you don’t have someone to teach you, looking closely at good things and noticing their patterns becomes your education. I have no formal teaching in writing or literature (perhaps the reason grammar is such a thorny matter for me), so I have to school myself. It’s fun.

    I’m finally making my way through Robert Caro’s tome The Power Broker. One of the things that’s popping out is his use of repetition. This could be seen as a stylistic indulgence, but after reading about a fifth of the book’s 1200 pages, I’m realizing that Caro’s repetition becomes the thread that helps the reader through the book’s sprawling assessments, wide focus, and complex topics. Here is a bit from the beginning of the fifth chapter:

    The wheels of the Tammany war machine might be greased with money, but the machine was pulled by men, the men who voted Democratic themselves, the men who rounded up newly arrived immigrants and brought them in to be registered Democratic, the men who during election campaigns rang doorbells and distributed literature to those immigrants and to their own friends and neighbors and on Election Day shepherded them to the polls to vote Democratic. And the most succulent of the carrots that lured these men forward, that kept their shoulders braced against the ropes that pulled the Tammany machine, was the carrot of jobs, jobs for themselves, jobs for their wives, jobs for their sons.

    An easy read, since most of the words are the same words in different order, strung together to lead you on to the next idea and reiterate important points, strung together to reflexively reference previous ideas and build on top of those ideas. The first half of each new idea is the last half of the previous idea. Baby-stepping through a minefield of complexity.

    Here is the same paragraph, with a few words left out:

    The … Tammany war machine … machine… men, the men … the men … immigrants … the men … immigrants … the carrots … these men … the Tammany machine, … the carrot of jobs, jobs… jobs … jobs….

    Sure, painfully close to beat poetry, but you still get the idea. I wouldn’t be surprised if The Power Broker’s page count were cut in half if you removed Caro’s repetition. But this would surely make the thing too dense for any normal reader.

    Needless excess is, of course, the enemy of good writing, but that doesn’t mean all excess is needless. Sometimes a bit of padding is required. I’m reminded of the African drum communication described in the first chapter of James Gleick’s The Information:

    No one spoke simply on the drums. Drummers would not say, “Come back home,” but rather,

    Make your feet come back the way they went
    make your legs come back the way they went,
    plant your feet and your legs below,
    in the village which belongs to us.

    Nineteenth-century Europeans were bewildered by the musical correspondence. How could the locals derive nuanced meaning from a drum beat?

    The first hurdle was to understand the drums mimicked the tonality of many African languages, where a spoken word’s meaning is determined by its rising or falling tone in addition to the sounds of its consonants and vowels. Tonality is missing from most Indo-European languages (such as English and the rest of the Romance languages), but is famously present in Cantonese and Mandarin as well as many African dialects. Distinguishing between words while speaking takes a sharp tongue: boili said flat means “riverbed”, but emphasize the middle consonant and it turns to “mother-in-law.”

    Drums do not have tongues, however, and can not make the sounds of consonants or vowels. They can only communicate through tone. So how does one say things with a drum, despite missing half the tools of the spoken language? The drummer reproduces the tone of the appropriate word, which limits the field of words to those with similar cadence, then he clarifies which of those words he intends through context. Gleick, again:

    A drummer would invariably add “a little phrase” to each short word. Songe, the moon, is rendered as songe li tange la manga—“the moon looks down at the earth.” Koko, the fowl, is rendered koko olongo la bokiokio—“the fowl, the little one that says kiokio.” … Every ambiguous word begins in a cloud of possible alternative interpretations; then the unwanted possibilities evaporate.

    Both the drums and Caro’s writing style are examples of people using redundancy and inefficiency to overcome ambiguity. Sometimes puffy writing is more efficient communication, because it’s the best way to get a complex idea through. I’m learning to appreciate that the clear thing isn’t always the simple thing, and that’s worth repeating.

  3. Let’s Talk About Timeless Design

    I have a pet peeve when it comes to describing design (or any kind of creative work). The word “timeless” makes my skin crawl, like that scene in Indiana Jones where he has the snakes and creepy crawlies all over him and he’s all like “Oh God! Snakes!” but you totally saw it coming because he said he hated snakes maybe ten minutes before that.

    Allow me to complain in bulleted points:

    • I read an iPhone app review earlier this week that said the app’s design was “timeless.” And I went, “Ha. Ha ha ha ha ha.” The app was quite pretty. And Lord knows there’s plenty of good things about iPhones, apps, stores, and design. But an iPhone app is about as timeless as an ice cream cone given to a chimp on a hot day.

    • It irks me that we’re throwing around the word “timeless” all willy-nilly. At this point, “timeless” is hyperbole for something with a shelf-life of a couple years. This bag of Doritos? Timeless.

      Our sense of time is all out of whack. When people link to older blog posts and articles, they’ll maybe call it “timeless” or say some other inane thing like, “Old, but good!” Two years old isn’t old! A two-year-old can’t even wipe his own ass.

      Let me let you in on a little secret: if you are hearing about something old, it is almost certainly good. Why? Because nobody wants to talk about shitty old stuff, but lots of people still talk about shitty new stuff, because they are still trying to figure out if it is shitty or not. The past wasn’t better, we just forgot about all the shitty shit.

    • Ironically, most timeless design looks like it came from the 1962 Graphis Annual. It’s good stuff worth mimicking, but it sure isn’t timeless.

    • I think “words” mean “things.” So when you say something is “timeless,” do you really mean it is not affected by the passage of time or changes in fashion? Would it spoil your day to say that timeless design is currently in fashion? (That doesn’t even make sense.) Regardless, perhaps you truly mean to say that a design is fundamentally sound, or that it is sturdy, or well-built. All great things.

    • Why is timeless design always the goal? What’s wrong with making something look like it was made when it was made? Why do designers all of a sudden want to exist outside of time, like Scott Bakula in Quantum Leap? We’re already thirteen years into the 21st century, and I still don’t know what the hell is going on. One day you’re playing laser tag, the next Google’s making spy glasses to secretly record video of all your hot air balloon rides.

      Other people: can you help me understand what is happening in this world of ours? I want to know what technology is doing to my brain. How do I stay human in a digital world? I want to understand what all this technology does to my expectations of myself, other people, and the world. None of this is timeless. These problems are right now.

    • Some might say that this blog’s design has some “timeless” qualities. I will let you in on a secret: I am lazy. I want to make as few decisions as possible, but I want those choices to be good ones. I don’t add cruft, because I’d have to make the cruft so that I could add it. And then I’d have to decide where it would go, when all I really want to do is find that chimp with the ice cream cone and hang out with him.

    Thank you for reading my measured critique. Have a timeless day.

  4. The Cloud is Heavy and Design Isn’t Invisible

    I rarely say this, but Timo Arnall’s dismantling of the “invisible design” ethos is essential reading. There’s too much I want to talk about in the essay, so I’ll settle and highlight one choice bit that runs parallel to something I’ve been considering myself.

    We already have plenty of thinking that celebrates the invisibility and seamlessness of technology. We are overloaded with childish mythologies like ‘the cloud’; a soft, fuzzy metaphor for enormous infrastructural projects of undersea cables and power-hungry data farms. This mythology can be harmful and is often just plain wrong.

    A metaphor can clarify or obscure. The most dangerous ones do both. They illuminate one characteristic of a concept, but also throw another (usually less favorable) aspect into shadow. “The Cloud” is one of these complicated metaphors, because it’s a clear description of the user’s experience, but overlooks its costs by misrepresenting the situation. Storing data on servers is light, accessible, and omnipresent for the user. But The Cloud is not a dissolution of data’s “weight”; it simply outsources its handling, in much the same way your garbage doesn’t disappear when it’s picked up from the curb. It’s a complicated transaction, because the true implications are hidden. Still, I wouldn’t want to get rid of the Cloud or my garbage pick-up. All this stuff has to go somewhere, and generally it’s better if I’m not the one toting it around. So, my garbage goes somewhere in New Jersey, and my data goes to Douglas County, Georgia.

    IDI_014

    One of Google’s Data Centers in Douglas County, Georgia. Thousands of feet of pipe line the inside of the data center. The bright pink pipe in this photo transfers water from the row of chillers (the green units on the left) to a outside cooling tower. How industrial. Please note the strong resemblance to an oil refinery.

    It’s worrisome that The Cloud as a metaphor clarifies the benefits of its user’s experience, yet hides the repercussions of that convenience. (Of course, it’s old hat in capitalism to conceal the unsavory bits of production behind a curtain.) What kind of energy does that data factory use? Where does it come from? And how does it compare to the energy used if we kept all this data locally? How does that building affect the community where it is built? And what are the repercussions of having all that data in one place?

    The answers to these questions don’t need to be awful. For instance, many of these data centers are blanketed with solar panels to collect energy and offset or eliminate its dependence on the grid. Google’s not trying to hide anything. In fact, the image above comes straight from them. Yet, I believe it’s important for users to ask these questions, if only to understand their dependencies. Still, it is hard to know what to ask if the topic’s complexity and requirements (infrastructure) are concealed by the metaphor that names it.

    All of this is well-trodden territory, so I’ll sheepishly confess that I’ve backed into the real reason I wanted to write a bit. There’s another loss from this kind of obfuscation, one more miraculous in nature, which also undermines the “invisible design” ethos.

    Look back up. Isn’t the picture of Google’s data center marvelous, in a complicated Dr. Seuss machine kind of way? It is like a Pipe Dream level come to life. The ethos of invisible design suggests you shouldn’t see this design. I think you should look again.

    DLS_013

    Sometimes I wonder if the desire to obfuscate production and make the resulting design invisible or seamless to users diminishes their appreciation for the craft of building systems. I think there’s a strong likelihood that metaphors like “The Cloud” and sayings like “It Just Works™” reduce a user’s appreciation of the software/hardware they are using. “Magic” is a great word for selling product, but it also can cheapen all the sweat it takes to get there. If the seams have been covered, you can’t admire how things connect.

    Design doesn’t need to be showy to prove its value, but it shouldn’t be invisible, either. Designers mistake invisibility for elegance and simplicity for clarity at their peril. The best design speaks not only so it can be understood, but also in a way it can be admired by those that use it. What if you were inspired by the things that you used, simply because they were impressive in a way that was evident to you? And why is it bad to try to build things like that? I don’t think it is.

← Older Posts