Everyone from users to entrepreneurs to advertisers loves the "mobile" category because those products are always with us, always on, and instantly accessible. But these opportunities are also design constraints: Mobile screens are small, driven by touch, and often connected to spotty networks. Which is why companies like Facebook, Google, PayPal, and countless startups taking the plunge into mobile-first design quickly realize that designing for mobile is not the same as designing for the desktop PC.

Our PC-driven instincts are often very wrong for mobile. Yet they’re so deeply ingrained, we apply them anyway.

That's why I want to share these common mistakes. I hope designers, product managers, and entrepreneurs can learn something from them – not just about how to design for mobile, but about how to think differently about mobile design. I've included behind-the-scenes examples from my company’s app, since most users and even business leaders are not deeply involved in the design process; they only see the outcomes.

On Mobile, Sometimes You Have to Fake It 'Til You Make It ———————————————————

It’s no secret that mobile networks can be much slower than those connected to PCs, and nothing frustrates mobile users more than a long load time. As Instagram co-founder Mike Krieger put it, “Who wants to wait while they’re waiting?”

Yet that’s exactly what many mobile apps make users do while waiting for confirmation that their actions have taken place. This type of PC-inherited process typically goes something like this:

A user does something in the app.

The app sends a message to a server telling it what happened.

That server responds that it got the message and took the appropriate action.

The app then updates letting the user know their action was successful.

...That’s a lot of waiting around.

Contrast this standard approach to the one employed by Instagram’s mobile app: When people like or comment on a photo on Instagram, the results of their actions show up right away. In reality, their request is still getting processed in the background – but Instagram *assumes *it was successful rather than waiting to find out if it actually is.

While designers can’t speed up the network, they can provide users with the sense that response times are faster than they actually are. This flips the previous PC paradigm around.

Instagram’s technique here helped us with an early mistake we made on our mobile app, Polar, which allows people to collect, share, and vote on opinion polls. When someone makes a poll on Polar, uploading any images they choose to include takes an average of 12 seconds.

#### Luke Wroblewski ##### About [Luke Wroblewski](http://www.lukew.com/) is CEO and co-founder of Input Factory Inc. Prior to that, he was co-founder and Chief Product Officer of Bagcheck, acquired by Twitter. Wroblewski has been an EIR at Benchmark Capital; Chief Design Architect (VP) at Yahoo!; Lead User Interface Designer at eBay; and Senior Interface Designer at NCSA (birthplace of the Mosaic browser). A co-founder and former board member of the Interaction Design Association, Wroblewski's books include [*Mobile First*](http://www.abookapart.com/products/mobile-first).

In our first release, we waited until those images made it to our server before displaying the finished poll in the app. In the current version of Polar we do the opposite: We assume that any polls a user creates will make it to our server. As soon as they create a new poll, it shows up in their feed.

In reality, we’ve created a temporary local copy of the poll and added it to the front of the list. This temporary version of a poll is fully functional: That is, users can vote and comment on it and we’ll make sure their actions get applied to the actual poll once it is live. (To ensure the poll does go live, we use multiple background processes to hold on to it locally and resend it to the server several times before ultimately telling the user something went wrong.)

Sound like a lot of extra effort? It is. But the end result is worth it if something seems instantaneous. In this case, the perception of being fast beats the mobile-network reality of being slow.

Indicating Progress On Mobile Can Slow Things Down ————————————————–

Clearly, great mobile experiences are about speed. Because mobile networks can take a while to respond, it’s common for mobile applications to bring up progress bars or spinners when something is happening or loading because conventional, PC-influenced, user experience design wisdom tells us that we should let users know when things are going to take a while.

Even though the intentions behind such indicators are good, the end result can actually turn out to be bad for users. Why? Because progress indicators, by definition, call attention to the fact that someone needs to wait. It’s like watching the clock or an elevator button panel: time seems to go slower.

Ironically, most indicators make users focus on the indicator itself – not the actual progress. This needs to be flipped to make it clear users are advancing toward their goal instead of just waiting around.

We learned this lesson the hard way on Polar when we experimented with using “web views” to load parts of our native application’s interface. (Web views are like little embedded web browsers that can fetch pages from a server and present them within an app, but only after they are loaded.) To let people know these elements were downloading, we had added a spinner that showed up as each web view – and we used several in our app – was retrieved from our server. But then we started getting feedback like: “There seems to be an excessive amount of waiting around for pages to refresh and load; it doesn't seem as quick as the previous version.”

With the introduction of progress indicators, we had made people watch the clock: Time went slower and so did our app. We focused them on the indicator and not on the progress.

Google’s Search application takes care of this problem by making the webpages users have requested slide in from the side. This design puts the focus on progress by making the loading indicator part of the transition that brings up the requested page, making it feel like content is loading immediately, even when it isn’t:

Another way to focus on progress instead of wait times is with "skeleton screens" – a blank version of a page into which information is gradually loaded. This creates the sense that things are happening immediately as information is incrementally displayed on the screen:

We used this technique in several places on our app to effectively eliminate all spinners. The focus then shifts to the content being loaded – not the fact that it’s ... ... ... loading.

Don’t Divert the Mobile Attention Train —————————————

On the desktop, adding more links, menus, and buttons for people to interact with comes naturally. Mobile, however, forces us to reconsider this approach. Gone are big screens that can display lots of user interface controls and the precise mouse-controlled cursors that allow people to use them. In their place are small, palm-sized screens and bulky fingers for input.

We can no longer just worry about how to fit more controls on a small screen. Now, we have to focus on where the action is – on people’s primary flow through an app.

Think of that flow as a speeding freight train. Outside of Hollywood blockbusters, getting in the way of a train usually doesn’t end well. It takes a lot of effort to shift the course of something with that much momentum. So instead of trying to divert people’s attention from their primary task, mobile designers should just hop on board and use the train’s momentum towards their – and their users’ – goals.

On our app, the “freight train” is the screen where people vote on polls, because it’s where people spend the most time in the app (where we see over 40 votes per user per day). We knew this experience could be even better if the list contained polls from people the users know. So we added a prominent action in the header that allowed them to find their friends on Polar.

But very few people did. As it turned out, we were trying to divert the train by requiring people to go to a different part of the application to do things like find and invite friends.

Now, when users are immersed in voting, the 20th poll we show them asks “Would you like to find your friends on Polar?” When we made this change (and removed the Find Friends button in the header), use of the Find Friends feature shot up dramatically.

Since then, we’ve redesigned a number of other features this way including setting preferences, requests to rate the app, and more. Treating desired actions (in our case, voting on polls) as part of the main activity of our app – instead of as separate interface elements – makes a huge difference in their use.

***

Following PC conventions in the design of Polar led us astray, to a mobile experience that:

waited for replies from the server instead of assuming actions were successful and instant;

focused on indicators and not progress when things were going to take a while; and

added more interface controls instead of integrating key actions in primary flows.

To avoid these and other mobile mistakes, we all need to take a critical look at our existing best practices so we don’t try to squeeze the PC world onto mobile – but instead fit just right on mobile.

It's more than just avoiding mistakes, however. Designing mobile first is about exploring, sharing, and embracing new ways of doing things. It's an exciting time in design.

Wired Opinion Editor: Sonal Chokshi @smc90