Journal tags: lukew

It’s the afternoon of day two of An Event Apart in Seattle. The mighty green one, Luke Wroblewski, is here to deliver a talk called Mobile Planet:

With 3.5 billion active smartphones on Earth, we’re now faced with the challenges and opportunities of designing planet-scale software. Through a data-informed, big-picture walk-through of our mobile planet, Luke will dig into how people use computing devices today and how the design of our products needs to adapt to this reality. He’ll cover key issues like app on-boarding and performance in enough detail to give you clear ways to improve first time and subsequent use of your mobile apps and sites.

Luke has been working on figuring out hardware and software for years. He looks at a lot of data. The more we understand how people use technology in their daily lives, the better we can design for them.

Earth is the third planet from the sun, and the only place that we know of that harbours life. Our population is at about 7.7 billion people. There are about 5.6 billion people in our addressable market (people over 14 years old). There are already 5 billion mobile subscribers in there. That’s interesting, but which of those devices are modern smartphones? There are about 3.6 billion active smartphones. Compare that to about 1.3 billion active personal computers—the vast majority of them Windows devices (about 1.2 billion). Over the next four or five years, we’ll have about 5 billion smartphone users and a global population of 8 billion.

The point is that we can reach a significant proportion of the human species. The diversity of our species makes it challenging to design for everyone.

Let’s take a closer look at these 3.6 billion active smartphones. About 25% of them are iOS devices. 75% of them are Android. Bear in mind that these are active devices—what’s actually being used. That’s different to shipping devices. Apple ships 15% of smartphone, and Android ships 85%, but the iOS devices tend to have longer lifespans (around 2 years for Android; around 4 years for iOS).

The UK has 82% smartphone penetration. Compare that to India, where it’s 27%. There’s room to grow.

Everywhere you look, the growth of these devices has led to a shift of digital things overtaking analogue. Shopping, advertising, music, you name it. We’ve seen enough of these transitions happen, that we should be prepared for it.

So there are lots of smartphones, with basically two major operating systems. But how are people using these devices?

In the US, adults spend about 2.3 - 3.5 hours per day on their mobile devices. Let’s call it an even 3 hours. That’s a lot of time. Where does that time come from? Interestingly, as time spent on mobile devices has surged, time spent on other media has only slowly declined. So mobile is additive. It’s contributing to more time spent on the internet rather than taking it away from existing screen time.

Next question: what the hell are people doing during those 3 hours per day on smartphones? Native apps get about 169 minutes of time compared to only 11 minutes on the web. There are about 2 million native apps on Apple, and about 2 million native apps on Android. But although people have a lot of apps, people only use about half them. Remember folks, downloads does not equal usage. Most apps don’t make it past the first opening. Only a third make it past being opened ten times.

Because people spend so much time and energy on these apps, and given the abysmal abandonment, people start freaking out about “engagement.” So what do they reach for? Push notifications. Either that or onboarding.

Push notifications. The worst. I mean, they do succeed in getting your attention: push notifications do increase the amount of time spent in your app …but there’s a human cost.

Let’s look at app onboarding. Take Flickr, for example. It walks through some of the features and benefits of the service. But it doesn’t actually help you much. It’s a list of marketing slogans. So why do people reach for onboarding?

If you just drop people into an interface and talk to them about it, they’ll say things like “I don’t know what to do. I’m lost.” The Intuit team heard this from people using their app. They reached for onboarding to solve the problem. They created guided tutorials and intro tours. Turns out that nobody would read these screens and everyone would try to skip them. What the hell, people!?

So they try in-context help, with a cute cartoon robot to explain the features. Or they scribble Einstein’s equations over the interface. Test this. People respond with “Please make it stop.”

They decided to try something simpler: one tip that calls out a good first step. That worked.

Vevo used to have an intro tour. Most people were swiping through without reading. They experimented with not running the tour. They got a 10% increase in log-ins and a 6% increase in sign-ups.

