UX Advantage: Infusing Design Into Our Organizations

Jared Spool - Using his entertaining storytelling style, Jared weaves together the threads of what was heard throughout the conference. We’ll look at how to rethink the way we structure our teams, how they collaborate, and the implicit and explicit rewards that drive their achievements. Organizations need to approach every problem and decision from a design viewpoint. Jared connects the UX Advantage themes together to form a framework for how we tackle the amazing challenges ahead of us.

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.


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."
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.


A UXA Podcast with Karen McGrane: Shifting to Continuous Deployment

The speed of Agile delivery fundamentally changes the work process and puts new demands on the design cycle. What happens when the notion of deadline dates is replaced with a continual stream of experience enhancements by everyone in the organization?

In this podcast, Karen tackles the UX Advantage topic, Shifting to Continuous Deployment.

Full Transcript.

Sean Quinn: Hey now, everybody, I’m Sean Quinn. Today is another very special UX Advantage podcast. You see, for the past several UX Advantage podcasts, I’ve been joined by Jared Spool, which was pretty sweet. Today is even better, because we are all really lucky to be joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared has been working really hard on putting together a unique conference that focuses on UX strategy issues no one else is talking about.

How are you doing today, Karen?

Karen McGrane: I’m doing fantastic. Thanks for having me.

Sean: It’s great to have you here. The speed of Agile delivery fundamentally changes the work process, and it puts new demands on the design cycle. What happens when the notion of a deadline date is replaced with a continual stream of experience enhancements by everyone in the organization? It must put some strain on the top, all the way down to the bottom. What do you have to say about that?

Karen: It’s just such a fundamental shift in the way that we work. As far as I can tell, it’s moving our design and development practices into a truly digital space. When you think about all of the historical models from other industries that we have been basing software development on, whether that’s…I do a lot of work with the publishing industry.

The idea of, you’re going to print a magazine every month so you’ve got to have this big push up into the printer, where the magazine gets sent to the printer and then you can’t make any more changes to it, or architecture, obviously. It’s like you either have a building or you don’t have a building. It’s not like you can be continuously adding to the building.

Even thinking about software development, the idea that up until, just a handful of years ago, all software development was essentially products that were bought in boxes on the shelf. You have the marketing plan behind them and TV commercials and what not.

Now, the idea that we would be creating websites that where apps or digital products that are only ever going to be delivered through the web or through the Internet, it just doesn’t make sense. Why should we be following that sort of offline, box-centric model, when we could be continually updating and iterating on these products?

That’s just a fundamental shifts in the way that we think about our workflow, the way that we think about our processes, how do you make decisions, who do you have working on the team, who has the power to make changes. I think it’s quite transformational for organizations to start thinking that way. I also think it’s probably a pretty hard shift.

I do a lot of work with the publishing industry, and so moving an organization away from “we publish a magazine every month” to “we are constantly writing stories and publishing them on our website.”

You might think you can just get them to start being like, “We’ll publish things all the time,” but it doesn’t work that way. It changes the whole culture. It changes the whole value system of the organization to be working that way.

Sean: I imagine it also changes the perception outward, inward of your consumer base, what’s the value of this thing if I don’t have to wait 30 days for this?

Karen: It changes the economic structure. It changes the revenue model. It changes the level of quality in some cases. How do you decide whether something is good enough?

All of that, I think we talk about those decisions as if they are purely technical decisions. How are we going to decide if we’re ready to ship something? How are we going to evaluate success? It really gets to some really deep-seated cultural issues, some really deep-seated values around how the organization describes what it does, what the right way to do things is. Those things are harder to change, I think.

I think even organizations that say they want to work in a more agile method or say that they would like move toward continuous deployment, it’s going to take them a while to get there. It’s not that technically they couldn’t get there, it’s that culturally they can’t get there.

Sean: Whenever you couple fundamental shift or fundamental transformation followed by the word organization, if an organization could cringe, I believe that those terms, “fundamental shift”, would make that happen.

As organizations become more calcified with the systems and the habits that they have, how do you go about getting everyone in the organization on board to not only embrace the concept, which just seemed really hard enough, but to then put the concept into action for execution?

