Infusing Design Into Our Organizations

Transcript

Jared Spool: ...I actually want to step back first before I do that, and get to something that actually was part of the inspiration for this entire event, which was a realization we had when working with companies, about the maturity of how design works through organizations.

To start with that, I want to start with probably what was in my mind, one of the most important user experience stories of 2014. It never got much discussion, in the UX world. That was the Disney MagicBand.

The Disney MagicBand was a culmination of a four year project, where Disney invested more than a billion dollars on what essentially is a wearable.

They put in more money in than Apple did on the Apple Watch, so this is a big deal, and it doesn't tell you the time, or it doesn't count your steps, and I don't even think it vibrates when your heart rate gets too high. It doesn't do any of those things.

What it does do is completely change your park experience. For those of you who have never seen the Magic Band, or had one, the way it works is you order it when you book your park reservation, and it actually comes before you get to the park.

This was a realization that Disney had, that the vacation starts before the vacation. It comes in a box that is all decorated with your favorite Disney characters, and when you open it up, all the bands that you've ordered for you and your family are there, and each one is named with a family member.

You take your band, and you try to keep the kids from playing with it to death before you get to the park. When you get to the park, you don't actually have to check into your hotel, the Disney resort that you're staying at, you just go straight to your room, and the band opens the door to the room.

If you took their bus from the airport, your bags are already in the room, which is why they put big warnings over the box, "Do not pack this in your bags," because you can't get into your room. From that moment on, that band controls every interaction you have with the administration of the park.

It's your FastPass to get on rides, and the preferred line, and it's the way that you pay for food, or gifts in the gift shop, and it has three different radio transmitters in it, and it knows where you are in the park, to the point where if your kid has a birthday, your kid's favorite character will seek out your child in the park, based on the GPS that's in the van, and actually wish them a happy birthday.

When you go into the restaurant and you order dinner, the wait staff just knows that it's your kid's birthday, and will bring the cake at the end. The whole experience is orchestrated to be this completely different thing.

That's what a billion dollars will buy you.

[laughter]

But Disney wasn't always this way. Back in 1997 when we were doing our first studies on websites, the Disney site was actually one of the running stories we kept talking about. For years, we were teaching teams how to do website usability testing, and these were teams who had never done usability testing before.

By the way, it's a pet peeve of mine, usability testing, not user testing. We're not testing users, we're testing the design. Please, no more "User testing." The usability testing that we were doing, we would teach these teams how to do usability testing, and they'd never done it before.

We would pick the Disney website, always. This was because when we first studied the Web, one of the first studies we ever did of the Web, it was this simple study, when I think back on it now, it was one of the simplest things we had ever done, but no one had ever done it before.

What we did was we brought in a handful of folks, and we sat them down at websites, and we just asked them to find things. It's what we now call "A scavenger hunt test," where you give people a list of things to find. The whole purpose was to figure out how the Web worked.

We were watching people use sites that they'd never used before. We picked the Disney site because of all the sites, it was the prettiest. It was the one, in 1997, that had the graphics, and the images, and all the elements to it.

We learned so much. For instance, one of the things we learned was in one rendition of the site, for a period, while we were testing it, there was this animated GIF of a woman doing these sort of jumping-jack like motions. I don't know why she was there, or what she was advertising, but she was part of this thing, and she just kept doing this.

This is how we learned that people will scroll, because people would try to scroll her off the page. The page was less than two screens high, so if you brought the scroll bar all the way down, it wouldn't take her off the page, but it would get her close to the top.

I remember watching users just repeatedly trying to slam the scroll bar down, to throw her off the page, so that they didn't have to look at her anymore. That's how we learned that animated things piss people off.

One of the other things we learned was there was a task, and this was a real task that we'd gotten from a participant.

She had a six year old who loved trains, just absolutely loved trains. She wanted to know how to find the cheapest hotel on the monorail at Walt Disney World. She didn't know which hotel that was, and at the time, there were 14 different properties that she could have stayed at, but she couldn't figure out which one would be the cheapest one and on the monorail.

You could find out which was the cheapest, and you could find out which ones were on the monorail, but it was almost impossible to actually complete this task. It turned out to be a fantastic example task for teaching people how to do usability testing.