Vevo got rid of their tour, but left the sign-in/registration step. You can’t remove that, right?

Well, Hotel Tonight experimented with not doing registration. Signing up was confusing people—it’s Hotels Tonight, not Accounts Today. When they got rid of accounts, they saw a 15% increase in conversions.

Ruthlessly edit.

Google Photos used to have an in-depth on-boarding experience. First they got rid of the animation. Then the start-up screen. Then the animated tutorial. Each time they removed something, conversion went up. All that was left from the original onboarding was a half screen with one option to turn on auto-backup.

Get to your product value as fast as possible. Of course that requires you to know what your core value is. And that’s not easy to figure out.

Google Maps went through a similar reduction, removing intro screens and explanations. Now they just drop you into the map.

It’s not “get rid of everything”. It’s “get rid of everything that gets in the way of the core user action.”

Going back to the Intuit example, that’s exactly what they did in the end. That one initial tip was for the core action.

But it’s worth discussing how to present this kind of thing. If you have to overlay a tooltip for an important UI feature, maybe that UI feature should have a clearer affordance. People treat overlays as annoyances. People ignore or dismiss overlays when they’re focused on a task. It’s like an instinct to get rid of them. So if you put something useful or valuable there, it’s gone.

The core part of your application should feel like the core part of your application. It’s tough because stakeholders want to make things “pop.” We throw contrast, colour, and animation at things. But when something sticks out from the UI, people ignore it. Integrate the core action into the product UI. When elements feel foreign to a product UI, they are at best ignored, or at worst dismissed.

These is why cohesive design matters. It’s not about consistency. It’s about feeling integrated. In many cases, consistency can be counter-productive.

Some principles for successful onboarding:

1. Get to to the product value as fast as possible. Grubhub needs your address. Pinterest needs your interests.
2. Get rid of everything that doesn’t lead to that product value. Ruthlessly edit. Remove all friction that distracts the user from experiencing product value.
3. Don’t be afraid to educate contextually. But do so with integrated UI.

Luke talked a lot about what’s happening in mobile apps, and mentioned that the mobile web only gets 11 minutes to the native’s 169. But let’s dive into this, because people sometimes think that a “mobile strategy” comes down to picking between these two. 50% of those 169 minutes are spent in your most used app (Facebook). 78% of the time is spent in the top 5 apps. Now the mobile web doesn’t look so bad. It turns out you can get people to a mobile web experience much, much faster than to a native one. The audience size is much, much, much higher on the web (although people will do more in a dedicated native app). So strategically both are useful—the web can attract people to native.

Back to our planet, and those 3 hours of usage on smartphones every day. People unlock their phones around 80 times a day. The average time people sleep is about 8 hours. So for every 12 waking minutes, you’re unlocking your phone. Given this frequency, it’s unsurprising that most sessions are very short—most under 30 seconds.

Given that, if things are slow, you’re going to really, really, really hate it. Waiting for slow pages to load is what really pisses people off.

The cognitive load and stress of waiting for slow pages is worse than waiting in line in a store, or watching a horror movie. That’s an industry that’s all about stressing people out by design! But experiencing mobile delays is more stressful! Probably because people aren’t watching horror movies every 12 minutes.

Because mobile delays are such a big deal, many mobile apps reach for loading spinners. But Luke saw that adding a spinner to his product increased complaints of slow loading times. Of course! The spinner is explicitly telling people, “Hey, we’re slow.”

So the switched to skeleton screens. This should feel like something is always happening. Focus on the progress, not the progress indicator. Occupied time feels shorter than unoccupied time.

A lot of people have implemented skeleton screen, but without the progressive loading. Swapping out a skeleton screen to a completely different UI all at once doesn’t help. The skeleton screens should represent the real content.

This is a lot of work; figuring how to prioritise what to load first. Luke isn’t talking about the techical side here, but the user’s experience. Investing in getting this right makes a lot of sense.