Karen: I think we’re going to have some great speakers at UX Advantage. We’re going to be able to talk about how they did that at their organization. Bill Scott from PayPal, I know, has some fantastic stories of how he has moved PayPal to a Lean UX-focused organization.

I think that all of our speakers are going to be able to describe much better than I probably could what it actually takes to get your engineering team, to get your design team, and to get your executives on board with what it means to do this and to do it right.

Sean: We’ve talked about in our other conversation how these topics are intertwined with one another. I’m thinking as I’m hearing you talk about the incentives and rewards, there must also need to be a fundamental shift in how those are conceived of and then distributed when you’re changing the rate with which things are deployed. Is that an accurate statement?

Karen: Yeah. One of the things I’m most fascinated by is, how does an organization tangibly reward people for performance? I genuinely believe that you can look at how particular executives in the organization get their bonus and diagnose what that organization really values.

They may pay lip service to caring about design or caring about the user experience, but where they put their money is what really motivates them. I think Jared is fond of talking about this, that many, many organizations are motivated by ship dates.

There’s the sense of, we’ve got a product and we think it’s got to launch by a particular date, and somebody’s going to either get a bonus or get fired, based on whether that product actually meets that date. I know I have definitely worked with organizations that have said, “This thing has to launch by such and such a date, and we will give you more money if you hit that date.”

That sets off some really perverse incentives. That sets up some incentives to launch something, even if it sucks. Even if it doesn’t meet the needs of the business, if it doesn’t meet the needs of the users, but my god, you have that hard deadline and you needed to have something to show for it.

I think that when you poke at that problem, you realize that, there is a deeper ecosystem of goals and motivations that also needs to be changed in order to make something like this happen. You may need to ensure not just that the continuous deployment or that you’re moving to an agile method, you might need to ensure that HR is on board with writing, job descriptions, or writing bonus plans that don’t use ship date as one of the motivations.

You might need to change the way that your contracts are written. You may need to get your legal team on board with working in a different way. We’re going to have representatives from the US Government, Digital Service, the White House, and from Fidelity, talking about how you change the legal and procurement processes to make things like that happen.

I’m really fascinated by how changes like this happen in large organizations, because you realize it isn’t just the engineering team, for example, saying, “Hey, you know what will be great? Is if we stop focusing on ship dates and instead move to a continuous deployment model.”

The rest of the organization has to be on board with that as well. You’ve got “little ducks”, you need to get in row there before that can happen.

Sean: Let me ask you this then. Is it possible to apply what we’ve been talking about to the actual process of getting everyone in the organization on board? Could we be continuously deploying as we move towards getting everyone on board?

I’m not sure if it makes sense, but that popped into my head when I was listening to you. Can you move before you have everyone on board?

Karen: I think many of the guests who we’re going to be talking with will be able to speak to the small changes that they’ve made. Yeah. I think there’s no way that anybody would ever get anything done if they believed that they had to make one massive shift in the organization overnight.

I think that one of our guests said something. You got to eat one bite at a time. How do you figure out what the small incremental improvements are that you can make in your process so that over time, you get to the place you want to be?

Big changes are scary. They’re risky. They’re something that people really don’t want to take on. Can you do a pilot project? Can you start hiring for some new roles that might start working in this way? Can you change the way that you structure your contracts or change the way that you structure your weekly meetings so that you’re moving in that direction?

I would never encourage anyone to think, “We’re a failure if we can’t do all this all at once.” Instead saying, “Where are we at right now? What are the baby steps we can take in the right direction?”

Sean: That’s great. Where we are right now is at the end of this podcast, so I wanted to thank you for your time today, Karen.

Karen: Thank you so much. It’s always a pleasure to talk to you.

Sean: Watch for other podcasts that’ll be covering more of the conference topics. Be sure to check out our conference speakers and all the topics at uxadvantage.com. You definitely don’t want to miss this event. It’s coming up fast. It’s in Baltimore on August 18th and 19th. You can register at uxadvantage.com.

Bye for now.

A UXA Podcast with Karen McGrane: Why Marc Rettig?

There are always burning questions about how to get organizations to be more design-centric and what better way to learn than from someone who has done it. Marc Rettig has been helping organizations make the transition for 30 years. In this podcast, Karen McGrane shares why he was chosen as one of the keynote speakers for UX Advantage.

