"Is Jobs-to-Be-Done Just Watered-Down UX?" with Jared Spool!

Part 1

Jared Spool is the founding principal of User Interface Engineering and co-founder of the Center Centre, both of which have provided invaluable UX education for the software industry.

He and I were recently engaged in a Twitter conversation about Jobs-to-Be-Done's place in the UX world, and it spilled out into a phone call. All 3 hours(!) of it were recorded so that it could be shared with you. Enjoy!



Once you're finished with Part 1 above, be sure to check out Part 2 and Part 3!


Jobs-to-Be-Done 101

Samuel Hulick:

Ok, so, I did just start recording.

Jared Spool:

Ok. Hello everybody!

Samuel Hulick:

I was thinking for the purposes of this -- I think that this would be a really helpful thing for people to get to hear. And so I think it'd be cool to think of this almost as like an ad hoc podcast episode, almost.

Jared Spool:

Yeah. That's how I've been thinking about it.

Samuel Hulick:

And you're okay with me with me pretending to be the host?

Jared Spool:

Uh, sure!

Samuel Hulick:

Ok. So in thinking about this a little bit, I thought that it would be most helpful to people to follow a loose format where we start by just sharing what we already agree, on and just establish that, and maybe establish some definitions and terms for people who might not be familiar, and then explore where we disagree and then try to wrap it up by seeing if there are new things that we do agree on.

Jared Spool:

Sounds perfect.

Samuel Hulick:

Excellent. Is there anything that you want to start with?

Jared Spool:

Other than I'm a big fan of yours? Uh, nope. Nope.

Samuel Hulick:

Ah, you stole -- that was what I was going to say to you.

Jared Spool:

Well, it can be a mutual, you know, uh, they call it a mutual admiration society.

Samuel Hulick:

Fair enough. Well, on that note, I can kind of set the stage a little bit, just from my own personal experience. So, I am not blowing smoke when I say that your work and especially the Brain Sparks podcast or the SpoolCast was really the big legitimizer that I fully explored when I decided to go into UX. And so I want to be clear: this is something I've been focusing on for 10 years. I know you've been focusing on for much longer. I in no way want to give the field of user experience the short shrift. It's been one of the most important elements of my entire life. So, speaking of mutual appreciation or admiration societies, I would like to be very clear to you and anyone who's listening that user research and user experience design or whatever we want to call that general area of focus is something that I consider to be supremely important and I would like to see it become a little bit better.

Jared Spool:

Sure. Ok. Yeah, we agree on that.

Samuel Hulick:

Ok. And then as far as how you see Jobs-to-Be-Done… well, let's start quickly with Jobs-to-Be-Done as a concept. So this is a mindset that's been popularized by Clayton Christensen from Harvard Business Review, etc., author of The Innovator's Dilemma, things along those lines, and it has become popular in the software design world as a lens through which to evaluate your product design process.

Jared Spool:

Ok. I get different answers from different people. So, when I say that out loud, a whole bunch of people disagree with me.

Samuel Hulick:

What is your take on it? How would you describe what it is?

Jared Spool:

Well, this is my problem, right? I'm trying to get my take on it.

Samuel Hulick:

Okay. So, as far as Jobs-to-Be-Done is concerned, and how it came to be something that we talk about, I think that you can look at user experience design -- is there a term that you prefer to talk about the biggest, most all-encompassing term for UX slash user research slash user centered design, so on and so forth?

Jared Spool:

UX or experience design is sort of where I end up. We're creating the experiences of people, though there are those who will argue you can't do that, but that's a different argument for a different day.

So, experience design is usually where I end up because people get upset -- you can't say anything in this world without upsetting somebody. And there are people who get upset if you use the word "user" because it sounds like you're talking about drugs even though, you know, baseball players can be "players" without actually being disloyal to their wives. So I tend to like experience design as sort of the overarching thing, and then we talk about user experience when we're talking specifically about the experiences of users, and talk about UX design when we're talking about creating usually digital interfaces -- though not always, you know, apps and websites and things. So that's sort of how I sort of see the world.

Samuel Hulick:

And then you mentioned briefly on Twitter that you don't fully endorse the term "user centered design", or it sounds like you had some sort of conflict with that -- I'm not sure exactly where you're coming from beyond that. Can you fill me and the listeners in on that one?

Jared Spool:

Yeah. There's a group of people who always use "user center designed" to mean "usability testing" and sort of a screen-level simplistic notion of digital design. So if you see them say "this is what user-centered design is," you get this very narrow view of design and it's widespread enough that I tend to avoid using that phrase because it kicks in a bunch of stuff. Similarly, I don't use the term "human computer interaction" because that really brings up the world of cognitive psychology. And that's not a bad thing, but it's a very narrow view of what people who do the work we do practice. So I tend to avoid those terms because I find myself unwittingly narrowing the conversation when I use them. Does that make sense?

