A Strategy Can Make Or Break Design

“The start of any project is where the greatest risk lives. Essentially, you’re starting from the darkest depths of the ocean…and it is a long, long way to the surface. If this sounds like a big task, that’s because it most certainly is. But if you look at all the individual parts of any design process, and if you understand how they affect each other, it becomes a lot easier to tackle. and if you devote significant time and attention to the very first order of business — your strategy — the foundation you build will be strong enough to withstand any weather as you move into design and coding.” –Think First, by Joe Natoli

Thus begins Think First, Joe Natoli’s new book about strategy, thoughtful UX, and successful projects. It’s the perfect read for anyone who has ever been mid-project wondering, “how did we end up here?!” In Think First, Joe outlines not only what a strategy is, but how to build one, and how to avoid many of the pitfalls we face when we follow them.

We’re delighted to be interviewing Joe this week. Read on to find out what inspires him, how he thinks we can design for the Internet of Things, and his magic formula for doing the impossible: staying within a project’s scope!

Want a copy of Think First? Enter to win a signed copy here. →

Strategy provides the big-picture perspective for UX professionals who might otherwise get caught up in the weeds. What inspired you to write about strategic thinking?

Experience. After doing this for so long — headed towards three decades now — what’s become really clear is the fact that when a product fails, the underlying cause is rarely poor UI design, and it’s not technology platform limitations. It’s not even bad UX. Those things all contribute and exacerbate the problem, but they’re really just symptoms.

The underlying disease, so to speak, is almost always strategic in nature. The team delivered what the business thought customers expected or wanted or needed, without taking the time to qualify those features or functions or interactions. For example, maybe the UI design was done according to an existing theme or template, instead of being customized in a way that guided users appropriately, in a visual language they specifically would understand, that was appropriate for the context of use.

In other words, the team jumped to tactical solutions before ever asking enough strategic questions. Designers were told to mimic a competitor’s UI or interaction pattern, or that of a completely unrelated business. Development teams were pressured to deliver under time and budget constraints that left no room to implement anything other than lowest-common denominator functionality. While there was a whole lot of effort and activity, no one was certain whether any of this was the right thing to do. As a client of mine likes to say, “the urgent trumps the important.”

My experience has been that typically the three big questions I talk about in Think First are never asked, or at least never explored to the degree they should have been:

1. what’s worth doing,
2. what exactly should we be creating, and
3. what value does it provide?

Knowing why you’re doing something is the first step in making something of value. And when you don’t take the requisite time to ask and then qualify the answers, you build something that people either don’t need or can’t use. You’re solving the wrong problems — even though in some cases you’re doing so really well!

It’s so important to know why you’re embarking on a project. Of course, it’s important for us to remember that realistically, some organizations’ primary reason for creating things might be to “be successful” or “make money,” or even to “make a difference.” How do you recommend designers convert these vague goals into more specific strategies?

You press the people in the room for specifics. And as I say in the book, until you get specifics, you keep asking questions. And you explain why specifics matter. For example, with enterprise clients, I’ve had the following exchange many times:

Client: “We have to make this responsive.”
Me: “Why?”
Client: “So people can use the site on their mobile phone.”
Me: “What part of this data-intensive system will anyone really be willing to
look at on a six-inch screen? What specific interactions do we think they’ll
be willing to undertake in this format?”

I often get silence after that question. But the reason I ask it is because “responsive” isn’t a measurable goal. So I usually give them an example, something I’ve experienced before or that a colleague has shared with me. For example, I tell them that I might learn that the company could save $600 for every one of its 3,000 employees who complete an onscreen process they’re ignoring now. And maybe we would then find out that while they hate the internal system, simplifying it on a mobile device may get somewhere around 63% of all employees to do it. Now we’re talking about saving $1 million and change semi-annually. That’s a clear target, one we can focus on. And more importantly, one they’re willing to invest time and money into researching and solving.

The light bulb goes on when you tell that story. They understand why you’re being a pain in the ass, and they see how taking time to be specific could benefit them.

You do that in a polite, respectful way, mind you. I take great pains to remind clients that I’m not pressing because I want to make their lives difficult: I’m doing so that when they pull the trigger on a significant investment of time and money, they can do so with some peace of mind, with certainty that a real, measurable business problem will be solved as a result.

That’s a great place to get to with a client. You also suggest comparing the top business goals of your organization to your competitors. Of course, the challenge there is that we can’t see the competitors’ process, but only their output. How do you recommend a designer determine the business model of a competitor?

When you don’t have access to any intel on competitors, you use the Internet. If people either radically love or hate something, you will find a wealth of evidence confirming that online. Facebook and Twitter alone are littered with praise and criticism for both B2B and B2C products. Any Google search on any business, product or service will return a mountain of forums and blogs and support websites filled with evidence.

