The Not Unreasonable Podcast

Robert Hoekman on The Tao of User Experience

April 13, 2021 David Wright
The Not Unreasonable Podcast
Robert Hoekman on The Tao of User Experience
Show Notes Transcript

Since joining the technology business I've had a whole variety of mental upgrades but Robert Hoekman has given me the chance to dig into what may be the most profound of them all: design. In the world of software we are confronted all the time with how feeble our minds are when tangling with reality. I think that the core mistake at the heart of bad software is that we humans are pre-programmed to believe our own BS. 
User Experience research lives and breathes human cognitive frailty and Robert Hoekman is an absolute master. He has written many books, in this episode we talk about The Tao of User Experience. A small, tidy phenomenal work that sits on my desk and from which I read nearly ever day. 

show notes:
https://notunreasonable.com/?p=7320
youtube:
https://youtu.be/-lyxd9E4lJM

Twitter: @davecwright
Linkedin: https://www.linkedin.com/in/david-wright-73661214/
Social Science of Insurance Essays: https://notunreasonable.com/the-social-science-of-insurance/

David Wright:

My guest today is Robert hoekman, Jr, an innovation strategist with two decades of experience in product design, UX design thinking product design methodologies, Lean principles and rapid experimentation. He is the author of several books, including the acclaimed bestsellers, *Designing the Obvious* and *Experience

Required:

How to Become a UX leader, regardless of your role*. Today, we're mostly going to talk about another book of

his:

the Tao of User Experience, which is awesome. Robert, welcome to the show.

Robert Hoekman:

Hey, thanks.

David Wright:

So first question, organizations have goals and objectives. And once they have these, they tend to think through how to hit them. And that thinking is called planning. So it strikes me to be a pretty, pretty reasonable thing to do, planning. But let me read the preface to this book. Just so we're clear goes the text at design is a plan to design is to plan a designer is a planner. Now my question is, can a company plan to innovate?

Robert Hoekman:

Wow, that's a great opening question. Can a company plan to innovate? I think absolutely. And it's really easy to do, actually, once you dig into the process of strategizing and innovation. So for me, that starts by basically diagramming what the current reality looks like. You know, a lot of startups talk about the idea of, you know, falling in love with your market before you fall in love with your idea.

David Wright:

Interesting.

Robert Hoekman:

I think the same thing is true in enterprises, in startups alike. But the idea is, you know, go figure out what problems currently exist in your in your market? And then diagram those out and say, okay, where are the problems within that, within that current reality? And once you've identified a problem and a market, who cares about that problem, you have an opportunity to innovate? The delta between those two points is, is your is your space for innovation? And from there, it's a matter of identifying, you know, what potential solutions might exist to those problems? How important are those solutions? how critical are those problems that you're basing the solutions on? How big of an audience do you have for those potential solutions? And then, you know, starting to prioritize them and figuring out you know, which, which ones you're going to try to take on first? And how are you going to get them out of the world and prove that they're good ideas? So that's kind of the the long answer, but the short answer is, yes, I think you can absolutely plan to innovate, as long as you have a market with a problem that has not yet been solved, or has not yet been solved? Well, you have an opportunity to go after that and do it better than other people haveseen.

David Wright:

One of the challenges I have with this is that to a certain extent, it seems to me that the innovation process is kind of open ended. Right? So you don't know, if you're going to come up with a solution, right? There's an inherent uncertainty to it. And the exploration process might not conform to your your pathetic human need for things to happen during a timeframe, an arbitrary, you know, number of seconds in a year or whatever, months, minutes, days, months. Right. So like, I feel like there's something threatening to planning that comes from not knowing the answer.

Robert Hoekman:

I see. So we're talking about time constraints and things like that. I mean, roadmap.

David Wright:

Yeah, sure. Right. Because like, if you think about I mean, I set the question kind of particular way, because thinking from like a perspective of like a financial planning and analysis person, the people who run the corporate plan, right, they say, goal is like, it's not some high minded thing, we want to solve problems, you know, you know, generate some social benefit, right, which is really what companies do, right? They bring something to the world that the world wants, but they you know, they care about that. But they don't care about that, because what they want to do is they want a number and a bunch of numbers, and they're really important hitting those numbers. And, And to me, that's I like, the idea I want to play with a little bit here is that we're using planning in a couple different ways, kind of, I think, and I'm really intrigued by that tension.

Robert Hoekman:

Yeah. So that's, that's an interesting point and an interesting angle. So So yeah, you're right. Ultimately, businesses always care about numbers. Ultimately, businesses only care about numbers. And this is something I actually talked about pretty often, I think, ultimately, every project I've ever worked on, and every project that probably has ever existed in the UX space, in the software development space in the tech space has been about one of three goals and those goals are making more money spending less of it or both. Sure. And everything you do can be mapped back to one of those three goals. And so planning, you know, very often for a company comes down to well, how much money do I need to invest in a certain amount of time to get x outcome. And to that extent, it can be very difficult to plan innovation because you don't, you can never truly know if if the thing that you put forth into the world is going to stick or not if it's actually They're going to be an improvement over something until you do it until you actually put it out there. And until you actually get an audience for it, it's all speculation until you actually deliver something. And that's something I've been saying for, I think, 20 years. It's all speculation till you put it out in the world. So, so planning innovation, according to a deadline is a tricky proposition. However, planning, planning objectives, according to a timeline, I think is much more reasonable. Because that, so that's sort of a pivot in the thinking that I think helps free up the logjam there a little bit. So you can't necessarily say, Oh, I'm going to put out X, Y, and Z features over the next three months. And that will be our innovation, and we'll have done it, yeah, you can't really do that. What you can do is say, in the next three months, I would like to improve our conversion rates by 5%. and improve our retention rate by 6%. You can set that kind of an objective, and then pursue any and all reasonable paths toward achieving that. So don't constrain yourself or pigeonhole yourself into a particular solution. Figure out what it is, you know, what is the business objective that you're chasing after, and then look at any and all paths that that might take you there? I do think that very often, I mean, it's, nothing's ever guaranteed, but but very often, more often than not my experience, when you when you focus on the objective, rather than on the thing that you're going to build. And you open up multiple paths to achieving that objective, it becomes much, much more feasible to to accomplish that objective in a certain timeframe.

David Wright:

So allow me to read book *Tao of User Experience*, "the problem expressed by the user is almost never the real problem. The real problem is almost never the first one you identify, or the next, or the next." I love it. I mean, it, you know, back to this idea of open endedness. Right, like there's this sometimes a really deep hole, you got to go down, because the layers of misperception can run deep, which is why it's so hidden. Right?

Robert Hoekman:

Yeah, that's absolutely right. It's, it's, it's so funny to be talking about this book, because I seriously haven't even picked up a copy and looked at it in, I don't know, three or four years. So hearing these, hearing these things like I, one thing I'm glad about so far is that everything you've said is still something I absolutely 100% believe my opinions have not changed that the foundation is still in total agreement with my past self. That's nice. But yes, the the problem that you uncover is very rarely the problem. And this is chronic in product development. And it is the number one reason that critical thinking skills are so incredibly pivotal to successful product development. Because there are frameworks like critical thinking frameworks, too, that are meant to help you get to the core, the core of the issue, right? So very often, the problem that we'll hear about from a customer from a user from a business person, what have you is something very at the top, it's it's the symptom of a problem. Yep. And if we, you know, go about tackling that problem with a solution at tackling that problem as it's been framed with a solution, it will ultimately a band aid be a band aid, and it could actually make things worse. And that actually happens a lot. So one idea from from critical thinking, and actually, yeah, is the idea of the five why's and so like, that's a very simple framework, you know, ask the five why's Well, why does this occur? Well, why does that occur? And keep digging until you find the root cause? It's actually part of root cause analysis and critical thinking. And the reason to do that is because you'd be stunned just how often nobody knows or nobody has asked that the question before. So if you are the one asking why, why, why, over and over again. And I think I've written about this multiple times in my life. If you're the one asking why over and over again, you will almost invariably find out that no one has asked those questions previously. And you will almost invariably land at the root cause of the actual problem that you're trying to solve the actual business objective. That could be attained by solving it, the actual stakes, you could be the one to figure that out. And when you are the one figuring that out, you get to drive the conversation. So now, you know a whole lot of projects I've been involved with, you know, when you ask that question enough times you find out There's no there there. You may find out though, you know what, there's actually not a good reason to try to solve this problem. It's not an actual problem, we just thought it was. But once we dug into it, we found out the real problem is something else. And we can solve that by doing something else entirely. And so, yeah, it's incredibly important to me, and I talk about it a lot. And I think I lead by example, by doing this, all the time in projects, asking those questions and pushing, you know, pushing through what I hear, to try to find out what's behind it, and ultimately get to the, to the real heart of of a problem, so it can be solved. Clearly, a lot of times, the problem we hear about, again, is a symptom. And when you solve the real problem, the symptoms just disappear.

David Wright:

So let me let me kind of do one more of these. And this theme has a bunch of really cool the themes in the book and to to this to this world of UX. So human beings do not know why they do what they do. They do not know what they would do in hypothetical situations, observe, it is the only way to learn. Yes, they don't want to lie to you. But they do and to themselves.

Robert Hoekman:

Yeah. And that's very well said, they don't intend to lie to you. People don't intend to be terrible self reporters, and to say that they would do one thing and actually do another, they don't intend to do that. People are just really bad at self reporting. You know, it's very hard for us to imagine, when were in an interview situation, talking to a researcher, who's asking questions about a hypothetical situation, it's really difficult for us to honestly come up with the right truth. to that question. Things are very different in those contrived situations of, of interviews and research interviews like that, than they are in real life, when we're facing real circumstances, when we're in the middle of doing 10 different things at once. And, you know, now my job is actually dependent on being able to complete this task, let's say, and it's a very, very different thing. So there's always this is a gap between what someone thinks they're going to do or say, or think or believe or react, in a in an interview, then how they actually do it in real life. And so in solution development, that's, that's a really key thing to accept, and to embrace, and to try to mitigate against, by, you know, using those those sort of qualitative and interview type research situations to inform a solution, but then actually truly evaluating that solution by putting something out there and seeing how it plays out in real life.

David Wright:

So that I mean, you mentioned critical thinking skills a minute ago. And I really, I don't like you using that term. I'm sure it's perfectly accurate. But to me, it allows the listeners of this podcast to kind of slot this into Oh, this is something I understand, because I've heard of critical thinking skills before, right? And probably even many take a course on it, maybe even use them once in a while. But I just find that there is something so deeply contrarian to the kind of culture you need to be a part of to be a great you like, you know, I think there's only one, I don't have it open the page. But there's one of the quotes in here, which says question everything, absolutely everything, right? And not just some things, not just things that are important, like absolutely, like, you have to be willing to deny to be the ultimate skeptic, right? And that, to me is like, really, I'll use the word subversive, right? to like, institutional authority, like you walk into a business or anybody who has a problem, and you start questioning everything, people can be threatened by that. And you have to be successful at this job. It feels to me like you need to be able to be immune to that kind of social pressure that they put on you to conform to their concepts, right? Because, you know, they don't know what the heck they're doing or why they're doing it. But they don't believe they don't know, they think they know, you know, I'm a big successful businessman. I know what I'm doing here. You don't nobody does. It's not just you. It's everybody. And it's like, you know, and I have to think that that you've had circumstances where you felt uncomfortable because of what you felt you needed to do to pursue the truth.

Robert Hoekman:

Yeah. So there's a lot to unpack in that response. So yeah, critical thinking. First, let me let me go to that first point. So critical thinking is definitely one of those things that I think a lot of people believe that they understand, much in the same way that user experiences. It's one of those terms that can be used very glibly, and thrown around and not really defined. And as long as a group of people refuse to define it. Everybody in the group can define it differently. And they can walk away with their own interpretations and their own understandings and, and what have you. And as long as that term goes undefined, then it's you know, everybody just sort of projects onto the term what they want. I always equate it to the mask of Michael Myers, because it's the blank face, and you can just whatever fear you've got even planted on that face, the exact same thing is true for the term user experience and the term of critical thinking. I have heard the term critical thinking thrown around, thrown around a lot, you know, and everybody goes out. Yeah, but yeah, we really need to do some critical thinking about this. But what does that truly mean? You know, I don't know how many people have actually taken courses in critical thinking, how many people have actually really learned the rigor of critical thinking. And it's an incredibly important skill. I mean, it basically, I mean, it applies in all sorts of ways. But it's basically, you know, one huge strategy to critical thinking is like, you know, identifying a real problem identifying what the key success factors are identifying potential pathways to achieving it, which attributes of those potential paths are most important. And then, you know, which are the most feasible and which ones contain elements of risk, and how much risk and how much risk you're willing to absorb? And, and basically, like, you know, crafting a pathway forward by answering all of those questions. And so when I say question everything, absolutely everything. That's what I mean. So like, you know, first let's talk about the problem, every part of the critical thinking problem solving path involves a different set of questions. And this is something that I think of as diagnostic inquiry, in fact. And the idea is, you know, when you're defining a problem, there are a whole bunch of questions that ever get asked. So just to make this, you know, really concrete, just in one specific phase, there are a whole bunch of questions that never get asked such as, who said that this is a problem? Why is it a problem? Are the people who said it's a problem? Are they are those people important to us? And why? And how do we know it's a problem? And what are the stakes of the problem? And do we need to solve the problem? And how well do we need to solve the problem? And what happens if we don't solve the problem? There are all these basic problem definition questions that most people just skip right over. Right. And we do that in a lot of situations. And we go, Well, we think this is a problem when we think this is the solution go. And then we just go flying into action. And so that's partly what I mean by you know, question everything. And that's definitely what I mean by critical thinking. To the other part of your, your recipe on when to go about the the social pressure of questioning. I am starting to think, Hey, I don't know what's on the next page in that book. I have no memory of it. But I'm wondering if maybe it should have been, you know, do it artfully?

David Wright:

I don't think so

Robert Hoekman:

Because there's a there's a way to go about mastering everything. It's not just brute force, you know, being antagonistic. That never gets anybody anywhere. But there is a way to, to ask these questions in an honest and genuine way. And in a humble way, that will earn you respect. I mean, it's basically I mean, if you think about that, put it let's put it in context of the Socratic method. So Socrates is legendary, as a philosopher, because of the Socratic method, which is basically all he ever did was ask his students questions, and then more questions, and then more questions until they revealed till they came across and revealed their own flaws in their thinking. And at one point, you know, he was while he was alive, he was revered as the wisest man alive. And he was like, how can I possibly be the wisest man alive? All I ever do is ask questions. You know, he never actually posited anything, just asked people questions until they came to their own conclusions. So the Socratic method in a in a solution development context. For me, it works very much like that, you know? So it's basically about, you know, asking those questions humbly, really just being open and curious. And, and also knowing what kinds of things that you need to know in that situation. So let me try to make that concrete. So I'm working on a project right now, where a business person has decreed to a team this thing should be done. Over the next three months, you should devote all of your time to absorbing this product over here into this product. And no one on the team can actually figure out why that is. At first no one on the team asked why that was. They all said okay, we're gonna go do that and then started planning for it, and then someone on the team started asking questions about it, which was, oh, okay, well, if we're going to do that, then what are the business outcomes? Are we going to achieve? That we're going to achieve by? what's what's going to happen as a result of us absorbing this one product into another? And in attempting to answer that question, she quickly found out that like, nobody knew the product manager didn't know the project manager, and the engineers didn't know no one was like, they were all like, but you don't understand our job is to, you know, someone said, this product needs to be pushed into this other product. So we're gonna go do that. That's our job. That's what we're held accountable to. But she said, you know, but what business effect does that have? Because if we know that business effect, then we can evaluate what we've accomplished. That's where meaning comes from, in our work. Meaning is not derived just from doing the thing that we were tasked with doing. Meaning comes from attaching the work that we've done to the effect it had. And she was asking that question, what is the effect that we're going to have? And it turns out, no one knew the answer. And it turns out, the more digging she has done, the more she has come to the conclusion, they're actually not only appears to be no good reason to do this, and to absorb one product into the other. But they're actually, it actually may be a bad idea to do it. Because doing it may expose this company to a legal risk that no one had thought about yet. And if you look very glibly at the reasons to merge this old product into the new one, it was you know, it was basic stuff like, Oh, this product fits into this category. So that should work the same way, the same team can support it, or, oh, this product over here, it doesn't currently have a development team behind it. So let's put it over here. So it does have the development team behind it. But so that's those are the glib motivations for absorbing one product into another. But the use cases for the users of these two products are wildly different. To the extent that as far as we can tell, at the moment, that it would actually be really bad to push this product into the other one. And but no one had asked that question, no one had, no one had done that. And so just by, you know, this, this, this researcher who kind of went in and started asking these questions, you know, I just want to understand the business impact. So we know what we're going to accomplish and doing this, because that's how we, that's how we measure our progress. That was the approach you took for asking the question, and then it's very non confrontational, it's honest, it's genuine. It's like, Look, I want to know what meaning there is, in this effort for us. And so that we can prove we can come back to you later and say, Hey, we accomplished this Hooray. We accomplished the thing that we set out to do, but we don't at the moment, we don't know what that thing is. So approaching the questioning in that way, made it very non confrontational, which meant, you know, she was able to ask those questions and sort of work her way through a series of conversations. without, you know, just being like, the, the resident antagonist or the naysayer, like she just wasn't, you know, she wasn't just going in there to be combative. She was going in there to find meaning in things. And people respond to that. So so there is an artful way to question everything. And I think it's all about, you know, knowing why it is that you want to know the answers, and just getting people to sort of buy in with your rationale about about why that information matters.

David Wright:

Okay, so let me let me tell you another question that touches on this theme. I there's like several times, which I could have asked this question, I'm gonna nail it now, because I love this and I, myself am still interpreting it. The less important the task is to the user, the less tolerant he is of its obstacles, and the less willing she is to persist through the, this does not mean that we should make the task easier, designed for the common and the important. All selse should remain accessible, but in the shadows, accept the complaints do not adjust for them. What does that mean?

Robert Hoekman:

Except the compliancy damages, okay.

David Wright:

When do you ignore users

Robert Hoekman:

that is somewhat specific, okay. And that's a weird contrary and phrase somewhat specific, but I'm always very concerned with precision in language. So it's a weird thing to say, somewhat specific, but the idea there is that I have seen a tremendous number of designers and product teams, try to solve for making something easier when it does not necessarily need to be easier or it doesn't need to be easier for that person. Or in many cases, it's actually beneficial for it not to be easier. So this is contrary to a lot of what you You know, is trended or brands as user experience professionals, right? The idea that something should not be easier. But think about Let me see if I can come up with a good example. You know, it's gonna elude me at the moment. But let's think about something that might be a setting, or

David Wright:

can I give you can I give you an interpretation? I think I know where you're going with this. Because I was thinking about, I thought about this a lot. And I thought, you know, sometimes there are nice users who are diehard who will do anything to use this product, right. But there's no like gradual slope, to like the general population, nobody else wants it. Other than the hardcore, right. And the hardcore will walk through fire and roll over coals or whatever they have to do to get it. And you know, making it easier for them will not add any more users, it just makes it easier for them. And they're already using it. So there's no problem here, even though there were some things you could do to simplify. don't have that. Right.