Full Transcript.

Sean Quinn: Hey now everybody. I’m Sean Quinn, here with another “UX Advantage” podcast. Today, I’m joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared Spool, have been working really hard on putting together a unique conference that focuses on the UX strategy issues no one else is talking about.

How are you doing today, Karen?

Karen McGrane: I am doing fantastic. I hope you’re doing well too.

Sean: I’m doing exceptionally well. That’s my default setting. I think it’s why people like to be around me.

Will you take a few minutes and share with our listeners how Marc Rettig was chosen to give one of the UX Advantage keynotes, and what makes him uniquely qualified to do so?

Karen: I am so excited that Marc Rettig is going to be joining us. I personally find him to be genuinely inspirational.

Marc, a while back, wrote a little talk called “Interaction Design History in a Teeny Little Nutshell” that was so interesting, and exciting to me, that it genuinely sparked years of research. I wound up teaching a course at the MFA in Interaction Design program at SVA, a short course on the history of interaction design, basically as a result of seeing Marc’s research.

I think that if I was that inspired just by one little talk that Marc put together, think how inspiring it will be to have him share what is literally his 30 years of insight, research, and case studies on how you move organizations to be more design-centered.

I just don’t think there’s anybody better out there to speak to a range of different companies, a range of different types of problems, and what he has learned in working with all of these companies over the years to make this sort of change happen.

Sean: Then what do you think would be the most valuable things people will take away from Marc’s UX Advantage keynote?

Karen: He’s going to speak to what it actually takes for organizations to become more design-centered. I would imagine that pretty much everybody who’s going to be in the audience is attending UX Advantage because that’s one of their primary goals or concerns.

To hear Marc talk, not just about some of the case studies and examples in his past work, but he’ll also present a framework for what organizations do, or what kind of transitions that they need to go through.

I would imagine that Marc’s talk will be both inspirational and practical, that it will give people in the audience a sense that there’s some genuine hope, that there’s something that they’re moving toward, and that there’s some things that they can start doing in their organizations today to make that happen.

Sean: Do you think that this talk, this addition of Marc to the line-up was a key to making this a more valuable experience for attendees?

Karen: When Jared and I were thinking about who would be the right keynotes for this talk, Marc was one of the very first names that came to mind. There are so few people in this industry that have 30 years of experience with guiding organizations on how to be more design and user-centered.

Marc is, I think, one of the people who has the most solid understanding and experience in this space. I’m really excited he’s going to join us.

Sean: In listening to you talk about this, having never heard or seen Marc speak, I know I’m looking forward to it. [laughs] I’m counting down the days to UX Advantage in Baltimore on August 18th and 19th.

It was short, but informative, and I thank you for your time.

Karen: Thank you again.

Sean: Be sure to check out the conference speakers and all of the topics at uxadvantage.com. You don’t want to miss this event. We hope to see you in Baltimore August 18th and 19th. Check it out and register at uxadvantage.com. Bye for now.

A UXA Podcast with Karen McGrane: Taking Advantage of Fear

The belief of public failure or marketplace irrelevance can drive an organization to change. How does a UX leader exploit this corporate fear? What transforms the momentum from fear into positive change within the organization?

In this podcast, Karen tackles the UX Advantage topic, Taking Advantage of Fear.

Full Transcript.

Sean Quinn: Hey now, I’m Sean Quinn. Today is a pretty special UXA podcast. Why? That’s a great question. For the past several UX Advantage Podcasts, I’ve been joined by Jared Spool, which was great.

But today I’m super lucky to be joined by the co-executive producer of the UX Advantage Conference, Karen McGrane, who along with Jared has been working really hard on putting together a different type of conference focusing on UX strategy issues no one else is talking about. How are you today, Karen?

Karen McGrane: I’m doing great, very happy to be here.

Sean: That’s good to hear. In this podcast, we’ll dive into the UX advantage topic of taking advantage of fear. Public failure can put the fear in you. The healthcare.gov disaster is a good example of a public failure. My first question for you, Karen, is how can you use this fear and turn it into positive change within an organization?

Karen: I think the healthcare.gov example is instructive, that up until they had a huge, spectacular public failure, the US government was able to treat web services technology, services, digital services, what this hands-off business is usual approach. “This is the way we’ve always done it. It must always work.”