This would be the demo we would do, we'd bring somebody up from the audience, and we'd give them this task. Inevitably they'd fail at it, because practically nobody could succeed at figuring out that the Polynesian Resort was the cheapest hotel on the monorail.

In the process, we'd teach them how to observe, and how to work with a participant who was getting frustrated, because inevitably everybody got frustrated. It was a great task for us to do this, but there was something else we learned from this task.

I subsequently watched literally hundreds of people do this particular task, and what we learned was that approximately one out of every five participants would accidentally go to the Disneyland site, instead of the Disney World site.

Land-World, World-Land, what's the difference? It turns out it's about 3,000 miles. They would go to Disneyland, and when we first saw this in the lab, we were completely baffled by it. I remember sitting next to the first participant that this happened with.

We would go to the lab, and they would go and give them tasks, and they would search, and they would come to the contemporary resort, which at the time was the only hotel at Disneyland that was on the monorail. I think it was the only hotel at Disneyland, at the time.

They would look down, and they would say, "Well, this is it. This is the one." I would say, "OK, so that's the closest hotel to the monorail at Walt Disney World?" They'd go, "Yep."

"Can you take the monorail from that hotel to Epcot Center?" "I don't know." Click, click, click, click, click, scroll, scroll, click, click. "Yep."

[laughter]

Every time. Every time they would tell us, "Yeah, I could get there from Epcot Center." Just so you know, 3,000 miles, on a little train, no bathroom.

They didn't know. I remember, for a long time I was giving talks at conferences, and I would bring this up. I would mention that if you looked at Disney's analytics, they would tell you that one out of every five people, at least who were doing this task were showing up the Disneyland site, but there was nowhere in the analytics that you could tell that there was a problem.

At one point, I'm giving this talk, and I get off the stage, and some woman comes up to me, and she says, "I work for Walt Disney World." I said, "Oh, really?" She goes, "Yes, and I'm going to tell you something that's off the record." I said, "OK."

She says, "That happens all the time." I said, "Yeah, I know. It happens one out of five times." She says, "No, no, you don't understand. We have people who show up in Orlando with Anaheim reservations."
 

Audience Member: Oh, no.

Jared: Yeah, that's exactly what I said. [laughs] Apparently they actually are so prepared for this problem that they hold rooms in Walt Disney World for people who have Disneyland reservations, so your vacation is not ruined.

You will get a hotel at Walt Disney World. They have those set aside for those people, because they know that. This is a great example of parts of an organization not talking to each other, because the folks behind the website were not realizing that the folks at guest services were overcompensating for a problem that was well understood, without fixing the problem.

The problem went on for almost a decade. We continued to see the problem, over, and over, and over again. This is a big difference from the billion dollars they spent on the MagicBand. A lot happened between 1997, and even 2007, and now.

That's a lot of growth. That's a huge amount of growth. When organizations go through this path of discovering there is this notion of design, and user experience, the path, over time, has made itself fairly obvious to those of us who watch organizations go through this. It starts with a period that we refer to as the dark ages.

The dark ages are when the organization is just not thinking at all about the experience of their customers or users, usually because they are completely over their heads with just getting a product out with the features they need to be competitive, as far as they're concerned, and that's what they focus on, is all that sort of internal machinery of getting those things out.

Then, it works that somebody in the organization has the idea that maybe something could be better and there shows up little spot projects. If you could do an FMRI of the brain of an organization, you could see UX firing in little corners, just for moments, where some team, some manager says, "You know, we could do better here," and they apply some type of design, some type of user experience, and it takes, for a second.

But then they move on, and it doesn't quite continue. Then, over time, as the organization matures, you start to see a real user experience effort, and people start talking about the user experience. Maybe there's a designer or two, or least a UX person of one, or one of these grassroots efforts that takes a little longer.

People start building more user experience in, over and over, at the time. Then, that becomes sort of a centralized group that works on the user experience, those are the user experience people, those are the design people, and they tend to work on this stuff.

The next step for maturity is really interesting. They take that group apart, and they disseminate it out into the teams, and they realize that getting UX closer to the people who make the decisions is key. It's funny, because over the years I've been asked, "Where in the organization should the design group be?"