Let’s look a little closer at this number: people interacting with their phones 80 times a day. The average user touches the device 2,617 times a day. A power user touches the device over 5,000 times a day. Most touches are within one app.

90% of the touches are dealing with one thumb. Young people tend to operate with one hand. For older people, it’s more like 60%.

This is why your interface targets need to work for the thumb.

On phones, 90% of the time you’re dealing with portrait mode. Things at the top of the screen on larger devices are hard to reach. Core actions gravitate to the bottom of the screen.

Opera Touch is a new browser designed specifically for one-handed use. The Palm Pre’s WebOS was also about one-hand usage. Now that’s how iOS and Android work: swiping up from the bottom.

So mobile usage is:

• One-handed/thumb.
• In portrait mode on large screens.
• Design accordingly.

What’s next? What do we need to be aware of so we don’t get caught with our pants down?

We can use the product lifecycle chart to figure this out. There’s an emergent phase, then a growth phase, then consolidation in a mature market, and then that gets disrupted and becomes a declining market.

• Mobile devices—hand computers—are in a mature consolidated market.
• Desktop and laptop computers are in a declining market.
• Wrist computers and voice computers are in a growth market.

Small screens get used more frequently, but for shorter periods of time than large screens. Wrist and voice computers are figuring out what their core offerings are.

In the emergent category, it’s all about exploration. We have no idea how things will turn out. We just don’t know. But we do know that we are now designing for lots and lots of different devices.

For today, though, focusing on mobile is still a pretty good idea.

To summarise:

• It’s a mobile planet.
• Understanding real world usage helps you design.
• Prep for what’s next

Luke is at An Event Apart in Atlanta to give his presentation: It’s a Write/Read Mobile Web. He begins by showing us where he lives in Los Gatos in Silicon Valley. Facebook is up the road in Palo Alto. Yahoo is down the road in Sunnyvale, next to a landfill. In between, there’s a little company called AOL. Then there’s Google and YouTube just off Highway One.

So you have a bunch of internet companies in close physical proximity. They are also the top sites in the US when it comes to time spent on the web, by a very wide margin. You would think that the similarities would end there, because they all provide very different services: social networking, email, messaging, search, and video. But they have something in common. They are all write/read experience. They don’t work unless people contribute content to them. You post updates, you send emails, you type in searches, you upload videos.

Tim Berners-Lee said that his original vision for the web was a place where we could all meet and read and write.

This isn’t just a US-centric thing. Looking at the worldwide list of most popular sites, you’ve got the ones mentioned already but also Twitter and Wikipedia, where all the content is contributed by their users. Even Amazon is powered by reviews. This is what makes the web so awesome. It’s not a broadcast medium. It’s a two-way street. It’s interactive.

So what’s the biggest factor that’s changing for all of these sites? Mobile. 67% of Facebook users and 60% of Twitter users are on mobile. If you look at the stats for Facebook, you can see that their growth is coming from mobile. Desktop usage is pretty flat: mobile usage is soaring. Facebook also has a growing segment of mobile-only users. Zuck has defined Facebook now as a mobile company.

When people hear about the growth in mobile, they assume it’s all about content consumption: reading status updates, watching videos, and so on. There’s a myth that small devices are not good for content creation. But if that were true, then wouldn’t that be a huge problem, given the statistics for growth? Facebook and Twitter would have almost no content. But it’s simply not true. Three hours worth of video are uploaded to YouTube every second from mobile devices.

People think that mobile devices are for games, social networking, and entertainment. And it’s true that those are popular activities. But that kind of usage is actually going down. Where is that time going? The fastest growing category is utilities: finding and buying things, financial management, health services, travel planning, etc. Basically, mobile is anything. So if mobile hasn’t effected you yet, it will.

How do we think about this write/read experience? We imagine that 100% of people are consumers: reading, browsing, etc. Then 10% are curators: liking, faving, etc. Finally there’s the 1% that actually create stuff. 1.8% of users provide almost all of Wikipedia’s content. So we naturally focus on the content consumption in our designs, because that’s the biggest number. But Luke thinks it makes sense to flip that on its head. That 1% are your most important users.