Samuel Hulick:

That does make sense. As you mentioned, different terms mean different things to different people. So just getting clear at least on what you and I mean when we use them, I think, would be helpful.

Jared Spool:

Yeah, I mean, when I give presentations, I'm very careful to define the terms as I'm using them so that people can follow along and not just assume something that I'm saying.

Samuel Hulick:

Ok. Would you -- again, for the listeners at home -- would you -- well, not to assume that they'd be at home either, I guess, but anyway... so if we're talking about general experience design, I would say especially within the context of software, it's a general process of making the experience of using the software, or the product, or whatever you might want to call the experience touchpoint that someone is interacting with a more meaningful, and enjoyable, and successful experience.

Jared Spool:

Yeah. Better by, by some definition of better. For the user, and hopefully for the people who are creating it too.

Samuel Hulick:

Ok. So that's kind of the experience design side of things. For the Jobs-to-Be-Done side of things, my understanding of it is essentially saying that your company, your organization -- we'll say "business" just to keep the terms consistent -- let's say your business is going to have a central organizing principle. And for a lot of businesses, that is the product or service that they offer -- their business offering. So, "we make pianos and we make the world's best pianos" and you can define a quote-unquote "better piano" in a number of different ways, but essentially the major thing that's being focused on is the product being delivered. Other companies are more customer-centric or more user-centric, so instead of saying "we make pianos and we make the best pianos," say "we understand piano players and we have organized our entire company around piano players. Just knowing them inside and out and delivering on everything that they need." And Jobs-to-Be-Done, by contrast between those two, says the central organizing principle of this business is the progress that someone is seeking. So maybe you identify pianos, maybe you identify piano players, but what is the thing that they're trying to do that you can help them with? And ultimately that's the thing that you would define in loose corporate terms as like "delivering value", quote-unquote. And that is the thing, according to Jobs-to-Be-Done, around which you want to align your entire business experience.

Jared Spool:

Ok, but there's a lot of assumptions baked into that.

Samuel Hulick:

Alright, let's talk about them!

Jared Spool:

Well, first, it sounds very much like you've adopted the Alan Klement school of Jobs-to be done, because he's the one who mostly talks about progress.

Samuel Hulick:

I just want to be very clear: I have read the Harvard Business Review paper "Integrating Around the Job-to-Be-Done" and also Competing Against Luck, which is by Clayton Christensen. Outside of that, I haven't really done a whole -- I know the Moesta/Spiek framework and things like that. I'm honestly not very familiar with Alan Klement's work. Maybe by coincidence I have come into alignment with that, but it's really -- my main reference has been Clayton Christensen's work and, to a degree, I see a lot of similarity with Kathy Sierra's Badass concept as well.

Jared Spool:

Right. Which is why I'm consistently saying "ok, I'm still struggling to see what's new here," because these concepts have been floating around for decades. The reason I brought up Klement, is that he seems to write the most of the people who are out there promoting Jobs-to-Be-Done, which, while Christensen wrote about it in the book, he doesn't actually seem to promote it. And everybody wants to be the heir of Christensen -- there's this sort of "Game of Thrones" thing going on with the consultants. Everyone's vying to be the official "Christensen is talking about me" person, so they get hired more, I guess.

But that's where Klement comes in. The Spiek/Moesta framework has something like that, but it's really about things that cause people to switch. And then there's a third one, which is Ulwick's framework, which has nothing to do with either of the other two, and has to do with unmet needs and identifying unmet needs and then building products around that. As far as I can tell, based on what I've read, those are the three dominant schools, and there's very little overlap between, which is one of the things that makes having these conversations really complicated. Because you have to quickly identify whose framework we're talking about, because beyond the name "Jobs-to-Be-Done" and the fact that they all want to be the official one that Christensen's talking about, they don't have much in common.

So that makes it complicated to begin with. And the second thing is that progress is an interesting thing. And I like the idea of a designing for progress, but there's also this notion that good design is invisible -- that the design should actually disappear -- and so the progress in that case is actually removing the design from the focus. Right? So the idea of "good design is invisible" is this notion that you want the room to be the right temperature, you don't want to have to know that the air conditioner is running. You only care about the air conditioner when it's either too cold, or too warm, or it's making too much noise, or it's dripping on you, like the one that I used to have to have in my office.

Samuel Hulick:

Sure. Like scuba gear, if you're noticing it, something's wrong.