"Should it be in marketing? Should it be in engineering? Should it be IT? Where should it be?" Years ago we came to the answer, which was, "It should be next to where the decisions get made. It should be right where the decisions are happening."

It turns out that if it's a marketing-driven group, and all the decisions are made by marketing, then by all means, have the UX team be with that marketing group, and if it's engineering, it should be there. In this day and age, where things are now more cross-disciplinary, more multidisciplinary, even that answer doesn't really make sense, because those folks are all getting together.

This sort of embedded idea is that you have these teams where everybody is embedded in them, but then you run into this problem of the teams themselves, the members of the teams who are doing design, feel isolated, because they feel like they're back in that world of being the team of one, and they're there.

You start to have to create this sort of cross-communication, where the folks are combined, but they're also in the teams, which is why I really like what Adam is doing at IBM, where they have the studios where the designers are together, but they're completely embedded in the teams, at the same time, because of the ways that IBM does remote.

That works out really well, but you could have the inverse, too, where the designers are co-located with the teams that are not remote, but then are remote with their design compatriots, in that regard. It turns out that lately, we've been seeing a different sort of model, beyond embedded teams.

That's what we've started to call design infused culture that it's not just the designers, it's not just the UX people who are trained, and proficient, who are talking about design and user experience, that in fact, it's everybody talking about design and user experience.

The CEO is standing up in the town hall meetings talking about how, "Now we are a design-driven organization," and that they are actually doing all the things that they need to do to be a design-driven organization, and to put those things into place, and to make sure those elements are there.

We've seen that this is starting to happen, and we've talked to a bunch of folks that are different stages of this, over the last two days. That idea of being design-driven, and design infused, where everybody is part of this, is an interesting new way of doing it.

It's that last one that I want to take apart for a second, and talk about, because it is here where we see something that we call the UX tipping point. The UX tipping point has to do with how designs become real in the world, how they get shipped.

Before you get to a design infused culture, design always plays this secondary role. It plays this thing that you do, in addition to all the things you've always done. You're going to put out the product, it's going to have features, but now we're also going to make it well-designed.

It's that secondary thing, but when you get to design-infused culture, design is now at the forefront, it's driving the strategy, it's driving the products, it's driving what you're ending up doing, and it is the thing that makes it happen.

The tipping point happens somewhere in that process, because what you start to see is, every so often, a project will do the unthinkable. It will delay a shipment, not because the product is technically broken, not because the business goals have not been reached...

It's technically working, the business goals have been reached, but it's not being shipped, because the design isn't right.

If you look at any new Apple product, the ads of any new Apple product, when they release it, the clock on the product, whether it was the original iPod when it came out, the iPhone, the iPad, the Apple Watch, the clock is always set to 9:41 AM.

I don't know if you ever noticed that, but if you look, go back and look at the first ads for the iPod, set to 9:41 AM. The reason it's set to 9:41 AM has to do with the original announcement of the iPod. The original announcement of the iPod was during a keynote at Macworld.

The keynote started at 9: 00, they went through all sorts of stuff, and then Steve Jobs did his, "But there's one more thing," and that was at 9:41. The story goes a little deeper than this. It turns out that before Apple announces any new products, before that keynote starts, at 9:00 West Coast Time, they take their website down.

Apple.com just comes off the grid. They replace it with a static HTML page that just says, "We'll be back soon." This is just crazy in its own right. Here you have this streaming resource that's going down to the world, and they take down the website that everyone is probably going to find out more about the products as it's being talked about.

But they do that, and while it's down, that website, which had no previous mention of the products that are being announced, gets completely re-launched. At 9:41, it comes back online with the new products.

The way they do that, I found this out the hard way, the way I found this out was we had invited one of the people who was in charge of designing apple.com to a conference. We were all set to have them there then they called us and said, "I can't come."

The reason they couldn't come was that four weeks after our thing was a keynote that had just been announced and basically everybody who works on the website is locked down for the 10 weeks or 12 weeks before the new launch because they're just not allowed to do anything but get that website ready. They worked on that website.

