Customers Request Solutions. We Need to Understand Their Problems.

“They need a way to export data.” That’s what the salesperson told the product manager. “It’s a big sale. We’ll lose it if we don’t put a data export feature in.”

On the surface, it sounds like a reasonable request. But there’s a complication.

The team can’t do a great job with the information they have. They could implement a data export feature in several different ways—each very different. If the designers just guess what the customer wants, it’s very likely they’ll build the wrong functionality. That would be a costly mistake.

The salesman came to the meeting with a customer’s solution. To be successful, the team needs to understand the problem behind that solution.

Human nature kicks in.

It’s human nature to start with a solution. When any of us walk into a store, we bring with us a shopping list of solutions. Not the problems we want to solve.

Starting with a solution is a concise way to communicate what we think we need. It’s expedient, but it leaves out important information.

Why did that customer tell the salesman they needed to export data? There are at least three possible reasons:

• Maybe they needed a secure backup.
• Maybe they wanted to move the data to another instantiation of the application.
• Maybe they wanted to bring the data into another vendor’s application, to manipulate it somehow.

(There could be more possible reasons, but let’s stick with these three for now.) Each of these reasons is radically different. A well-designed solution would be very different depending on which of these is what the customer actually needs.

The problem changes how we implement the solution.

The first alternative problem assumes the customer needs a backup solution. If the team were to build a backup capability, exporting the data is only half the problem. They’d also need a way to restore the data. That’s a bit of work.

Whereas, if the customer really wants to move the data to another instantiation, that’s a completely different problem to solve. Do they need all the data moved, or just a subset? Is it just the raw data, or do they need to move any tailored capabilities? That’s a different bit of work from the backup solution.

And if they are bringing the data into another vendor’s application, what functionality does the third-party application provide that the team’s application doesn’t? Maybe it’s better to build the missing functionality? (Or is it possible that functionality already exists, but the complexity of the team’s design prevents the customer from realizing that?)

Once we realize there are multiple problems, it’s clear we need to do more research.

Starting with the best outcomes.

One approach to getting to the right solution is to start with the outcome. To start, the team can ask a critical question: If we implement the data export capability perfectly, how will that make our user’s life better?”

Research could tell us that the customer now gets to sleep soundly, confident that they could easily recover from a catastrophic technology failure. That would indicate that backup is why people need to export data.

But it also creates a few more questions: How might the design make it easy to do make backups and restore them? How might it demonstrate that the data backup process is working smoothly and is ready to recover at any point?

But what if the research says the outcome would make it easy to duplicate best practices across the organization? That’s where we might want a way to duplicate data across multiple instantiations. How might we give the user an easy way to deliver data to other groups for their own use?

Maybe the user needs to report some type of progress, as indicated by the changes in the data, to their superiors. That would be why they want to move the data into an application like Excel. What are they doing with that data? Are they making charts for presentations? How might we make it easier for them to communicate that information effectively?

Outcomes > Problems to be solved > Solutions.

Outcomes are the improvement our users see because we’ve done a great job with our design. By starting here, we’re starting with the end in mind.

Once we identify the desired outcome, the problems to be solved are all the things that currently prevent the user from attaining that outcome. These are the obstacles our design needs to overcome.

The solutions then represent how we’ll overcome those obstacles. There’s a small chance that the solution the customer has first suggested is the right one. It’s more likely there are better solutions out there, waiting for us to discover them, once we know the outcomes and problems to be solved.

Shifting to outcomes gets us to the best solution.

As designers, our job is to improve our users’ lives. We need to identify what it will take to make that happen. That means looking past the solution our customers first ask for.

When we do this, we shift our work from being a design request “order takers” who only work off the customer’s shopping list. Instead, we end up with solutions that truly meet the needs of the user. This is how we deliver the best-designed products and services.