Jared Spool:

Exactly. Yes, exactly. So design wants to disappear, which is why I have some trouble with the nomenclature of Jobs-to-Be-Done because I don't think people think in terms of what "job" they're "hiring" a product to do.

Samuel Hulick:

"People" being designers, or users?

Jared Spool:

The users, the people who are hiring the product.

Samuel Hulick:

Is that their responsibility to be consciously aware of what it is that they're trying to do?

Jared Spool:

Well, I don't know. I've never "hired" -- you know, having been in business now for 30 years, I've hired walks of people to do lots of things and I've never not known about it. And maybe it's because of my business side of running a school and running a business for 30 odd years now -- actually not 30 odd years; it'll be 30 years in August -- having done that for that long and having had many employees and contractors and other people work for me over that time, hiring is always an explicit act.

Samuel Hulick:

Oh, you mean literally hiring people?

Jared Spool:

Yes!

Samuel Hulick:

Oh, not the -- so, in Jobs-to-Be-Done terminology, the idea is basically that when you consume a good, that you are in a sense "hiring" it to help you accomplish something.

Jared Spool:

Yeah. I don't buy that nomenclature. I really -- that language does not resonate with me. I just had grapes for lunch -- for dessert -- and I didn't "hire" the grapes. [laughs] I can't get my head around that language. It baffles me to no end that we're going to "hire" everything that we've touched and use.

Samuel Hulick:

Let's start one step back. Let's at least get to a place -- to a definition of Jobs-to-Be-Done that you and I can share, that when we talk about it, we know what the other person is talking about.

Jared Spool:

Ok.

Samuel Hulick:

So do you -- would you like to go, or do you want me to throw an idea out there?

Jared Spool:

You throw an idea out there.

Samuel Hulick:

So, one word that comes up a lot when discussing Jobs-to-Be-Done -- a very central concept to it -- is the concept of causality and, by contrast, correlation instead of causality. People who promote the Jobs-to-Be-Done mindset talk about causality in terms of what is driving the engagement with the product, or the purchase of the product, or things along those lines. And with sayings like "people don't want a quarter inch drill, they want a quarter inch hole," that there is some result that someone is seeking, and the means through which they seek it is less important than the attainment of the result.

Jared Spool:

Yeah. I mean, I get that, but again, I get stuck. Because people don't want quarter inch holes either: they want pictures hung, or bookcases to stop falling over, or some other thing. Right? That there's a much bigger thing. And then, you know, Carl Sagan once said that if you want to truly bake an apple pie from scratch, you have to start with the big bang.

And when we start going down the road of "well, they don't want a drill, they want a hole. Well, they don't want a hole, they want a picture. Well, they don't want a picture, they want a house that looks nice. Well, they don't want a house that looks nice, they want a living..." -- where do you stop? At what point do you get to an element where it's like "well, they want an existence that's pleasurable," and everything comes down to that! The reason I ate grapes for lunch was I wanted a existence that was pleasurable. And the reason we're having this call is because we want an existence that's pleasurable.

Samuel Hulick:

Yeah. but that's a pretty hedonistic a worldview as well.

Jared Spool:

My point is that -- who gets to say that it's the hole they want, or the drill bit they want? I mean, this feels arbitrary to me. The whole thing feels very arbitrary to me and I don't understand how it helps a team get on the same page about what they're building if you have all these arbitrary junctures. That's where I get stuck.

Samuel Hulick:

I think that there are boundaries and limitations to what people can pay attention to and what people can be useful in serving. In the same way that you have a feature for your product, for example, and in planning it out you identify a feature scope which says "it is this, and it stops short of being this." I think in the same way you can look at the progress that someone's seeking and have a progress scope and say "within these boundaries will be our focus and then yes, it's also important to understand the broader context, but right now we're focusing on helping people quit smoking, or helping people manage projects, or helping people go on a date, or things like that.

Jared Spool:

Ok. And I'm okay if we acknowledged that that was an arbitrary stopping point, that that's where we arbitrarily decided to focus on that.

Samuel Hulick:

Sure. And I would argue that it's the same level of arbitrariness -- that it's as arbitrary or more so to just pick a demographic and say that we're going to figure out what the goals of this ethnographic profile is.

Jared Spool:

I don't think anybody is suggesting you do that, so that's fine. I'm certainly not suggesting you do that. I've never proposed that that's a good idea. If that's the purpose of Jobs-to-Be-Done -- to help the people who do think that's a good idea get over that notion, I can get behind that. But that's not what real UX professionals do.

Samuel Hulick:

I would like to stop you there for a second because, I don't think that that is a helpful way of defining the sort of "platonic ideals" of the industry. I think that when you say there are "real UX people" then that implies that there are "pretend UX people" or people who don't really --

Jared Spool:

-- well, I mean, there are people for whom, like anything, there are people who take some idea and they adopt some piece of it and they think they're doing it and they tell everyone they're doing it, but they're actually not. They don't understand what they're doing, they're just going through the motions. It's sort of "cargo cult" type activity. And in those instances, to compare them against folks who actually understand how to use the tools effectively -- we have this scale that we use to talk about how people learn design...

Samuel Hulick:

Who is "we"? Your organization?

Jared Spool:

Yeah. Those of us at Center Centre / UIE. It has four parts, and at its lowest part is what we call "unconscious incompetence". And unconscious incompetence is when you don't know how to do something, but you don't know you don't know how to do it, right? And if you're learning a new language or you're learning to cook, or you're learning how to do design, everybody starts in unconscious incompetence. And they they produce a result, they cook something, they make a song, they say a sentence, but it turns out that they don't know what they're doing. And anybody who knows what they're doing immediately sees the problem with it, but the people who are doing it, they don't see it. From their perspective, it's just as good as anything else. You move from unconscious incompetence to conscious incompetence. Conscious incompetence happens at the moment that you can start to see the difference between good and bad outcomes. And now you can see that the food you make isn't very good, or the music you're trying to produce isn't very good, but you don't know what to do about it. So, you're still incompetent, but you are now conscious about it. The next stage is what we call conscious competence. And conscious competence is when you know the difference between good and bad, but you also know how to get a decent result. You follow the recipe, or you play the music exactly as you learned it, or you say a sentence the way you learned it, or you do the design work following the process, and you now can regularly get good outcomes predictably. But as soon as something happens where you no longer can use the recipe -- like you run out of an ingredient, or you no longer can follow the process, you are stumped. You don't know how to get a good result, and you're just as bad as you were when you were unconsciously incompetent.

The fourth stage is unconscious competence. Unconscious competence is when you can move through the problem space easily, and combine new solutions that you were never taught to explicitly. So, it's when you can form sentences and talk about things, uh, even though you've never practiced those sentences before, or you can, take ingredients and make a decent meal even though you didn't have a recipe to work from, or you can solve a problem with design that you couldn't solve before. And so when I'm talking about people who use something like personas effectively, I'm talking about people who are consciously competent or unconsciously competent in their use of personas. People who are consciously incompetent or unconsciously incompetent are people who are going to do it poorly. And every process, every tool, every technique has that. So to suggest that Jobs-to-Be-Done is more effective than personas is really just a straw man, because unconsciously competent Jobs-to-Be-Done is probably no better than unconsciously competent personas. And so --

Samuel Hulick:

-- hold on, hold on, hold on. Again, for the listeners who may or may not be at home, what is your definition of personas and what is your definition of the correct use of personas?

Jared Spool:

Well, you keep talking about taking people's demographics and plugging them into -- and this is something that is talked about in the Jobs-to-Be-Done community a lot. Klement has a big piece about why personas are bad. Ulwick talks about personas being a bad idea. I've heard Moesta talk about it in his podcast. So, there seems to be a unifying thing that personas are bad, that --

Samuel Hulick:

-- what are they, though?

Jared Spool:

Personas are a way of distinguishing one collection of individuals from another. They shouldn't be role-based, they definitely shouldn't be gender-based, they definitely shouldn't be most of the time -- unless you have data that supports that somehow those things make a difference. Because in design, we're working with behaviors -- the medium of design is behavior -- the personas that I recommend people go with are differentiated by behavioral things.

So, for example, a nurse behaves different from a doctor. One might suggest that that's role-based, but it really isn't. It's actually contextually-based, because nurse practitioners work differently than doctors (but they do the same things as doctors). But different nurses work different from each other, depending on contextual things. A nurse dealing with a child, for example, would work differently than a nurse dealing with a senior in many ways, and in some ways they do exactly the same thing. So what you do is you look at the behaviors that are there, and then you start to say "well, we see these two groups of behaviors: what do we want to call people who do these behaviors versus people who do those behaviors? Ok, now we have two personas, and we can design for those two sets of behaviors. So that's personas done well, and personas always come with scenarios, because --

Samuel Hulick:

-- ok, hold on. So, just basic terms here, would you say that personas are summaries of different kinds of people?

Jared Spool:

They are a shortcut for a design team to talk about the behaviors they've seen, yes.

Samuel Hulick:

But why are they embodied in terms of "personhood" rather than "behaviorhood"?

Jared Spool:

Ah! The scenarios talk to the behaviors in the context, the personas talk to the user who is having those scenarios, who's executing those scenarios, or are participating in them.

Samuel Hulick:

So what is a scenario, then?

Jared Spool:

You don't have personas without scenarios, you don't have scenarios without personas.

Samuel Hulick:

Well, I would definitely push back on that. I think many companies have personas without scenarios.

Jared Spool:

Well, again, unconsciously incompetent efforts -- 98% of everything is crap, right? That Sturgeon's law. If we're going to say "well, there are lots of companies who do things poorly and because there are lots of companies who do things poorly, we're going to assume that everything works that way. That's not fair.

Samuel Hulick:

But I think that all tools are "opinionated" in a way, that they lend themselves to a particular kind of use.

Jared Spool:

Sure, that's fine. I don't know what the opinion of my hammer is, but then again, I'm not going to hire it. But, sure. I mean, everything has a point of view. I get that. There are companies out there that claim to have personas, just like there are companies out there that claim to "do Agile", just like there are companies out there that claim to do design, that when you actually look at their behaviors, you see that they don't do the things that actually get the results that they are hoping to get by doing those things.

Samuel Hulick:

And you're saying that if you couple them with scenarios, then you get a more comprehensive picture.

Jared Spool:

Yes. People who do them well always couple them with scenarios.

Samuel Hulick:

Ok. And what are scenarios?

Jared Spool:

Scenarios are a combination of the -- they're basically a narrative through time.

Samuel Hulick:

A narrative through time.

Jared Spool:

You talked in the video, you talked about narrative description... they're the narrative that talks about something that the persona does in order to get from Point A to Point B, and the contextual elements that fall into that.

Samuel Hulick:

Ok. Now, here's a big question for you. What is the primary means of research through which you discover scenarios?

Jared Spool:

You watch people.

Samuel Hulick:

Right, but it's people again, for you. It's the kinds of people.

Jared Spool:

Yeah, there's scenarios don't happen without people. A whole bunch of years ago, I worked on a project that involved adverse reaction drug reports. So if you are a pharmaceutical company, and you produce a drug that is approved by the Federal Drug Administration in the United States, you have to have a system for what's called "adverse reaction reporting". Somebody calls up, your company and says "your drug turned my hair green," you actually have to report that to the FDA within 24 hours. At least you did back then when I worked on this project -- I assume the rules haven't changed. And there's a whole machinery that happens to deal with the fact that someone has reported an adverse reaction to a drug that you have had approved from the Federal Drug Administration. And so in this project, we studied what those reports were. And we actually followed the report through, from the moment it was reported by the patient to the moment that all the papers settled down -- either at the FDA or at the pharmaceutical company -- and, literally, these were paper forms that we were automating. So we were literally following pieces of paper. And we were studying what happened to that piece of paper. So I guess technically we weren't studying users, except the only thing that caused a state change in that piece of paper was a user. 17 of them, in fact. And we got to watch each of those individuals handle those papers and then study how they handled all the other papers they handled, and then looked at the behaviors to try and understand how we would automate this process. So yes, on the one sense we weren't quote "studying users" because we were following the paper, but the only thing we saw was users interacting with the paper, and we needed to design something that would give those users improved behaviors with a digital version of an adverse reaction report. Okay. So, I don't see any instance where you're studying some sort of experience design where you don't have a user involved, because in its basic form experience design is just about somebody's experience.

Samuel Hulick:

Sure, and I think that that really calls into question a basic, again, kind of definition of terms. Are you saying that you're designing experiences -- like you were talking about with the grapes -- that we're in the business of delivering pleasurable experiences, but whatever the, the nature of those experiences are and the purposes that are underlying them is almost arbitrary? Or are we holding ourselves to delivering results to people, and really focusing around identifying what the causal motivation that's driving the experience to begin with, and whether that's pleasant or not, seeing that through in a reliable and consistent way?

Jared Spool:

I think that's a good question. Right? And that depends on a lot of things. First, companies make promises. The company I was working for was promising and automated adverse reaction report system. And the company that sold me the grapes is promising delightful grapes.

Samuel Hulick:

But they're also promising a healthy snack. It's hitting on a number of levels.

Jared Spool:

I read that into it. There was nothing, no promise made to me that it was healthy, other than my preexisting expectation that grapes are healthier than candy. But I have no data and no belief and no actual evidence that that is true.

Samuel Hulick:

That grapes are healthier than candy?

Jared Spool:

I don't have any at my fingertips. I'm taking that based on some assumptions I've made about the world, as a customer of grapes. But it could be that they are just as toxic as candy is. And I would have no way of knowing.

Samuel Hulick:

This is like a flat-earther theory!

Jared Spool:

Well, no, I mean it's like, you know, people believe that protein bars are better than a candy bar. And looking at the ingredients in most of the protein bars I see, I can't believe that's actually true. They're mostly sugar.

Samuel Hulick:

Well, I think that's an excellent point, which is that you evaluate the merits of a product by how conducive it is to supporting the accomplishment that you want to make. You evaluate it through the context of the accomplishment, the priorities of the person using it.

Jared Spool:

Yeah. For some reason, I feel better about myself because I'm eating a protein bar that tastes more like cardboard than like candy, not knoWing whether in fact that protein bar is any healthier than the candy bar I would have enjoyed much better.

Samuel Hulick:

Right. And so, my biggest question -- and the question that I will keep coming back to -- is why, in experience design, is the primary unit of evaluation not the accomplishment that someone wants to make, as opposed to the people who want to make the accomplishment? Why is it beneficial to focus on the people as the primary unit of analysis rather than the accomplishment itself?

Jared Spool:

Because we don't assume that everybody has the same accomplishment. And not everything is an accomplishment, right? Making the air conditioner invisible is not an accomplishment for the user.

Samuel Hulick:

Giving them a cool -- an office or a room that's the temperature that they prefer, is the accomplishment.

Jared Spool:

Uh, no! I don't think anyone would list it as an accomplishment. Again, we get into these terms where -- an accomplishment means someone feels accomplished. It actually is something of note. And in fact, what we're trying to do in design is make it completely not of note. And so I have trouble with that conflict. That that's where I run into problems. I can name a dozen different accomplishments that happened when we improved the adverse reaction report, right? We got one of the -- here's one of the big ones: it turned out when we followed the paper that everybody who touched that piece of paper… the first thing they would do before they did whatever it was they were supposed to do to approve it, or sign off on it… there are about seven different things they had to do. But the first thing they did was they went and made a photocopy of it, and took the photocopy and stuck it in their files. From the moment that that report entered the building to the time it got to the FDA, 17 photocopies of it had been taken. And stored in filing cabinets all within the same business. And none of those people knew that anybody else was taking a photocopy. And when we asked them why they were taking the photocopy, the predominant answer was covering their ass. If someone brought up that thing, they wanted to have it in easy reach, and the only way they could do that was to make sure they had a copy of it. So they either took the copy at the moment they received it or the copy of the moment they sent it off, but they always took a copy.

Samuel Hulick:

Let me ask you a respectful question, just so that I can better follow you. Are you saying that we should only design for things that people are consciously aware of themselves doing?

Jared Spool:

No, no, no. I'm saying quite the opposite. I'm saying that I have trouble with the word "accomplishment" when it's something they're not aware of.

Samuel Hulick:

That's actually why I chose the word "accomplishment". Because, for me, if I'm setting my air conditioning to the temperature that I want and then I go out on the town and then come back home and it's a hot day and I go "ahh, it's so nice and cool in here," to me, that IS an accomplishment, of sorts. I'm probably not going to write a letter home about it, but it's still something where I can say there was an investment, I coordinated things, and I get to reap the benefits of that. Conscious or unconscious, I think that's a thing.

Jared Spool:

But here's the thing, right? Let's say we are successful with that. We are successful with getting air conditioning such that nobody ever notices the air conditioning. Is it also an accomplishment for your children? Because from their perspective, that's just how life is.

Samuel Hulick:

I would say that it alleviates the need for them to have to resolve that accomplishment on their own.

Jared Spool:

Agreed. We agree completely, but isn't it an accomplishment if they have to do nothing to get a perfect thing because it was designed well?

Samuel Hulick:

I would say yes. I think that --

Jared Spool:

-- whose accomplishment is it? What did they do to accomplish that?

Samuel Hulick:

Ok. Alright, Jared, I'm going to lay it out a little bit for you as far as how I see it. Ok?

Jared Spool:

Ok. [laughs]

Samuel Hulick:

So I had a fundamental shift in my whole approach to experience design several years ago -- kind of from the beginning, but I couldn't really figure out how to articulate it -- but the way that I would put it now is that, in industry terms -- and I am much more in the software industry then than in "digital experiences" or enterprise products and things like that, so I'm just talking software in general, but specifically more along the lines of SaaS and things like that. So when I say "industry", I mean the software industry. I think there's a very common mentality in our industry to focus on users. And there are a lot of ubiquitous values: it would be very difficult for someone to come off and say "you know what, I don't think we should design for users." So there's the notion of understanding the users, getting as close to them as you can, seeing the world through their eyes so that you can better coordinate your efforts around serving those people, or your understanding of those people. And then there's also the concept of the product that you make. So product managers make sure things get shipped on time, you have to create new features, you want to reduce the feature creep of your product at the same time, and create an interface that's enjoyable to operate, things like that.

