Q&A with Joe Natoli – Author of Think First

8 minutes read

Joe Natoli likes to call himself your friendly neighbourhood UX Evangelist (just like a friendly neighbourhood superhero, every neighbourhood needs one). In-between training students in the mythical art of UX design and strategy; and helping enterprises to harness the power of UX to strengthen customer relationships he likes to write about UX on his rather splendid website givegoodux.com. And as someone with 26 years of experience consulting to Fortune 500 and 100 organisations Joe has a huge wealth of UX insights, help and advice to dispense. Fortunately he has now made tapping into his vast mountain of knowledge and experience that bit easier because he has condensed a massive chunk of it into his upcoming book titled Think First: My No-Nonsense Approach to Creating Successful Products, Memorable User Experiences and Happy Customers (available from the 5th October 2015).

In Joe’s own words, “I truly believe Think First is unlike any other book on the subject of UX strategy and design. I didn’t want to write yet another book that covers the narrow, tactical pieces of the design process. Why? Because great design and great UX are the result of multiple activities across multiple people, roles and disciplines. It’s everybody’s business. Think First walks you through everything that must be considered to create great UX — and gives you a roadmap to make it happen. Think First details my no-nonsense approach to creating successful products, powerful user experiences and very happy customers. I share countless lessons learned from my 26 years as a UX consultant to Fortune 500 and 100 organizations — including a few I’ve learned the hard way ”.

I’ve had the pleasure of tapping into Joe’s vast mountain of knowledge and experience by asking him to elaborate on some of the UX and product strategy topics he covers in the book.

Firstly, why did you call the book Think First?

I wrestled with this for awhile, to be honest. I wanted something short and sweet that encapsulated my overall message, what I was trying to get across. And the whole point of the book is to hammer home the idea that great UX starts between your ears. It isn’t the tools you use, it isn’t what you build or design onscreen. It’s how you think about those things. It’s really the thinking that informs those decisions, because every choice you make — from platform to requirements to features to functions to UI design, coding and testing — has a massive impact on UX.

What I’ve seen in my nearly three decades doing this is that when there’s a UX failure, one that’s really hurting the organization or its users, the cause is a lack of time and effort spent considering what I call “why” questions. Why are we doing this? Why does it matter to us, or to users? Why do we think it’s useful or valuable? Why does this problem need to be solved?

When there’s a big problem, it’s because nobody spent the time to think before they acted. So the title of the book reflects my way to rectify that: Think first. Act next.

You say in the book that anything that was ever worth doing started with a strategy. Is strategy more important than actual UI design or coding?

Yes. Because if you don’t know why you’re doing something, then the chances are very good that you’re designing and building something that people either (a) don’t want or (b) won’t use. Designers, developers, product owners, executives and the like often have a laundry list of functions and features in mind at the outset of a project, but those items almost always benefit from being re-examined. Who wants these features, and why? How do we know? What have we observed (rather than heard) that suggests these are strategically important to success?

The other thing that has to happen to come up with strategic objectives is to force everyone involved to answer this question in great detail: What IS success for this endeavor?

What does it look like, what concrete things happen a result, and how will we measure them so we know if it’s working? Does the sales curve go up? Does employee efficiency or utilization increase because the system saves them time? Can we make better decisions because we have a clearer picture of where our money is being spent?

My point here is that the very first thing we have to ask is “what is success?”

Once you have real answers to that question, you look at each possible or proposed feature or function and say how does this element contribute to that success? How does it provide perceived value to a user, to encourage use? And if they act, how do those actions bring value back to the organization? The point of Think First is to clearly demonstrate why this matters so much to great UX, and give people a guided roadmap for making it all happen.

In the book you say that innovation lies at the crossroads of three very specific attributes: desirability, feasibility and viability. What’s the difference between feasibility and viability?

The simplest way to explain the difference between feasibility and viability is this: feasibility addresses everything that has to happen just to create something, from Day 0 to launch. Viability addresses all the things you’ll have to do to ensure success after it launches. So:

Feasibility means “do we have the resources – time, money, people, expertise, etc. – to actually design and build this?”

Viability means “once it’s built, will we be able to sustain it? Upgrade and improve it? Keep people interested and/or satisfied using it as competitors emerge?”

I’ve heard you say that “Good UX is everybody’s business.” Does that make the role of “UX Consultant” or “UX Designer” potentially redundant?

This question actually hints at a larger problem that exists in organizations — the common thinking is often “well, if we hire some ‘UX people,’ these problems we’re having will go away.” The truth is those problems will stick around until everyone learns to filter the work of their specific role through the lens of good UX. So yes, I am definitely saying that UX needs to be seen as a philosophy and an approach first.

