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

Part 2

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 2 above, be sure to check out Part 3! And if you missed Part 1, start there!


Jobs-to-Be-Done 101

Samuel Hulick:

Ok, let's go back to the idea of pattern integrities and that phenomena exist independent of the thing that's expressing them. There are three main things that we're talking about here, and I'm going to use very generic terms: who we help -- which most would consider to be the users or the consumer base or whatever. Right?

Jared Spool:

Yeah. I mean, there's lots of subsidiary beneficiaries, but ok.

Samuel Hulick:

Ok. So three main things: who we help, what they want help with, and how we help them.

Jared Spool:

Yeah. There'd be a fourth thing. You're missing a critical fourth thing.

Samuel Hulick:

The environment or the context?

Jared Spool:

Yeah. Exactly.

Samuel Hulick:

I have thought of that. I would say that that is a quality of what they're trying to do. That the context drives the thing.

Jared Spool:

Oh no, no, no. Because you can be trying to do exactly the same thing in completely different environments, and they will get different outcomes. Same person, same intention. The simplest example of this is getting up in the middle night to get a glass of water. It's a very different thing to do it in somebody else's house than in your own home. You're sleeping over at somebody else's house, getting up in the middle of the night to get that glass of water -- that's a completely different activity.

Samuel Hulick:

It's a different experience, I agree, but the causal mechanism is still the same. You're thirsty in the middle of the night.

Jared Spool:

Ok, but the context changes the environment, and to design successfully, you have to take into account those changes.

Samuel Hulick:

Ok, what if we called it a "motivation" instead?

Jared Spool:

Called which the motivation?

Samuel Hulick:

The thing that they want help with.

Jared Spool:

Sure! I'm not disagreeing that that exists. I'm just saying there's a fourth thing that you cannot just say "it's a part of some -- one of the other three." It's its own thing.

Samuel Hulick:

I think we're close to getting -- we're either going to agree or disagree, and I think it's going to hinge a bit on the question that I'm about to ask you, if you will let me be so bold.

Jared Spool:

I don't know if we could agree with the fact that we're going to agree or disagree. [laughs] Maybe we will.

Samuel Hulick:

Let's just for now, let's table the contextual element or the environment, and agree that that is crucially important, but let's just focus right now who we help, what they want help with, how we help them. Who we help is the user, I think many people would say. And how we help them is the product, I think many people would say.

Jared Spool:

I think those are limiting definitions, but ok.

Samuel Hulick:

I agree. We're just trying to talk about anything. We have to establish some general, base understanding.

Jared Spool:

Ok.

Samuel Hulick:

And so when you say that personas and scenarios give you -- and I don't want to put words in your mouth -- that those two can be used correctly to "do experience design".

Jared Spool:

Yeah. They have all the three things plus context embedded in them. So they are a way of communicating -- I mean, Jeff Patton today just tweeted something which was brilliant. Actually, he didn't tweet it. Somebody else attributed to him and then he claimed he didn't remember saying it. But what it was was, uh, I'm looking it up right now. "We don't need an accurate document. We need a shared understanding." That's a brilliant sentence, right? Personas and scenarios and job stories and all these things are the document. That's not what we're going for.

Samuel Hulick:

Ok. Hold on, hold on. Personas and scenarios are the document is what you're saying, right? What are they documenting?

Jared Spool:

They're documenting the individuals that have different behaviors, what those different behaviors are, and the context that those behaviors exist in.

Samuel Hulick:

Okay. That's exactly what I'm saying -- I don't think it's helpful to evaluate things through the lens of "users". I think it's helpful to evaluate things, through the lens of --

Jared Spool:

-- I just don't understand how you avoid it. How do you talk about how something is used without talking about users using it?

Samuel Hulick:

I think it's a question of focus, in the same way that you were talking before about how you have to put a boundary around what it is that you focus on, because otherwise you're just -- there's no such thing as arbitrary objectiveness, or objective arbitrariness. In the same way, there's the nature of where you're placing your focus. And I would say that the primary nature of experience design focuses on things in terms of users or people. You segment by "people types".

Jared Spool:

So is Jobs-to-Be-Done!

Samuel Hulick:

No, that's what I'm saying! I don't think that that's true. I think that you can also --

Jared Spool:

-- give me an example of something in Jobs-to-Be-Done that doesn't have a user.

Samuel Hulick:

I think you can study the phenomenon independent of the ethnographic profile --

Jared Spool:

-- give me an example!

Samuel Hulick:

Anything! Anything that I've already listed: going on a date, quitting smoking, losing weight, graduating from college, all of these things are things that people want to do. And you don't have to --

Jared Spool:

Let's talk about quitting smoking.

Samuel Hulick:

Let's do it.

Jared Spool:

So, quitting smoking, A) involves someone who is smoking, right? So first, it's contextual in that only people who smoke qualify for this. Nobody else has to quit smoking.

Samuel Hulick:

No one else COULD quit smoking. I'm with you.

Jared Spool:

So that's that. The other thing to note is something around 22% of smokers don't get addicted, which means they are not compelled to smoke by the cigarettes.

Samuel Hulick:

On a biological level.

Jared Spool:

On a biological level. They get the relaxing qualities that the cigarettes give them, but they can put the cigarettes down and not smoke for months at a time and then come back to it for whatever reason. So now you have two groups of people: you have people for which are physically addicted to smoking, and you have people who are not physically addictive to smoking. And if you wanted those two groups to stop, you would have to design something different for each of them.

Samuel Hulick:

Because they have different motivations. It's a different accomplishment for them.

Jared Spool:

No, no. As I understand it, it's the same accomplishment. They no longer smoke, I believe is the accomplishment, correct?