Jared Spool:

Ok.

Samuel Hulick:

And for me -- and I realize this sounds kind of blasphemous -- I think that that is an unhelpful dichotomy. I think that --

Jared Spool:

-- what's unhelpful about it?

Samuel Hulick:

Well, I'm going to tell you what I think IS a helpful way of looking at, and then we can break that apart. I think that it is better to, rather than thinking of ourselves as "we are designers who design products that users use," to think of ourselves as collaborators with the users on an accomplishment that they are seeking.

Jared Spool:

Ok, yeah. I buy that completely.

Samuel Hulick:

So, you want to do your taxes, we help you do your taxes.

Jared Spool:

Sure. I was helping the pharmaceutical company produce a better method for adverse reaction reports. I was helping all the people who had some role in that to get through their day better, we were co-collaborators. I completely get that. And that's actually not a new idea, right? That goes back to Scandinavian design and the sixties. In fact, I was just in Stockholm last week and we were talking about this, because Swedes and Finns and Estonians, they have a long tradition of this type of design ethic.

Samuel Hulick:

Ok. And let's clarify: that's not a way to dismiss the concept. No idea is "new", quote unquote. But there is still a predominant mindset in an industry, and I would say that that is not it for ours right now.

Let me lay it out a little bit, and then we can pick it apart. Buckminster Fuller, who is one of my personal heroes. Jared-Spool-level hero of mine.

Jared Spool:

[laughs] No, no, no, no. Bucky exists on a whole different plane. I am nowhere near close to that. You -- I'm not going to let you get away with that. Bucky Fuller is incredible. I had an opportunity to work with his daughter.

Samuel Hulick:

Oh really.

Jared Spool:

Yes. It was a great pleasure. She was amazing.

Samuel Hulick:

I would love to hear about that off the air.

Jared Spool:

Sure.

Samuel Hulick:

So there's a concept that he espoused called "pattern integrities", which you're probably familiar with, but again, just for the listeners, it's an idea that can kinda be borne out in an example: let's say you have a bucket filled with water and you drop a rock in the bucket, into the water. It will create a series of concentric ripples that go out. It's a phenomenon that you can observe. The ripple effect -- literal ripple effect. If you fill up a bucket with milk and drop a rock in, you can observe the ripple effect. If you fill up a bucket with kerosene and drop a rock in, you can observe the ripple effect.

Jared Spool:

Yes.

Samuel Hulick:

And so what he calls, in this case, the ripple effect… is a "pattern integrity", which is basically that phenomenons persist independent of the medium that happens to be expressing them. And my whole design philosophy is oriented around the idea that in the same way that there are ripples -- you drop something in liquid and makes ripples -- in the same way, there are pattern integrities as far as behavior are concerned. And I called those accomplishments. People will always want to lose weight, or quit smoking, or plan a trip out of town, or a have a fun wedding, or all of these different things that are, again, progress that people seek. And so to me, yes, it's crucially important to understand what that looks like through the eyes of people. But the thing to align all of your efforts around is that accomplishment -- whether they're conscious of it or not -- rather than the people who are motivated to to accomplish that given thing.

Jared Spool:

Ok. But that eliminates a whole world where design can make life better. So I'm curious why we want to restrict ourselves to that.

Samuel Hulick:

Can you give me an example?

Jared Spool:

Sure. The first example that comes to mind is any sort of automation where we can adapt the context of the user for them without their knowing.

Samuel Hulick:

I'm not even sure I follow that one, but especially for the people who may or may not be home, what exactly do you mean by that?

Jared Spool:

I have a car which is probably, if we were to put some sort of numeric scale on it, a thousand times safer than the car I drove 40 years ago when I first got my license. I can't tell you all the things in my car that are safer, but all of those things were designed. All of those things were designed for me, for my benefit. And as a result, I have a safer car because of the hard work of that. Little piece of trivia: my father-in-law is on the original patent for the seatbelt. Just putting that out there.

Samuel Hulick:

You're so well-connected!

Jared Spool:

I have lived a long, fruitful life and I've been very lucky.

Samuel Hulick:

You're like the Forrest Gump of experience design.

Jared Spool:

I know! I am. I am. Where's my box of chocolates? That's, like, the best thing anyone's ever said to me. But where were we? Oh yes. We are back on safety, right? So safety is one of these things. There are two ways to build safety: you can either burden the user by having them have to buckle the seatbelt. At which point, the fact that they buckled it, I guess, it would be an accomplishment in your world.

