Are Your Lights On?

I recently read a little book on problem solving called, Are Your Lights On? It’s full of hideous illustration, lousy typography, and corny anecdotes. It’s also full of brilliant, succinct thinking and gem after gem of problem solving wisdom.

There are some great lines throughout (e.g., “Designers are special people whose job it is to solve problems in advance for other people”) but many of the best parts appear as moral-of-the-story lessons at the end of each anecdote.

Here are a few of the lessons, along with some commentary on how they intersect with digital product development.

What is a problem?

As defined by the authors:

A problem is a difference between things as desired and things as perceived.

Who has a problem?

Another principle established early in the book is that rarely is there a single problem. Usually there are multiple problems with multiple parties and viewpoints, and figuring out who has what problems is the first step towards identifying the breadth of the collective problem.

Problem definition

To get to work, the first thing a problem solver needs is a description of the problem. But often the first thing the problem solver receives is a solution.

Don’t take their solution method for a problem description.

Designers and developers know this one well. Requests tend to arrive in the form of predetermined solutions: the familiar “We need a carousel”, “We need an export feature”, and “Move the hyperlink button over here”.

It’s OK. It’s natural for people to think and communicate in terms of solutions. The important part is that you have a design process where the first step is reverse engineering the solution into a workable problem statement.

Sometimes you have to give it to them

Another gem:

In spite of appearances, people seldom know what they want until you give them what they ask for.

This happens all the time when doing design work for clients. The client wants something, you know it’s a bad idea, but no amount of protest or persuasion will do.

The trick is to give it to them. Show them what they’ve asked for, at which point they will often immediately change their mind and see the light on the thing you had originally suggested.

The Problem Chain

I’m going to go into a little more depth with this one, because I think it’s the most important and most powerful concept in the book.

Each solution is the source of the next problem.

The authors elaborate:

We never get rid of problems. Problems, solutions, and new problems weave an endless chain. The best we can hope for is that the problems we substitute are less troublesome than the ones we “solve”.

This is a critical concept to grasp. Solving problems isn’t about making problems go away—it’s about trading up for more manageable problems. Like a trained chess player, a good problem solver is thinking several moves ahead, cycling through the potential lineage of each considered solution, looking for the optimal path.

Experienced developers are good at this sort of thinking, partly because they’ve spent so much time receiving first-hand punishment from the problem chain(self-induced or otherwise).

The upside to this never-ending web of problems is that it allows for problem variability, which gets us to the magical technique of problem restatement.

Problem restatement lets you zoom out from a problem, reshape it, and then come at the problem from a more advantageous angle. Restating complex problems as simple problems, using problem restatement you can make large amounts of work disappear and uncover all sorts of new directions and opportunities.

A Real Life Example

A few weeks ago I received this email from an editor:

Is there any chance that we can also update the CMS platform so that it will have full backend functionality on tablet? As it stands, editors are unable to embed links if uploading content from a tablet, which can make it a challenge to cover conferences remotely, etc.

First step: convert the solution assumption—”Add CMS functinality for tablets”— into a problem description: Editors are unable to embed links when publishing content from tablets.

A quick glance down the problem chain tells us that we probably want to start with a slightly broader problem description, maybe something like: The full set of publishing features available on the desktop is not available on the tablet.

At this point we could go with the proposed solution of adding CMS functionality and take the request to the Dev team and get a work/cost/time estimate. There will be a cost for the initial work of adding tablet support but this will not be the total cost of the solution because our solution is now the source of a new problem.

One of these problems is that we’re making a commitment to feature parity between desktop and tablet devices, which means that all future CMS development could incur the extra cost and burden of supporting multiple devices.

Restating the problem

Or we can try restating the problem. The clue in this case has to do with when the editors have the problem: when they are covering conferences and events remotely. They aren’t using tablets to publish content from their desks, it’s only when they are traveling.

“Is there a reason editors don’t use laptops at conferences?”

“Most of the editors prefer to travel with tablets since they are so much lighter.”

Now we have a different angle on the problem—the laptops are too heavy. What was originally a development problem is now a hardware problem. The solution could be a simple equipment upgrade. In the book, the authors call this Problem Displacement.

I had another question. “Have we tried a workflow where someone uploads content to Google Docs via tablet and then someone back in the office publishes it in the CMS?”

“That’s actually what we do now. But the team is stretched thin at the moment so it’s difficult to have multiple people assigned to the same event. Also it adds a delay to the publishing process.”

Now we have yet another take on the problem. The editorial team is under resource pressure. The solution might involve reorganizing responsibilities or growing the team.

Regarding the delay to the publishing process, maybe this is a problem for the development team but maybe the solution is not about tablet support but about building a better notification system for article drafts.

If we go with the These Laptops Are Too Damn problem description, notice how much smaller and simpler the original problem becomes. Hypothetically, it could be the case that there are only two editors traveling at any one time, meaning we only need two MacBook Airs, which we happen to have sitting here in the IT closet. Instead of spending weeks of development cycles and tens of thousands of dollars we’ve solved the problem overnight at virtually no cost.

Of course it could be the case that, in the long run, upgrading the CMS with tablet support actually is the best option. This isn’t about being shortsighted or always taking the easy, expedient path. The point is that problems often misrepresent themselves and it’s important to look at them from every possible angle.