It wasn’t until they had the media and the public attention pointing a finger at the problems with that website and those processes that they were really inspired to change.

I think in our conversations that Jared and I have had with some of the guests who will be at UX Advantage, fear is something that’s come up. I think it’s one of the hardest things for people to talk about.

There’s the sense that people want to say, “Oh, no. We really are inspired and we’re excited, and we’re not motivated by fear at all,” but I think honestly, most organizations really are motivated by fear to some extent.

The fear of a big, spectacular public failure, or perhaps having a big, spectacular public failure is what drives companies to day, “Hey, we got to work differently.” I think companies that can recognize that and take advantage of it can harness that for good.

Sean: This seems to parallel, then, with the idea of getting the executive buy-in from the top down and not just paying lip service to that, because I imagine this fear transcends the organizational chart.

Karen: I think that many organizations probably find that it’s difficult to get genuine C-suite attention for some of the digital initiatives that a lot of times the web and other mobile and other initiatives like that are treated as if they’re more of a tactical implementation detail.

That they’re something that once executives have said, “We need to have that,” it’s expected to just run and be managed and not actually influence or drive other aspects of the business.

I think what we’ve heard from so many of the guests who will be with us at UX Advantage is that that mindset, that approach just really doesn’t work, that you need the genuine involvement and support of C-level executives to ensure that digital initiatives which touch a variety of different groups across the organization, so marketing and IT and customer service and sales, all over those groups have to work together.

You might need something that shines a big, bright light on the fact that those groups don’t have a really effective way of working together and that that is painfully obvious when you look at the website. That might be what sparks someone’s attention to say, “Hey, we got to fix this.”

Sean: I’ve been thinking a lot about this particular topic. It’s one that I think a lot of people can get something from. Do you think that the different industries have to deal with different types of fear?

What I mean by that is, do you think, say, Fidelity, because of the scope of their business and what they’re actually providing their customers, they’re dealing with a different sort of fear than, say, Marriott?

Not that they’re not in a very competitive space but there is something, it seems a little safer about the fear they might be experiencing than the fear of the transactional relationship that Fidelity seems to have with folks.

Karen: As you’re talking, I found myself thinking that we’re going to have a range of guests that cover the needs of private companies, privately-held companies, public companies, publicly-traded companies, and then civic or government organizations.

While I think that the challenges that many of those organizations face are, in many ways, quite similar, I agree. I think that there probably is some different motivation, some different fears that come to play.

Whether you are a government institution and beholden to your citizens or whether you’re a public company and beholden to your shareholders or whether you’re a private company and, to some extent, you maybe have the luxury of dealing with some of these things behind closed doors.

I think that the types of problems organizations are solving also probably, can cause some different motivations or different fears. I know that Stephen Turbek from Fidelity will probably mention some of the concerns that they have around changing their transactional experience.

I’ve had some great conversations with him about the work that they’ve done to build a beta version of their account servicing so that they can go responsive but have the ability to test and learn and not be making changes on the core transactional experience because that would be really  risky.

I’m sure that we’ll get some great stories from organizations like Marriott about how they’ve managed risk as they move into global markets. Yeah, I agree. I think that there’s just all kinds of interesting stories here about how organizations recognize their fear and then deal with it.

Sean: It sounds like beta mitigates fear. That’s potential bumper sticker slogan, I guess.

Karen: I definitely think that organizations that have moved toward a more data-driven and perhaps even continuous deployment model, which is another thing that we’re going to be talking about at UX Advantage.

How do you get around the fear of the one Big Bang release? Maybe you’re doing more frequent testing. Maybe you’re supplementing what should be a really rigorous approach to in person user research sessions with also some ongoing AB testing or split testing that you’re running on the live site.

You’re continuously deploying a variety of different objects into the live site so that rather than waiting for the one big reveal, you’re constantly evolving the site.

If I was thinking about ways that I might mitigate my fear, making lots of small incremental changes rather than one big bang might be a really good way to do it.

Sean: Listening carefully to you talk, it’s clear that what’s going to be really exceptional about the UX Advantage Conference is that all of these topics were obviously very well thought out, because they’re seemingly interwoven together.