It turns out that they don't find out what those new products are until that moment. All this stuff has been in development, but they read the rumors you and I read. Then they learned what's going to go on the website. They don't let them out partially because there are so much work to do and partially because they don't want anyone telling anybody.

The whole thing is locked down. They worked on that website that they can make that flip-the-switch change in front of all those people in that 41 minutes right then and there.

That flip-the-switch change is amazing because there are products that have been ready to launch the website for those pages for those products were all set. The order pages for those products were all set. Everything was there. Then someone high up, someone wearing a turtleneck decides that the product is not ready to ship.

It has happened Monday evening before the Tuesday keynote at 10 o'clock at night Pacific Time. They have between 10:00 PM and 9:00 AM that morning to pull any evidence that that product existed because people are going to read the source code of the website to figure out if there are references to things.

They pull any existence that that product ever existed off of the design of the site that they had readied and tested to launch. They have to retest everything in order to make that flip-the-switch launch where millions of people are going to show up in those next few minutes.

It's not because the product wasn't technically working or wasn't business-wise because it wasn't designed right. That's the commitment that they have to this UX tipping point. The UX tipping point is actually the moment when that happens for more than half the products or services that the product delivers.

That suddenly this organization is so focused on design that they will not ship most of their products. Occasionally things go out. That explains iTunes. Most things will not go out until they are ready, until the design is right.

There are not very many organizations that have reached this tipping point. Probably just a handful of them. This is the way you tell. This is the Holy Grail. This is place we are trying to get to, to tell us that we have reached what we're trying to do.

Now, technology itself goes through an evolutionary pattern. It starts with just being something that goes out that we just are happy that it works.

The first mobile phone was this massive Motorola device and that you could just make a call on it was all that mattered, that it cost 2,400 bucks and weighed four pounds and barely you could hear the connection on the other side, was not nearly as critical as the fact that I just made a call.

People who needed that thing would pay for that thing. It's a small audience. That's how that market starts. Every new technology starts with something like that first version of something. Then a competitor comes out with something and it becomes the war of the features where people go back and forth and they are like, "We have these features. We have those features."

You see this now with the health wearable wristband stuff as well. Do I get an app? Do I get a Fitbit? It's just really a list of features that are competing on that.

Then there's an evolutionary change where there are so many features people don't care about them anymore. We see the shift go to experience. That's like, "Well, which one delivers a better experience?" You saw this with the iPhone when it came out. It had actually less features than many of the flip phones and other types of phones that were on the market, but it had a much better experience.

I've been talking about that stage of moving from technology to features to experience as a way to describe this evolution.

One of the interesting things is that companies that were the top dogs when we were in the feature section, they were the ones with all the market share like Motorola quickly lose their market share because they're not prepared to have a conversation about experience. They have to struggle with that conversation about experience.

We can map that into the maturity that we see of moving through those different stages of having a design team that works on the design versus having embedded teams. It's in those shifts that we see people start to focus on experience. We see the investment that gets made to be there.

There are lots of business factors that cause this, but there's a fourth stage that I rarely talk about because you don't see much evidence in it. The fourth stage is a stage of commodity.

The first GPS systems that came out, the Garmins and the other systems that you would buy and hang on with those suction cups to your car and things like that, those delivered a great experience. Those had or some of them did, some of them were horrible, but over time the absolute points were experience was there.

After a while, those all went away. We didn't need to have explicit GPS devices because those GPS devices got sucked into other things. The phones have them now. The cars have them now. The wristbands have them now.

That commodity stage is when we take the experience bigger and we're not thinking about the specifics of the product, the specifics of the element and we're moving it further. The other piece of this is that in order to have this idea in your organization that you're not going to ship something until the design is right means you have to define what the right design is.

Not only do you have to define it, you have to get everybody in the chain to agree to it because all it takes is somebody in a tie or a turtleneck to say, "Well, that doesn't matter. We have to get this thing out," to overrule the decision.

There has to be this buy-in in order to get to this point where you're delaying ship because the product is not right. You have to have a clear shared understanding of what that means.

It's that phrase "Shared understanding" that came up several times over the last two days of "What are we trying to do? Who are we trying to build this for? Why are we trying to build this?" That turns out to be the key piece to answering the question, how do we know when what we're doing is good enough?