When I talk with clients at the outset of a consulting engagement, I explain to them that I’m not there to radically change their existing processes and practices (which, by the way, never works). I’m there to change the things their teams think about before they make decisions, before they act. The tactical stuff stays the same, but the decisions get smarter and more meaningful, because now everyone’s stopping to consider how what they’re about to do affects the UX.

I don’t think you ever stop needing specialists, people whose expertise is focused in a specific area. Nearly every area of life benefits from someone who’s had deep experience, someone to point the way and refocus things (and people) when they go astray. That need never goes away.

Rockets launched into space veer off course repeatedly throughout their journey. And while they are capable of course correction, some of that is always done manually by human beings monitoring what happens.

While people can and should learn to course correct themselves, there will always be a need for them to have someone to lean on when they can’t figure it out, or when the right course isn’t obvious.

You talk about the “Long Wow” concept in the book. In your opinion is programmed obsolescence part of the “Long Wow” concept?

I do think planned obsolescence is often a component of Brandon Schauer’s “Long Wow” idea, which I explore in Think First. Without some purposeful limitation or lifespan, motivation to try the next release flags a little.

The next new thing is always the carrot on the stick, to be sure — but that carrot looks a whole lot better when the one you have now is underperforming in some way.

That said, balance is important: companies that err on the side of creating a poor product so people will buy the update usually receive a very swift and equally fierce backlash. You cannot deliver too far below expectation, because users know there are other choices; they know they don’t have to be your guinea pig. Microsoft learned this lesson the hard way, and Apple is starting to experience a bit of the same.

The core product has to be sound, and those incremental changes have to be meaningful. Otherwise, people very quickly get the idea that you’re simply after their wallet and could care less whether the product actually helps them in some way.

You talk a lot about uncovering customer and business value. How do you find out whether what a client is asking for is actually valuable to users?

The value to users depends entirely on what they expect from the product to begin with. It doesn’t matter what you or the client thinks that value is — only what users believe it is. Whether or not they perceive that value exists. For example, if you’re looking at a specific requested feature or function, ask yourself if it would help a user or customer:

• Save time?
• Save money?
• Learn how to do something?
• Automate and simplify a complex task?

If the app/site/system does those things, value is provided.

If it doesn’t do those things, doesn’t meet their expectations — they don’t see it as useful or valuable.

My point here is that you cannot really deliver value until you know what users want and expect from the product — what constitutes value in their minds.

I’ve heard you say that requirements aren’t features…can you explain what you mean by that?

Sure. I’m speaking to the fact that people often confuse requirements with features, but they’re not the same thing. My take is this: requirements, if done right, should only describe what needs to happen; if they’re stated as solutions, something is wrong, because at that point in the project you don’t know enough to suggest solutions — and if you’re doing so, you’re guessing. I talk about this at length in Think First.

Requirements can and do suggest features — but they are still questions. Some of the questions posed by a requirement, for example, are:

1. How important is this?
2. How will we actually create this?
3. How realistic is it that we can actually implement it (with all the other things we have to do)?

By the time you get to wireframing or prototyping, even if only on paper, you’re looking at the possible feature (or features) implied by the requirement. You’re socializing it and testing it to see if it makes sense — and whether the requirement that says we may need that feature makes sense as well!

My point is that you have to go through that process in order to determine what to spend more time and energy on. There’s no way you’re going to have a definitive solution at the outset of the project, and to assume so will usually hurt you (or your client) down the road.

You say that good strategy starts with research. Any advice when it comes to talking to users?

The most important thing to remember when interviewing users is to ask open-ended questions about how they do what they do.

Leave the “what” out of the equation. Everything you need to hear from users and clients should be focused on (1) motivation and (2) expected outcomes/results. Features, functions and interactivity should be derived from those two things.

In other words, you ask “walk me through how you accomplish [ task X ].” No more than that. You don’t want to say “how do you you use [ system or specific tool ] to accomplish task X?”

That’s because the second question is leading — it focuses their answer on the tool instead of the process. You want to know what they do with or without the software in question. If you provide too much detail in your question, constrain their context, you won’t hear about all the things they do outside of the software to get the task done. If you’re too specific, you won’t hear about the workarounds they’ve created that will suggest new features, new functionality or changes that need to be made to workflows. And in my experience, those are the things that present real opportunities for improvement.

More about Joe’s book – Think First

More information about Joe’s book, including a sneaky peek is available at: givegoodux.com/think-first.