And while you will certainly have to take some of what you read with a grain (or pound) of salt, when you do enough digging you will absolutely start to see patterns. Repeated instances of the same issues, over and over, people praising the same good and complaining about the same bad. So you can get a pretty reliable read on what competitors are doing right, and where they’re screwing up. But it takes time — you really have to dig, spend a significant amount of time sifting through hundreds of instances.

In your introduction you actually point out many important questions to consider for the user, including “how does using our product fit with other products they may be using?” This is even more important in today’s Internet of Things (IoT). Can you speak to some of the challenges in designing amidst the IoT?

I think the biggest challenge for everyone — from product owners and BAs, to designers, developers and the businesses they serve — is to have the requisite time and resources to widen your scope enough to consider these things. In Think First I talk about the fact that there are a number of naturally competing forces at play in any project: preconceptions, personal opinion, politics, time, money, resources, and more. And all of those force all of us to be really judicious about how we spend our time and what we spend it doing. That’s real pressure, and it often results in what I described at the outset of our conversation: not enough time spent asking and answering strategic questions, asking why, exploring the larger issues.

The IoT essentially amplifies the fact that nothing is used in a vacuum. Nearly every tool we use, digital or otherwise, is used in conjunction with a multitude of software and hardware additions and variations. Sometimes those are things your app or system should be doing, so people can use one tool instead of three. At the same time, sometimes those are necessary complements, because you’ll never be able to provide what those other tools can. And rolling out something half-baked is often a recipe for disaster. You can’t unseat the king of the hill unless you are superior in every way — and if you’re not, you’ll just get yourself hurt. I’ll give you an example.

I worked with a client awhile back who wanted to add an unrelated feature set to their core product, in order to capitalize on the popularity of a specific app their customers were using in conjunction with theirs. I advised them to qualify the idea before committing to such a large bet. Their plan didn’t involve nearly the amount of upfront customer research and prototype testing that was necessary to qualify the idea and figure out whether it was worth doing.

What I told them was this: “unless you roll this out in a way that is absolutely, unquestionably superior to that app — in form, function, ease of use — you’re going to waste a great deal of time and money and capture none of that market. If you don’t want to commit to validating the idea, spend the money improving some other area of your business.”

They did it anyway, their way. Several million dollars down the drain on features no one used because — you already know the answer — it was faster and easier to use the other app.

So frustrating! Of course, doing all of the necessary research would probably have convinced them to add quite a bit beyond the original scope of the project. How do you recommend a designer help to keep clients within the scope while also maintaining the strategic goal?

This is one of my favorite topics, and it could be my favorite part of the book! I think there are two parts to managing scope with clients.

The first is that you have to make sure you do a good job clearly establishing scope, down to the most minute detail. A lot of folks tend to rush into the design and development process without really, fully understanding everything that the finished product needs to do. In most cases, what happens is that no one raises the red flag when they first start feeling uncomfortable, that little voice that suggests something is amiss, that scope isn’t clearly defined. That something isn’t possible or just doesn’t make sense.

As I say in the book, silence is almost always interpreted as agreement — and that can get you in trouble. So if you say nothing when that voice in your head pipes up, you’re not only agreeing that all of this is the right thing to do — you’re agreeing to do it.

The second part of managing scope is that you have to be willing to act as the gatekeeper, the person who politely but firmly says “no” to additional requests that are outside the established scope. You can’t take those requests personally, you can’t internalize the pressure to do them to make someone happy. You have to hold your ground and say no. Otherwise, every little addition is another cut, another injury, which in case we are talking about employees, you might want to be sure to have a good work accident attorney on your side.

Thank you so much for talking with us Joe! Before we say goodbye, how do you recommend our readers begin the journey to thinking first?

First, let go of the idea that you have to be right. Don’t get yourself locked into the idea that you have to know, at every point in a project, exactly what your requirements are, exactly what will result in the best UX or exactly how something should be designed. You don’t, and you shouldn’t be expected to. You don’t miraculously have that intrinsic knowledge; you get it by investigating, by being willing to try some things and be wrong and learn. You’re not the smartest person in the room and you don’t have to be. Learn to collaborate instead, put all the brainpower in the room to work. Be patient, be flexible and remember that there is always more than one right way to do something.

Second, something I say often, both to myself and to young designers and developers: let go of the idea that success comes from being fearless. Forget the idea that successful people are somehow fearless in their endeavors. That’s not true. People who succeed are almost always feeling more fear than they think they can handle, and they dive in and do it anyway. And even if you do get your nose broken, you’ll learn that it doesn’t kill you and that, in fact, the next time is a lot better from having had that experience.

So in whatever you’re doing, allow yourself to feel the fear — and then do it anyway.

Joe Natoli is the author of Think First: My no-nonsense approach to creating successful products, memorable user experiences and happy customers. His online UX courses serve over 30,000 students, and he has consulted with and trained Fortune 500 and 100 organizations for nearly three decades. His articles, tips and advice can be found at givegoodux.com.

Readers: want to get a free copy of Think First? Enter our giveaway!