Samuel Hulick:

Well, people could die and no longer smoke, but that just because --

Jared Spool:

-- ok, that's a third outcome, but "no longer smoke, no longer pick up cigarettes, and put them in their mouth, light them on fire, and inhale the toxins." Right? I believe that's the accomplishment that you're talking about. Unless I don't understand quitting smoking.

Samuel Hulick:

I would agree. I'm just not sure where you're going -- are you saying that people who are addicted to smoking have a more legitimate case for quitting than people who just have it as a habit?

Jared Spool:

No, I'm saying that if I'm going to design something to help people quit, I can't design the same thing for people who are physically addicted. It won't be as effective if I try to design the same thing for people who are physically addicted from those who are not. Because the context -- in this case, the biological reaction of their bodies -- -is actually different. And because of that, I need a different design solution for the people who are not in a physical addiction scenario from the people are, because the people who are not in a physical addiction can work purely on a psychological basis, whereas the people who have physical addiction, no amount of talking to them about the psychology of smoking will get them to quit because their body will tell them they need a cigarette. And I need a different solution for them. And that's where I'm saying, is that we can simplify this down to "people want to quit smoking, so we designed something that helps them quit smoking," done. But as soon as we turn our lens to the people involved, we learn that there's two different contexts. In fact, there are many different contexts, because, for example, people who live in abusive relationships have a different problem with smoking than people who don't live in abusive relationships.

Samuel Hulick:

So how, how are you determining which "types" of people to focus on?

Jared Spool:

Well, there's lots of ways that you choose that. In some cases, it's a business decision, right? Which ones can we get a product to who will pay us the money we need to survive? So that's a very sorta "capitalist" approach. There's another one, when I worked for the White House, which approach we would take to something like this, which is "which community would be best served by the solution we can provide?"

Samuel Hulick:

Ok. So that would be, by definition, a demographic of people.

Jared Spool:

No, no, no, no.

Samuel Hulick:

A community?!

Jared Spool:

Communities can be defined by demographics, but you can define a community -- a community is just a collection of people. So, you can slice and dice into a community as much as you want, but communities are not always defined by demographics. They could be defined by psychographics, they can be defined by behavioral actions. I'm using the word "community" to just mean a collection of constituent -- in terms of government, communities are collections of constituents. They're just, that's all they are.

Samuel Hulick:

This isn't rhetorical: I'm genuinely having a hard time thinking of a community that is defined by everyone sharing the same behavior. Could you give me an example? Like a soccer fan?

Jared Spool:

Yeah. Veterans.

Samuel Hulick:

Veterans?

Jared Spool:

Veterans. Military veterans. They come from all race, all creed, all levels of income. But the one thing they have in common is they were once employed by the US government to be in the military.

Samuel Hulick:

Ok. So let's use veterans for an example. That, to me -- how I would break that down is I would say that it's a type of person who share a quality.

Jared Spool:

Sure. That's a community. But that's not a demographic community.

Samuel Hulick:

Alright, well maybe I'm using that term incorrectly, but I'm still talking about kinds of people.

Jared Spool:

Yes.

Samuel Hulick:

Ok. And so you could say "we're going to focus on veterans, and understand what veterans' problems are, and understand what goals veterans have, and what tasks veterans might be experiencing, and how we can make those better experiences."

Jared Spool:

Exactly. And we can subdivide those. We can --

Samuel Hulick:

-- hold on, hold on, hold on! I want to build with atomic lego pieces, here.

Jared Spool:

Alright.

Samuel Hulick:

So we're saying goals, tasks, all kinds of qualities -- you can study a kind of person and get to know them better, including the things that they want to do. However --

Jared Spool:

-- ok, but that's not actually how you do it.

Samuel Hulick:

I think that you can also start with --

Jared Spool:

-- but that's how you do it. I just want to make it clear: the way that you described it is not how it is done.

Samuel Hulick:

Is this again by quote-unquote "real practitioners"?

Jared Spool:

I'm just talking about how anybody does it. Because there's only one way to do it, which is you don't study a group of people -- you study individuals who you believe to be of that group.

Samuel Hulick:

Ok. Everything that you're saying -- and I think you will agree with this -- is that you are evaluating a kind of person as your primary unit of analysis and that you're deriving insights and understandings based off of that.

Jared Spool:

Uh… yes. That is a way to describe it. It's leaving out of lot of nuance that could be important.

Samuel Hulick:

Ok. I agree with you. We're just… we're just trying to get somewhere here.

Jared Spool:

But you've made a generalization, and I just want to make it clear that you've made a generalization which isn't completely accurate when you look at the actual things that are happening.

Samuel Hulick:

Ok. How about we just say "you start with kinds of people"? Would you agree with that?

Jared Spool:

I mean, you start, yes. In any research project, you start by deciding who you're going to target for the research, and who is not part of the target. So if we were studying veterans, we would eliminate anybody from our research who did not serve in the military. We would only look at people who served in the military. Now, if we were looking at the effects of things that happened to veterans, we might choose a different qualifier. We might say we want to look at people who served in the military, but we also want to look at caregivers of people who are taking care of people who were injured in the military. And we want to look at employers who might hire people from the military. So now we have three different groups that are all part of the same research as we try to understand the life of veterans.

Samuel Hulick:

Right. And these are three different -- you will agree, three different KINDS of people.

Jared Spool:

Well, yeah, we're selecting people by those qualifiers. So in research, you can do three things: you can select, you can segregate, and you can balance.

Samuel Hulick:

But before we get into research, though, what I'm trying to establish here is that "the thing being researched" is -- there is a whole paradigm difference between what we're talking about.

Jared Spool:

We're researching people. We've decided to select a subset of them, by a criteria.

Samuel Hulick:

Your process looks at kinds of people, and then derives your insights from that.

Jared Spool:

No, we look at people -- "kinds of people", I think, is a generalization that causes confusion. So I'm trying to avoid "kinds of people". What we look at as people who meet a certain criteria.

Samuel Hulick:

Ok, that's fine with me too. Let's say that it's "people who meet a certain kind of criteria."

Jared Spool:

Ok.

Samuel Hulick:

What I'm saying is that instead of looking at -- how about "people who share a quality"? Could we both use that term?

Jared Spool:

Sure. I mean, if serving in the military fits into your definition of "a quality".

Samuel Hulick:

Well, this is where the term "attributes", this is where I would use that. They all share "had served in the military" attribute of their personhood.

Jared Spool:

Ok.

Samuel Hulick:

Ok. And so when you evaluate through that lens, you segment and analyze and extract insights from a process that's all inherently couched in "people terms", and I don't think you would even say that's a bad thing.

Jared Spool:

Yeah, because we're studying behavior.

Samuel Hulick:

You're saying that's a good thing.

Jared Spool:

I'm saying that's how you do user research. There's no other way to do it.

Samuel Hulick:

By definition, you are researching users, right?

Jared Spool:

Yes. Yes. Yes.

Samuel Hulick:

And what I'm saying is that you can also look at something through the lens of primary evaluation being "what is it that someone's trying to do?" and slice and dice things through that lens. Again, as the primary thing through which everything else is couched.

Jared Spool:

But if the veteran is trying to get an appointment with a VA doctor, how do I look at the act of getting an appointment with a VA doctor without looking at the veteran themselves?

Samuel Hulick:

I'm not saying that you completely throw out user research. I'm saying that you can look at it in a lens in which the -- again, what I'm using as "accomplishment" or "the thing to be done" or whatever -- is the primary unit of analysis and that the people types who correlate with that are a subset of viewpoint. Or you can look at things through a more people-centric viewpoint and say that the things that they're trying to do are a subset of people types.

Jared Spool:

I guess so. Yes. That's true. But I think in a research project, you do all of that. You keep going back and forth.

Samuel Hulick:

I'm trying to show the two different ones, because you're saying you're not sure. You felt like Jobs-to-Be-Done wasn't making sense to you. And what I'm saying is, as I understand it, the basic principle of Jobs-to-Be-Done is that you're evaluating things primarily through the lens of the thing that someone's wanting to do, not the person who happens to want to do that thing. That's a very important concern, but it's a moon that orbits around the planet.

Jared Spool:

I just don't see how you can look at one without the other. I don't see what that isolation buys you.

Samuel Hulick:

Well, because you aren't starting with trying to understand -- you can almost think of it like "who you're working with" as nouns, "people type" being nouns, and "what they're trying to do" as being verbs. And I like to start with the verbs and then use that as the context that I better understand the people who happen to want to do that.

Jared Spool:

Right, but in good design practice, you do both of those activities. I mean, that's just what you do. And I will admit there are lots of people who don't do good design practice and I get that and we can teach them to do good design practice. And, if the easiest way to teach them to do good design practice is to give them this sort of training wheels type approach, where you say, "ok, focus on the verbs, just focus on the verbs. We'll call that Jobs-to-Be-Done. Let's focus on the verbs." I'm okay with that. If that's all it is, then we're all set. That doesn't seem to be what the consultants are selling, and the reason it's not what the consultants are selling is you can't make money off of that. And I don't understand this argument of "Jobs-to-Be-Done is better than personas," because in personas you start with scenarios which are the verbs. So I really don't understand. You only get to personas after you've determined that the verb is the same, but the outcome is different because the people are different.

Samuel Hulick:

But you're starting your whole process and you're starting your thinking within a context of "kinds of people", not "kinds of things that they do".

Jared Spool:

No, you're not. That's an assumption you've made that's not true.

Samuel Hulick:

It's USER research.

Jared Spool:

Yes! Because we're studying how users accomplish something. Look, here's the deal: it's very different for a veteran who's already in the system to get an appointment than a veteran who's not in the system to get an appointment. A veteran who is not in the system has to jump through a whole boatload of hoops that one who's in the system doesn't have to jump through. If the veteran already has a relationship with a specific doctor, it's much easier for them to get an appointment than ones who are already in the system but don't have a relationship with a doctor, and even much harder for people who aren't in the system and don't have a relationship with that doctor.

Samuel Hulick:

So this is a bias of the system as it was designed.

Jared Spool:

Yes. Yes, the systems as they exist today are that way. But the thing is, is that if I want to improve the lives of those veterans and help them get the healthcare they need, I have to segment them into those three groups.

Samuel Hulick:

Groups of what? Groups of people kinds?

Jared Spool:

Yeah, they become personas.

Samuel Hulick:

Ok.

Jared Spool:

Veterans who already have a relationship with a doctor is a different persona for making an appointment than veterans who don't have a relationship with the doctor but are in the VA system, and there's actually a fourth type, if you understand how the VA works, which is they have to be in that facility because if you are seeing a doctor in Portland and you move to Boston, you actually have to reenroll in the VA hospital system when you get to Boston. Because it's 192 separate entities that are designed independent of each other. So now I have four different persona types, right? And the tool I'm going to build to help them get appointments quickly and get to a doctor as soon as possible actually have to be different, based on those contextual elements. And the only way I learn those things is by spending time with veterans, and learning the system, and I have to spend the time with the veterans. I cannot do it by just studying the appointment system that the VA has. It won't be clear to me, and so I have to spend the time with it. So I end up building very different things, and as I understand the way it works, it's the same "job" -- if I use that mentality -- of "hiring" the appointment system to get me an appointment with my doctor. I hope I'm using that right. But the thing that the job has to do is very different depending on the context of the veteran who's hiring that person.

