Before the Solution

It’s so tempting when you work in product to want to get a solution out into the world. As designers, we can almost see it. We can almost taste the answer before we even start to think. People from various teams come up to us with ideas, requests, complaints… always with the solution.

30% of our work is to stop ourselves, and everyone else, in our tracks. It’s not easy to think backward and inside out. It’s even more difficult to convince others to see in this manner. But that is what we must do. This is the role of the designer. The designer must be like Merlin, living our product’s lives backward.

Before we go to the shelf to dust of a solution or a prepackaged thing, a thing that was tried and tested and proven, in order to shove into a place to fix the bad stuff, we must go through a process.

I know, I know… it sounds soo much easier to just go to your favorite website or pop open the UI kit you just downloaded, the kit that dices, slices, and mixes ready-made components for any and every recipe at a low easy payment of $15.99/month, and pluck one of those prefab solutions and force it into place. Browsing existing solutions and components is part of the process and may eventually work for the case you are solving for, but in order to build good products, you must go through the process.

And so, before the solution, we must exercise the methods of human-centered-design, or we risk designing crap.

How to Not Design Crap

Well, this is kind of a trick postulate, and maybe a bit of a catch-22, because, in order to not design crap, we need to design crap. We just need to design it over and over again.

The thing is, we don’t need to design the whole shiny friggin’ swiss army knife over and over again. If we design low-fidelity work in short bursts and pause to test and iterate in between, we will get through a lot of crap rather quickly. This is the iterative process, but we cannot enter it blindly.

The trick here is to remember not to start right away into sketches with your pencil and your paper because even though this is low fidelity, you are still starting with a solution when you put pen to paper. And if you start with the solution — at any level of fidelity, even if you employ testing and iterations, you will ultimately be spinning your wheels. You will have a giant pile of ever-shinier sketches and wireframes and mockups, all being cobbled together into the same large pile of crap.

To avoid this hamster wheel of digital pellets, precede the ideating and the UI –in any form– with research. Because research breaks the wheel. It gives us a frame of reference.

Research Isn’t Scary

It’s really not. Research is just a stuffy word for watching people and talking to them. Who’s at the center of human-centered-design, anyway? The robots! Wait, no… it’s the humans, of course! And how do we design for humans? We ignore them and tell them what they need and want! Wait, no that’s wrong, too. Oh, yes, we talk to them. We ask them questions. We also observe them, because sometimes humans don’t even know what they need or want. And because sometimes, though usually not on purpose, humans lie.

UX Research is merely the process of figuring out these three things:

1. What’s the problem?
2. Whose problem is it?
3. Why is it a problem?

Number one is usually the easiest part. What’s the problem? Well, this stupid thing is broken. Or, I can’t do this thing. Or I can’t do this thing the way I need to do it.

In order to get to the root problem, you will have to do some real digging. Often times you’ll be presented with a solution. For instance, “Hey, Bob we need a button that does X, Y, and Z. With confetti. And Dolphins.” You’re going to have to work backward from the proposed solution to understand the root problem.

You’d think that number 2 would be the easiest, but it can be a tricky one! Whose problem is it? Well, it’s the client’s problem. Oh but wait. Our client is a large company and they have 20 different job roles, and there are about 100 different humans in each of the roles, and they’re from about 100 different places, with 100 different life experiences. So who are we really talking about? Is it HR Sue, who’s never used a touchscreen before, or IT Tim who knows more about the code in your product than you, the designer, does?

You can learn who you’re solving problems for by talking to as many people who will touch your product as possible. Try to get at least five conversations in from every different kind of user you can think of. And try to make those five conversations happen with a diverse group of people.

Number three is the most important. Why is it a problem? When you start asking this question, you’re going to confuse and even frustrate people. But if you lean into it, you will uncover the real meat.

When we start asking why, we begin to unravel the truth. We start to understand the root causes of the problem. We usually learn that proposed solutions don’t usually address the real problem, and we sometimes learn that even the problem isn’t really the problem! Wait, what?

When the Problem Isn’t the Problem.

This is how you know you’ve done some good UX Research. It’s the moment you uncover an underlying issue or series of issues that are causing people to become blocked or frustrated.

For twilight-zone inspired example, please review the following scenario. Person A comes to you, the designer, with a solution.

“Steve,” says Person A, “I really need a buffalo lasso.”

It’s a very specific request. There’s passion in Person A’s voice and on their face. It’s a request for a thing that has a purpose. You assess. You question.

“Oh, yeah? What do you need a buffalo lasso for?”

“Well, Steve,” Personal A continues, more enthusiastic now that they have your attention, “Last week I had ten buffalo and this week I only have four. The others have all run away. So I’m gonna ride out in the morning and capture the runaway buffalo again with a lasso.”

Hmm, you think to yourself, Person A needs a better way to keep their buffalo because their buffalo are escaping.

Having heard Person A’s solution, you’ve deduced the problem they’re experiencing — escaping buffalo. Now, at this point, you could run off and start coming up with a hundred remedies to solve for this problem. You might even entertain the Reactive Lasso as one of them. You’re already thinking about a bigger, better fence and electric collars for the animals. However, you pause.

You take a breather.

You remember not to rush into solutions and you decide to take your research a little further than an initial conversation. So, you set up a stakeout on the ranch for an evening.

What you observe changes everything. The buffalo aren’t escaping through some imagined hole in a shoddy fence. They’re not running away. There are no wolves sneaking onto the ranch for late-night feasts. It’s aliens. Little green Martian guys popping overhead in their shiny silver discoidal spacecraft and abducting the buffalo one at a time for their own mysterious research projects.

Congratulations! You have identified the root problem. Only at this point can the work of discovering a solution commence, and your mind is already racing with anti-spacecraft laser turrets….

Source: Steven Paul Winkelstein, https://medium.com/nyc-design/three-questions-to-ask-before-you-pick-up-a-pencil-435c7fc4a43a, Three Questions To Ask Before You Pick Up A Pencil, Medium, Jan 29th