What Problem Are We Solving?

There is no such thing as Good Design.

Sure, there’s design that you personally like, which is nice. And there’s good default practices that can help you get started. But over the course of my career, every time I came up with an iron-clad Rule of Good Design, I was generally one project away from breaking it.

“Any man who would letterspace blackletter would shag sheep,” said the great type designer Frederic Goudy. (Blackletter is a font face like the New York Times masthead, and letterspacing would mean adding too much space between the letters.) And he was right … until the mid-90s when grunge design made breaking those rules cool.

In 1999, all the smart designers knew that “mystery meat navigation” (links that were invisible until you interacted with the design) was an unequivocal sin. Today, one of the most popular mobile apps is Snapchat, which is almost entirely mysterious, requiring the user to paw at the screen like a wild animal until something happens.

Fashions change, of course. But my point is that there is no universal law when it comes to good design. Design can only be judged by how well it solves a problem. A can opener is a great solution in a world full of cans, but a terrible solution in a world full of boxes.

So before you can tell if a design is good or not, you have to know what problem it’s trying to solve. And defining that problem is, in itself, a kind of design.

Step 1: Define the Problem

A clear problem statement should be the first step, no matter the size of the design project. A good problem statement should make it clear who has the problem (ideally, the user), the dimensions of the problem, and why it’s a problem. It should not contain a solution – that comes later.

So, for example, this is a bad problem statement: All our links are blue, but this one is green. We should make it blue.

It may be true that all our links are blue and one is green, but that’s just describing the current site. Why is that a problem? And for whom? Adding the solution just cuts off consideration of other angles, which doesn’t lead to creative thinking.

A better problem statement would be: As a user, when I’m on our site, I know the blue text is a link. When I see green text, I don’t know it if’s a link or not, so I’m confused.

Now we know who we’re talking about, what they’re doing, and why it may be a problem. Which leads us to step two.

Step 2: Is the Problem a Problem?

Ask yourself (and each other): is the problem really a problem? What proof do we have that the problem exists? Can we confirm it somehow?

For example, perhaps the inconsistent green link is different on purpose. Perhaps the color change is there to communicate something important to the user. Explore the site. Are there other green links? Do they all have something in common? Do the users know what they mean now?

Sometimes there’s disagreement among the team, and that’s great! Time to dig in. Can we discern a pattern in the usage data? Or define an AB test to learn more? Is it time to do some user interviews? Disagreement is a great indicator that more data is needed.

If we agree that the problem is a problem, and we’ve made sure it’s well defined, then we can move on to step three.

Step 3: Pitch Solutions

Now that we know who is having the problem, what it is, and why it’s a problem, we can get to the fun part: solving it.

The nice thing about a well-defined problem is that invites a variety of solutions, and the first one is not always the best. Turning all the green links blue might have been the obvious thing to do, but doing so might have a downside. There might be ripple-effects in other parts of the interface, or with users who already know the system.

So what are some other solutions? Perhaps the problem isn’t the green, it’s the confusion. So one solution would be to explain why the link is green somewhere. Another solution might be to make the link blue on hover, so the user knows “oh, this is a link.” Once you get the solutions ball rolling, you’ll be surprised what kinds of things come up.

 

When we skip defining the problem, we can’t judge which solution would be “good design” outside of our own personal tastes. But with a defined problem statement, we can judge each solution by how well we think it would solve it. Even then, there’s room for disagreement. Sometimes the best course is to try a solution and see what the result is. And with the problem defined, we’ll know how to judge the results.

The best part is, when we collectively agree on what problem we’re solving, we can be impersonal about the solutions. It’s not just the designer’s job to solve every problem – the solution can come from anyone.

In the end, every team member is contributing to the user experience through their work. We all have the ability – the responsibility – to solve the users’ problems. We just have to agree on what they are first.