Not Your Parent’s Mobile Phone: UX Design Guidelines For Smartphones

About The Author

More about Tim ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

The way mobile devices are being used is changing all the time, and users are increasingly expecting exceptional experiences from the applications they use. In this post, Tim R. Todish brings us guidelines to help you create a great experience in your mobile application.

In your pocket right now is the most powerful “remote control” (as Drew Diskin put it) that has ever existed. It is no ordinary remote control. It can harness everything that all of the previous mass media (television, radio, Internet, etc.) can do. People aren’t using them just for simple entertainment or for phone calls. They have become the hub of our personal lives.

Smartphones are what younger generations know as just phones. The iPad (aka the tablet) is giving your grandma’s PC a run for its money. You certainly are holding some amazing futuristic technology in your hands. It will be even better tomorrow, though, so why does it matter to us or to users? Moore’s Law tells us, in effect, that these things will continue to become capable of more than anything our minds can think up.

It’s no longer just about the evolving power and capabilities of these devices. It’s about us and how we, too, are changing. The user’s expectation of a great experience is the new standard. It falls to us as UX professionals to apply our skills to make this happen on the vast array of devices out there. It’s not always easy, though. The mobile realm has some unique constraints and offers some interesting opportunities. While covering all of the nuances of mobile UX in one article would be impossible, we’ll cover some fundamentals and concepts that should move you in the right direction with your projects.

Mobile Constraints

The mobile realm has many constraints. Here are several of them, along with thoughts on what to keep in mind as you come upon them.

Form Factor

The most obvious constraint going from desktop to mobile is screen size. Mobile screens are smaller. A lot smaller. You need to seriously consider this when designing and developing your application. Antony Ribot makes a good point in his presentation, “Mobile UX: The Intricacies of Designing For Mobile Devices,” when he says, “Mobile is not about making things smaller.” It’s much more than that. We need to consolidate what’s on the screen. Boil the application down to the most critical functions and content, and then lay them out strategically in the available screen space. For example, action buttons should go in the lower third of the screen, where they are most easily tappable.

Input Methods

Another obvious constraint is the absence of or difference in certain input mechanisms, and the addition of others. First, there’s no mouse. No mouse means no hover states. It also means that there must be some other means of clicking and navigating content. In most cases, this other means is the user’s finger. This difference in input method can be quite exciting because it opens the door to new possibilities with various gestures. Many standards are forming around these new gesture capabilities: pinch to zoom, swipe to scroll, etc. Take the time to include support for these gestures in your application. In addition, think of new gestures that you could add to enhance interactivity.

Discovering new gestures can be a powerful experience for users. It adds a sense of excitement, mystery and achievement — “Hey, I just figured out something new!” Take care, though, not to change the function of standard gestures unless you have a very good reason to do so, or else you will cause unnecessary confusion and frustration in users.

Gesture Card
Touch Gesture Cards (PDF): Luke Wroblewski.

One other caveat: consider the type of application you’re developing before getting too fancy with gestures. If it will be highly utilitarian in nature, then keeping things simple and straightforward would be best. If the application is for a specific task, then users will want to complete it as quickly and easily as possible. They don’t have the time or desire to discover new interactions.

Technical Constraints

While the capabilities of these devices improve with each new release it, keep in mind their limitations. Things like battery life and processing power are important to consider. Draining the battery or bringing the device to its knees with memory leaks or processor-intensive operations is a surefire way to destroy the user experience. This is why testing on the device early and often is imperative. Simulators cannot be trusted.

Data Transfer and Pricing

This will not be an issue for users who have unlimited data plans or who work on Wi-Fi networks. Unfortunately, unlimited plans are becoming increasingly rare. So, be sensitive to the amount of data you are transferring to and from your application. Keep the sizes of assets to a minimum, while maintaining quality. Don’t transfer data unnecessarily. For example, implement delta updates whenever possible (i.e. update only the data that has changed since the last transfer).

Food Sense - Responsive Web Design
Images: and Food Sense.

Much has been said recently about Responsive Web Design. This approach does create some challenges with minimizing data transfer. Jason Grigsby has a very good write-up on the specifics. To summarize, CSS media queries — part of the magic sauce of responsive design — do almost nothing to lessen the overhead of data transfer to mobile devices. Resizing or hiding unwanted images still requires the full images to be downloaded to the browser. In addition, resources such as JavaScript libraries might be downloaded to mobile devices without even being enabled for users.

Good General Practices

What follows are some good general principles to keep in mind when designing and developing mobile applications.

Mobile First