We know it can't perfect. That will never happen. We have to have a common definition of the term "Good enough". That turns out to be problematic.

To do that, we have to take all of that understanding we have of our users, of what they're trying to do, of what makes the products work or not work. We have to negotiate within the organization how that fits into the roadmap that we're going to create. How that fits into the plan of what we're going to build out. That turns out to be really tricky.

It's even trickier because we're constantly in an environment where everybody thinks they're a designer. Everybody has an opinion about design. Everybody has a thought about this.

I get to work with a lot of folks who are new to the design world and they get very frustrated that everybody thinks they're a designer. I know about design. I learned about design. I was trained in design. These people, they know nothing about design yet they're telling me how to make the logo bigger.

The reason everybody thinks that they're a designer is because in fact everybody is a designer. We are always designing things. In fact, one of the faults that we have in our school systems is we don't actually teach enough design early enough.

You think about in life, when you move into a new house, you're going to put the dishes away in the cabinets. How do you design the right way to do that? It's going to be really hard to take all the dishes out and rearrange them later. You'll probably have to do that when you redesign the kitchen. It would be nice if you had gotten that right the first time.

We're probably going to make a form for signing for Sunday school or the PTA or something like that and that's a design problem. In fact, people are doing design problems all day long. They're always designing.

When we get into companies, everything really is a design problem to some extent. That's the mantra behind this idea of design thinking. It's why design thinking is now on the cover of this month's "Harvard Business Review" that it's everybody needs to be going through those steps of exploring and understanding and sharing this stuff out there.

There is nothing magical about design thinking. Design thinking is just design. Design is going out and understanding what good enough is and how we present that. It's very much that we have to help the people we work with, bring out their inner designer. We have to help them understand and we have tools to do this.

A few years back, we did a project where we took a bunch of companies that were fantastic. About 20 different organizations that were fantastic at delivering great user experiences and great products to their customers.

We went and found direct competitors who were selling products and services into the same markets as those companies that were successful and we compared them. For example, we looked at Apple and we compared them to Dell on the hardware side and Microsoft on the software side.

At the time, Netflix was doing fantastic that we compared them to Blockbuster. We looked at non-tech companies like Virgin America and compared it to United. We looked at Cirque du Soleil and compared them to Ringling Brothers.

We were able to pair up these companies and look at what was there. Then we actually had the opportunity to go in and speak with the folks who were making design happen in organizations and making these things successful or trying to make design happen in the struggling companies and working really hard to make them successful.

When we compared them up, we found that there were basically three things that the companies that were successful at shared amongst each other that were rare in the companies that were struggling. The first one was exposure to users.

We heard today that user research is the catnip for executives. It turns out it's the catnip for everybody that in fact having constant exposure to users, constantly being able to understand what is happening with the product, what is happening with the service, and seeing it all the way through how people used it was absolutely key.

Those of us who spent time indoctrinating teams with things like field research or usability testing, you often hear the comment, "Wow. Why didn't we do this two years ago?" That's one of the first things you always hear.

It turns out that it's because it is such a powerful experience. Like you are hiding this information from us. The users aren't telling it. We try to supplement this with surveys and customer satisfaction forums, but those things miss the mark so badly because they don't tell us why these things are happening. They don't give us the sense of it and they homogenize all the data in this horrible, horrible way.

The idea that you get out and you meet people. We started to figure out, "Well, what's the right amount of time meeting people?" We realized that there's actually a number. It's a very simple number. It is two hours every six weeks. Everybody who has any influence over the product or service needs to spend two hours every six weeks.

One of the organizations that's been incredibly successful is the Government Digital Service for the United Kingdom. We've talked a lot about the US Digital Service. The US Digital Service thinks of the United Kingdom's Digital Service which is about four years older as the prototype for them.

The Government Digital Service under the work of Leisa Reichelt went and made it a policy that everybody in the organization had to spend two hours every six weeks if they wanted to have any say in what these products or services should be, just watching a user use the products.

It turns out it doesn't actually matter what you watch. You can watch one person for two hours. You can watch four people for half an hour each. It can be 15 minutes every week or it can be two hours at once then nothing. It's that frequent repeated exposure that makes a huge difference.