Facebook redesigned their content creation flow multiple times, trying to make that “write” experience as good as possible. Same with YouTube’s uploading interface. They both focused relentlessly on the content creation.

So as we shift our attention to mobile, we should be asking: how do we design for mobile creation?

1. One-handed use

Like Luke’s old adage about “one thumb, one eyeball”, this is literally about testing content creation with one thumb. For his startup, Polar, Luke tested the interface with one thumb and timed how long it took. It was tested and designed for a thumb.

“But Luke”, you cry, “Not everyone just uses their thumb on their mobile device screens!” Well, observing 1,333 people using mobiles on the street showed that they pretty much do.

Dan Formosa says we should design for extremes. In Objectified he talked about designing garden shears for someone with arthritis. If it works for that user, it will work well for everyone.

“But Luke”, you cry, “Aren’t you falling prey to the myth of the ‘mobile context’ where the user is in a hurry, using just one hand?” Well, it is true that lots of people use their devices in the home. But even when you’re not out on the street, you’re still using your thumb: using your phone while watching TV.

Focusing on this use case means you can rethink a lot of interactions. As a general principle, Luke advises “don’t let the keyboard come up.” That is, only provide a virtual keyboard as a last resort. Use smart defaults. Let people tap on links or checkboxes instead of typing. If the user needs to enter a location, they could do so by tapping on a map instead of typing in a place name. Provide a date-picker instead of making people type out dates. Let people use sliders for setting values.

When you design for one-handed use, you’re designing for an extreme case. It also forces you to challenge your assumptions.

2. Visually engaging

When you aim to avoid the keyboard, you often come up with more visual solutions, which can be a great opportunity.

Take Snapchat. People express themselves through photos. The Line app is chat, but with a huge amount of emoticons. Chat becomes visual.

The lesson here is not that society is collapsing into sexting, but that images are very powerful on mobile.

Hotel Tonight’s mobile experience is based around big beautiful images.

“But Luke”, you cry “Why are you advocating big images? Isn’t performance the most important thing on mobile?” Well, yes. But instead of just abandoning images, let’s get really creative about how we serve up images. Take, for example, the experimentation around increasing image dimensions while reducing quality, which results in much smaller files with no noticable loss of fidelity.

3. Focused flows

Dwelling on one-handed use and visually engaging imagery are techniques you can use, but you should really focus on simplifying the processes you put people through. Foursquare have drastically simplified their check-in process.

Creativity is all about focusing on something until you find the simplest way to do it.

The Boingo wireless service used to require 23 inputs. They got rid of 11 of them and increased conversion by 34%. That’s great, but they didn’t go far enough. You can always simplify even more.

Hotel Tonight got their flow down to three taps and a swipe. The CEO says that’s a competitive advantage. Just compare how long it takes to book a hotel with their competitors.

It takes big changes to go small.

When taking about forms and input, this might seem like standard design advice: focus and simplify. But keep focusing and simplifying even more.

4. Just-in-time actions

So we’ve seen three different ways to make things simpler, faster, and more focused. But isn’t that really hard on a small screen, with so little real estate?

Instead of providing intro tours (which are more like intro tests), why not provide introductory information only when it’s needed? Apply the same approach to actions. On Polar, there’s an option to hide the keyboard, but that action is only visible when the keyboard appears.

On long pages on Polar, people wanted a way to get back to the top. If you start scrolling upwards, the navbar from the top is overlaid. It detects that you might be trying to get back to the top, and provides the actions you want.

5. Cross-device usage

Everything Luke has talked about so far has been specifically focused on one kind of device: mobile. But we need to keep our eyes on the multi-device write/read web that is emerging. Creation is happening across devices …sequentially and simultaneously.

The simplest example is access. If you’re on a desktop browsing Luke’s site on Chrome, and then you move to Chrome on the iPhone, there’s Luke’s site.