Samuel Hulick:

I'm not saying that that is or is not the case, but ok.

Jared Spool:

Well if I'm safer because I buckled it, maybe, I don't know. See, this is where I'm running into trouble: I can't even distinguish what is an accomplishment, what isn't. But from there, there are all sorts of things like the frame of the car and the airbags system that I don't control, that when it works as designed will save my life, but I have no control over it. I just get in the car and I go. I don't think about it and I did nothing to get it. It came with the car. It comes with every car now. There were no choices in my life that I made that got me to that accomplishment.

Samuel Hulick:

I would strongly disagree. I would say that you chose to have the car that had airbags in it.

Jared Spool:

But I can't NOT choose one anymore.

Samuel Hulick:

Well, certainly, I mean not if you're only buying new cars.

Jared Spool:

Even amongst the generations of used cars that are still on the road, it is virtually impossible to get one without airbags. And if it's not true today, it will be true in 100 years. So there's some point where there are things that are designed, that designers do, that do not result in an explicit action of the user to get an accomplishment. They're just how it's designed. And, privacy is a great example of this.

Samuel Hulick:

Hold on. Can we talk a little bit more about the car example? Because I think it's a good one.

Jared Spool:

Ok.

Samuel Hulick:

I would say, in accomplishment terms, the primary accomplishment of -- the primary reason that you would, uh, "employ" a car -- I know you don't enjoy the term "hire" -- the reason that you would use a car is to get somewhere. Primarily. Maybe you just want to go into it for privacy, there are all kinds of different crazy edge cases, but primarily that's what cars are for.

Jared Spool:

Yes.

Samuel Hulick:

And I would say if we're just talking about getting to another place, cars are things that you can hire to do that.

Jared Spool:

Yes.

Samuel Hulick:

And I would say that if you get to another place -- if you don't arrive or if you arrive injured, those make the accomplishment less successful.

Jared Spool:

Yes.

Samuel Hulick:

Ok. So a car with airbags contributes to the success of the "getting somewhere" accomplishment better than a car without airbags does.

Jared Spool:

In the instance where there's an accident. For 99.9% of all travel, no. But here's the thing: it was not an option. It was not a choice. It was not anything that I could do if I summon an Uber to magically appear at my house to take me to work, I don't have to specify an Uber with airbags. I will get an Uber with airbags. And I certainly won't have any idea whether I did or I didn't, right? It's just like the protein bar. I can't tell whether, in fact, that it's healthy for me or not. But I'm assuming it is safe, and the Uber driver is assuming it's a safe, and Uber, the company, is assuming it's safe, and all of those people are assuming it's safe. And the designer did something at some point that made that happen. Several designers did something: there's the designers who worked on the airbag system, and there are the designers who created the policy that said no new cars can be made without airbags. And in all of those instances, we created something to be safer. I just wouldn't apply the word "accomplishment" to that context. It's just does not make sense to me. If it's something that people design... the word doesn't help me understand what I'm trying to do better.

Samuel Hulick:

Ok. In my terms, I would say that being uninjured in the case of an accident is a contributing accomplishment to getting somewhere, period. Getting somewhere safely is a contributing accomplishment to getting somewhere at all.

Jared Spool:

It's very zen to have these things that didn't happen be accomplishments.

Samuel Hulick:

What do you mean "things that don't happen?" If no one ever got in an accident, I would agree that those are --

Jared Spool:

-- "no bad thing happened, and therefore it was an accomplishment that no bad thing happened."

Samuel Hulick:

I'm saying in the scenario where somebody does get into a car accident, then the way I would describe it is you as the driver of the car and the car manufacturer are collaborating on the accomplishment of you not getting a concussion.

Jared Spool:

I guess, except that I did nothing in that collaboration. I mean, I just existed.

Samuel Hulick:

Okay, well let me, let me try to rephrase this a little bit more --

Jared Spool:

-- and that's, I think that's where… to me, an accomplishment to something… it's just the way I know the word. Now, let me go look up the definition of it because maybe I'm… I don't have the right definition of the word accomplishment.

Samuel Hulick:

While you're doing that, I think that we can talk about this in more of a term-agnostic way. There is --

Jared Spool:

-- "something that has been achieved successfully," so I get that. "The successful achievement of a task." Ok, I don't know what the "task" is other than not dying in an accident. "An activity that a person can do well, typically as a result of study or practice." See those definitions… I get that something has been achieved successfully in this context. The other two definitions, they're not working for me as accomplishments. And maybe that's because I think that those two definitions are what I run in my head with the word accomplishment.