What Leisa noticed was that the meetings which used to start with, "Well, I think we should do this. I think should do that," started to be more of, "Well, we saw someone last week who I don't could do that." People would tell the stories about Mary, or James, or one of the participants that they saw.

The other thing that Leisa was very successful at was that she was very good at not just getting the developers and the designers, but product managers and product owners and the heads of the agencies and the ministries and all of the folks.

She basically said, "Look, if you want a say in how this product is designed, you have to have spent this time actually researching folks and actually going out and talking to them and seeing them." It was hard to get that on the executive schedule.

Once they managed to do it, that catnip thing kicked in. It wasn't that hard to get it a second time or a third time, and making the rule that says, "If you want to have a say, you have to have participated in the research," turns out to be something that got supported from the highest levels down.

The second factor that we found that was common amongst the excellent organizations and missing in many of the struggling organizations was having a vision of the experience. Now, a lot of organizations have a mission statement, "We want to produce the best market-driven product for our growth consumer business."

World class is a requirement for anything. It has to be world class. Best of breed is the other one. There's an Etsy store that just sells mission statement phrases that you can get.

A vision of the experience is different. A vision of the experience is being able to walk up to a member of the team and say, "What will the thing you're working on be like for a person who will use it five years from now? What will that be like five years from now?"

The immediate reaction I get is "The technology will change," but we're not talking about what the actual design will be. We're saying what is the experience like five years from now?

This is in fact how Disney got billion dollars of money out of the executive board of Disney to build this park system is they created a series of prototypes. A lot of it was foam core and just artwork. They worked with frog design and they built out in the back lot of Disney World, in the movie studio back lot.

They took over a sound stage and they built a working prototype of the band. The whole thing was smoke and mirrors. You would go in and you'd put the band up to something and someone behind will go, "Poop-poop," and it would let you in and the whole thing was just this fake thing, but they could share the experience.

The thing was is that when you went through it and you saw how the whole thing worked, you could talk about it. You could explain that experience. Anybody who worked on the team and anybody who was approving the team had the same description of this.

This turns out to be key. I often do these exercises where I'll go into an organization that say, "Yeah, we have a vision of what our product is." I say, "OK. Let's do a little exercise." I have them take out an 8.5 by 11.0 sheet of paper, put a landscape, draw a line down the middle.

I say, "OK. On the left hand side, we're going to do a little controlled experiment. I just want you to write down the story of Hansel and Gretel in bullet form." "OK. I can do that." "Give you two minutes, just write down all the major milestones that happened in Hansel and Gretel."

"Now, on the right hand side, I want you to write the story of what a user will go through with your product five years from now." People look at me like you're looking at me right about now, like, "What? Whoa, whoa, whoa, whoa, whoa." "No, no, just simple. Just bullet form, just write down the major things will make your experience your experience five years from now."

A couple of people put their heads down and start writing. Most people will just keep staring at me like I was speaking to them in German. The folks who write down what they wrote, it doesn't match what anybody else wrote down in the room, but everybody's story of Hansel and Gretel will match. Everybody else's story of Hansel and Gretel.

Here's the freaky thing about this experiment. None of the have ever talked about Hansel and Gretel at work before. It never comes up. Yet, they all had a matching version of that story. Theoretically, they've been talking about their product and service every day and nobody knows what the future of it is.

That vision of the experience and the ability for everybody to write down the same words on the page in order to make sure that everybody's marching towards the same vision is something that we never talk about but is critically important to our success. That's part of that shared understanding.

If we want to know whether the product is good enough to ship, we have to know what the current experience is. That's what happens when we visit our users. We have to know what our vision for the experience is and what our current cutoff is towards that vision. What baby steps are we going to be taking to get to that vision? Those are the key pieces of that.

Then there's a third piece of this. The third piece of this is a culture of continual learning. We've talked about culture a bunch today. Mark talked about it a great deal. Other people talked about it. I love the definition that we heard earlier from Steven which was that culture is the stories that we tell ourselves until we believe them about what we do and how we work.

