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.
- Adobe has solutions that “let customers produce, distribute, and realize value from great content.”
- Oracle has “solutions that minimize risk, streamline business processes, and reduce the cost and complexity of your IT infrastructure.”
- And if you simply visit solutions.com, you’ll find your “go to source for home organization, storage, and problem solving products.” Problem-solving products!
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.