I guess you’d be lucky in an organization if you only had to deal with one or two of them. It sounds like they come part in parcel with another.

Karen: As Jared and I were planning the topics for this event, we realized that most of the leaders that we were going to speak to would be able to cover probably the majority of the subjects.

While we have some guests that are going to come in and give us a really focused look at topics like globalization or how you get your lawyer on your side, I think most of the interviews will be able to cover a range of different topics.

Everything really is an interwoven look at all of the different steps and all the different processes that organizations take as they become a more design-centric, more user-centric organization.

Sean: Taking this full circle, this idea of fear and how can leverage that to make better decisions and release better products, what are some valuable lessons that you think every organization can learn from the challenges that healthcare.gov launch uncovered in spectacular fashion?

Karen: I think first and foremost that fear and even the risk of failure can be a good thing. I don’t know that we would have the US digital service or 18 F right now if we didn’t have healthcare.gov. I think organizations being able to look at a failure and say, this is an opportunity to change is probably one of the most powerful things they can take away.

I think I’d also like to say, you don’t have to wait for a healthcare.gov fiasco in order to make these changes. One of the benefits that I think organizations will get from coming to UX Advantage is a chance to hear from organizations that have already been through this transition and hopefully walk out with some tools that they can use in their own companies to make this change happen.

Sean: That’s great. I think this is going to be an excellent event that people will be well-served attending. I just want to thank you for your time today, Karen.

Karen: I think it’s going to be a fantastic event too, and I hope to see everybody there.

Sean: Watch for other podcasts. It’ll be covering more of the conference topics. Be sure to take out the conference speakers and all of the topics at uxadvantage.com. We hope to see you in Baltimore, August 18th and 19th. I’ll be there. I’m excited for the event. We hope you’ll be there, too. Bye for now.

Get Insights from Marriott, Nasdaq, Fidelity, and PayPal at UX Advantage

The UX Advantage Conference in Baltimore, August 18–19, has 14 inspirational pioneers who are delivering user experience as a competitive advantage to their organizations. In live, on-stage interviews, Jared Spool and Karen McGrane interview the design leaders who are at the forefront of redefining their industries.

You’ll hear how:

  • Lean UX methodology at PayPal has changed the way teams work
  • User research helped the Nasdaq design team get a “seat at the table” and affect future company strategy
  • Prototypes paved the way in helping the Marriott organization understand the relevance a design brings to different markets
  • The design team at Fidelity works with the executive team to promote customer experience as the top priority

See the other interviewees

Extraordinarily Radical Redesign Strategies

It may seem counterintuitive, but Flip-the-Switch redesigns turn out to be the most ineffective way to get major changes into a design. They are overburdened by corporate politics, the need for every one to get their piece of the pie, and huge expectations of amazing improvements the moment the new design is launched. The expectations are rarely realized and everybody is left wondering what just happened.

Part of the problem comes with the attitude of having a single moment when you’ll launch the new thing. Suddenly that launch moment becomes everyone’s focus. Nobody wants to have their new feature or capability left out.

We all grumble when the designs we use every day decide to change suddenly. We need to respect our users and understand they don’t like it when we do the same thing to them. How can we do that?

Small changes at glacial speed. The beauty of making small changes means that you never have high risk. A menu item here, a new form field there. Slowly the interface morphs, and if you make a mistake, well, you change it back.

This type of redesign takes patience. It also takes humility, especially from those organizations who think people want to hear that they’ve made it better. Unfortunately, to most people, those proclamations sound like the web equivalent of “Our menus have changed so please listen carefully.”

To pull this off, the team needs a solid vision of where the design should eventually go. Then, one small change at a time, they start in. Make the change and watch what happens, proceeding slowly to the next. The team will know it’s succeeded when they hear a user insist that a new addition has been in the design all along.

Come to the UX Advantage Conference to hear how top UX and design leaders have influenced top-down organizational change and gotten true executive support as opposed to just lip service to a great user experience.

adapted from “Extraordinarily Radical Redesign Strategies” by Jared M. Spool

About the Conference

UX Advantage covers UX strategy issues no one else is talking about.

Stay In Touch

Stay up-to-date about the next UX Advantage conference, live recordings, and podcasts.

UIE values your privacy.
We will never sell your e-mail address.