Mark defined it as being the myth that underlies what we're doing that's so strong that we believe the myth. It's a common shared thing. That's what our culture is.

What's interesting here is a lot of organizations do not have culture of continual learning. Continual learning is the simple idea of understanding what did I learn that I didn't know before? It's reflection. It's a basic piece of what we're doing here.

What makes the reflection interesting is that it happens in small pieces, not big. Many of you know that I'm starting a school with Leslie Jensen-Inman who is sitting at the back of the room and we're starting a school for UX designer in Chattanooga, Tennessee. The team that we put together for Center Centre, we started doing daily stand-ups.

It's the common thing. The whole team gets together. For half an hour, we talk about the standard things that you talk about at standup. What did all do yesterday? What are we planning to get done today? What's in our way? What's the most important thing on our plate?

We added what we call the fifth question to this standup equation. We added this fifth thing which is what is something that you learned in the last 24 hours or since the last standup. Actually, what did you learn since the last standup that's important to you and how will you use it going forward?

It turns out this changes the tone of stand-ups completely. It changes the way they work in an amazing way. That suddenly, first, it's by far the most interesting part of the standup. We all know what people worked on yesterday and we all know they didn't get everything done. We all know that they've pushed a lot of it on to today and we all know that they probably won't get that done.

We know that there are obstacles and we can work through those and we'll take that offline and we'll deal with it. We know what everybody's priority is, at least we think we do and that's good too, but what did you learn yesterday? How are you going to use that going forward?

The conversations that come out of that ware often big and small. Sometimes, it's like, "I learned a shortcut in keynote that I didn't know before and I will use that in every presentation I do." Sometimes, it's, "I learned that I have this awful habit of interrupting people and I'm just feeling like I need to work on that because it just really came out to me that that's important."

Or, it's, "I learned the way that we are building this product is just not going to work and we have to sit back and rethink that structure." Everybody participates in that moment of learning and that reflection that happens. Just by doing that on a daily basis, you create a culture that makes learning happen all the time. It's not about failure. It's about success. It's about what did we learn.

At the US Digital Service, they have a motto which is, "Only make new mistakes." The idea is mistakes are going to happen. It's going to happen big, but we shouldn't make the same mistake twice. How are we going to learn? How are going to get things better?

When you think about it, there are some underlying themes that came out over the last two days that fit into this really well. For instance, one of the themes that came out was the theme of storytelling. That part of our job as the leaders of design is that we have to be the emcees of a massive storytelling effort.

It's the storytelling of what we're trying to do, how do we know it's there? If you think about it, what we learn from the users we have to relate to the people who didn't see those users. We have to tell the stories. There's nothing more potent than telling the story of a frustrated user alongside, as Chris pointed out, the importance of telling the stories of happy successful users.

Being able to tell the story of the current experience is key. The telling the story of that vision, what it will be like when we get this thing done, that's key too. Then the telling the stories of what we're learning every step of the way.

We have to foster this notion of storytelling that we're always communicating stories and more importantly we're getting other people to community the stories. We heard Bill Scott yesterday say that one of things he's had great success with as he boils these little mantras down to Twitter size statements. He keeps repeating them in front of the executives until the executives start repeating them themselves.

That's brilliant. That's storytelling. That's key.

The reason that all of us could do the Hansel and Gretel story, if I did that experiment right now, is not because we have prepped for this moment. It's because we heard the story over and over and over again as children.

We have to repeat our story. That's part of storytelling is repeating the stories and putting them in the current context.

Another theme that came out was this thing that a friend who's a brilliant product manager coach, Bruce McCarthy, says which is we have to focus on themes over features. It is so tempting when we hear a problem to immediately come up with a solution. What we really want to do is come up with the theme of what the problem is.

There's an old saying which is, "The best designers don't fall in love with their solutions. They fall in love with the problem." They really get to know the problem. Bruce says that in your product management roadmap, you shouldn't ever list features you will ship.

You should list the problems you will solve because down the road, you may come up with a way better solution to the problem than the feature you can come up with today.

By making the roadmaps be theme-based, themes of problems that the users are having and how we're going to address them, then telling the stories of those themes, that's what a product manager does. That's what a great product manager does. That's not a whole lot different than what anybody else in the design process should be doing.

