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.
9th September 2015 @ 7:52 pm
Great Q&A. A lot of sites and services seem to forget about the importance of the long wow, and everyone in an organization should be focused on understanding and improving the User Experience (UX). I appreciate your work, courses, and blog very much Joe. As Product Manager who loves creating products and services, you have helped me in many ways. Best of luck with the upcoming book launch, I look forward to reviewing it and buying it!
9th September 2015 @ 8:10 pm
Interesting questions and great answers. the question regarding customer value is an important one. Differentiating between what you or a client thinks the value of a product or tool or service will be is one thing, but it is what the end user believes to be true that matters most. It should be the end user that drives most decisions and this is sometimes lost. Good point.
9th September 2015 @ 10:30 pm
Interesting points on the three core attributes of desirability, feasibility and viability. All key to understanding the strategy for building a product users want and are will to use. It takes a right balance of each to sustain the test of quality and time. Overall I appreciate your Think First approach to UX.
9th September 2015 @ 10:58 pm
Think First, love that message to take a step back and not just use our gut or preconceptions. I have had the privilege of working with a small client and growing together. Can’t wait to apply this her business.
9th September 2015 @ 11:01 pm
As a fresh Web Developer coming from the InfoSec world of IT, I found all of Joe’s advice, suggestions, and lessons extremely valuable when I took one of his UX Design courses (he now has a Master UX Design course that I’m now taking also). I’ve read a lot of material related to UX and I found the way he delivers his lessons to be the most easily understood and they make so much sense. We’ve all been witnesses to a lot of companies or organizations that have made terrible decisions when it comes to delivering their products or services, and we’ve all seen them fail tremendously. I’ve mostly seen the cause of their failure boil down to someone (or a few) in their organization who did not THINK FIRST!!
I can’t wait for Joe’s book to come out cause I’ll be one of the first in line to buy it!! And I highly recommend anyone who’s even remotely interested in delivering a successful product or service (no matter what field or industry), to do the same!!!!! Good luck Joe!!
9th September 2015 @ 11:09 pm
I cannot agree more about the concept of Strategy > UI/Engineering/Just about anything. If you don’t know the five W’s of your project, what do you have? Art, Engineering and Project Managers would all not have proper focus. Having proper strategy leads to proper documentation, a laser focused scope, and a usable UI. Great Q&A!
9th September 2015 @ 11:29 pm
Mr. Natoli told here some very useful information. UX is about users (from that the ‘U’) and the user’s needs have to be the main subject of UX. In the real life, many products are great looking with great features, but when it comes to use them, one can be frustrated, because these “great” products are so unusable. If people would think first about users, their needs and possibilities, I believe, there would be much more really great products. After I read this Q&A with Mr. Natoli, I hope and believe the book Think first will help them both, makers and as a result users.
10th September 2015 @ 2:23 am
Very practical and meaningful advice. I thoroughly enjoyed reading the article. I am certain that anyone working in the tech industry will be able to relate to all the challenges discussed above. I was particularly impressed with the explanation of feasibility vs viability and “requirements aren’t features”. I couldn’t agree more !
I wish Joe the best and really look forward to his new book “Think First”. A must read for designers and developers alike.
10th September 2015 @ 5:42 am
Sometimes we are accelerated and we forget the most important thing in a project, “think first”.
Good interview. I’m very excited to read the book.
Niyati Gupta Jain
10th September 2015 @ 5:52 am
Finally, we will have a book to help us strategize projects! Thanks Joe. We often start creating user journeys, personas and even wireframes before getting all the answers to ‘Why’ questions, perhaps this is because we do not know how to articulate what ‘Why’ questions we need to ask our clients or project stakeholders. Also, very little time is spent assessing how we will eventually measure the success of the project, we only think about this later – and all this needs to change. I look forward to the book launch of Think First and to learn how to build a focused strategy for future projects.
10th September 2015 @ 3:52 pm
Weighing desirability and feasibility as they relate to deliverables is always a challenge. Compromises always have to come into play.
10th September 2015 @ 4:18 pm
“….people often confuse requirements with features, but they’re not the same thing.” Thanks, Joe! I try to stress this point with the business groups everyday.
11th September 2015 @ 3:19 pm
This was a great round of Q & A. It’s great when someone has so much experience and success in a field and they are willing to share their expertise. Think First – ” great UX starts between your ears”, what a strong and powerful message. The article offers such valuable information, I can’t wait for the release of the book.
11th September 2015 @ 8:20 pm
I am a recent graduate and I think it should be introduced in Italian University course which covers these topics. I will read the book and finally go into this interesting topic.
I believe that to be an excellent web developer user experience studies are needed.
Thanks Joe and Good Luck!
13th September 2015 @ 9:38 pm
The golden question of UX is WHY. If you don’t know the why, then you haven’t “thought first.” Requirements aren’t features. UX is everyone’s business. Solid points from a well versed subject matter expert! Great interview! Hoping there’s a part 2!