Jared Spool: I am fully aware that I am the thing between you and drinks.
[laughter]
Jared: I am even more aware that you are the thing between me and drinks.
[laughter]
Jared: Let's talk about strategy. To do that, I want to talk about what is probably the most expensive, most involved UX project that has ever happened. The really weird thing is that we haven't really talked about it as a group.
We don't hear people talking about this. We hear people talking about the Apple Watch. We hear people talking about all sorts of things, but we're not talking about what turns out to be one of the most important projects that have happened this decade. That's the Disney MagicBand.
Now the thing about the Disney MagicBand is that it's a wearable. It's like an Apple Watch. But unlike an Apple Watch, it doesn't count your steps. It doesn't measure your heartbeat. It doesn't even tell time even though it is sold by the same people who make Mickey Mouse watches.
The even more impressive thing about this is that this band costs a billion dollars to develop, a billion dollars. Put that in perspective. That's about 20 times more than Apple spent on the first iPhone. It's more than twice what Apple spent on the Apple Watch. Disney invested a billion dollars in a wearable that doesn't tell time.
But what it doesn't do is not the important thing. It's what it does do that's interesting. It has embedded in it three different transmitters. Those transmitters communicate all sorts of information.
You see, when you order one of these things, actually when you order all of these things because you get them as a group when you take your family to Disney World or to Disneyland, you put in your order. A few weeks before you show up at the parks, you get a box, a beautiful box with the bands labelled for each person. In fact, the bands are identified on the back for each person because they are customized to that individual.
You configured them when you purchased them and there's all this information about who you are and what you're doing that's there. Of course, they tell you very specifically in the instructions. This is one of the things they learned through their usability tests, was that they had to tell everybody, "Do not pack this in your suitcase."
Because, if you pack it in your suitcase and take it to Disney, when you arrive at Disney, they come and they take your suitcases. They bring them up to your room for you. You have to have the band on. Because when you have the band on, you actually get a message on your phone that tells you which room to go to.
You don't check in at the hotel. You go straight to your room. You can use the band to unlock the room as if by magic. Of course, if it was in your suitcase, it would be inside the room. That's not going to work.
[laughter]
Jared: You use it to go on the rides at the park. You use it to pay for everything at the park. They know where you are. They know what you're doing.
Because you've told them, and it's often the case, they know about the kids. They know who their favorite character is. They know when their birthday is. If you show up at the park with the MagicBand on and it's your kid's birthday, their favorite character will actually hunt them down in the park and wish them a happy birthday.
The reason this cost a billion dollars was they had to completely gut the infrastructure of the park to make this happen. The actual wristband itself didn't cost that much to design. It was everything in the park, the entire system, the end-to-end experience that they built.
That's what a billion dollars gets you. It's magical the way this works. Disney is all about the magic.
Disney's always been about the magic since Walt started it. But they've had this problem for a while and they slipped away. This isn't the way Disney has thought about technology for the last few decades.
In fact, if we go back to 1997, we see a very different Disney. Now Parks and Resorts is the team that's in charge of the MagicBand. They're the team who's in charge of everything that happens in the parks and resorts. It's appropriately named to that extent.
In 1997, this was the website they put out. It was horrible. If you tried to book a reservation on this site, there was a very good chance that you'd end up talking to someone at the Call Center.
In some ways, they didn't see that as a problem because the people at the Call Center who finally booked that reservation you tried to book online but couldn't finish, they actually got a commission for it. They were quite happy to help you.
They had these competing things. The website was trying to book reservations, but it was so poorly made that you ended up calling in.
I've got to tell you, the site was so problematic to use that, for the period of 1997 to 2007, we used it as a way to train usability testing because you could pretty much guarantee that whatever participant you put in front of it would fail at whatever task you gave them to do.
[laughter]
Jared: For example, the canonical task that we used was this one that was basically our benchmark training task. It's called, "What is Walt Disney World's least expensive hotel that's on the Monorail?" This was actually a real task that we got from a real participant in one of our early studies of the site.
We had someone come in who was a real, what they call, "Worldphile." That's someone who loves Disney. They go all the time. They had a six-year-old who was into trains, particularly into the Monorail.
They wanted to book their next vacation which happened to be the six-year-old's birthday at one of the hotels at Walt Disney World that's on the Monorail. Now there are 28 resorts at Walt Disney World, but only three of them are on the Monorail.
You have to figure out which one it is. Of the three, two of them are wicked-ass expensive. One is normal Disney expensive.
[laughter]
Jared: You had to find the one that was normal Disney expensive in the task. That was the task we would give participants. This one was a soul crusher.
[laughter]
Jared: Now in case you were wondering, you want to try yourself, the answer is the Polynesian Resort. That is always the one that is Disney expensive.
For a period of about 12 years, when we've had to teach usability testing to a team, we would bring up the Disney site. We would start to go through this task. We started to collect statistics because we actually watched literally hundreds of participants go through this study. They only had a success rate on this particular task of about 1 in 10.
It was truly amazing. But what was even more amazing was a particular failure case that we saw. One in five participants, 20 percent, instead of choosing the Polynesian Resort at Disney World, they would pick one of the resorts at Disneyland. Land/world, world/land, what's the difference?
[laughter]
Jared: We saw this continually through that 12-year period. We kept seeing this particular problem to the point that we would actually put it in our moderator scripts. We had a whole procedure for it to make sure we understood the problem.
When we saw someone end up at the hotel in Disneyland, they found the one on the Monorail, and they'd say, "Oh yeah, I guess that's the cheapest one on the Monorail at Disneyland." They'd go, "OK, I've completed the task."
Our moderator would say, "Congratulations. I have a question though. Can you ride the Monorail from that hotel to Epcot Center?" They'd get this look on their face of, "Probably. I don't know." They'd turn back to the computer, they would click around on links, and they'd look at things. They would turn back to the moderator and, pretty much every time, they'd go, "Yep."
[laughter]
Jared: "Yep. Yes, you can."
[laughter]
Jared: Just in case you needed to know, Disneyland is 3,000 miles from Disney World. That's 3,000 miles in a train that has no restrooms.
[laughter]
Jared: I'm standing on a stage somewhere, and I'm telling this story, and after my talk, this person comes up, and on their badge, it says Disney Parks and Resorts.
[laughter]
Jared: I'm not really sure what's going to happen next. The person says, "Can I tell you something?" I go, "Yeah." "You probably have to promise not to tell anyone." "OK." It turns out it happens all the time. We have people who show up in Orlando with Anaheim reservations.
Audience: Whoa.
Jared: Yeah, you're feeling this. I can tell.
[laughter]
Jared: In fact, we confirmed this. It turns out that they hold a block of rooms, not an insubstantial number of rooms, in Orlando for people who show up Anaheim reservations. Because why ruin their entire vacation even when you're sold out by not having a room for them? That's amazing.
Apparently, it goes both ways. People are constantly mixing the two up, so they show up in Anaheim with Orlando reservations. It turns out that on a book keeping perspective, it's actually awash because every time someone checks into Anaheim, it frees up an Orlando room.
[laughter]
Jared: They're able to just make it work, and this is Disney magic.
[laughter]
Jared: Now, we knew about this problem for 12 years. I actually don't know how long it went on, or if it still goes on, but I do know this. Apparently, it was cheaper to keep a block of rooms reserved than it was to fix the damn website. That's how bad it was at Parks and Resorts.
Parks and Resorts was not part of Imagineering. Parks and Resorts is an IT organization, and when they put up that first website, they did what IT organizations do. They said, "Well, we've got this application that our customer service people use. Why don't we just get one of those designer people have them make it paddy, and put it up for the customer?"
That's what they did, and it wasn't a good solution, and it took them a long time to get better. What I'm really interested in is the fact that they pulled it off. They actually succeeded at getting better.
Let's talk about how they did that, and to do that, we have to talk about how we learn stuff. It turns out whenever you need to learn something new you start at a particular stage which we call unconscious incompetence.
Unconscious incompetence means that you actually don't know what you're doing. You're incompetent, but you also have no idea that you are incompetent. That's the unconscious part. It doesn't matter what you're learning. If you're learning UX, or you're learning cooking, or you're learning a musical instrument, you always start off at this unconscious incompetent stage.
When you're at this stage, you actually think everything you do is pretty good because you don't really know the difference between the good and bad. You don't know that some things are good, and some things are bad.
As a result, you produce a lot of bad stuff because just probabilistically, that's what's going to happen, and apparently you don't have any good friends to tell you that that's what you're doing.
You keep cooking, making really awful music, or whatever it is, and for that point. At some point, a friend takes you aside, explains to you that you're actually not good at what you do, and you become aware that there is a difference between good and bad. That's when you move to the next stage which is called conscious incompetence.
Conscious incompetence is in fact what happens when you now know that you are bad at what you do. Now, let's think about this for a second. When we were unconsciously incompetent, we were very happy people. Now that we've become consciously incompetent, that's actually sort modifying.
This is in fact the stage where lots of people give up. Most of us, who never learned to draw well used to think we were great at drawing, learned that there was a difference between a good drawing, and a bad drawing, and we stopped. Many of us gave up those musical instruments after the first few weeks once we learned how hard they were. It was the exact the same thing. That's the difference.
For those of us who push on, who get past it, we begin to realize that there are things we can do, there are practices that we can repeat, and those practices basically allow us to get good outcomes.
I mean, we follow recipes, we learn our scales, whatever it is. We start to learn the rudiments of what we're doing. Those practices make us better at what we do, and that's when we get to conscious competence.
Conscious competence is when we actually now can predictably produce something that's good as long as we follow the steps, as long as we're paying close attention to what we do. If I follow the recipe, I can make a pretty good mac and cheese, but if I try and improvise, it's not a good mac and cheese.
I stay with the recipe. I just keep working on that, and if I keep practicing, if I keep getting better at what I do, then eventually, I start to be able to do this unconsciously. I'll be able to learn these practices, and I can get these things to happen unconsciously. That's when I get to unconscious competence.
Unconscious competence is that state where I am now capable of doing this without thinking about it, without being able to see the difference.
Now, it turns out that these states follow a pattern. Getting from unconscious incompetence to conscious incompetence is basically becoming literate. When we're learning the difference between good and bad we are learning the literacy of the thing we are studying.
So when we talk about design we're becoming literate in design. We're becoming aware that colors don't always go together, that a grid makes a difference, that there are certain times you use a checkbox and certain times you use a radio button, that in fact responsive design is an important element. All of these things that we start to teach ourselves is that literacy.
But just because we're literate doesn't mean we can do it. We can read about. We can learn the teams. We can see the differences, but that doesn't mean we're capable of it. To become capable of it we have to become fluent so now we move to fluency.
The thing about fluency is that it's really about being able to make it happen. I can learn a language. I can learn the vocabulary, but that doesn't mean I can go to a country and have a conversation of any meaningful detail with someone until I become fluent.
Moving from conscious incompetence to conscious competence is that notion of developing fluency.
When I start to learn how to do things intuitively without consciously thinking about it, that becomes mastery. That's when I've mastered my craft. That's when I've mastered the language. That's when I've mastered the instrument.
When we talk about design, fluency is that ability to be able to do the activities and produce those outcomes, and mastery is the ability to walk into situations and say, "Aha, even though I've never done this before I know what to do."
Now here's the thing. I didn't make this scale up. The scale actually came out of the medical profession. It came from Johns Hopkins University, because they were interested in answering a completely different question.
The question they were interested in answering was, "Why is it that the world's best surgeons are amazing surgeons but horrible teachers?" Why is it that they really don't teach surgery well? Because for years the way doctors would learn is to go work for the best surgeons. It turns out that's a horrible way to learn.
The reason is that when you are unconsciously competent it's actually really hard to understand where someone who's consciously incompetent is coming from. You look at the situation and you can clearly see all the signs of what's going on, but that consciously incompetent person looks at that situation and they can't see it. They don't know what to do.
People who are really good at their craft turn out to make horrible instructors. The people who are the best instructors are the ones who are at the far right of the conscious competence scale because they are at least close enough to conscious incompetence that they remember what that was like so they know how to teach.
This turns out to be really important, because if we're going to get teams and the people we work with to understand the value of design we have to go through these stages. We have to understand how to move through this space.
But this is how it works for an individual. How does it work in an organization? If we want to talk about user experience design turns out there are stages there, too. The first stage is the Dark Ages.
It's where no UX design is happening. It's where the business is completely focused on just doing the business things, on producing the technology, on actually just making sure the business is profitable and no one's paying attention to design.
This is the world of unintentional design. Any design that comes out of that organization has not been given any thought whatsoever. All those things you look at and you go, "How did someone design this?" This is probably how. They were in this Dark Ages stage.
What happens here is there's this moment, and there's an emergent UX leader of some sort. Maybe it's somebody who actually has done this before. Maybe it's someone who just read Steve Krug's book. Who knows?
But someone comes out and says, "Hey, we could do something." They put together a project, and that project compared to what came before it is decent. It's a good user experience, and it gets noticed.
For a while the organization goes through another stage which we call spot UX design where there are these emergent leaders who keep trying to bring UX into the organization. They get a little traction. They do version one of whatever this thing is. Maybe they get to version two.
But eventually the organization closes in on them, everything goes back to the way it was, and that person gets frustrated, and they go work for a company that gets it. That's really what this stage of spot UX design is about.
But then there's another change that happens, another inflection point. That's when the executives for some reason say, "You know what? This UX thing, we need to make an investment in this."
Maybe it's because there's a competitor that's nipping at their heels saying, "We have something that's easier to use." Maybe it's because they're going home and they're using their iPads or they're using their phones and they're like, "How come our stuff doesn't work like this?"
I've seen a huge amount of this happening when the iPad first came out, because the executives were all walking around with their iPads, and then they would bring up their stuff and be like, "I can't even use our stuff on this thing. Why can't I use this stuff on our thing?"
That was thing. That was the inflection. Suddenly we get to the next stage where we put together a team and we say, "OK, this is the design team, and that team now runs a little service agency inside the organization. They do their best to help everybody in the organization get to this user experience stuff and get this design stuff. That agency comes up and it starts to work.
That starts to kick in. Some teams are good. Other teams you have to really push hard. Some people get it, some people don't but this is beginning to take. If it takes enough with some teams those teams will realize the value of having good design. They actually start to get impatient with that internal agency.
They start to really feel that that agency isn't giving them everything it can, because the agency is servicing the entire organization, and they need dedicated people. So we reach another inflection point where specific teams are demanding more involvement from design. They want to have dedicated design on their teams.
When we get to that point what can happen is we start to embed designers into those products and service groups, and they stay in touch and keep in communication with that agency, that centralized group, but now they are actually working with those teams.
They are available, and they are thinking about those problems day in and day out. They're not switching between one task, or another. They are dedicated to that thought.
As that grows that turns out to work really well, but in a few cases now we've seen another inflection happen, and that inflection happens when the teams that have these embedded designers are so bought into this process that they cannot get enough out of those designers by themselves.
Those designers become a bottleneck, and now they start to take non-designers who are working on those teams -- the developers, the product managers, the other people who are involved -- and they start to have them know enough about design that they can do the basic stuff. They are now fluent in that design process. That's what we call infused UX design.
Infused UX design is where we get this idea of being design-driven. This idea that we are now thinking about design throughout the organization because everybody has at least fluency in it, and that's the process.
Now Parks and Resorts in 1997 was in the Dark Ages, but Parks and Resorts in 2014 when the MagicBand came out that's an infused organization. Everybody gets design. It took them 17 years to get there so if you're thinking, "We're never going to get there..."
[laughter]
Jared: ...you might be right. But it's a slow process so it's hard to tell from where you're standing.
Now there's a thing about this, right? Because we've been talking about the organization, but organizations in fact are made up of teams, and when we start to look at what happens in an organization that's moving through this scale we find that different teams are actually moving at different rates, and so at any given time different teams will be in different spots in the growth stages.
Some teams will be really getting it, and they'll have dedicated designers, and they'll be moving forward, and other teams are still in the Dark Ages. They're producing crap, and they're not paying attention, and they don't know the difference.
When we start to look at those teams what we see is in fact they are made of people. Eventually it always becomes Soylent Green. But the thing about them being made of people is that they're not just any people. They're people who have influence.
That turns out to be really important because influencers have different behaviors at different stages. If we understand where our influencers are on a given team we can understand why the team is able to move forward or not.
If you have a strong influencer who is basically in the Dark Ages and just says, "Look, I don't know what this design stuff is. Let's just keep moving and get stuff out," that's a problem. That's going to hold the entire team back. That's going to cause those folks who are at the front to say, "Our folks don't get it. How do we convince them?"
We've being playing this how do we convince them game for a long time, but that's because we've been thinking about it wrong. The influencers are at different stages which means, that a team is actually held back because of the most immature influencer.
It's not a matter of selling them on the idea. It's a matter of literacy and fluency and mastery. The issue here isn't that they need to be convinced. The issue is they need to actually have the understanding of design. What we need to do is through our work actually get them to level up.
If you want to understand what a UX leader does, that's it. They are leveling up everybody on the team, and when everybody on the team is leveled up that team produces better work, and when more teams produce better work we get better outcomes.
For the last few years there's been this interesting mystery that I've been trying to get to the bottom of, and the mystery has to do with a thermostat. This was the Round Thermostat. That's what its brand name was called, the Round Thermostat that was produced in 1953. It was designed by a designer named Henry Dreyfuss who probably is the first real user experience designer around.
He created this basically canonical design that became the mainstay of the industry, and Honeywell sold millions of these things. In 2011 the Nest came out, and the mystery is why didn't Honeywell come out with the Nest?
Why was it that it was Tony Fadell and his team that pulled that off and not the team that owned that market that made billions of dollars on those thermostats? How come Honeywell didn't create the Nest?
To get to that we have to look at one more progression of stages, one more progression of growth, and that's how the market works. Now when any new thing comes out the market gets infatuated by the technology of it.
The first cell phone was the Motorola DynaTAC 800. This device cost $2,500. It weighed four pounds, and it barely worked, but people would pay for it, and it was incredible. People would pay that kind of money for a cell phone. It was crazy.
Then an inflection point happened. In this case there was a competitor. Once there's a competitor the market shifts to one that talks about features. When you're in the feature phase it's all about what those things can do, and everybody's talking about this feature versus that feature.
Initially you have to just deal with the quantity of features. Eventually it has to do with the best features. You can tell you're in this stage because every ad for every product that are competing against each other has these checkboxes.
It has columns with the different competitors, and rows with the different features, and under our products it says, yes, yes, yes, yes, yes, yes, and under their product says no, no, no, yes, no, no, yes, yes, no.
Our goal is to get as many features into the product as we can, but there's another inflection point, and that inflection point happens when the market, the people who are deciding which product they buy, stop caring about features.
At some point you cannot put any more features in a product that anybody cares about so you just start creating stupid features just to get people's attention. This is how we got the paperclip. We just keep putting stupid things in. Come to think about it it's probably whey we have Chatbox and Messenger now. We just have to put the stupid things in.
At this point we enter a new stage of the market, a stage that's focused on experience. This is when someone who is often an outsider to the competitors, not the leading competitor, comes in and actually makes a difference, actually starts to change things.
This is a fascinating period, because suddenly we can talk about the user experience. This is where we shine. We do fantastic. None of us like working in that feature stage, and we don't even get employed in the technology stage.
It's the experience stage where we get valuable to folks because we're going to pull this off, but interestingly enough we don't get valuable from the market leaders, because the market leaders are so in that feature mindset that they can't get out of their head that there's something else that could be better.
Even if they could get out of their head the problem is they've got a sales force out there that's telling people, "You need the features. You need the features. You need the features." Then one day say, "Actually all those features we told you about yesterday, you don't need any of them." That goes away.
When the iPhone first came out it had fewer features than the Nokia N95 which came out six months before, which the N95 was all about the amazing camera, and all about video, and all about music. This thing had no ability to send pictures, it had no ability to do video, and yet it cost three times as much, and everybody thought they were nuts.
Turns out there's another inflection point, and that inflection point happens when the product becomes part of a bigger experience. The phone interestingly enough is hardly about making calls. Every time I get a phone call on my phone I look at it as if, "What the hell is it doing that for?"
[laughter]
Jared: Oh, yes, that's the phone. I'm supposed to answer this now. Everything becomes part of this bigger thing. I was reminded of this recently. We get to this stage. I call it the commodity stage.
I was reminded of this recently when I read a headline in the paper that talked about how American Airlines was suing Gogo Inflight. They were suing Gogo Inflight because the contract that American had signed with Gogo Inflight five years ago for a 10-year contract for WiFi on airplanes they wanted to get out of.
The reason they wanted to get out of this contract is that Gogo's service -- the speed of the connection, the ability to handle a plane full of customers, the price of that service -- was making American Airiness look bad. People were complaining to American that the WiFi sucked.
American wanted to go to one of their competitors because it turns out now there's five or six other companies that actually have lower price, better service, in-plane WiFi. But the 10-year contract would not let them out. Gogo would not let them out of their contract.
They decided to sue to get out of their contract. It's like someone saying, "I want to move. I don't want to live here anymore because, I don't know, I guess there's mice." Same deal, they just got into a contract. They thought that 10 years was going to be enough time when they signed it, but it turns out the technology has been moving too fast.
Here's the thing. Gogo did what they promised to do, it just that it's not good enough to be on an airplane anymore with that quality of service. They were making the bigger airplane experience worse. This is what happens, right?
Suddenly we are looking at our devices, we are looking at our things, and we were now moving in a direction where that thing that we built, that one piece of technology, it does what we promised it will do, but it actually doesn't fit in the bigger experience, that end thing.
This commodity stage, this is where service design happens, because we are no longer focused on that little thing. We are focused on the bigger picture, the bigger journey that those users and customers are having, and that service design element is key.
All of user experience will be service design in a very short period of time because this stage keeps happening, or service design will be all UX. They're interchangeable.
These four stages turn out to be very important particularly when we map them against the stages of how we get better, how we become more design-driven, because what we've seen is that if we truly want to compete in those experience and commodities stages our organizations have to get to that infused design point, which it's almost impossible to remain a viable competitor if you don't get to that last stage.
How does this answer the Honeywell dilemma? Well, we can see the progression. Honeywell started as a technology play. Then in the last decade or so they got into programmable thermostats, but they never made it to where the Nest was. They stopped at the feature wars just like people often do, and an outside competitor came in, Nest, and took over.
That's intriguing because that change through a new player they came in at a later stage, and if we look at what happens here what we see is that there's basically this interesting phenomena of Honeywell being its spot design and the Nest being an infused design.
How did the Nest get there so fast? Well, it's sort of the way startups work. A startup can actually chose where it goes. Now originally when we were putting this theory together we thought maybe startups are like stem cells.
Stem cells are these magical cells in the body that can be anything, and when they're a stem cell there they really aren't anything, but at some point the stem cell decides what it wants to be, and then it becomes a liver cell or a colon cell. Then it's a colon cell forever.
Startups are sort of like that. I definitely have met startups that I think of as colon cells.
[laughter]
Jared: The thing about the startups is that they are in fact these things that can be wherever they want to be, but it turns out it's not quite that. What Tony Fadell did at Nest was he hired a whole bunch of ex-iPod and iPhone people, he being the designer of the original iPod and having worked on the original iPhone.
He brought a whole bunch of those people with him. They were already design-infused so that when they showed up, they actually were in a situation where they didn't have to deal with an existing company team that would hold them back.
This is why Honeywell could not pull this off. Honeywell would have to get rid of everybody who was less mature than this new startup thing they were building. You see companies try this.
They go off and they create this little startup thing, or maybe they acquire a startup thing, or maybe they start some sort of incubator thing, and they're trying to do this, but their existing immature organization holds them back, and that is the problem.
The issue here is that startups live in this little vacuum where if they hire the team just right they can be way down the infused stages and not be held back. But interestingly enough they have to keep that up.
Often what happens as they grow they lose that ability to hire those great people. They start to bring in people from other companies who are less mature and suddenly those wonderful startups just become just like everybody else. Now they are back where they need to be.
The thing is that where we're at here is at these stages where we need to really think about what we really want to do. There's something magical about that infused UX design stage. There's another point of inflection that happens.
Before we get to that point of inflection, the organization sets its bar such that it will only ship a product or service if it technically works, and if it meets the business needs. But if it's not designed well we'll still ship it. It's OK. We'll get it in the next release. If not that release it'll be the release after.
There's an old saying that Microsoft products never get good until version three. It's because Microsoft has this as their way of doing business. It has to work technically, has to meet the business need, but the design, the user experience, we'll fix it. We'll get there.
But an infused UX deign organization, if it pushes hard enough, will get to something that we call the UX tipping point, and the UX tipping point is when, yes, it still has to work technically, yes, it still has to meet business needs, but it also has to be delightfully designed. That's the key, being able to be at that point where they are able to be delightfully designed.
The interesting thing about that is that we can look at an organization and we can say, "That's a goal. That's something we can strive for. This is the thing that to look at, that moment, that point, where products are held back, because they aren't designed right."
The MagicBand was exactly that. It was exactly two and half years late, and it was two and a half years late not because it technically didn't work, not because it didn't do all the business things they needed it to do, but because the user experience wasn't right.
The Disney cast members have a saying. The saying is, "What would Walt want us to do?" Walt would hold back a product if it didn't have a great experience and the MagicBand team did just that. Raising the cost, huge, creating risk, huge.
They were so afraid that Universal was going to find out they were working on this and come out with some cheap knockoff and get there first so that when they finally came out with their thing it looks like they were just a me, too product.
They were so afraid that Six Flags was going to beat them to it. The secrecy around this product was crazy, but they got there and it was amazing.
My friend Dan Mall likes to talk about the difference between this -- this is Newton's pendulum. You've seen this before where basically it just goes back and forth and back and forth. He refers to this as a process.
There's really only one way to do it. You set it up, it just goes back and forth, and it's really not that interesting. You watch it for a little while. It's mesmerizing, but after a while it just gets dull.
But if you compare that to a soccer field what we see here is a system. Dan says this is filled with rules and constraints, but what happens when you put people inside those constraints, that's fascinating, that's interesting. That's fun.
Systems are way more interesting than processes. They're way more creative. They're way more fun to work within, and the results are much better. If we want to get to being these organizations, if we want to do what Disney did, we have to figure out what's the system that we want to build?
You can think of the system as being this place where you put down the rules, you put down the constraints, but then you give people a set of plays, and you have them execute those plays.
That's basically how sports works. What are the plays that we can use to become design driven? We started to study this, and we've actually come up with a list of about 100 plays. There are things like getting people started with usability testing, and talking about design.
They go all the way to doing critique, and putting out a living design system, then moving forward, and starting to use metrics more effectively, and analytics, and all these things. Each one of this is a play.
We started to ask the question, what are the plays that make the biggest difference? We looked at a bunch of organizations that have really pushed the limits on this infused design thing. We said, "OK, who's getting there? Who's becoming design driven? What are the plays they are getting?"
We found out that there were basically three plays that drove all these organizations that were working really well. The first one is immersive exposure. Immersive exposure is what happens when we get folks into the field. We get them to see the users. We get them exposed to what users actually do.
That exposure is key and it's a literacy play. You can use this for teams that are not very literate. You can use this for influencers that don't understand design. Instead of explaining to them the value of design, the simplest thing to do is to get them exposed to actual users using the design.
This is why usability tests work so well. We get these influencers to see what users are there. Yeah, sometimes you have to bring them video tapes and cut out all the boring parts of the test, and just show them that.
But if you really want to be immersive, what you need to do is get them in the field. You need to bring them out, and actually have them see the users work, see them use the tools. See them deal with the situations. When you do that, it's a radical experience.
I'm betting that many of you have shown somebody real users doing real stuff, and the reaction you get is, "Why didn't we do this two years ago?" It's just crazy how much this works. We found that the organizations that are best at this, they're investing a minimum of two hours every six weeks.
That's the minimum. The better organizations are investing way more. They are getting people immersed on a regular three week basis for a full day. It's crazy the amount of time people are spending, seeing users actually use their designs or a competitor's designs. The benefits are huge.
Now, the process of doing this allows you to get an understanding of what's happening to that customer, to that user. We can map this on a journey map. There are lots of different ways to do journey maps. The way I like to do it is you take the things that a user needs to do -- in this case, we're having them book a property.
You measure it on a scale of frustration to delight. You say, "OK, that first step where they were searching for the hotel, that was really great. But once they got to the hotel and they started to look at the different rooms that were available -- man, that was frustrating. They couldn't figure out what was different between one or the other.
Then you say, "OK, but they decided to pick one and they start booking. That works, but then they get into the payment engine, and the payment engine is asking them to take the dashes out of their phone number, and it's asking them to put in the security number on their card multiple times. That's really frustrating."
Finally they say, "OK." That experience is amazing. You get an influencer to see this happen, and the first thing they say is, "We've got to fix that. We've got to look at these points on our design, and we've got to make them better."
My favorite thing to do, I have two little tricks that I do with this. The first one is, before we actually get to where the customer is, often when we're driving in the car, when we're at the meeting place for our pre-gathering before we all march in and visit this user. I ask people, I share with them what I know about the participant in the study, say, "Here's what we know.
This is a person who uses our product all the time. They use it for these things. They work at an organization that's given us this much money to buy these extensions. We're going to hopefully today, see them use this thing."
Then I ask, "What do you think their journey is going to be like? What do you think the steps they'll go through are? What do you think the frustrating parts and the delightful parts will be?"
I have everybody who's on that little away team tell me what those frustrating or delightful parts are. Often, what happens is they'd get really excited about it. "This person's going to be one of our best users because they use it all the time. They're big on this. They're going to be there."
Then we get to their office, we see it, and it never works out that way. It's a dismal period. Here's the thing. There's two outcomes that happen, either they predicted correct, at which point whoever that is, is like, "Hey, I'm good." I'm like, "Hey, you actually sort of know something about customers. I'm going to keep talking to you." Or they get it completely wrong, but they know they got it completely wrong.
One of the things before I started doing this, one of the things I noticed is we would take people out. They'd sit through this experience. They'd watch these people suffer and have all these frustrating moments. They'd go, "Yeah, I sort of expected that."
Sort of expected is not expected. Sort of expected means, I didn't really think about it before now. I make them think about that. That does it.
The other thing I do is whoever the most highest paid person in the room is, they're the ones who draw the map. That's their job. "Hey, I'm too busy. I'm going to be talking to the person. I really need to concentrate on the interview and the session. Could you actually draw this for me? Write down each step, and then write down whether they're frustrated or delighted as we go."
"Yeah, sure, how hard can that be?" They're the ones who are putting those points at the bottom of the scale. That's immersive exposure, getting folks to see it. It changes the way things work.
Dana Chisnell who is part of the US Digital Service, she talks about how she's been using immersive exposure by getting developers and product managers out into the field to actually see government employees use the systems that they're building. What she's learned is that every time she does that, those developers and those product managers come back and the way they create user stories, the way they create use cases, the way they think about the design changes completely.
It doesn't take more than a day's worth of visit to see that outcome. This turns out to be really powerful.
The second play is the shared experience vision. A shared experience vision is going and showing where we want to go. What is the experience we want the user to have?
This is really a fluency play. But if you've got a lot of people who are fluent, you can use it alongside the folks who are still becoming more literate as to talk about where you're trying to get to.
The way to think about this is this is the experience. This isn't the actual screens of what you're going to do. This is the story of what that user's experience is like. What is that journey going to be like?
The way to think of this is it's basically a flag that's in the sand on the horizon. It's too far for us to get to today or tomorrow. Maybe, it's going to take us five years to get there. But because we can clearly see the flag, we know which direction to go in. We know it's not that direction. It's that direction.
We can start taking baby steps to get there. It doesn't matter where anybody is in the organization. If everybody can clearly see the flag, the rule is, march towards the flag. That's the only rule you need.
The really neat thing is it's in the sand which means if market conditions change, if the various elements change, you pick it up and you put it someplace else. As long as everybody can clearly see it, the rule doesn't change. March towards the flag.
You can get to that vision pretty simply. You get to the vision with the journey map. Because what you say is, "OK, we've got these frustrating bits. What happens if we made the whole thing delightful? What would the experience be like if it was delightful all the way across?
If we know exactly what the frustrating bits are, what if we remove them all and everything was a delight?" How would it be a different experience for that person? That's where you start. You put that flag in the sand on the horizon.
We use a question to figure out how well organizations have one of these. It's a simple question. We just go up to everybody, and we say, "Five years from now, what will it be like to use your product, or service? What will it be like? What's the experience of a customer five years from now?"
We pick the five-year date because we are interested in getting past the legacy constraints. If you just said, "Well, a year from now, what will it be like?" It's like, "Well, it won't be a whole lot different because we're never going to get rid of that mainframe. Five years, yeah, we could get rid of that existing technology. We could get rid of those existing business rules. We could make this work." What is that five-year thing?
We don't go out 10 years because 10 years, we're now in jet packs and flying cars. Five years, if you think about what technology was five years ago, it wasn't a whole lot different than now, except we use our phones a lot more. OK, I get that, but five years ago, we were on the iPhone 3. It wasn't that different than it is today. We can sort of extrapolate five years from now. We'll be on 7SC.
[laughter]
Jared: What is that five-year vision look like? Teams can start to think about that, and they can say, "OK, this is what that experience is like. You stick that flag in the sand, and then as you learn more, you move the flag around, but as long as everybody can clearly see it, you've got your shared experience vision."
The last play is a culture of continuous learning. Now, culture is basically something that we keep telling ourselves until we actually do it. It's what we say we're going to do. We keep repeating it until we actually work that way.
The culture is how we perceive we work. It's that idea of what we're doing, and a culture of continuous learning is a way to constantly ensure that we're trying to get better than we are, and this turns out to be a play we use in all the stages, whether it's literacy, fluency, or mastery.
It basically is about understanding who our customers are. Understanding what our organization is. It's the stuff that Mark was talking about earlier in terms of having those conversations and getting to that sort of rich place.
Now, there's a culture out there that people try and do. It's this culture of fail first and the problem with the fail first culture is that nobody is comfortable answering the question why did we fail.
What we've learned is that people are really good at answering the question, what did we learn? If you ask that question frequently enough, you've developed a culture of learning where people are constantly talking about this.
Mark talked earlier about reflection. Taking that time to just stop, and think about what it is that we just did that's part of learning. Having those reflection moments is key. Some of you may know that I'm involved in a school called Center Center. It's a school to create UX designers which we're hoping to open this fall.
We have built reflection into the process. Every day, the students will take that time to reflect on what they've done, but we've even done this in the way we've built the school. We, as a team, have daily stand-ups, and like most organizations are, daily stand-ups have the usual corduroy of questions.
What did we get done since the last stand-up? What are we planning to get done before the next stand-up? What's preventing us from getting this stuff on our list done? What's the most important thing on our list? Because it turns out when you share that, people discover that the thing I thought you were working on is not the thing you think is most important, and I now wonder why that is.
These are common stand-up questions. Most teams use some variation of this, but we added a question. We actually call it our number five, and number five is what's the most important thing you've learned since the last stand-up, and how will it change what you do in the future?
Every day, you have to bring a number five to the meeting. What's fascinating is that this is the most interesting part of the stand-up. Hearing people's number fives is fascinating, and educational, and sometimes, I learn things I didn't know, and sometimes I learn that I'm only slightly ahead of someone else because I just learned that a little while ago, and it's really brilliant.
What's incredible about this is that we've developed a culture of learning where every day, we get to say that we didn't know something until yesterday, and it's going to change the way we work so that we are not embarrassed to admit we didn't know something. We actually are proud to admit it.
The most embarrassing thing is when you can't think of a number five, and I've learned that everybody on the staff keeps a little journal of things that they've learned that they haven't told anybody yet so that when they have a day when they can't think of their number five, they can say, "Oh, there's that. That was like my number five a couple of weeks ago."
This is incredible when you start doing this. You actually develop this culture of learning. It's these three things that Disney did. The team that was building the MagicBand spent tremendous amounts of time in the park. They built in a sound stage behind what was the MGM studios, it's now the Hollywood studios park. They built in a sound stage there, an exact replica of what the entire MagicBand experience would be like.
At first, it was just complete cardboard and phone book gallery, and when you would take your plastic MagicBand that didn't actually do anything, and you held it up to the thing, somebody would go booboop.
[laughter]
Jared: You would go through, and every point of contact for that thing had a markup in that sound studio.
They were able to see what it was like, and they were able to bring people from the park, and experiment, and test things. That immersive exposure was key, but more importantly, they got the executives, all of the executives.
The board of Disney had multiple meetings in that sound studio. They got to see what that was like because after all, they were approving a billion dollar investment. They saw what that future was about.
That studio also represented this shared experience. As that experience changed, they updated the studio. Everybody knew what was happening in that sound stage. They knew what was shifting. That was the place where the decisions were made that said, "That's not good enough. We need to do it better."
That sound stage, they kept all of their old prototypes. They have a history of the evolution of learning. Having that room, that space, that place where you can see how you got there...So many times, we present our final work and we don't tell people the evolution of how we got there. Then, they start making suggestions of things we've already done, and we get pissed at them.
[laughter]
Jared: They're not part of the culture of continual learning. They haven't been brought on that journey.
This is what Disney did. Because Disney did this, when your seven-year-old holds up their band to get into the park, and it's their birthday, that little meter makes a special noise.
The entire Disney cast -- the 10 or 15 people that are standing around that entrance gate -- turn to your seven-year-old and say, "Happy birthday." That's magic. That's what happens when you go past the UX tipping point.
We've got to take teams from unconscious incompetence through to conscious competence or even unconscious competence. We have to think in terms of literacy, fluency, and mastery to get there. Design is no longer about putting pixels on the screen. Design is about, "How do we get everybody around us to understand that evolution?"
By having these frameworks of these stages, we now can understand why organizations struggle. We now know what to do. The plays that we've created, which are really good, they help us. We can put together the playbooks that actually get us to that design-driven organization.
This is really exciting for me because we've put together a workshop -- a day and a half workshop -- that talks about this whole experience. It talks about how an organization gets through those stages.
We take that apart and we tailor plays specific for each person in the workshop to say, "Where's your organization at? Where are the teams at? Where are the individuals at? What are the plays that are going to work?" We look at product strategy and delivery.
We look at the teams we're building and specific plays around, "How do we get the designers in our organization leveled up? How do we get the non-designers leveled up? How do we hire new talent so that they come in at the right stage instead of coming in too immature, and thereby setting us back?"
This is exciting direction for where we're going at UIE, because it is key. What's beautiful is that we can merge what we're doing with Center Centre so the students we're producing at the school are going to come out and be ready to tackle these organizational challenges. The whole thing fits together. This is how I get very excited.
[laughter]
Jared: If for some reason you found any of this the least bit interesting, of course you can find out more stuff about this on uie.com. We're going to be producing a whole bunch of podcasts and articles on the plays, and how they work, and how to put together the playbook. That's coming out in the next few months. Please look for that there.
If you work in design and for some reason we're not connected on LinkedIn, please connect to me on LinkedIn. You can use this email address to do it, if it asks you. LinkedIn turns out to be a great way for me to get in touch. I know many of you I'm connected to. We've had great conversations on LinkedIn. Please come do that.
Finally, you can follow me on the Twitters at @JSpool, where I tweet about design, design strategy, design education, and the amazing customer service patterns of the airline industry.
[laughter]
Jared: Ladies and gentlemen, it is time for drinks.
[applause]
Jared: Thank you very much for encouraging my behavior...