Samuel Hulick:

Ok.

Jared Spool:

And I need to understand all of that. And what I don't see in any of the writing about Jobs-to-Be-Done is the research that gets me there.

Samuel Hulick:

Well, we agree on that one. I'm just going to fold on that whole point.

Jared Spool:

Ok. But the only way I got there was by studying users. And creating personas, and coming up with scenarios, which is what I just did before your very eyes.

Samuel Hulick:

So, if we're talking about segmenting around kinds of users, as we understand them, versus segmenting around kinds of things they want to do… I find that that happens a lot in software design where -- let's say you're creating an account or you log in to do something, a lot of times software might say "are you a designer or a marketer or a developer?" and then you choose one or multiple --

Jared Spool:

Yeah, but that's role-based. But here we have -- to use your words -- four kinds of users. We have the veteran who's already got the relationship with the doctor who's in the system at the facility. We have the veteran who's at the facility but doesn't have the relationship with the doctor, but they're in the system. We have the veteran who's in the system in another facility but not in this facility who needs a relationship with that doctor. And there's the veteran who's not yet in the system at all. And they're all veterans.

Samuel Hulick:

And the doctor!

Jared Spool:

Well, yes. It turns out that the doctor doesn't play much of a role in that particular interaction. But they're all veterans and we're designing something to help those veterans accomplish what, at a high level surface, is the hole in the wall. Right? We are trying to help them get an appointment with a doctor they desperately need to see. And when I was at the White House, we were at a time where veterans were committing suicide in VA hospital parking lots because they were told they couldn't have him an appointment for mental health care within six months, and they couldn't live with the pain anymore. So this was a life-and-death issue that the design team was dealing with, and the design team had to quickly realize that there were four different types of folks and they had to design for different types of solutions to accomplish this one job.

Samuel Hulick:

Certainly there could be at least a high degree of overlap, though.

Jared Spool:

Yes there is. But there were enough elements of each of the differences that they needed a different solution for each one. Now, that doesn't mean that that screen 7 and screen 15 are identical, of course, across all four groups. Yes, they probably are. But you had to ask for things from one person that you didn't want to have to ask from another person, because you already knew the information and there were other things that were required. So for example, you had to get the records from the other facility or you had to get the records from the DoD, who up until recently were not passing them electronically. The DoD has the electronic health records, but up until about a year and a half year ago, when you left the DoD and you went to the VA, when you got out of the military and you went to go to the VA for your treatment, you had to literally carry a folder of papers from your exit interview with the military to your VA incept place. Instead of having the records electronically sent from one government server to another.

Samuel Hulick:

Which would benefit everyone, regardless of what kind of person they are.

Jared Spool:

Exactly. But… actually, no, that's not true. They only benefit people who are leaving the military. People who have already left the military do not get the benefits of it.

Samuel Hulick:

I guess that's kind of the question that I have for you, because you're saying it benefits people who are leaving the military. To me the "are leaving the military" part is much more important than the "people who are doing it" part.

Jared Spool:

I'm sorry, I didn't understand what you meant by that.

Samuel Hulick:

Well, you're sort of describing people like there are types of people who are trying to do a particular thing, who are in the process of leaving the military. That's a kind of person.

Jared Spool:

We're talking about soldiers. We're talking about soldiers who are no longer serving.

Samuel Hulick:

But "leaving the military" as a process.

Jared Spool:

Yes, it's a context. They're at the point where they are no longer in the healthcare system of the military and they wish to be in the healthcare system of the VA, but they're not. So that's a state that they're in, and there are people who are already in the VA service and there are soldiers who are already in the military service, so it's the people in that transitional state. They're the only ones. They're the only ones who are affected by it, so it's not everybody. It doesn't affect everybody. It only affects the people in that transitional state.

Samuel Hulick:

I think there's a huge difference between the process of attaining that desired state -- or even just the desire to attain that state -- versus "a sort of person".

Jared Spool:

But they are distinguishable people. You can take an individual and put them in one of three groups.

Samuel Hulick:

In time. They might happen to be that at one time, but not after they're out of the military. They're not that kind of person anymore.

Jared Spool:

That doesn't matter. When you're talking about personas, you are talking about people in distinguishable groups. That's all you're talking about. It could be that they're distinguished only in that moment in time, but that's the distinguishing fact.

Samuel Hulick:

Right, and I don't think that distinguishing people as the primary context is as helpful as distinguishing by those desired states as the primary context.

Jared Spool:

Ah, but the states and the people are in a interweaved. You can't have one without the other. That's where, I guess, maybe we disagree. I don't understand how you can separate them out… they're inseparable. In that particular example, they are inseparable. I am either a veteran who's in the system, a veteran who's in transition in the system, or a soldier who's still serving. At any given moment, I am in one of those categories. And the way we design the system depends on which of those categories you're in. So, I have to create different solutions for each of those things. Whether that difference is just a field in a dialog box, or a completely different app, or a whole surface design model, I'm designing something different. To say it's not helpful to think about those differences, I think, is problematic.

Samuel Hulick:

I'm saying as the primary way of looking at it. I think that it's very helpful in a supplementary way.

Jared Spool:

I guess I don't understand what a "primary" way of -- what I'm trying to do is create an entire understanding. There's no notion of primary and secondary. And maybe that's the problem. I don't have that idea, that somehow when I'm researching, there are primary attributes and subsidiary attributes, and that somehow only focusing on the primary helps me solve something better than not taking into account the subsidiary. In fact, I think that that gets us into a whole lot of trouble, the minute we put on those blinders. I think that if you try and solve for -- you can say "we are designing for the transfer from the military to the VA" and yeah, there's only one group of people that fall into that category, so yeah, the persona is not that interesting until you get into subtlety. Right? And the minute you get into subtlety is "well, are they injured? Were they injured in the military or were they not? Were they released without injury?" That turns out to be an important thing. "Was the injury brain trauma related?" That's huge right now. So if that was the injury, you go through a completely different set of design than if you didn't have brain trauma related injury. "Does the injury incur a disability?" If, so, that gets you into a different thing. Right? And so all of a sudden, we're now segregating people -- because these are different people -- in order to come up with design solutions that solve a complex problem. The overall task -- "accomplishment", as you were -- is getting your appointment with your doctor. But all of those factors will make a difference in how we design. How you get an appointment with your doctor.

Samuel Hulick:

I completely agree. But even in your words, didn't you just say that was the primary thing? I guess we could go back to the tale of the tape, but it sounded like you were saying the primary thing was getting the appointment with the doctor.

Jared Spool:

I was using your word of accomplishment.

Samuel Hulick:

Ok.

Jared Spool:

Getting the appointment with the doctor is the moment in time that demarcates the end of the design sequence. It's certainly not the end of the service, right? So for doing service design, we would end there.

Samuel Hulick:

It would be like the finish line.

Jared Spool:

If we are building an app to make an appointment, the appointment is done when it's made. So therefore, the task is completed, the accomplishment is had. Assuming that's what we're working on. So, if we're building something that helps veterans get appointments with doctors so that they're not committing suicide in the parking lot, then we have succeeded when the appointment has been made, or maybe we've succeeded and when the veteran is in the doctor's office. But we have some moment that we say "that is successful task completion" and the design is created to do that job.

Samuel Hulick:

Ok.

Jared Spool:

I think that's what Jobs-to-Be-Done means, but I cannot treat it simplistic that all veterans need the same solution to make an appointment. Because if I go down that road, people kill themselves in parking lots.

Samuel Hulick:

Sure. Well, again, there's who you help, what they want help with, and how you help them. And so the solution would be how you help them, but it doesn't change what they want help with. It can help them well or not well --

Jared Spool:

-- oh no, but it changes how you will deliver that.

Samuel Hulick:

Of course, by definition.

Jared Spool:

Yes. So you cannot separate the people out of that.

Samuel Hulick:

But like your example with cars or hammers, if you said "we make hammers, and there are people who buy and use hammers, and we want to better understand hammer people…" I think that's a very limiting way to look at it. I think instead, saying --

Jared Spool:

-- of course it's a limiting way to look at it. And most of us aren't designing hammers. I think most of the things we design are not hammers. I think most of the things we design are way more sophisticated than a hammer.

Samuel Hulick:

Okay. How about a car?

Jared Spool:

They're way more sophisticated than a car. A car has what? Maybe 150, 200 function points. The appointment system for the VA probably has a thousand. It's an order of magnitude difference in complexity. The thing about a car is the car doesn't care whether the person has been a veteran or not. The car doesn't care whether someone's injured or not. The car doesn't care about any of those things. It's a design that's made for everybody. Now here's the deal. Do you remember the Ford Probe?

Samuel Hulick:

Uhh… no.

Jared Spool:

Oh, you probably don't because it was a very poorly-designed vehicle that was designed for women. It literally was designed for women. They assembled a women engineering team. They test drove it in high heels. It was designed for people, but it was a poorly designed vehicle because that's not how you should design something. However, cars are designed to have adjustable seats. They're designed to have adjustable steering wheels. You can't shift that at all. You can't put a child in the front seat. It's against the law, because if you do, they will be killed when the airbag explodes. They'll be suffocated by it. At some level, we're designing for people. We're always designing for people. And otherwise we're just making art. And if we're designing for people, you have to take the people and their differences and their uniqueness into account. Now, you can try to ignore it and you come up with very generic products, but there isn't just one type of hammer on the market. There are many different types of hammers on the market, and you design each individual hammer for the thing it needs to do, which as I understand it, is the whole Jobs-to-Be-Done thing. But the only way you get there is by understanding the people and the motivations and the context for which they need to put the nail in the wall. Maybe they're not even putting nails in the wall, maybe they're doing something else with the hammers. Sledgehammers are not for putting nails in the wall. At the end of the day, what we're talking about is we need to really understand the full picture of what's going on. We can't design by just focusing on one piece of it. I don't think that produces good design. I have not seen any example of good design that has come by treating the users as the secondary attribute and only focusing on the thing that users try to do, somehow in absence of users. I just don't see it.

Samuel Hulick:

Where does that break down for you? So you could say --

Jared Spool:

I'm going to need to interrupt us right here. Is there any way we can put this on hold so I can, uh… I have a job to be done. [laughs]

Samuel Hulick:

[laughs] Sure! I will. Uh, okay.

So we've been talking for a while, and I've been enjoying this. I think we can try to summarize. And I think I have a helpful way of framing it. So, we agree on a lot. We agree on more than maybe either of us are letting on, I think.

Jared Spool:

I think we agree on quite a bit.

Samuel Hulick:

Yeah. And it's easy to get caught up in the words and terminology and things like that, but I think that we can hold different concepts in our head. And we can talk, generally speaking, about people types -- people who want to do something -- versus the wanting of that thing. It's sort of like the tail wagging the dog a little bit, right? Is the dog "the person" and "the things that they want to do" are the tail, or is the dog "the thing that people want to do" and the tail is "the people who want to do it"? And I think that what we can both agree is that that might be a concept that we can consider in the abstract, but when it's borne out in reality, there's a sense of "these are individual people doing actual objective activities and abstract concepts only goes so far." But here' the question that I have for you, which is if we're talking the tail and the dog, and whether that's "the person who wants to do something" or "the doing of the thing that people want", what is the thing that you would organize your entire company around? For me -- and I think that the Jobs-to-Be-Done perspective says you organize all of your efforts, everything that you value -- everything that you invest in as a company should be in delivering those results to the people who are seeking them, with the results being the main focus and the people being a complementary -- giving a complementary level of understanding to how that actually takes place. And what I'm hearing from you from an experience design perspective, is that the thing that you organize your company and your efforts around are the people and you want to understand what they want to do, but those are the moons that orbit around the planet of the person.

Jared Spool:

No, no, no.

Samuel Hulick:

Great.

Jared Spool:

I think I understand now where we're at.

Samuel Hulick:

Ok.

Jared Spool:

Because what I was missing here was this idea that you are suggesting that you organize your company around choosing between users or thing --

Samuel Hulick:

Users or what?

Jared Spool:

You have to choose between either the users or the thing you're building.

Samuel Hulick:

No, that's again -- what I'm saying is the thing that you're building exists independently of what people are trying to do with it. You would agree, right?

Jared Spool:

Ok. Ok. Yes. So the thing that they're trying to do with it. But that somehow you have to choose one of those things to organize your company around.

Samuel Hulick:

Yeah. I think in basic terms we can say there are people, and there are things that people want to do. And, and I am on team --

Jared Spool:

I think that you are asking companies to choose between their favorite child. This is the problem, right?

Samuel Hulick:

And I would argue that companies have already made that choice without realizing it, and that they've chosen people.

Jared Spool:

No, I don't think so. I think companies -- the vast majority of companies out there choose their business. They organize around their business. They don't organize around their users or what their users are trying to do. I think it's a notion of design maturity, right? So companies that are very good at producing great designs all the time -- of which there are only a handful -- those companies don't make the choice that you are asking them to make. And they don't choose it the way you're suggesting.

Samuel Hulick:

They have two favorites?

Jared Spool:

It's not a "favorite" thing. They realize that this comes part and parcel as a whole, that you cannot separate out either one of those things. That they think about who their users are and they think about what their users are trying to do. And when that gets out of balance, they sway the balance in the other direction. So if they feel like they know more about the users but less about what they're trying to do, then they go in the other direction for a little while. But they are always thinking about both of them. I don't think you can separate them out. I don't think that idea actually works.

Samuel Hulick:

So it's not, uh, "the tail and the dog", it's… two dogs, no tail?

Jared Spool:

It's the whole dog!

Samuel Hulick:

[laughs] Yeah. I don't know. I think that especially when you look at it being called "user" research, not "accomplishment" research and how most --

Jared Spool:

-- we call it user research historically, so that we use a term that we always use. The same way that we referred to this as a telephone call even though neither of us are using a telephone. I wouldn't put too much weight into the fact that we call it user research. We call it user research because what we have to do is we have to talk to users. And we have to watch users. And that's how we get to what they're trying to do, and how their world lets them do that today, and how we can improve that in the future. The only way we get there is by researching users. The opposite of "user" research is "market" research, or "business" research. And either case ignores the user. Market research looks at wholesale, aggregated analytics, and business research looks purely at business activity. User research is called "user research" to get people to realize they have to spend time looking at their users. But what we're trying to learn from the users is all the things we've talked about. And you don't favor one over the other, because that doesn't work.

Samuel Hulick:

And you are positing that the only way to learn is to learn from users.

Jared Spool:

Yeah. I don't see how you learn anything about your product without talking, observing, being with your users.

Samuel Hulick:

Well, I guess that's again what I'm coming back to. I'm not even saying "learning about your product", just learning what it is that you should be helping people with, period, I think can definitely be investigated --

Jared Spool:

-- yeah, I don't see how you do that without being around users. How do you do that? Give me an example of somebody who's done that without interacting with users.

Samuel Hulick:

Well, let's say there's Tinder, for example, as a product that helps users go on a date.

Jared Spool:

Ok. Do you know anything about how they built it?

Samuel Hulick:

No. I'm not claiming to. I'm just saying that you can study going on a date independently of Tinder users.

Jared Spool:

Ok. Wait, wait, wait, wait, wait, wait. Is that where you're getting hooked up? That the notion of users is they have to be actually using your existing product?

Samuel Hulick:

No, I'm just saying that limiting your research to "better understanding people who might use your product and what it's like using your product" blinds yourself to the point of --

Jared Spool:

-- right, but that's not what user research limits itself to. User research says "well, let's go find people who want to have a -- you know, want to either couple up or, you know, whatever it is." Whatever you decide the end goal is -- is the date the end goal? Was getting married the end goal? Is not dying alone the end goal? Whatever it is, let's go find people who are in that situation and let's study them and let's see where there are -- what works in their lives and what doesn't work in their lives. That's what user research is.

Samuel Hulick:

Right. And again, I agree that user research can be a really helpful tool, but if you look at Tinder versus Christian Mingle, one of those is much closer to supporting the accomplishment of "finding someone to marry" than the other is. The purpose is different between the two.

Jared Spool:

Ok. That's fine. But there's nothing in how research is done by people who do it that says that you wouldn't go research the whole spectrum of people who were doing it.

Samuel Hulick:

Sure. And then again, just as a central organizing principle of your business efforts, I would say that getting clarity on that is really, really important. And defines the kind of people that you go talk to.

Jared Spool:

Sure. So what we agree on, if I understand, is having clarity about the thing you're building and who you're building it for in order to build something better for them, that makes them happier, more delighted, or whatever metric you want to use. That's the organizing principle.

Samuel Hulick:

No. You just said "getting clarity on the thing that you're building and who you're building it for to make it better and more pleasurable for them"?

Jared Spool:

Improve it by whatever metric you want to use as success.

Samuel Hulick:

I would say no. I would say that it's not a question of what you're building and who you're building it for. I'm saying that both of those are determined by a bigger question, which is "what is it that people are trying to do?"

Jared Spool:

Yes, but that's what you're trying -- ok, I don't see the distinction.

Samuel Hulick:

Ok.

Jared Spool:

I don't see a distinction. I don't understand why you would build something that people aren't trying to do. Maybe that's the problem I have, is that no one's ever said to me "we are absolutely trying to not build a product that serves what people want to do. We want to go in the other direction. Whatever people want to do. We want to go the other way. People want to get a date, we're going to break them up." No one has ever set that out as a goal in any meeting I've ever been at. I know people who are ignorant about what their users are trying to do, and those people definitely need help with that. And they may think they know everything about their users, but if they don't know what the users are trying to do, they obviously don't.

Samuel Hulick:

Well, let me ask you this question because I genuinely don't know what your response to this will be, but I think it might be illuminating. If you and I spin up a consulting firm -- which sounds like a lot of fun -- and Tinder hires us, for example, would you place -- again, "primary", "complimentary", I'm not saying that there's one that's the thing that you focus on at the exclusion of another -- but if you're just identifying the main area that you will be investing your time and attention, would you choose understanding, in and out, all of the different parts of going on a date, or understanding, in and out, all the different parts of being a single person, specifically? "Single" type of people?

Jared Spool:

Well, that's a scoping issue.

Samuel Hulick:

But it's also just the fundamental nature of whatever it is that you're studying.

Jared Spool:

Yeah, but we haven't actually said what we're studying. We said we want to -- Tinder's hired us, but what did they hire us for?

Samuel Hulick:

To make their product more effective, presumably, right?

Jared Spool:

Their dating product more effective? Or to expand their product set to reach unmet needs around, the life of being single?

Samuel Hulick:

Well that's -- I mean, again, that's the crux of what I think we're talking about too, which is do you understand singleness or do you understand going on a date? And both of those are highly correlated, but again, in the Clayton Christensen sense, being 50 years old and six feet tall and having a particular income level might correlate with having a subscription with the Wall Street Journal, but it doesn't cause the subscription to the Wall Street Journal. It doesn't explain the consumption of it. And for me, when somebody is in a position where they go "I know I'll use Tinder!", I'm saying that has less to do with who they are and more to do with what they're trying to do. And I like to focus my studies --

Jared Spool:

-- no, it has everything to do with who they are, but it doesn't have to do with the attributes you just mentioned. Who they are is not defined by what some database thinks they are. Who they are is who they are, and everybody's different.

Samuel Hulick:

I don't think it has a lot to do with who they are, and I'm not sure --

Jared Spool:

-- it absolutely has to do with who they are.

Samuel Hulick:

In what way?

Jared Spool:

For one thing, because you can start to slice that experience in about 17 different ways. Someone who's had a bad experience with dating is a very different person than someone who's had no experience with dating, versus someone who's had a great experience with dating.

Samuel Hulick:

I agree that there's a lot of overlap.

Jared Spool:

The four women on Sex in the City would use Tinder very differently.

Samuel Hulick:

Right! And I don't think that you create four different Tinders for the four different kinds of characters. I think that, that maybe --

Jared Spool:

-- well you do, but they may all be under the same code base.

Samuel Hulick:

I would have severe misgivings about saying "there's a Catherine and a Sarah and whoever else, and we're designing different things for these different kinds of people." I would say "let's identify what it is that everyone's trying to do, and if there are severe differences there, then we segment around that."

Jared Spool:

Yeah, I think you build really boring products if you go down that road. I think you build products that don't make anybody happy. If you go down the road you're trying to go down, I think you end up building products that actually serve nobody, because they don't take into account the nuance that makes any given person different. And you end up with something that is so generic that you are unlikely to satisfy anybody's basic needs.

Samuel Hulick:

Well, to use your terminology, "not if you're doing it right."

Jared Spool:

Well, please -- show me someone who's done it right. This is what I've been trying to get to with Jobs-to-Be-Done. I would love to see that happen. This would make me happier than anything, to see someone actually pull that off.

Samuel Hulick:

With "that" being "we identified something that people try to do and we coordinated all of our efforts around helping them do that and it was successful?"

Jared Spool:

Without trying to understand the users.

Samuel Hulick:

That's not what I'm saying, Jared. I'm not saying that it's completely devoid of any concept of the people involved.

Jared Spool:

But let's say that the characters in Sex in the City were real people that we were trying to design for. I don't think one interface would solve all their needs. I think you could package it in a single code base. You could have different dialog boxes appear for different people, or different fields, or different interactions, but I don't think they would have identical experiences with the product.

Samuel Hulick:

Well, I guess you could say no two people would ever, by definition, right?

Jared Spool:

Oh no, no, no. You can. You can get people to -- ok, let me tell you another story.

Samuel Hulick:

Alright. I'm lovin' this. We're going to have to make this, like, a three-parter, but let's continue for sure.

Jared Spool:

Ok. Years and years ago, I worked on a project for a company that was putting an installation into Epcot Center. This was in 1983, before Epcot Center opened.

Samuel Hulick:

A building?

Jared Spool:

Yeah. It defies architectural description. Are you familiar with Epcot? Have you been there?

Samuel Hulick:

Well, I know the big dome, but the --

