The Back Up Question: Defining a Project’s ‘Good Enough’

All too often, the first time we hear about their project, they already have a specific solution.

Can we refresh the design of the home page?

We’d like you to build a new form for our workflow.

Can we get rid of the carousel on the landing page?

We need tagging for all of our content.

Can we add in a carousel on the landing page?

There was thinking. There were discussions. That all happened before they came to us. Somewhere in there, they honed in on their solution. And now they want us to design it.

We don’t understand why they are asking for this particular solution. There’s a high likelihood what we design won’t be the solution they’re seeking.

If we take their request at face value, we’ll design what we think they’re asking for. Yet, because they specify the solution in vague terms, we’re likely to miss the target.

We end up with something that isn’t what they’d hoped for. We don’t know what good enough is for this project.

The conventional reaction is to get them to specify their request in substantially more detail. What design would you like to see? Asking for more details puts these non-designers in the role of designing. That’s a role we should be involved in, if not taking over completely.

Instead, we need to know more about the problem. Why do they need this particular solution? There could be a better way to solve it. There could be a solution our design experience brings to the table, one that they wouldn’t know to propose.

How do we start to understand the problem their proposed solution wants to address? After dealing with this very problem for decades, I’ve come up with a simple question. I call it the Back Up Question.

A Key To Unlocking The Problem

The Back Up Question is simple: Let’s say we do a great job on this. A year later, what great things have our users accomplished because we delivered a great design?

I call it the Back Up Question, not because it’s an alternative to another question, but because it forces our stakeholders and clients to back up for a moment and talk about the outcome. By framing the question in terms of what our users accomplish, we focus that outcome on a benefit to them.

Now, there are plenty of ways to bend this question to our needs:

A year later, what causes our shoppers to shop with us more because we delivered a great home page?

Six months later, what has improved our applicant’s lives because we’ve added this detail to our application form?

A year later, how has a well-designed tagging system improved our users’ productivity?

To answer any variation, we start talking about improving the lives of our users. That’s what I find to be the beauty of the Back Up Question. It backs up the discussion to talk about how we help users. We’re no longer talking what the solution should look like, but what the overall outcome needs to be. We’re talking about the problem we’re trying to solve.

Steve Jobs once said, “You have to start with the customer experience and work backwards to the technology.” The Back Up Question becomes a catalyst for restarting the journey from the user’s experience (not all of our designs are for customers), giving us an opportunity to talk about how we’ll tell if we’re successful.

We Blame The Plumbers

It would be great if we didn’t have to ask the question. If our stakeholders and clients showed up at our door with a clear description of the problem, we could go from there. Collaboratively, we could work up possible solutions and whittle them down until we know exactly what project we needed to execute. But that doesn’t happen.

I think we can blame the service workers of the world—plumbers, mechanics, restaurants—for training our colleagues to find a solution before knocking on our door. You tell a plumber what you think needs fixing. You tell the waiter what you want for dinner. If they understood the problem we wanted addressed, they might have a better solution than what we’re asking for.

Yet, that’s not how the customer request goes. “Make my car run better” is a different request from “change my oil.”

The same is true from our stakeholders and clients. They start with the solution. We need a trick to back up into talking about the problem.

“Huh, That’s A Good Question.”

Much of the time, when I ask the Back Up Question, I seem to surprise the stakeholders. I’ll hear “Good question. Let’s think about this…”

I can tell, from the length of the subsequent pregnant pause and the number of attempts they’ll take to form an answer, that they’re often crafting the answer in that moment. These stakeholders are searching for the benefits in real time.

Not everyone does that, though. Some stakeholders will have an answer on the tip of their tongue. “Removing that form will make for a smoother interaction, reducing the amount of time our project management users are fiddling with their projects. It will give them more opportunities to see where they can optimize their team’s resources.” They were clear on the problem from the beginning.

Fast Identification Of Solutions In Search Of A Problem

Other stakeholders will resist talking about the problem. We’ll have a discussion that echoes the technique of asking five ‘whys.’

“Adding the carousel will give us more places to advertise the new content we’re providing users.”
How does that make for a better experience for our readers?
“They’ll know about new things.”
How does knowing about new things make a for a better experience? What will they do with these new things that they can’t do now?
“Um, I’m not sure.”

From these stakeholders, we may have a solution in search of a problem. We see this with some roadmap-focused teams. They gravitate to providing more features over better quality experiences.

Talking with these stakeholders about their users and the challenges those users face is a collaborative way to get an answer to the Back Up Question.

“Our readers need descriptions of the latest techniques to be more effective in their work. We know that we’re producing videos that help them, but they aren’t discovering them. Our new design should deliver helpful information they can put to work right away.”

OK! Now we’re on to something.

Translating Outcomes Into Measures Of Success

The answer to the Back Up Question guides us to how we’ll measure if the project is successful. We can measure how much time project managers spend fiddling with dialogue box values versus how much time they’re spending resolving important resource management issues. We can measure if readers are employing new techniques immediately.

To collect our measures, we may have to go old school and talk directly with users. This helps us see the value. Seeing how our current users interact with today’s design will give us insights into how to make them successful with our future design.

Using these measures, we can now explore if any proposed solution is the best alternative. We can try out different solutions to see if one may fit the problem better. We may return to what the stakeholder initially brought us as the ideal course of action, but now we know how we’ll tell when we’ve done a quality job.

We’ve defined good enough. That’s an important milestone for any project.