The next cross-device pattern is flow. We want our processes to work across devices. So if I’m on my laptop and I do a search, then I pick up my phone, I want that last input to carry over. On Ebay, you can save a draft listing on the desktop and pick it up later on mobile. On Google Drive, editing is synced simultaneously between all your devices.

Control is another pattern: using one device to tell another device what to do.

Luke hates log-in forms; that’s no secret. Five years ago, he worked on Yahoo Projector which used a scanned barcode to take control of a TV screen with a phone. He wanted to use this to replace log in, but that never happened. But there’s a service called OneID which is tackling the same use case: you can control log-in across devices.

The last example of cross-device usage is push. Going back to that draft listing on Ebay: take a picture on your phone and have that picture show up on the desktop browser view.

People talk about mobile versus desktop, but these are all examples of these different devices working together.

This was just a taster. We’re just getting started with this stuff.

Next up at An Event Apart in Boston is Luke Wroblewski. Let’s see if I can liveblog just some his awesomeness.

Luke begins with some audience interactivity. We’ve all got to stand up. Now we learn a few small moves. Put them all together and what have you got? The Thriller dance!

There’s a point to this: his talk is called Mobile Web Design Moves. Small moves can add up to very big things.

But why learn new moves? Well, Mobile changes things:

• Mobile web growth and
• Mobile is different.

Mobile web growth

A few years ago, Morgan Stanley published a report in which they predicted that somewhere in 2012 more mobile devices would be shipped than PCs. Well, it happened two years earlier than predicted. As Eric Schmitt has said, everything to do with mobile happens faster. There’s been a 20% drop in PC usage, with the slack taken up by tablets and smartphones. But as Luke points out, the term PC—Personal Computer—is actually better suited to a mobile device; the device you have with you on your person. The way we interact online, email, etc., is shifting to mobile devices.

But is all this usage happening in native apps? No, as it turns out. 40% of Twitter’s traffic comes from mobile, of which 78% is from the mobile website. Mobile browser users increased over 300%. What people forget is that growth of native apps also drives growth of mobile web use.

In a nutshell, more people are going to be accessing your websites with a mobile device than with a desktop device. Find one study of mobile usage that doesn’t show exponential growth.

Even if you have native apps, like Gowalla with a client for iOS, Android, Blackbery, etc., people will still post links in your native app and where does that take you? To a browser.

Anyway, it doesn’t have to be either a native app or a mobile web site. You can hedge your bets and do both …so you’re protected if Steve Jobs pulls the rug out from under you.

Mobile is different

When you’re sitting at a computer at home, you’re sitting comfortably with a keyboard, mouse, chair and coffee mug. The mobile experience involves a small screen, short battery life, an inconsistent network, fingers and sensors. This tactile experience makes it intensely personal.

Where do people use these devices? There’s the sterotypical picture of the businessman on the move, walking down the street. But 84% of mobile usage happens at home; watching TV, for example. 74% of people use them standing in line. People use them in the toilet.

What about when people use these devices? All throughout the day, as it happens. That’s quite different to desktop use. iPad users do a lot of reading on the couch in the evening and in bed at night.

Mobile devices have different technical capabilities and limitations and there are also some distinct times and behaviours associated with their usage.

By now you should be convinced: I need new moves!

Organise yourself

Try to understand why someone would pull out their mobile device. What is that device good at? Try to marry that up with your content. Luke breaks down mobile behaviours into these categories:

• Lookup/Find — usually location-related.
• Explore/Play — often related to reading.
• Check in/Status
• Edit/Create — email, for example.

Think about organising your structure to fit these tasks. Luke shows a college site that prioritises campus information less than marketing fluff. But you know, this isn’t just about mobile users. That useful information—like a campus map—is useful for everyone, regardless of their device. So if you go through this process of prioritising for mobile, you will also be prioritising for desktop.

Mobile forces you to prioritise. Screen space is tight. Attention is short. Apply the same prioritisation to desktop users.