Robert Hoekman:

Yeah, that's absolutely true. And I think there are other situations where that applies as well. But yeah, the thinking is that, you know, not every task needs to be easy.

David Wright:

Yeah. Right.

Robert Hoekman:

So for one, think about, you know, let's say you're filling out a complicated tax form or something. It would behoove the company to actually make the user slow down, and actually make sure that they're entering the right information. So you don't necessarily want that to be the quickest thing that happens, you want to be more accurate, accuracy matters more than speed. So easier may not be the right solution. In that case. In other cases, you're exactly right. There might be you know, a certain segment of your audience that is somewhat of a power user. And they are, you know, they they have tasks that they're commonly interested in, but 95% of your audience couldn't care less about. And so should you make that front and center, probably not, you should make it readily available and accessible for the people who are taking advantage of that thing. Absolutely. But putting something front and center that would be disadvantaged or disadvantageous to the rest of your audience, the larger portion of your audience could actually make their experience worse, not the not the least of which reason would be that sometimes, actually, very often, always, when you enable a possibility and a product, you there's a very fine line between enabling and encouraging it. So just because something is possible in your product, because somebody needs it, the fact that it now exists, means that people think they're supposed to use it or that they're, they're now being encouraged to do a thing that they that they didn't need to do, or they didn't need to worry about. And so part of the thinking behind that sort of tenant, and the Tao of user experience was the idea of hiding some of those things, making them available, but not sticking them out, you know, front and center in your product where people are going to inadvertently be encouraged to use them when when it wouldn't benefit them to do so.

David Wright:

I got another one that I love that I just really am fascinated by. And I want to I want to hear you explain expand on this. Great design is not the logical conclusion to research, but the result of courageous belief in what you're doing. What does that mean? The word courageous. There's a lot of moral valence ism in the language in this, which I think is so awesome. And I want to dig into some more of that later on. But courageous, tell me about that word in this in this concept.

Robert Hoekman:

Yeah, that one, I think my thinking at the time was about the difference between research and vision. And the difference between user needs and what you are actually interested in as a business. I have spent a lot of time in my career working with startups, and start startups, you know, especially the founders of a startup. I mean, anybody who has a job is basically saying, I'm going to sign over a whole bunch of hours of my life for this particular audience for this particular product for this particular niche, or this industry or what have you, and especially the founders of a company like they are giving over huge chunks of their lives to this product and this market. And, and, and I constantly think, you know, they have to be absolutely in love with, with what they're doing, they have to believe in their idea. And so there has to be some chutzpah. There has to be some gumption, you know, there's some fierce belief that they're doing something better in the world, they're doing something that matters, they're doing something important. They're doing something that will disrupt an industry make somebody lives, you know, life life better. And when you only focus on, on, on what flows out from the research, you can neglect all that you can, you can end up with stuff that's not that exciting. You can end up going down a track and saying, Oh, well, based on what I learned from my audience, I think, you know, X, Y, and Z would be great solutions. But they're also not that interesting to me as a human being. And if I were to spend five years of my life working on this thing, I need to be engaged. And I need to believe that somebody is going to care wildly about this. And it's not just some, you know, the next boring evolution of, of a thing that already existed. So for me, it's kind of hitting you know, the research against the vision, and also putting the research that you get through the lens of your vision. So the things that you've learned about your audience. I see a lot of companies take what they learn from audiences as gospel. So our audience would like us to do A, B, and C. But our audiences would like to do a whole lot of things that may or may not have anything to do with our product vision, or where we're where we're trying to go. And so you have to kind of put the research that you get through that lens, like what am I trying to accomplish here. And you have to be courageous enough to believe in your product vision, and, and balance that with the research that you get, instead of giving over entirely to one direction or the other. If you come only out of research, you might do something boring. If you go only into your vision, and neglect research, you might do something terrible. It's the overlap between those things, the compliment between those two things that I think is where great products come from, see, you've got to be aiming high, but informing that high aim with, with truth and intelligence.

David Wright:

So I just I it's kind of repetitive to this conversation, but I cannot help it read number 95. All progress depends on the breaking of rules, the questioning of standards, the defying of the status quo, it is not a flight of fancy to do so to achieve anything worth achieving. It is a moral imperative, moral imperative, man, that is powerful language, seek out those who separate themselves from the pack, separate yourself from it as well. That's great. You save that one for 95. I mean, we're so where it is like, where does where does this vision come from? You know, like, because here's what I did, I did an interview. Early on, in my own journey as a, as a kind of UX researcher, I guess, I had this, I had this intuition that, you know, looking from the outside the insurance industry, right, where everybody, everybody is maligns software, because it's a burden to insurance companies to software, they hate it, love hate. But mostly, I used to joke that they're the customer satisfaction rate of policy management system, which is like the sort of technological core of an insurance company was zero. Everybody into this system. Everybody was changing their system. Everybody knows, like this loathsome burden you have to bear. And I thought, you know, what is the difference between these organizations and the organizations to build great software, because there's lots of great software out there. And there's wonderful things that miraculous and I had this sort of feeling that at least somewhere in this product design kind of product management kind of world because that was a function that I just, I just really don't think about. And as I have learned more about this business, I've narrowed it down to really, it's a kind of UX research is the is a critical piece, but it's insufficient, because that helps you mold something, it seems but you know, I was reading this book as a podcast at the beginning of the journey for me, this gal named Melissa Perry called to build treptow link to it in the show notes. But she has this this, she it's an evolution of kind of this agile framework where she talks about how you have this cascading kind of prioritization, right? So the top of the organization, you have something called a vision, a mission, or whatever, right? Some constraining of the world saying we're gonna work on this subset of problems, right. And as you go down the organizational kind of work chart, you kind of constrain that more and more and more and like you're now in this little piece, and you're on this, it all sits underneath the same umbrella, right? It has to in order for the company to hold together, which is what is interesting to me. At the time, I thought the constraint must be grading on the people in the company because they're saying I want to solve these problems. But here you're telling me I can only work on these few things. What I have learned since is that constraints are liberating, right saying now worked within this area and here, here's the sandbox, go figure out how to solve the problems in a sandbox and that somehow is a more powerful Four kind of directive, then the world is infinite. Go figure it out. What do you think?

Robert Hoekman:

Yeah, um, so again, a lot to unpack it that the Yeah, first, I absolutely believe in constraints. I think anything you're doing without constraints is 100%. Creative. And there's absolutely something to that. But even within something that's 100%, creative, there are constraints, you're making formal decisions about the structure of your creativity. There, there are always constraints in a business context and a product development context, like the constraints are where the creativity happens. They are the things that put guard rails around possibilities in a way that enables possibilities. And that's ever realized, pretty abstract idea, but I can't, you know, I can't imagine being being able to do force being being forced to do good thinking in a situation where there are no constraints. Because without that honed focus, what's going to inspire your best idea, unless there are some guardrails around it. So be the the beginning of that, quote, was very much inspired by a headline from Ralph Nader, who was the guy behind the gargantuan effort and it took him I think, years to do this, to get car manufacturers to adopt the idea of putting seatbelts into every vehicle, and eventually became a law right now, they all have to have seat belts, but like that didn't used to be true. And Ralph Nader made it happen. He was a consumer advocate, to the extent that he like he, it took over his life. And and he, you know, at one point in his life, said, All progress depends on the unreasonable man. And I absolutely love that line. And that idea, because user experience used to be an unreasonable idea. And it's no longer true. What does that mean? It used to be unreasonable, because companies thought that design was something pretty on the front end, it didn't really matter if people could use it. And they didn't really understand that people had trouble. They thought that they were hired to be, you know, product engineers, and product managers, and therefore they knew better. And over time, some people chipped away at that idea and said, Hey, it turns out that your users have no idea what your product does. They don't understand how to use it, they're not getting the benefit out of it that they want. And we can prove it. And over time, companies started to recognize that and listen, user experience would not now be the household term that it is if it weren't for some unreasonable people about 20 years ago. The unreasonable people made that important to the companies who weren't paying attention to it at the time and are now. And in in a product context, the unreasonable person might be the one who says, hey, let's stop doing the same thing that everybody else is doing. And let's figure out if that actually solves the problem. And let's go see if there's not something better. The unreasonable person will be the one who asks all of those questions and says, What is the actual effect we're trying to achieve here? And how will our How does our work map to it? How does what we're doing right now? help us achieve that big goal, that big vision? How, how do these dots Connect? And the unreasonable person is often the one who will ask that question, and we will find that answer. And a lot of people it even, especially in situations when a lot of people just aren't answering that question. And so yeah, you know, user experience became popular, became a household term because of unreasonable people, great products have been invented because someone decided to disrupt in your industry, the insurance industry. There are plenty of disruptors right now, you know, like, I can think of several companies off the top of my head for in the life insurance spectrum, where they've looked at the whole world of life insurance and said, You know what, we can make this really painless, we can make it easy we can, we can take on people that other people can't, we've got this new, super streamlined, efficient way to do then they've tried to disrupt the life insurance industry. And they can do that by being unreasonable by saying, we refuse to accept that the current way life insurance works is the only way that life insurance can work. Let's go find out what problems people have with it. Let's go find out how we can do it better. And let's be unreasonable and go after a new vision that ends up disrupting that maybe making things better.

David Wright:

You see, like I I feel like in a lot of insurance businesses. I think a lot of the vision stuff I hear is I wouldn't say it's unreasonable. Honestly, like, you know that what you're saying there Like I, you know, I get it, I understand your point. But is it really so unreasonable to say people should have an easier time reading? You know, I think that's kind of obvious to the point where there's another another quote, you'll have to allow me a second to dig it up as I don't think we're going to come into this one this quickly, but we're gonna find it, or it says, might even just have it. trends, standards, best practices, personal biases, mediocrity, outright foolishness, they are all the same. Right? Which I love that, because, you know, obviously, wonderfully, wonderfully written, because it obviously starts with some things that, well, some things that are mixed, but some of them have purely positive connotation, best practices, standards, right. All the way to very negative connotation, outright foolishness, right? And so I think what you're saying here is that if you aren't thinking for yourself, then you aren't thinking, and you're dead.

Robert Hoekman:

Yeah, that is that is a big underlying theme of that line. Yeah, it's, it's, you know, that's about capturing the idea that best practices are very often not what's best and best practices are very often half baked ideas that grew, that became popular, and scaled. When I first became a consultant, in 2006, one of the first things I did was I spent three months working on some research papers from usability studies, basically, we did like this huge eye tracking study, it was literally 300 hours of eye tracking usability studies around web 2.0 design patterns, okay, such as, like tag clouds and infinite scrolling. And some of these things still, you know, in start pages, things like that back when those ideas were popular. And there were all these, you know, supposed design patterns that were best practices that people had latched on to, and people were perpetuating into all sorts of product products. And we went and studied them. And it turned out like some of them were just ridiculously badly translated ideas like the TED clap, but almost nobody, we interviewed 40 people, you know, across a number of these patterns and tag clouds just fail miserably. Almost nobody understand exactly.

David Wright:

You know, I get it. Like, I mean, I agree. Yeah.

Robert Hoekman:

Like they all thought, Oh, so the bigger darker word means like, oh, the designer wants me to click on that. It wasn't the result of like, you know, oh, this is the most popular of these terms that has been searched. But there was just tech clouds were widely misinterpreted. They had low usability, nobody really understood their motivation. And they thought they were design driven, rather than the result of other people's activities. And but but it was a best practice. Do you remember how prevalent tag clouds were? They were all over the place. It was insane. Yeah. And, and this has been true in every year, every company I've seen since there's some quote, unquote, best practice. That was really a half baked solution that just scaled somebody thought it was cool. And so they, they put it in more than one place. And the next thing you know, it's a design pattern. And then we call it and then we misinterpret a design pattern as a as a best practice. But so So what I mean by that is that outright foolishness and best practices can be grouped as synonyms. Because both because best practices can be outright foolish. And in order to find out if there's any meat on that bone, you have to go dig into whether the best practice is actually a best practice. Let's go study it. And again, with that idea of questioning everything, like let's dig into this and find out if people actually understand this best practice, if there's a better way, how this thing got adopted in the first place, how it scaled how it became a best practice, and if maybe there's some intelligent tweaks we can make to it that will significantly improve it. So yeah, don't just don't just blame the accepted best practices, don't just blindly accept standards, question them to. That said, I do believe there is some merit to best practices and standards and don't throw them out. A lot of them have a grounding in reality. And you know, not all of them, but a lot of them do. And if you are only reinventing things all of the time, you're gonna have a really hard time getting anywhere, making any progress with your product, and you have a really hard time getting people to adopt your product, because there's nothing for them to grab on to nothing familiar, nothing they can assimilate to. So if you throw it completely out, you might be lost at sea. But if you rely strictly on best practices and standards, you will also not be making any headway and you'll be accepting a bunch of status quo decisions that Other people have made before you and that are not necessarily benefiting you or your audience.

David Wright:

So what I think the book has a certain series of themes I alluded to this earlier. But the overall gist of it, I wonder if you agree with this, it's not kind of like, complete and write in a deep sense. Because it's not designed to be I feel like this book is, is sort of your contribution to a conversation, like correcting. It's unforgiving. Right? So the book is relentless and unforgiving. Right? It's, it's forcing us, me to acknowledge the hardest parts, right, and be open about them. And there's some things that are not so hard, which, you know, like your point earlier about, when you said, you know, on the next page probably said, you don't do it nicely. And you didn't set the next page next page to turn to some other kind of deep and difficult and painful truth. Right? And because the nice thing, people can do that on their own, they don't need you to tell them to be nice to each other, like, they will read somebody else for that one for you. It's like, No, no, no, no, we're gonna, you know, we're gonna line you up again, and we're gonna make you run up that hill again, and do something awful, because that's how you get better. And, you know, I think that there's a dual kind of theme, two themes that I think go back, when paired, are especially unforgiving. And one of them is is forcing us to continually realize how ignorant we are about ourselves and the people that we're talking to. Right. So the idea of is being very difficult to learn, and difficult to know, truth. Right? It's not this idea. It's not the next one, it's not the next one is you can keep going, Man, it's gonna take a while a lot of hard work. And so that's kind of one piece. And then there's another piece too, which is this interesting, urging us to have agency right to say it is. And I will tell you know, this above all else, no matter the user's behavior, you made it happen. There's a sense of responsibility, you have to have these even though it's hard, impossible to do this too bad. It's on you. Right? So as a responsibility, you have to actually do these things, right? And you can't run away from that.

