In the first episode of “Behind the App”, a special series of Inquisitive, we take a look at the beginnings of iOS app development, by focusing on the introduction of the iPhone and the App Store.
Tips on avoiding rejections by Apple’s app-review staff and what to do when your app get rejected.
This week’s episode comes to you live from the Atlanta Pen Show. Hear Brad, Myke, and Anna talk about their experiences of the show, in front of a fantastic audience.
Fraser and Bradley continue with the 2016 Deployment series with a discussion disaster recovery, backups, and file storage on iOS. If you enjoy the show, please consider leaving a rating or a review on iTunes. You can also send feedback directly to us at outofschool.net. If you’d like to support the show, please visit our…
Hacked began as a concept for a documentary. With Jordan asking questions and Scott answering, they quickly realized that the content was definitely of interest but the base of knowledge was too much to transfer in a single video. Hence, Hacked.
It seems that everyday a news story breaks that speaks to digital security. Every season, a new TV show tries to latch onto this growing curiosity but most fail to represent reality.
We hope you enjoy!
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.
Harmony can control Insteon, Richard ensures his garage doors are closed, and Garry Whittaker joins us to discuss home automation in the United Kingdom.
Brad and Myke are joined by Adam Kornfield and Joey Cafone, better known as the team behind Baron Fig. We discuss how they got their start making notebooks, the transition into digital apps, and their latest venture, a pen, appropriately named The Squire.
Katie and David discuss various ways you can optimize your iOS experience. From wrangling notifications to extending battery life we run through a number of tips and tricks for creating a better experience when using your iPhone or iPad.
Page 1 of 3Older