Jared Spool:

-- yes, the big dome is called The Planet Earth, and it's a ride. And when you got off the ride you were deposited at the back entrance of Planet Earth. And at that point you encountered a set of kiosks -- and this was in 1983, so the Mac hadn't even come out yet, the PC had come out at this point, but most people did not have one in their house, and didn't use one at work -- so you encountered a set of computer kiosks that had touchscreens, that allowed you to explore Epcot Center and plan your day, including making reservations or asking for directions or all these things. And you could touch an icon which was the picture of a guest services cast member and you would be connected to someone who was in a support center through video conference link, and you would have this conversation about making a reservation for dinner or something like that. And they would do all these things, and it was supposed to be this kiosk of the future. It doesn't exist anymore because that's not the future anymore. But in 1983, that was the future. And it was a joint project between Disney, AT&T, and Digital Equipment Corporation, who I worked for. And so I was in the park before it opened, helping do the installations, and our Disney counterparts gave me a backstage tour of the Magic Kingdom. One of the things that we got to do in this backstage tour was we got to sit in an observation room in the haunted house ride. And in this observation room, you got to watch guests on the ride go through the experience. And it was situated in a place where there was a cemetery, uh, in the scene. And the cemetery had all these ghosts that were visible and --

Samuel Hulick:

-- not real ones, though.

Jared Spool:

Not real ones, as far as I could tell.

Samuel Hulick:

That sounds very scary.

Jared Spool:

Yes. And the ride basically was: you were in these half dome cars that have a sound system in them. What was unbeknownst to the riders was they also had microphones in them. And we would see the cars come around and the microphone at that moment, the sound from the microphone would get piped into our observation room, and we could listen to the conversation that was going on in the vehicle until it went out of view, and then we got to see the next vehicle and hear its conversation. And as we're sitting there, one vehicle after another, there would be a dad and two kids or three kids, and -- or a dad and a mom and two kids or something like that. We would see these people come by, and maybe three out of every four vehicles, as soon as it went around the corner and the family spotted this graveyard scene with the ghosts, the dad -- it was always the dad -- would say "heh, they're dying to get in there."

Samuel Hulick:

[laughs] Speaking of pattern integrities…

Jared Spool:

It happened over and over and over again. Now, that dad thought he was the first one to make that joke, he thought he was the only one to make that joke. And yet as we sat there, we heard that exact joke 50 times in a 15 minute period. And that experience was designed to elicit that joke. In fact, the Disney imagineer who was giving us the tour told us they would tweak the design until they got everybody to say that joke.

Samuel Hulick:

Ok. That seems like a weird outcome to optimize for, but alright.

Jared Spool:

Yes. This is how Disney thinks. And that was a designed experience. You can't get any more "designed". You can't design an experience any more than that -- to get people to always make the same joke and think they are unique and making it? That is one hell of a design effort.

Samuel Hulick:

Ok.

Jared Spool:

So I am not of the -- that changed my entire opinion on this notion that "we can't design experiences" because I've seen it done.

Samuel Hulick:

Ok. I'm not really pushing back on that.

Jared Spool:

Ok. Anyways, that's what I wanted to tell you. [laughs]

Samuel Hulick:

[laughs] Ok. Well, if nothing else, that was a nice palette cleanser.

Jared Spool:

I have no idea why we got to that story. Other than you said something about not being able to design experiences, but…

Samuel Hulick:

I was saying no two experiences will be the same for two people. You can't step in the same river twice.

Jared Spool:

But see -- no, no! I contend that everybody on that ride was having practically same experience. I'm not sure that that statement is true. I'm not sure that, that we can't… I mean, I know that our tools for designing these things are so crude and so poor that it's very hard for us to do it reliably, but I am not convinced it can't be done.

Samuel Hulick:

Well, I'm not even sure it's desirable to do, but either way, I think that at the very least to say that the sum total of someone's lived experience as translated to a haunted house is going to be the same between two different people is ignoring --

Jared Spool:

-- ok, but let's go back to the veteran experience. I want to create an experience. Everybody on the VA team -- on the digital services team at the VA -- everybody there wanted to create an experience that was as seamless and as frictionless as possible to getting vets the medical care they deserve. And they were using the same exact techniques that that Disney team was using, except now with 30 years more of better experience behind it. But they were using the same techniques to craft experiences for each of those types of soldiers to get the medical care that they deserved. And I think they do want to craft a unifying experience, but they have to take into account the nuance and the context that is part of that to make sure that they get the experience necessary. And that is probably way harder than the task Disney had in front of them. But I think that that's what design is about, and research is about understanding what we need to know to pull that kind of design off. And I'm really trying to plug Jobs-to-Be-Done into something that says it makes that job easier in some way for some group of people, and I'm having trouble doing that. And that's really where my issue with Jobs-to-Be-Done is… is that I'm not seeing what it brings to the table that makes things better than what we already have. Now, granted, not everyone is using what we already have. I got that. And I think we should study that in more depth. I think a lot of us are studying that, but I think we should study "why don't people do design well?" That is the mission of my organization. So our hundred year mission is to eliminate all the bad design from the world, and the only way we're going to achieve that hundred year mission is to understand why people consistently, continually put out bad design. I believe we know enough right now to put out decent designs every time, yet we don't. And so understanding why that is is the core of our mission. That said, I don't understand what Jobs-to-Be-Done, in any of the forms I've been able to decode, brings to the table to help us accomplish that. I would really like to because if there's -- if there is something there, I want to be party to making it real in the world, whether it's hosting someone at our conference, or featuring them on a podcast, or whatever it is we do. If there's really something there that helps people, I want to be part of it. But I'm just not seeing it.