We get to this idea that I've been saying for a long time which is that great design is actually invisible. Bad design shows itself all the time. It's like the air conditioning in the room. You don't notice the air conditioning in the room if it's set perfectly. You only notice the air conditioning in the room when it's too cold or when it's too hot or when it's dripping on you.

I know you know this, but I'm going to guess that the collective here, if I were to measure the collective of all of us here, if we were to look at all the hours we each individually have spent in meetings in our lifetime and added them up, we'd probably be way over 5 or 10 million hours of meetings. I know that's very sad, but it's probably close to true.

I'm going to guess in all of those 10 million hours of meetings, there's never been one meeting for any of us where someone raised their hand and said, "Excuse me. Excuse me, I just want to say whoever set the air conditioning in the room, you did an amazing job.

I brought a sweater, I haven't needed it. I usually do, but you did a fantastic job. So, I just wanted to say that. I didn't mean to interrupt the meeting. We can get back to talking about the layoffs."

Really good solid design is invisible. What costs a billion dollars for the MagicBand was not the band. It was everything they had to do to the parks to make those three radio transmitters work at every moment.

They had to build a radio receiver into every hotel room door. They had to build tracker and elements all over the park. As your family goes through the on this experience throughout the multiple days that it's there, the park is constantly taking pictures of you for which when you get home, you receive an email with a link that brings you to a photo album of your vacation.

It's pretty awesome. A little creepy. Pretty awesome. Uber taught us that pretty awesome and a little creepy are side by side partners.

This idea that design is something everybody should see is in fact the inverse. We will do our job well when the experiences are so awesome that nobody notices the design that went into them. For many of us, that's a sad notion because we have worked so hard to get noticed.

I don't know if you're an amazing designer, how you put together a portfolio and visible things. Maybe you put together a portfolio of all the things you didn't build like, "I didn't make that. You would've noticed that. I didn't make that either. You would've noticed that."

I want to touch on something that's been gnawing at me. I got my head around it over the last few days. That's this word that we keep using which empathy. I've been hearing this [inaudible 52:15] . I go to a lot of conferences now where people talk about we need to teach empathy. The people who we're working with, they don't have enough empathy.

Everybody has empathy. Sociopaths not so much, but most of us don't work with sociopaths on a regular basis. There's that one person, but everybody else isn't a sociopath. The thing is you cannot teach sociopaths empathy. They are neurologically incapable of having empathy. That's a waste of cause.

Everybody else already has empathy. The problem isn't that people don't have empathy in our organizations. The problem is we designed a structure to our organization that prevent their empathy from happening. It prevents the empathy from happening, because we're not giving them any exposure to users. We're not giving them any way to iterate over the designs, and see the causal effects of what they build.

We don't build the structure of empathy. This is not a problem with people not having it, we don't let them take it out of its little satchel. We tell them that they have to be objective, and distant, from everything that actually will drive great emotional response to design.

If we really want our coworkers to bring empathy to the table, we have to design our process for that. That's what this idea of alignment is about, that Karen talked about. It is not just getting them to agree with us, it's building the substructure that allows everybody to come to that same "Aha" moment.

They tell you in negotiation school that the best way to get your way, if you want someone to do something, is to let them think of it as if they'd thought that this was a good idea, on their own. That's a fancy way of getting to alignment.

Alignment is everybody in the room having the same "Whoa. What if we did that?" moment. You get there with the tools that we have, but then to put those tools into perspective, you have to make sure that you are getting them out.

Our job, as the leaders in design, the ones who are trying to make our organizations competitive, our job is not to convince people that UX is important, but to bring out the current experience, to bring out our vision, to put in that culture of learning, to remove all those obstacles, all those elements, so that we can get there.

If we want the lawyers, and the procurement people, and the executives, and all the other stakeholders to come to that same moment, saying, "This is what we're all trying to do," we have to bring those stories out. We have to bring that forward, and make that culture, the story we tell ourselves, about telling the stories of design.

We have to in essence, design how we're going to make UX be a competitive advantage. That's what I hope you've gotten out of the last two days. Thank you very much for encouraging our behavior.

[applause]