The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #255 Luke Wroblewski - Mobile Behavior and Design Trends Live!

December 11, 2014  ·  67 minutes

Listen Now

Download the MP3

What’s going to make your whole company focus on mobile? How do people interact with their mobiles device? How can you design for this new reality and even create experiences that translate from mobile to laptop to TV?

Show Notes

Find out from Luke Wroblewski. He’s got the facts, tips, and case studies to help you talk confidently with your team about designing intuitive, cross-device experiences. You’ll think about how people are using your designs on mobile, whether browsing a content-heavy site or interacting with an e-commerce application.

Full Transcript

Luke Wroblewski: So I arrive at the hotel. I have a bag with my luggage inside. And I wake up in the morning and I'm going to go to the shower and I want to brush my teeth. And I'm looking all over and I can't find my little toothbrush case. And I just destroy the suitcase, tear it apart, look for it everywhere. It's missing. So in an act of desperation, I take one of these little wash cloths and I put my toothpaste on it. And I brush my teeth with a little towel and it seems adequate.
I get out of the shower. I sort of walk into the hotel room and there is sitting my hygiene kit. So that's the kind of day I'm having. I hope you guys are having a good day. But if I sound a little discoherent here and there, there blame it on the toothpaste . OK but I'm not here to talk you guys about toothpaste. I'm here to talk about mobile design. And in order to talk about mobile design, Jared actually did a real nice favor for me by bringing up the fact that I used to work over at NCSA. Does anybody know what NCSA is? So it's the National Center for Super Computing Applications. Sounds big and mighty, right? But it's actually where Mosaic came out, which is the first graphical web browser that gained any measure of popularity. That became Netscape Navigator when Mark Andreessen went over to Silicon Valley with it. It became Internet Explorer through the Spyglass deal. And it sort of kicked off the web. So I started off, back in the mid 90's, working at NCSA. And it was a really amazing time to get involved with the internet and with computers. Because if you sort of see what was happening back then, in terms of global sales of PCs, that is, how many of these personal computers were making their way into the planet. Keep in mind, this is a relatively new phenomenon but it's a really good run. Right? Up and to the right. And if you're involved in technology, every single day more and more people around the world now have access to the internet, have access to the web. And in the mid 90's, you know, we built things that looked like traditional websites. This is one of things I did over at NCSA. You can see menus, text, images, all the sorts of things we do right now. But it was actually a lot of sea changing things that led us to actually do that. Because NCSA was a research institution and the whole point of the web back then was to share research documents. We've come a pretty long way. So that was a cool period. And then what happened was the bubble burst. Anybody remember that? The dot com crash. I can't even remember what else you want to call it. Armageddon, if you lived in Silicon Valley. And so what happened was global sales of personal computers actually went down a bit. If you look from then, that had never happened before. And then they kind of flat lined and plateaued for a number of years. So this great growth and this explosion we had really kind of took a hit for a bit. And it was right around that time that I stayed at the University, taught some classes.
But then, towards the end of it, I decided to actually go and take a job over in Silicon Valley working for eBay. I did 2 and 1/2 years at eBay, 4 and 1/2 years at Yahoo. And again that period of my life turned out to be a really great run. Because again, if you just look at global sales of PCs, that was an even better run. Look at how many people now have access to the web, how many people are on the internet, and how many people we can reach with our apps, and our services, and our content, and our interactions.
And then, though a lot of time passed there, it was like a 10, 12 year period, the things that we are making for the web still kind of looked the same. My mid 90's NCSA design skills were totally applicable when we redid the Yahoo homepage. Or when we redid selling on eBay. The scale was a lot bigger, so we learned a lot more. And the bar was a lot higher in terms of design but the core principles, and the interactions, and all those things, they sort of held tight. And what basically happened is we could apply that to more and more people, more and more use cases, more and more things. So again a very exciting time period. But towards the end of 2009 and into 2010, something else happened to this line. It flat lined and then last year, in 2013, it dropped precipitously. This is the biggest drop in worldwide personal computer sales we've ever had as an industry. Again, follow that chart. There's only been that one during the crash and it was much less marked than this one. So that started in 2010, sales sort of plateaued. And In 2013, they really fell off a cliff. In order to illustrate what's behind this, what I'm going to do is sort of zoom out on this graph and build up the vertical axis for a second here. All right, so scale is a little bit off but I think it's illustrative to show what's going on. If we didn't have the scale like this, the PC rise wouldn't look nearly as awesome as it actually was. But let me add another line to this chart, which is the global sales of smartphones and tablets. Anybody see something interesting in this chart? That you might want to pay attention to? One of the more interesting things about this chart is that this moment where these two lines crossed actually happened a lot earlier than people predicted. There was these wild predictions that global sales of PCs would be surpassed by smartphones and tablets in 2012. Well it actually ended up happening almost two years earlier, towards the late end of 2010. And this is sales worldwide of these kinds of devices.
And I call that moment where these two things cross, where the mobile line crosses your conventional personal computing line, the mobile moment. I think it's an interesting concept to think about. It's a very simple idea, right? You have this non mobile internet software computer stuff. And then you have the mobile version of that. And when those two lines cross, you hit this mobile moment. And I've been tracking when companies publicly say they crossed this. So this is not nearly an exhaustive list, but it shows how many people are actually crossing this line and when. So Facebook, the Weather Channel, the music radio service Pandora, this happened to them about three years ago. Twitter and GooglePlus, which everybody uses, happened in 2012. So what that means is all three of the GooglePlus users in existence got an iPhone. 2013, Amazon, ESPN, Yelp. 2014, YouTube, LinkedIn, CNN, all these other companies are either there or about to cross the line. So that's in terms of traffic, of usage. Your audience size for these companies is larger on mobile than it is on conventional PCs. So that's an interesting thing to keep in mind. But it's not only just your user base, it's also revenue, right? So if you look at mobile holiday shopping in the US, you see a similar trend where for a couple years it was sort of on the up and up. And then last year, it crossed that mobile moment. So not only have a lot of internet services had their mobile moment, commerce in general in the United States in the busiest time of commerce of the entire year had its mobile moment. And I bring these things up because if you're selling stuff, or if you're using social media, like Facebook or Twitter, to talk about the things you're selling or about your businesses, these things are over the 50% mark. If you're sending emails, same story. Global opens of email, mobile versus desktop, it was 20 percent mobile in 2011. Went up a bit. And again, in 2013, we cross this mobile moment. So it's not just the audiences, it's actually the kinds of things that they're doing is shifting as well. Which leads to big opportunities.
So here's Paypal and in 2010 they did a decent amount of mobile payment volume. Certainly went up the following year. The year after that they seem to have gotten a little bit more growth. And last year they did $27 billion in mobile payments. And that's the impact of all these mobile moments, right? The traffic mobile moment, the usage mobile moments, all these things translate to direct money. And now this year we've actually had a bunch of companies coming out and saying they're actually making more money off of mobile than off of conventional personal computers. And this is an interesting thing because the prevailing thinking is like, oh, mobile is less, you can't run ads on mobile, nobody buys anything on mobile. All these kinds of things. Yelp, 40% of their search ads are now on mobile. Facebook makes 53% of their money on mobile. And Twitter makes 75%. So in a way, to summarize what I've been saying is mobile, mobile, mobile, mobile, mobile. And I think that's really exciting because of that opportunity, and these new audiences that we can reach, and all the things we can do for our businesses there. But in addition to that opportunity, I think there's another thing that's more of a challenge than an opportunity. Which is, the reason I walk through my career from the mid 90's up until now, is because that's what I've been doing for the past 20 something years. Every single day I fire up a laptop, I sit in front of the laptop, I use a keyboard, I plug-in to a power supply, and that's how I get my work done. And to sort of illustrate this, how many of you have been using a laptop or desktop for five years? Put your hand up? OK. How many of you have been using it for 10? Keep it up if you've been using it for 10. OK, 15? 20? OK you're all really old. That's the first thing we just learned. But the second thing is, it's really ingrained in our heads, the idea of what a computer is. If you use the same sort of piece of hardware and software for 20 years to do everything you do in the digital world, that is what a computer is. It's so stuck in the back of our mind that it's very hard to shake. And I think there's a real big impact that comes from the fact that most of us started in this environment with personal computers. And we continue, to this day, to use these kinds of devices. Even if you're designing mobile apps and mobile software, you're probably using a PC do it. You're spending multiple hours on these kinds of devices that look like that. And in reality, this goes even further back. I sort of touched on 20 years, but if you really want to trace the growth of PCs, so let's go further back than 1995. All the way to 1984. Anybody know what happened back in 1984? Other than that scary thing with the cameras. Orwellian, what was it? The IBM PC came out, that's a good one. But whatever you consider to be the sort of pinnacle of consumer computers, whether it's the Mac or whether it's something else, these things came out back in the '80s. And in the '80s they had a keyboard and a mouse. Not the TRS80, it actually had a tape recorder. [INAUDIBLE] But so since the mid 80's, up until 2014, there's been mice and cursor in our lives. And we have used interfaces and created interfaces for those input types, for those kinds of devices. The whole paradigm of a window and icons, menus, pointers, right, this whole WIMP model is all created to be used with these kinds of devices.
And what we sit on every single day and everything we do all day, which is usually answering emails, trying to get Outlook to work, or whatever it is you do in your lives. It's all by like clicking on these little icons and little pointers and moving them, right? How much time do you spent resizing little windows all the time? My desktop has looked like this for 20 something years and it continues to look like for 20 something years. And when you really pull back and look at a lot of the design decisions for the graphical user interface, many of them stem from needing to support these kinds of inputs. And Jason Grigsby, for those of you that caught his talk, talked about all the varying forms of input we're dealing with today. But input and output has a huge impact on the kind of design we make. And it's been with us for a long time. So to put this in perspective and kind of outline what's been happening. If we trace back to 1984, that's 30 years of a personal computer use. If I be very generous and I say the modern mobile era, the smartphone and tablet era, started in 2007, which is when the iPhone was first announced. If I be really generous, that gives us about six years worth of learning. It didn't really get going until a couple years after that, right? It was sort of like this new thing that nobody really did anything with. So generously, we've had six years to figure this out. Whereas we've had 30 years ongoing of the other stuff. So that creates an interesting situation in two ways. One, it means we actually have a bunch of stuff to learn about mobile. So all these new things we have to figure out that frankly we just haven't had that much time to figure out. But perhaps more importantly, and I think more challengingly, which isn't a real world, but now it is. I think the bigger challenge is, how do we actually unlearn all this stuff that we have? This stuff that's ingrained in the back of our heads from day to day personal computer use. And to illustrate this, lots to learn, lots to unlearn thing, let me show you an e-commerce experience. So many of you probably spend time here. Probably too much time here, if you're like me, because they make it so easy to buy you're just buying anything. But this is very much an interface created for the conventions of mice, keyboards, large sort of screens, if you will, search URL bars all managed by typing, links managed by clicking with a precise little cursor, big layout, taking advantage of the screen. Everything is sort of designed within that structure.
Now when Amazon takes this interface that they've created, long before there were modern mobile devices, and they poured it over to, let's say a native iPhone application. You can see it's 90% the same thing. With search results, they've got a little less stuff in them. Which, frankly, there's probably a most important set of information that they could apply everywhere. But since they got more room, they're like, why throw it in? But there's some critical amount-- and they use some native OS controls to allow you to refine and navigate around here. But for the most part, this is taking what we've been doing for those 29 years and pouring it over to a smaller screen, if you will. Let me contrast that with another thing that Amazon does. Now there's a lot of debate about, should companies have multiple native applications in mobile? Should we have three apps or one app? Should we have category apps? Amazon has a really interesting approach, at least looking at it from an outsider's perspective. Because they'll release a couple of native applications here and there. And if those things turn out to be interesting, they fold it back into their main app and it becomes a feature of the main Amazon native application.
And so this is one of those applications that started life as its own thing. And as of about a month ago, has actually gotten folded into the core Amazon experience. And it's called Flow. And the way it actually works, the best way I can describe it is a magic shopping wand for the world. So what you do is you just take your phone and you point it at things. So it's like, oh, is that a book? Oh I know that book. Hey, you want to buy that book? Look, oh, what is that, a bar code? Huh? What is that? Oh, it's another book. How about buying that? Oh, what is this? Oh, a CD. You want to listen to it? You want to buy it? Huh? Huh? Oh, a barcode, a barcode. What is this? Oh, that's like a disk. You can-- oh there's a video. I don't even know what it is, buy it. Let me just show that again. Magic shopping wand for the world. In real time it's identifying the things that it's seeing in the camera view port and giving you one click access to purchase it. So I'm on my back porch grilling because it's California and we can do that. And I run out of this seasoning. Still have the grill tongs in my hand. I pull out my phone from my pocket, I point it at that seasoning. It comes up with one click. I push buy. I put it in my pocket. It shows up the next day at my house. How different is that experience from this? A little bit different? A lot a bit different? And I'm not suggesting we're all going to go run around shopping by pointing our phones at things, right? But what I am saying is, if all we're doing is relying on everything we've learned about interface design, and interaction conventions, and visual design from those 29 years of PCs, moving to this kind of interface is a really big leap, right? You gotta let a lot of stuff go to get to this point. You gotta actually learn a few new things as well. So with that example, this is what I want to spend the bulk of my time talking about, is illustrating some of these examples of where we've got lots of things to learn, but also really highlight many places where there's things that we need to unlearn. And kind of let go of, if you will. And as I will probably say one too many times, this is the harder side of this slide. All right? Picking up a new skill here and there, you may be grudgingly doing that. Giving up on stuff that's worked for you for 30 years, that is a lot, lot harder to do. So what are one of the things that's actually worked for us? Well, we've been really spoiled because we've gotten bigger and bigger screens over the years. We've gotten these huge things. And people will debate over what the right screen size is for a PC but it is way bigger than what you get on a mobile device. Going from 1024 by 768 to 320 by 480, you're losing 80% of your screen space. And a lot of mobile design challenges, a lot of this unlearning, I think, happens when you don't go in this direction. That is, you don't start from this big screen experience and move it over to mobile. Because when you do and you can see this in a lot of design, especially on the web, right? Somebody will take their desktop site and they're like, OK, we squeezed it into a single column. Mobile website. Right. I love the responsive design methodology for adapting to lots of different devices, but many responsive sites you look at are like, you know how we're going to solve mobile? One big long list. Great. And you may say, well, what's wrong that Luke? Well let's take a look at one of the premiere examples of responsive web design, the Boston Globe. And the folks that worked on this, super bright, and at the time they were really pioneering and doing sort of new things. So I don't fault them for the way this thing runs today. But let's look at this page for a second. So when I hit this page, it looks like there is a game going on and Obama is mad about something. That's like it. That's all I get. And then I scroll. And I scroll. And it turns out, oh what was that? Was it like some opinion? Oh they have sports things here too. What? Metro? Nation, and the world, politics, who knew politics was here? Business, hey. Going, going, going. I removed the ad. Going, going, going. Still going. Phew. They managed to fit it all in. Good. This is my friend Eric Runyon. He is holding a print out of the University of Notre Dame website if they did nothing to optimize it for mobile. They actually do a bunch of interesting service side things to adapt it. But if they took their home page, this is just their home page, and they put it on a mobile web experience, this is how long the thing would run. Let me actually put some numbers behind it. So if you take that web page and you make it 320 pixels wide, it is 26,115 pixels tall. It is 26,000 pixels tall. Let's just hammer home that point for a second. A 27 inch monitor with very high resolution only has 1400 pixels in height. This is 26,000 pixels tall. Does anybody see a problem with this? And again it stems from where we start. Where we begin. We have this notion of what our website is and when it comes to mobile we're like, how do we fit it on mobile? And these are the kind of end results you get. And you may look at this and say, but Luke, Luke, Luke, people will scroll. Yeah, people will scroll. I'm not saying scrolling is bad. There's always this fear of scrolling. Has anybody ever lived in fear of the scroll? There's this evil Lord called the fold who sort of reigns over the scroll. Right? He's a tyrant. Because if you are in with the fold, good things happen to you. If you're not aligned with the fold, bad things happen to you. So 80% of people engage above the fold but only 20% of people will engage below the fold. There's all these kinds of stats about the fold. So it's always this conception that scrolling is a bad thing. That people won't scroll. Everything should be within one click away. Remember that stuff too? That's also a good one. People won't scroll, everything should be one click away and other awesome heuristics you can use to design your website.
Turns out this is actually not so true. So let me pose a question to you guys. This is a landing page for a service, right? So this is the control where they had a really simple call to action up above the screen. And above was the challenger that they ran a series of AB tests around. Now the challenger was actually 20 times as long as the control. 20 times as long. Which of these landing pages do you think converted better, the control or the challenger? Who says control?
OK, two people. Everybody else is getting the loadedness. Who says the challenger? It turns out the challenger actually had a 30% increase in conversion over the control. And there was a really interesting insight from this study that I am going to call out here, because I think it's worth mentioning. The problem isn't, is it visible above the fold? The problem, is it visible when you're ready to do it? All right. It's not like put a giant button on the page so people click on it, when they have no idea what it is. It's have the right action available, when they finally become convinced to act, or when there's an opportunity for them to act. And I think this is a lesson we can take forward to smaller screens as well. This idea of having just in time actions that allow people to do things when it's appropriate.
So scrolling is not bad. Josh Porter actually says this nicely, scrolling is a continuation, an example that highlights it. Like am I interested in this? Let me read a little bit more. Oh OK. Whereas a click is a decision. So people understand this context. They know the modality they're in. They will continue to scroll, and it's not an issue. Long pages and these things become an issue, if you don't understand the context. So when you just take a web page, and you fold it into one big scrolling list, there is this flat hierarchy, and that everything's equal. You got no idea what down here. Without landing pages, known as more information about the product there. And the other thing that happens in mobile, is if you're trying to take a large web page, and load it onto a small device to people use on networks anywhere and everywhere, it's going to be painfully slow in most cases. It's going to incur a heavy download.
Now the University of Notre Dame guys do some really interesting things with server-side optimization, and front-end optimization, to not incur a heavy download for their big pages. But generally, taking this huge desktop thing, and pushing it down to mobile, is probably not the best idea. And I'm going to jump back to an earlier slide that I showed for half a second, just to paint this in context. This is something I personally struggle with all the time, because I come from this PC era. And I look at this chart in my sleep, and I say to myself, am I doing bad to these guys by trying to make sure I support these guys? And just thinking too much about that experience. Are my priorities inverted, because I in my head have this understanding of what web pages, websites, and what software has been over the past 30 years? It's an interesting question and I encourage you think about it. So there's this flat hierarchy. There's this what's down here. There's this heavy download. And to illustrate this with the University of Notre Dame, if you scroll this page, here's some university news things, here's some magazine stuff down here, about info, over here, they have communities, academics, who knows where all that is, and what's coming. So in order to get around this issue, this everything's down here, you don't know what's here. There's been some interesting developments in mobile design to kind of address this. So one of the cool ones that I've seen people use, and has gotten more and more popular, is this idea of an off-canvas navigation. So rather than fitting everything into a single column, what you actually do is say, hey, maybe we can use some stuff off the screen for our content.
Instead of pushing everything off, let's make things accessible. We'll bring them in where appropriate. You could see this in action on our Google. So you see those three lines up there. And if you tap those three little lines, what it will do, is slide over this off-canvas menu, offering you more options. And then, if you hit it again, it will close up, and you're back to the page you were at. So you don't have to do this big scrolling thing. It's taking advantage of off-screen elements. And this is a pretty popular pattern. You can see it over here on ESPN. You hit the three little lines. And here it is over on Facebook. The icon itself has taken on a really interesting name, called the hamburger icon. Maybe because it looks like a hamburger. Some people call this the hamburgers.
When you actually dig into it, the hamburger icon doesn't like to be called the hamburger icon. He has his own Twitter account, and he likes to go by Mr. Liney. He doesn't want to be associated fast food, because he actually reveres himself. As he points out in his Twitter bio, I consider myself the most easily recognized icon on the web. And he's a little hoity toity about it, as you can tell. And he'll tweet things, yo check me out on iTunes. Here I am. So the hamburger icon, or Mr. Liney as he likes to be called, has become a pretty popular pattern. And I highlighted it over here on Facebook, because I believe a lot of people saw it on Facebook, and said, aha Facebook is doing this. Facebook uses the hamburger icon, cool. Everybody gets it now. Have you ever heard this line, Facebook has trained a billion people on how to use that? Anybody ever said that to you in a meeting? Facebook has trained a billion people on how to use Mr. Liney. And so, as a result of this, you have many, many, many, many implementations of this "pattern." and I say "pattern", because I don't think it's a pattern just because people start doing it. A pattern is something that is repeatable in a specific context, and you understand the why you use it, and how you would implement it. This is just copy. You're like, oh yeah, you know how to do that. As I said before, what are the rationales behind this? People say things like, everybody's using it now, so people get it. Facebook trained a billion people on how to use this. And let's look at the Facebook trained a billion people on how to use this thing. I've worked with many corporations over the years. There's always this outside perspective. They know what they're doing. They're clearly testing everything. And then you go behind, and you're like, oh my god, that's why you decided to do that? Seriously?
Here's the story with the hamburger icon Facebook. As of recently, they actually replaced this icon in their native iOS application, and they're doing this in other native apps as well, with this UI down here that uses the tab bar, a native iOS application control. And the reason why they actually made this change is they finally put an AB testing system into their app. Before they had been trying to shove all this JavaScript, and HTML, CSS5, into a native controller. They had like two-star ratings. The performance was terrible, and frankly, like testing the menu icon wasn't exactly a top priority. Soon as they fixed all that up, and they put in a rigorous testing environment, they really quickly realized that thing performs really badly. So in their testing, they found engagement, satisfaction, revenue, speed, even perceived speed, improves when they go away from that hamburger icon down to a visible set of icons. And when there's lots to learn, it's comfortable to go look for easy answers. This is new stuff. So we're always grabbing at things that we think are solutions to our problem. And I think that's challenging, because we run into a point, where we're doing things, but we don't really know why. And we make decisions based on, Facebook's doing it. Turned out Facebook actually didn't know it was bad, until they tested it, and then they realized it wasn't good. And so I've brought some of these things up. And I've had the pleasure of hearing from other people about their experiences with this interface, testing this interface. So Joe Leech, who's a User Experience Director over at CX Partners, sent me this info. He said, we "tested this hamburger icon with 15 people. 3 people got it but they thought it was an 'Apple' thing. " Danny, who is a lead technical architect at AT&T showed, "9 out of 10 people had no idea what it was." So when people actually went in there and started testing this pattern, they found that there was actually some problems with it. And as we started talking about this, more and more people began to chime in with their experiences actually trying it out. I didn't realize it before my research, was people still don't know what it means. We had to start labeling it. People under 35 seemed to know it a little bit. Most people didn't get it, what have you. And I don't mean to rag on this specific implementation here, but the meta point is, it's that understanding of why and how things actually work that matters. That's the learning peace. When I say lots to learn, I don't mean lots to copy. I mean lots to actually learn. Now, because this topic got some-- So now we've seen the Facebook thing. We've heard anecdotal usability studies.
James Foster picked up on this stuff, and he decided to run a bunch of A/B tests. And he made those A/B tests public. I will share these with you, because some interesting things come up from this. So his first A/B test, he ran about 20,000 unique visitors through a comparison. And what he did is, he took the hamburger icon, he put the word menu underneath it, and then he took the hamburger icon, and he put a button shape around it, if you will. So now it looks a little bit like an affordance. Bless you. And what he found was when they added the little word "menu," the amount of engagement actually went up. That little bit of clarity on what this thing was allowed a good number of people to actually start interacting with it more. But perhaps, more surprising, for those of us who like affordances, less surprising, is make it look like a darn button, actually had an even bigger impact. I'm sorry iOS 7. We can talk about that later, but this little addition of an affordance of making it look button-like actually helped a lot. And then he ran another test. So he ran another test. He did it for about five days. He had 50,000 unique users. And they were the 25 to 34-year-old demographic. And this time, he tried a few more things. He took the winner of the last contest, hamburger with a patty around it, the word "menu" with an icon next to it, and just the word "menu," compared against the control, which is the hamburger up top, the word "menu" performed quite well. The inclusion of the icon actually made things worse. It turns out that just the word "menu" is actually enough to say menu. Don't actually have to put a cryptic icon next to it. Go figure. But even more, perhaps, surprising was that this did so much worse. And what's missing? The affordance. It doesn't look like something that's tappable. And again Android and iOS guidelines in the OS, those interface guidelines that they have are about holistic experience across the whole OS. They don't necessarily take into account the specific context under which you're trying to design. So treating them as law sometimes is dangerous. Because if you've got an important primary call to action, and you just make it text up in the header like this, chances are you may actually be doing yourself a disservice. And I think it's also telling that if you look at some of the point releases in iOS, they now have "accessibility" accessibility options to bring the buttons back into a feature called button shapes. So if this wasn't enough, James did one more final test, 50,000 mobile visitors, to really nail home the statistical significance thing. And he took the winner of the first test against the winner of the second test, and this time he had 240,000 unique mobile users. The last one was 50,000. So it's close to a quarter million people hitting this, to again get a decent amount of statistical significance. And the word menu was selected 20 percent more than the icon. Now what does this tell us? It tells us two things. Affordances still matter, making things look actionable is still important. It also tells us that words are going to be clearer than icons, no matter how ubiquitous or self important those icons feel they are. But the third thing it tells us, it's like that stuff's is a duh. Don't need all this A/B testing to figure it out. You know how you can know? You can go to a website like, which has replaced their navigation with this menu, and you can see what they're doing here. Nobody can tell that's an icon for menu, let's add the word "menu." OK. Hey, nobody's clicking on this, let's do a callout. OK. Hey, this is the navigation. OK. OK. You can hear the conversations. Oh, we buried the sections behind this icon. Oh crap, nobody is going to the sections. Our page views are going down. We need them going to the sections. Let's add the word. They're still not going there. Let's do a call out. At that point, I don't need A/B testing to tell you there's an issue here. You can see it in your interface.
So while the data can help us make these decisions, I think when we find ourselves doing contortions, that's another sign that maybe what we're doing is not the right thing. And the other piece to this is it's actually OK if you put things behind a cryptic icon that you don't care if people find it. You may say, oh, you know what? People can't recognize that much. That's OK. That's only for situations, where they get really desperate to find the things they want. Fine. That's totally valid, right? If you've got like 50,000 pages, and you want to hide 30,000 of them, throw them behind an icon, you're good. But if it's stuff you actually care about like these favorite sections, which I'm assuming Time cares about. I didn't work on this project. I assume they care about it, otherwise they wouldn't call it out like this. If they care about it, then maybe you don't want to put it there. And let me illustrate this another way. So I have a startup that I run right now, we have this mobile application, and inside the mobile application, early on we had this segmented control. And what this segmented control, allowed you to do, is really quickly see these little polls of questions from people that you were following. You could see the most popular ones, or you could browse more of them. And so we had really clearly upfront, this controller allowing you to switch between these views. And when we went and did a redesign for iOS 7, we actually moved this to this toggle menu pattern, where up at the top, there's a menu control that brings down the menu, and then closes it back up. So you can tap that menu, it comes down, and then you can bring it back up, and you're back on the page that you were at. And we did a decent amount of stuff to try to make this look like an affordance. So it looks like a menu button with the arrow down, curved little button thing. We weren't being totally irrational by moving to this. And what prompted us to go in this direction, we started to see lots of other apps doing this, lots of other applications using this toggle menu pattern.
So here's Vine, which is a popular video sharing service. You can see they have this home icon thing, where if you toggle it, the menu comes down, and you can interact with it, decide where to go. This is Kickstarter. And they also have a little bit of 3D bevel to that menu. So again, you can bring that down, navigate around, close it up, and make your way through it. Now being a somewhat prudent startup, we tend to measure the things that we do. And one of the things that we care about a lot, is how much activity each of these questions is getting. So if people will post a question and they get replies, then they're more likely to post another one. And the more replies they get, the better they feel about themselves. So we care about that metric. We track that metric. And with our segmented control, we we're having a decent amount of votes per question. And somebody puts something up, they'd get a good amount of feedback, and they'd interact with it. Then, we launched this toggle menu. Anybody care to guess what happened? Awww man. Just fell off of a freaking cliff. And it's the same thing that happened with the hamburger icon. We hid these things. We put them behind a tab. We put them behind a control, even with our best efforts to make it look like a control didn't count enough. So if it's important, it should be visible. And needless to say, we quickly did a redesign where we brought those things back. And me as a designer, I cringe at these, they're ugly up there. I wish it was cleaner, just simpler, one link. That was one of the things that prompted us to do the last time. Look at how pleasing it is, just one thing. But it turns out that was actually a bad thing, and so the segmented control is back. And again, the only reason these things are front and center for us, is because that's a really important thing for us. Maybe for time, it's very important to give people the sections. Maybe it's not. If not, fine. And you may say, OK well, now I'm in a really big bind, because Luke you're telling me if something's important I have to put on the screen, but my screen is tiny. So what do we do? The screen is small. If it's important, it has to be on the screen. I'm screwed.
Well, I think this is actually amazing forcing function. I love this constraint, because you basically have to figure out, OK what's important? What content, what actions are actually important? Because if they're important, we've got to put them on the screen. We don't have a lot of room we have to fit them. We have to have hard conversations about what's really important. And if there's a secondary stuff that's not as important, maybe it's like complementary content or some secondary actions or whatever-- bless you-- great. We can put that behind a toggle menu, or put that behind a hamburger menu, an off-canvas or whatever.
But the biggest kind of pain I have here with the hamburger menu is not the fact that people don't get the icon, or they don't make it look like a button, those are things that are all addressable. You can manage that. My biggest issue with the hamburger icon and the hamburger menu is the way people understand is like, oh I have 5,000 levels of navigation on my website, how do I put on mobile? Behind hamburger. Good. Done. It becomes this crutch. You don't make this hard decision. You don't have to rethink what you've been doing for the past 29 years, you just find this place to put your menu, and its behind this little icon. That's the more troubling thing to me. It's not a crutch to automatically transfer this giant thing and prevent you from having to do the hard work of what matters.
For the record, what we currently do across our multi-device design for the same application, is we have a control for menu. We use a text label. We try to make it real high contrast, so it seems bottom-like. We even throw in a little icon there to support it. So that's accessible. But then we also take these contextual actions, these important actions, based on where you are, and we exposed them. And we don't try to expose every action everywhere. What we do is say, based on where you're at and what you're doing, these are the most important things, and so we're going to put those front and center and make them visible due to smaller screens. And that's a great forcing function for all kinds of screens as I was saying before. So hopefully that little fast food interval illustrates what I've been trying to get to. I feel like we've got some things to learn. We've also got a lot of things to unlearn. Your best course of action is probably not fitting your existing desktop website navigation onto mobile. And when I say learn, I don't mean see what Facebook's doing and just do that. I mean actually learn from it. Test it out. Try it. If you can't test it, try it, get information from other people that can, and learn what is behind this motivation. Because that's where you actually get to making good design decisions.
So let's look at another example of this. I find when people work on websites and software, there's really two things that bugger them the most. One is navigation, menus, seems to always come up over and over again, and the other one, is forms. People will basically spend all their time figuring out navigation, and figuring out forms. And that's the bulk of what they do. And so looking at this exact same pattern, when you start from the big screen, and you go down to mobile, but this time in input context, I think reveals similar things. So for a while, I've been highlighting this pain point that I have personally, because I fly. And when I fly, I try to get on the internet at airports. And I encounter services like Boingo that tell me, hey, just set up your account. Tell us about your firstborn child, submit all your information to us, so you can pay up $7 to get online for an hour. And these guys have figured out that mobile is important, so they've taken that whole experience. And here's step one, two, and three of five, of getting online at an airport. And just steps one, two, and three, add up to 23 inputs. It takes them 23 different sets of inputs for me to pay them money to access the internet. And since I've been talking about this for a little while, there's a really kind marketing manager over at Boingo who, every now and then, sends me an update. And says, hey, we heard that this is not good. We've been trying to implement.
So he sent me this recent redesign that has 11 less input fields. Ryan was pretty excited about it, notably. And I think he had good reasons to actually be excited about it, because this redesign boosted conversion 34%. If you're the guy at the company that raises conversion 34% on your primary funnel, they name a cake after you. and they serve at the cafeteria on Thursdays, right. It's Bob's cake day. And he also liked to point out that this led to a 53% decrease in sign-up times, which is cool. And I say, that's great. But I think, actually, you could do a lot better, because I have a design for those that only uses four inputs. And that's counting the button and achieves the exact same thing-- gets people online, gets you money. And this example of let's say, you are Boingo, and you care about giving people access to the internet. Turns out, maybe what they actually care about is getting you tricked into a monthly payment plan, but whatever. Let's assume they're trying to do the right thing by the customer and not trick you into subscribing to a monthly plan you don't know about. I don't know why I'd assume that. But let's assume that. Then this example-- OK, that flow matters to them. That flow is critical. This is an example of this process that Tim Cook actually does a really great job describing, because he says, the idea of being creative is really caring enough about something to find the simplest way of doing it. If something is important to you, can you iterate and get down to the easiest way of making it happen, to sort of the bare essence?
And I love this quote, because to me, this is what design is about. With design, the way my design process works is, I usually take a whole bunch of stuff and sort of barf it on the screen. And I spend the rest of my time trying to figure out, what can I remove. How can I simplify and get it down to what its bare essence is? And so his association of this with creativity really resonates with me. And I love this idea that this is the process. You just kind of keep iterating on it, until you find the simplest way of doing it. And to illustrate this, I want to show you guys a travel booking service. This is Hotel Tonight. And what Hotel Tonight does is, it allows you to get a Hotel tonight. Shocking, I know. But literally, you open up this mobile service and up pops the hotels near you that have availability and have good deals and have been vetted by this firm. All right, so they're only showing you good hotels at a good price near you. That's it. If you want to book one of these, all you have to do is tap on the one you're interested in. It'll show you some info about the hotel. You click a Book Room. It tells you the total price. You click Confirm Booking.
And then when you have to do is, you actually have to trace their logo with your finger, in order to complete the transaction. What? Why would they do that? It turns out, babies were booking hotel rooms. They had a certain percent of returns, because cats would get at an iPad and would actually book a hotel room. That's how easy they had made it. So they went through a couple of iterations, where they actually inserted this section where people had to draw their initials, but that felt sort of too legal. And then they came up with this idea, just trace our logo, which is kind of like a fun, brand-building thing. But it also verifies, you're not a cat or infant. And I like this example, because this is one of the few times I've ever heard the CEO of a big internet company-- and Hotel Tonight is pretty large in the travel spaces, especially in mobile-- say, a form is a competitive advantage for them. He basically says, look, getting a hotel is three taps and then that swipe. It's like a four-gesture interaction to book a hotel room. And we feel this is a competitive advantage for us. Now how could a form design be a competitive advantage? What he continues to say is, here's Hotel Tonight. Four taps, one swipe, it takes you about eight seconds to book a hotel room, eight seconds. He says, look at what happens on our competitors.
So here's Priceline, also allows you to book hotels on mobile-- 52 taps and 102 seconds, so notably a little bit more work., 40 taps, 109 seconds, also notably a little bit more work-- and you may say, look, how is it possible that there's that much more tapping. Isn't this a pretty standard flow, book a hotel. How can they possibly make it that much more work? Well, let's look at So out the gates, they've got some deal. So I hit Search, one tap. And I'm on the Search screen. And it's done this nice job of pre-filling my location, San Jose. And it defaults to tonight, great. So it's sort of doing the Hotel Tonight thing-- one night, one room, one adult. Fine, that all seems great. Notice, none of that stuff was visible in Hotel Tonight, take it for granted that's what you're doing. And then you hit Search, again. [AUDIENCE LAUGHING]
I'm in San Jose, California. What do I do? So I take pause, and I think. And I literally have to guess. Which one of these is the correct answer? Because I am actually in both, so both could technically be correct.
So I pick one, and then I'm back on the search screen. Can you see how this could quickly add up to more than four taps? I haven't even seen any results yet. And I think this is an illustration of this bigger picture issue. Because when you look at Hotel Tonight and you compare it to, I think it illustrates this challenge that it takes really big changes to go small. And what I mean by that? Well, let's look at what else has in their native app. They have a whole search feature. They have a Search by Star Rating feature. They have a Max price, Min guest rating series of filtering options.
There's a whole team dedicated to managing that location database and providing QA on it. They came up, oh, we have all these different locations. Look at how accurate it is. There's a whole team that's ingesting Star Rating feeds, checking them for spam and for quality, removing things that are good or are not bad right, normalizing the data keeping that up and running. Search-- there's probably a whole team of 30 engineers, half a designer likely, and like 15 PMs, or 50 PMs to be more accurate. Like 50 PMS, 10 engineers, and like a quarter of a designer working on that feature. And that's true for all these features.
But this is what happens when you come from this established structure. To, this is what a hotel-booking experience is. Of course, it has Search. It has to have Search. Of course, it has to have Star Ratings. We've always had Star Ratings.
And let's say, you go in there like, no Search, no Star Ratings, no Min/Max Price. We're just going to show you five hotels near you, good price good value. That's it. Every single one of these team's going to be raising their hands, oh, you forgot about Search team. Hey, yo, yo, ratings team-- And they're not wrong. Their understanding of the product is based on their part in it. So those are big. If you want to go to and say, hey, we're going to do mobile booking. And Search team, sit this one out. Ratings team, thanks, guys. You're done And like, you're going to cut off 75% of your existing product. Guess how many meetings you're going to be in explaining it to those people? You're basically going to be creating PowerPoint for the rest of the year. And you're never going to ship anything. It's a big change. So another example over here on Yelp-- so Yelp has actually been on mobile for many years. They've had a WAP site early on. They had BlackBerry apps. They've been doing a lot of mobile stuff. It's this local ratings and reviews thing. And though they've been doing mobile for many years, they've had one consistent request all those years for mobile which is, please let me write a review on my mobile phone. So it's such a consistent request that poor Eric, who runs products over there, has had to write a blog post, "Why Can't I Write Reviews on My Mobile?" Well, you know, imagine if reviews were done in SMS. It would be so bad. And he just goes on and on explaining how he can't do it. Personally, I would love it if you could leave little emoji poos reviews at restaurants. Because like seriously, you see three emoji poos. Are you going to eat there? No, you're done, right. That would be an amazing rating system. Hotel Tonight, on the other hand, also enables people to do reviews. But they actually allow them to do it on mobile. In fact, they encourage it. The way you leave a review for a hotel stay on Hotel Tonight is, they just give you this little blank card of photos. And you just take a picture of your room, take a picture of the lobby, take a picture of the bathroom. And that's it. You're done. They know you booked the hotel room, because you did it through their app. They know you're in the hotel room, because they have location detection. You have your phone with you. So it's like an authentic, genuine review of somebody who booked the hotel and was actually in it. And frankly, what would you rather do, when trying to decide whether or not to go to a hotel? Would you like to just flip through a bunch of pictures of people who actually stayed there, like this? Oh OK, that looks good. Or do you want to read some like prose that was written by some episodic reviewer?
'Twas a foggy morn in Monterey, when Ben and I decided to head out from our estate. Snuggle the puppy wasn't feeling quite well, so we were a little distraught, when we headed into the automobile. Luckily, as we arrived, as the gallant entrance of the-- shut up! Is it good or not? But again the Yelp review system was born of those 29 years of PCs. Why is a Yelp review a bunch of prose? Because it's a keyboard, right. It's comfortable to sit there and type on a big monitor and sort of interact like that. And on a big monitor, you can kind of read and take these things in. Those constraints and those opportunities don't exist in mobile. And four years after Yelp continuously got asked to add reviews, add reviews, add reviews, and 59% of their traffic is now on mobile. 40% of their ads are served on mobile. They finally released the feature that says, you can now add a review. But of course, to ensure their high quality, we might remove any that are too short. Takes big changes to go small. What you understand about the value of your business and how it works, I think, actually is up for negotiation, if you will. That's the whole-- yeah, we've got some things to learn about how to optimize those forms for mobile and take an input. That's an important part of it, but there's a whole lot more to unlearn.
To go back to where I've been up to for the past X number of years-- so I did a great run at eBay and Yahoo. And then this plateau kind of happened. And coincidentally, it was around that time that I left Yahoo and ventured into the startup world. So around 2009, we started a company called Bagcheck. We sold it to Twitter back in 2011. But it was a very different world than working at the big organizations I had worked in before. And the real big reason why startups are so different than large companies is, because when you are start up, you have to learn everything. You have to learn everything.
You don't know who your customers are. You don't know what product you're going to build. You don't know how it's going to work. You don't know what the interaction design is going to be. You don't even know what the back end is going to be. Literally everything has to be learned, because you're starting from scratch. You have to learn how to hire people. You have to learn how to pay them. You have to learn everything.
Big organizations that have been around for a while have probably learned too much and have a real hard time unlearning things. But when you're a startup, you have to learn everything. So when you're in a startup, arguably, the most important criteria in a startup is the ability to learn quickly. You have so much to learn that you need to figure out how to do it as fast and effectively as possible.
So my time and startups really keyed me into-- and I've been doing startups now since 2009. But it's really keyed me into this notion of, how can we learn fast. And I think these are relevant points to what we're talking about right now, because mobile has only been around for so long and because change is so rapid. And I think this is also why a lot of big organizations are so interested in startup culture. Does anybody work at a company that's like, we act like a startup. We have startup culture.
All of them are super fascinated with things like Agile and Lean UX and Lean Company, and all these things, because they were want to infuse this ability to move more quickly. And I think that moving quickly doesn't matter, unless you're learning.
I can run really fast into a wall, and I just keep repeating that. It doesn't do me any good. And I can get faster and faster at hitting that wall. And arguably, it's going to be actually worse for me, the faster I get. So it's not about moving fast. It's about learning fast. And the way I could sort of encapsulate this into a big picture thing-- and then I'll show you guys some practical tips. And then I'll let you digest them. Big picture, this means put stuff out there. You can't learn, unless you do something. Unless you release something, unless you try something, there's no opportunity for learning. So you've got to get good at releasing things. When you release it, observe what's happening. This is going back to the hamburger icon and all the things I've been talking about. Actually see what people are doing and refine it. Chances are, you released kind of quickly. You didn't really know everything. So if you just leave it there, you're not going to have that opportunity to iterate and learn. And the third one is just keep doing it, keep repeating it. One of the most challenging things I see this in large companies that want to be startup-like is, they release and walk away. That release is done-- on to the next release.
So it's got to be this loop. Put stuff out, iterate, observe it, repeat, and keep going. And so what are some ways to do this? So one of the things that we did over at Bagcheck back in the day was, we started with an API. And an API is something that allows us to be very presentation independent. So if we have to do three native apps or a website or we have to put something on a watch, we have the core essence of the application available to all those different front ends. Another thing that starting with this API allows you to do is think in terms of what does it have in it. And what do those things do, as sort of the structural layer? What are the core actions? What's the core content, and how are those things interrelated? That's a fundamental understanding of your service that will help you for every single UI you ever build. And the first UI we put on top of this API was actually a command line interface. There was no graphical user interface whatsoever. We literally spent two months or so just doing everything by command line. And this was a service for creating lists of things. So you could fire up the command line and say, hey, open this app. And it would tell you all the things that it can do. And then we would say, OK, show me a bag, which is what we called a list. Here's all the things that you can get out of a bag. And you'd say, OK, I want to add an item to this list. OK, what item do you want to add? I want to add some toast to it or whatever.
But all the actions, all the attributes, all the objects were all clearly visible and in this resolution-independent interface. And not only does that allow you to be very nimble on where you put that stuff. But I think it forces you to make these core decisions around the basics of things, which again lets you go faster. Then once we had this sort of core API layer, another thing that we did was, we really tried to separate the front end from the back end. If anybody has ever gotten in this situation where there's this muddled code in the middle that does some of your logic, it just turns into a big mess. But if use something like a Mustache-- I think actually Brad Frost talked about mustache, when he talked about atomic design. What you can really do is just throw a couple of variables in here. And this code, you can use it to render data on your local machine. Or me as a designer, I can just push this file up to the server. And then the server will fill in that exact same data. So I never step on the toes of my engineering counterparts. I push the file. They fill it, and it's just seamless. It works really, really well. Another thing that we did was, we had this real-time observation system, where at any point in time, we could go see who was on our site. And we could see every single action that they were doing, so clicked, clicked, clicked, clicked, clicked, clicked, clicked; oh look, went off the site for a minute; came back; clicked, clicked, clicked, ran a search. That's the term he used. And you could just stare at this thing all the time, seeing everything people were doing in real time. The other very cool thing was, you could click on any one of those links and go and see your service as that person. So if you were logged in, it would look like this to you. If you were logged in as that person, it would look like this to you. And you notice this garish admin background back there? Very, very quickly, I had to add this horrendous background layer, because people got confused who they were in the application. So we didn't want to go doing anything incorrect while we did that. So there's something really powerful about at any point in time seeing what's happening on your service and being able to view your service as any user on your service. It creates a huge amount of insights. It allowed us to do this thing that I call preemptive customer service.
So preemptive customer service means we're watching this admin system. We're like, what's this guy doing. It looks like he's having an error. Oh, we've got a bug. Let's fix that real quick and then email them or Tweet them and say, hey, we saw you had a bug. Really sorry, we just fixed it. And sometimes I get this comment like, oh, that's sort of creepy. I've never had anybody reply and be like, you creep. Instead everybody was like, oh, my god. You what? I had a bug. You fixed it before I could even tell you about it. That's amazing.
They love this experience. It shows you somebody cares. And I practice this to this day. I will go and do things for people that they don't even know they need done. And again, to this day, I've never heard anybody say, you creep. Instead, they're very, very, very grateful that somebody cares enough to actually fix things for them before they know they need fixing. So this idea of preemptive customer service is also a great way of learning fast. So it's not just being able to build quickly, which is what those logic list templates and APIs did. But it's also the opportunity to learn quickly-- see in real time what people are doing, view your services as them, and then actually start to talk to them. Kicking off those conversations is a great thing. One of the mistakes I realized literally this morning that I made in our current startup was, I made the Contact Us link way too small. And sitting in the back, during a talk, I was literally making a giant Contact Us label that I'm going to shove on every single page of the site, because talking to people is that important for learning.
So given we've had this much time, hopefully, this idea of getting better at learning is something that resonates. And again, I do feel like that's where one of the things that's hopefully driving all this-- we need to startup DNA. We want to function like a startup in organizations.
So to summarize all this stuff. And I think we'll have about five minutes for questions, which is great. This growth in mobile is a huge opportunity. Whether it's audience size, whether it's revenue, whether it's things like email or commerce, we've been hitting the mobile moment left and right. So with that comes this great new series of audiences that we can now reach with our services, with our applications, with our products, what have you. With that though come some challenges. All right, it's not just figuring out all this new stuff. It's actually figuring out, what do we let go of. How do we do adapt? And as I've said before, these aren't small adjustments. Many times, they're actually big changes that you need to push through an organization. I like to say, if people are like, OK, that sounds fine. Then you're probably not going far enough. If your suggestions for mobile are making people uncomfortable and they're feeling like, whoa, then maybe you're going the appropriate degree far enough. Again, consider the difference between and Hotel Tonight or the way Hotel Tonight approaches reviews, compared to Yelp. And then last but not least, this notion of releasing, refining, and repeating-- it doesn't seem to me in any way, shape, or form that the rate of change is going to slow down. If you think innovation and the rate at which new devices, new services, and this stuff is all of the sudden just going to lull out, I hate to break it to you. But it's probably going to get even crazier.
So this change is going to. And it's going to continue getting faster. And as a result, this idea of getting stuff out there, seeing what happens, and making that your mindset versus monolithic releases will really help you adapt to that world. So that's what I had to talk to you guys about. Thanks. [APPLAUSE]
We've got time for a questions, I think, five minutes. Anybody have a question? Otherwise, we can dispense with the formalities.
OK, we'll dispense with the formalities. Come talk to up here if you have a personal question. Thanks.