Here’s a good rule of thumb: content first, navigation second. Give people what they’re looking for first.

Don’t try to port all of your content to mobile. Instead use this as an opportunity to prune your content and get rid of the crap that people aren’t interested in.

What people want to do on mobile is the same as what people want to do on the desktop. For some reason, Yelp only allowed mobile users to point “mini” reviews …at the very time when people are in the place they are reviewing!

Don’t dumb it down for mobile.

Use your head

Content first, navigation second; yes, but navigation is still important. Facebook’s mobile version originally had 13 navigation elements, which is a bit much. YouTube puts the navigation on a different screen. The pro is that this saves screen estate. The con is that you lose context. ESPN’s mobile site has a navigation that you pull down. There’s also navigation at the end of the page. That’s better than what YouTube does: when you get to the end of the page on YouTube, it’s a dead end. One of the challenges with the ESPN site is that the navigation is duplicated (the pull-down nav and the footer nav). A potential solution is to have that nav link at the top point to the navigation at the bottom of the page.

What about fixed position menus? The iPhone has permanent software buttons on screen in the browser, right? But to do fixed positioning on mobile you have to use some hacky JavScript. And even if you get it working, it’s eating up valuable screen real estate. On the Android device, there’s the problem of the proximity to hardware buttons: people will accidentally mis-tap the hardware controls trying to use on-screen navigation anchored to the bottom of the screen.

So don’t just slavishly copy iOS conventions. Don’t put a back button in your site. It makes sense in an app but on a website, the browser provides a back button already.

Take it in

Input is interesting topic on mobile. The traditional advice is to avoid text input on mobile ….and yet billions of text messages are sent every day. So let’s reverse the traditional advice. Let’s encourage people to input on mobile.

The workhorses of input on the web have been checkboxes, radio buttons, drop-down lists, etc. Using these standards on mobile means you can type into the device interface features, like the select UI on the iPhone. But the constraints of the smaller screen on a mobile device introduces some challenges even if you use these standard controls. If you make your own interface elements, you can given them touch target sizes.

The stuff that we have to programme for ourselves today will become standard declarative features in the future. That’s already happening with HTML5 input types like date. But even small things can make a big difference. Use input types like url, number, email, etc. to get an appropriate on-screen keyboard on iOS. Make use of new input types and attributes. Every little bit helps.

Input masks—confining what’s allowed in a form field—can be very useful on mobile devices. Right now we have to do it programmatically but again, it should become declarative in the future.

Avoid the gradual reveal, where you format as people are typing but in a different format to what the placeholder text displayed. Beware with placeholder text: people can interpret it as the form field already being filled in. Phrase them as questions if you can.

There’s a lot of really exciting things happening on the input side of things with mobile devices. More and more device APIs and sensors are being exposed.

Ask for it

Input is the way we gather answers from people but we also have to think about how we ask the questions.

Many mobile browsers try to optimise desktop-specific sites to help mobile users by using zoom. In that situation, right-aligned form field labels are problematic: when you zoom in on the form field, you can’t see the label. Top-aligned labels work better …and there are many other advantages to top-aligned labels that Luke has talked about in the past.

Some people are trying to use placeholder text as labels. But the problem there is that as soon as you tap in there, it disappears. Again, watch out when putting labels within input fields: it’s not clear if the form field is already filled in or not.

Make your moves

Here’s an opportunity. Mobile is growing so quickly and it’s all new. Now is our chance to come up with new innovative stuff. This stuff hasn’t been figured out yet. More and more devices are coming online every day and they’ve all got web browsers.

We can push towards natural user interfaces where the content is the user interface. Minor rant: our design processes are more about designing navigation instead of focusing on the content and designing that. It’s a challenge. As Josh Clark put it:

Buttons are a hack.

So make your own moves. Yes, it’s a scary time; there’s so much to learn about, but also also a huge opportunity.

Keep an eye out for Luke’s book from A Book Apart called Mobile First coming out in Summer 2011.