Luke Wroblewski has a great post on the “Mobile First” methodology. In a nutshell, focusing on mobile first puts your mind in the right place. It forces you to focus on and prioritize the most important features and content in your application. It also extends your abilities by offering new tools and services that are not available in a traditional desktop environment. By approaching your project with the mobile-first mentality, you will start off on the right foot.

Behaviors And Archetypes

Build on the behaviors and archetypes that your users are already accustomed to. This will go a long way to reducing the learning curve of your application. If your application responds predictably to a user’s interaction, then the user will immediately become more comfortable.

This applies to more than general behaviors and archetypes. You will want to use design patterns that are specific to your target devices. This means building multiple interfaces for various devices and platforms, which is extra work; but it will pay off in the long run because users will appreciate that your application behaves in the manner they’ve come to expect from their device. For example, iOS design patterns dictate that tabbed navigation be located at the bottom of the screen, whereas Android devices have it along the top.

As with most good UX principles, if done properly, the user won’t even notice, while their increased comfort level will encourage them to continue exploring the application. Which brings us to our next practice.

Encourage Exploration

The more that users feel comfortable with and enjoy your application, the more likely they will explore it. You may want to lead them down certain paths or provide a few cues or coach marks on how certain things work, but still allow your users to “discover.” I’m not suggesting that you make the application complicated or ambiguous; rather, for example, if there are multiple ways to perform an action, one more obvious and traditional and the other a quick and easy gesture, then the user might come to prefer the second option once they discover it. Such solutions improve the overall experience if they prove to be quicker and more efficient than traditional interactions.

Provide Immediate Feedback

We’ve all witnessed our less computer-savvy peers clicking violently and repeatedly on a button trying to force it to do whatever they so desperately want to achieve. Touchscreens only add to this anxiety because they don’t provide that tactile response that we’ve been conditioned to expect from tapping on a keyboard or clicking with a mouse. Providing some indication that the application has registered the user’s interaction is critical, whether it’s a small bounce at the end of a scrollable region or a subtle color change at the tap of a button. This not only compensates for the lack of tactile response, but assures users that something is happening even if the screen isn’t updating immediately due to slow network traffic or some processor-intensive operation.


Person using a tablet at home
Image: S. Diddy.

Another glaring difference between mobile and desktop applications is context. With a desktop application, you can be relatively certain that it is being used in a particular environment. With mobile, all bets are off. This gives us some exciting opportunities: location-based services, on-the-spot social networking, the opportunities are vast.

It also raises some unique problems. Do your research to determine the context in which the majority of people will be using your application.

If you’re targeting on-the-go users, then you’ll want to build the application for speed: bold, obvious, stripped-down selectors and a streamlined workflow. If your application is more akin to a breakfast-table browser, then content will probably be more important to the user, but they may have only one hand free to navigate, while the other cradles their morning coffee. These are just two examples; the point is that your mobile application could be used in any number of contexts, and you will need to take the time to figure out how to provide the best experience to the user in their context.

One other thing to consider is the device(s) that you are targeting. Research suggests that a majority of tablet owners use their device mostly at home. Only 21% take their device with them on the go, compared to 59% of smartphone users who consult their device while out and about.

Ideate In The Wild

Crowd of people
Image: Niall Kennedy.

I’m borrowing this one directly from Rachel Hinman because she is spot on. The best way to determine context and to conduct research is to immerse yourself in the environments in which your application will be used.

Hang out where your target audience hangs out. If possible, do the things they do, go where they go. This will serve a couple purposes. First, it could give you ideas for great applications to build. Maybe you’ll observe common pain points and come up with a solution to alleviate them. Or, if you already have an idea for an application, you could gain valuable insight into how the application might be (or is being) used in the wild. We’d be surprised quite often by the difference between how we intend for our application to be used and how it is actually being used. This information can help us iterate our ideas and continually improve the application.


The way mobile devices are being used is changing all the time, and users are increasingly expecting exceptional experiences from the applications they use. While the mobile world has many constraints, its many more opportunities make building mobile applications a worthwhile venture. Keep in mind the constraints, and focus on mobile first when beginning your project.

Remember that innovative features and cutting-edge design aren’t as valuable to users as we may think. Users are concerned with getting the information they need through a sometimes limited connection, or perhaps getting accustomed to typing on a screen without any tactile feedback. Not everyone has an iPad… yet.

Talk to real people, follow common archetypes, and keep the context of your target users in mind. These guidelines should help you create a great experience in your mobile application.

Additional Resources

Design patterns:

Design guidelines:

Article sources:

Further Reading

Smashing Editorial (al, mrn)