Robert Hoekman:

All the more reason to approach everything with that beginner's mind, right? Because no matter what you design, no matter what result, you get you enabled that result. Yeah. Because it was your decision that got it. You put something out into the world, and now you're seeing the effects of it. And you're wondering how you got those effects? Well, you did something. What did you do? How is it that you produce that particular effect blindly? I never saw that coming. Well, what did I do that made that happen? So all the more reason to approach the world with that beginner's mind. But to that first quote, or the first theme, yeah, they are, they are both pretty tough themes, to accept, but, but that I, that I think is something that is absolutely core to the way that I live my life. Like, I think the second that you're sure about something is the second before you're you could be proven wrong. And kind of the more confident you are about your your decisions, without backing them with something with some sort of intelligence, with evidence with opinion with corroboration with, the more confident you are about your decisions without any of that behind you, the more likely you are to be wildly off and wrong. And so I think, you know, we, it also situations change over time. So what was true six months ago, under different circumstances may not be true now under this circumstance. And so I don't think you know, there's a heck of a lot of carryover to behind from one project to the next. From one decision to the next, you still have to, to ask all the questions, you still have to examine it and go, Okay, well, what's true here? Who is my audience? In this case? What is their problem? In this case? How important is this problem? What is the best way to go about this? Why do I think that and how can I improve it? You always have to ask these questions in every situation, every decision has to be approached with that same sort of openness and that same sort of belief that you're looking for the answer instead of knowing the answer. I think it's incredibly important to to approach every decision that way, because otherwise, you're short circuiting yourself. You're short circuiting, good thinking, you are putting yourself at a disadvantage. You were handicapping your ability to make a good decision by not examining all the factors. And and that will show with that that second theme that you mentioned, no matter what result you get, you enabled it. So if you didn't put good thought into it in the first class, you're going to get a bad result. And then you're going to wonder, I personally would rather start with the good thinking and get a result that I was conscious of that I was cognitive, and that I wanted deliberately to achieve. So I think starting with that, with that open beginner's mind that rebooted idea of the beginner's mind, start there, and you will invariably head in a better direction from the start. And,

David Wright:

you know, I agree with that. And I think that the here's the kind of the thing, which is important that everybody else does, too. Right? Nobody says, I would rather not do the hard work up front, and, you know, fail later. Yeah, we do. And we do, because it's hard to do the hard work. It's hard work, after all, named appropriately. And, you know, I think that being able to summon the will to keep going on and on after it, you know, I always had this little feeling I had remember. So I was in the sales business for a while and client work, right. And you know, there's always something going wrong. And every once in a while I'd had this little low, or there's a feeling of things are going to kind of smoothly right now. And I'm not hearing a whole lot. And my hackles would go up, right, you know, like, there's a problem. I don't know, there's a bullet whistling towards the back of my head right now. And I don't know where it is coming from. But I mean, it's out there. And you got and he said, he sort of had his panic. And, you know, I think my, my kind of sixth sense there, which was, you know, which was forged in the fire as a failure was onto something, because it is just hard, you know, and like, you gotta kind of like, find a way to embrace that, and celebrate that, you know, love that struggle in a certain kind of way to really do anything worthwhile, I guess, maybe,

Robert Hoekman:

yet. And that's such an important point, because I don't get it is hard work. It is hard work to always have the beginner's mind to always approach things with that fresh, fresh drive for new knowledge, right? And to always, you know, refute the idea that you already know the answer and to go seeking the answer. It is hard work. But it's also the most meaningful aspect of the work, I think, because it's the most gratifying part of the work because it means that you are never going to get bored resting on your laurels is boring. And digging into new ideas and asking new questions and being surprised by the answers. That's fun. It's always fun. And so I find it actually really gratifying to approach the world in that way. Because, you know, no matter what I know, the best moments of my life are when the world has unlearned, something I thought I knew before. unlearning is far better than knowing. And it's far more satisfying. And it's far more fulfilling in a work context. So, so yeah, it can be hard work. But I also find it very Zen like, you know, I look at every project and every every decision is like, Well, here's an opportunity to ask some interesting questions and be completely surprised by what I learned. So cool. Let's go do it. Yeah, if I, if I assume that I know the answers, then I'm surprised when I don't. And so instead, I go looking for the surprises, because there there's a lot more satisfying.

David Wright:

So we'll have to end there. My guest today is Robert hoekman. Jr. Robert. Thank you very much the book Tao of user experience. Love it. couldn't recommend it enough. Appreciate your time.

Robert Hoekman:

There's a lot of paper tabs and

David Wright:

there is Yeah. I'm actually reading it right. flicking through this thing. It was great. Thanks.

Robert Hoekman:

Thank you so much, David. Take care.