UX Movement » Mobile http://uxmovement.com User Experience Movement Fri, 16 Mar 2018 00:26:40 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.19 Why Mobile Menus Belong at the Bottom of the Screenhttp://uxmovement.com/mobile/why-mobile-menus-belong-at-the-bottom-of-the-screen/ http://uxmovement.com/mobile/why-mobile-menus-belong-at-the-bottom-of-the-screen/#comments Tue, 04 Jul 2017 13:09:11 +0000 http://uxmovement.com/?p=10349

The way you use your mobile phone can affect your brain. A research study has found that daily mobile phone users have a larger somatosensory cortex. That’s the region of the brain controlling your thumbs.

Further research has found that most users use their phones with one hand. When they hold their phone, they’ll use either their right or left thumb to interact with the screen. The thumb is like the user’s mouse but with limitations.

The Thumb is the Mouse

On desktop devices, users use a mouse to interact with the screen. They can move their mouse to a navigation menu with ease. This is because the mouse does not constrain their wrist movement.

But when users hold a mobile phone, their thumb has a limited range of motion. There are certain areas of the screen they cannot reach. These areas will vary based on which hand they use to hold their phone and the size of the phone’s screen.


(based on average hand size and grip span)

When you place a menu in a hard to reach area, users have to regrip their phone to move their thumb closer. Or, they have to use their other hand to interact with that area. This extra work can make navigating harder and slow down the user’s task.

Large Vs. Small Screen Phones

The top areas are becoming harder to reach as more users opt for large screen phones. Large screen phones (more than 5 inches) have lower reachability at the top than small screen phones (less than 5 inches).


(based on average hand size and grip span)

Large screen phones also have low reachability in the corner opposite to the user’s thumb. Whether it’s the left or right corner will depend on which hand the user holds the phone with.

If they hold the phone in their left hand, their thumb will have trouble reaching the right corner. If they hold the phone in their right hand, their thumb will have trouble reaching the left corner.

In contrast, small screen phones have high reachability in the bottom corners. This is because the device is thin enough for the thumb to reach the corner.

The Law of Thumb Reachability

Designers can’t change how users hold their mobile phone. But they can change where they place the navigation menu. Most designers place the navigation menu at the top of the screen. While a convention on desktop, it doesn’t translate well to mobile.


The hardest to reach areas for the thumb are at the top of the screen. Placing your menu at the top will make it harder for users to navigate your interface. Users use menus with great frequency. It’s necessary to place the menu within thumb’s reach. This will allow users to complete their tasks much faster.

Research has found that “regions within easy reach of the thumb were fastest and most comfortable”. In other words, the closer a target is to the thumb the faster it is to hit. The easiest to reach area for the thumb is the bottom of the screen. This is where your mobile menu should go.


The bottom placement of the menu allows users to tap the hamburger icon and select an option much faster. Placing the menu at the top forces users to regrip their phone or use their other hand to navigate. This requires physical maneuvering and slows down task time.

When users tap the hamburger icon with their thumb, the menu will open from the bottom. The menu options closer to the bottom are within thumb reachability. But the menu options at the top of the screen are out of the thumb’s reach.

In a traditional menu you would place high priority options at the top. But for a bottom menu you should place high priority options at the bottom. This makes them quicker to reach and tap. The new menu hierarchy would start with lowest priority options at top and end with highest at bottom.

The Thumb Sweet Spot

The hand users hold their phone with will vary by preference. Which side should you place your menu then? The same research study discovered a “sweet spot that required movement primarily from the base of the thumb”. This means users did not have to stretch or bend either of their thumbs to reach the sweet spot.


The sweet spot to place your menu is the bottom center of the phone. That’s the spot that’s easiest to reach for both left and right thumbs on small and large screen phones.

The sweet spot benefits large screen phone users more. Small screen phone users don’t have unreachable corners. But users may need to bend and stretch their thumbs to reach them.

As the trend of large screen phones grow, the thumb sweet spot seems more important to consider. The ideal is for users to navigate your interface with as little thumb movement as possible. This mechanical efficiency will lead to faster task completion.

Answering Common Criticisms

Any new recommendation that strays from traditional practice will get criticism. Placing the mobile menu at the bottom is not the norm. But it’s what should be the norm based on how users use mobile devices.

It’s clear that mobile menus at the top are hard to maneuver. But are there any drawbacks or conditions to following this new recommendation? Let’s answer the criticisms and see.

“The user will miss the mobile menu because it’s at the bottom and not the top where users are used to seeing the navigation.”

Yes, users are used to seeing the navigation bar at the top. But they’ve also seen it at the bottom on different mobile apps and devices before. A bottom navigation is not an unusual occurrence for mobile users.


Bottom navigation is more of an unusual occurrence for desktop interfaces. A bottom navigation on desktop is easy to miss because the screen size is much larger. This makes it harder for users to view the screen as a whole.

It’s easier to spot a bottom navigation on mobile because the screen is much smaller. This allows users to get view the entire screen where they can spot the navigation bar with ease.

“The bottom navigation will get in the way of browser controls which is also at the bottom. The user can accidentally hit a browser button instead of the menu button.”

You won’t have browser controls interfering with a bottom navigation on a native app. But a bottom navigation on a web app will have browser controls below it.

It’s possible users may hit a browser button on accident. But that’s no different than them accidentally hitting a button that’s next to the intended button.


When two buttons are near each other there’s always a possibility for user error. That doesn’t mean designers should never place buttons next to each other. It means they should add padding between the buttons to prevent these mistakes.

You can do the same with the bottom navigation bar. Add padding between the menu icon and browser bar so there’s visual separation. This will prevent accidental hits.

“It interferes with scrolling as the user swipes from the bottom. It can also distract users from viewing content.”

Users use their thumbs to scroll and their thumbs are closer to the bottom of the screen. This means they can hit the navigation bar when they scroll down a page. The bar can also distract users when they’re viewing content.


You can solve both of these issues by using a scrollup bar. This would hide the navigation bar when the user scrolls down the page. The bar would only show when the user scrolls back up. This is a common technique already used on mobile apps and browsers.

“It interferes with the call-to-action button on landing pages, which has higher priority than the navigation bar.”

An important call-to-action should be within thumb’s reach as well. But you don’t have to decide between the navigation bar or call-to-action button. You can put both at the bottom without interference if you use the scrollup bar.

If you don’t use a scrollup bar, you should weigh your goals. If your goal is to increase engagement, put a menu within thumb’s reach. if your goal is to increase conversions on a landing page, put a call-to-action button within thumb’s reach.

Thumb Function Dictates Menu Form

A bottom menu may look unusual compared to the more familiar top placement. But the latter ignores how the user’s thumb functions on mobile devices.

The thumb is the primary digit used to interact with mobile devices. This means thumb function should dictate menu form. Ignoring this principle leads to designing a menu that’s hard to use. A hard to use menu decreases user engagement and satisfaction.

The user experience designer’s goal is to make mobile navigation as fast and smooth as possible. Following the law of thumb reachability can make tasks faster and easier for users. Remove the obstacle of low thumb reachability with this simple design change.

http://uxmovement.com/mobile/why-mobile-menus-belong-at-the-bottom-of-the-screen/feed/ 21
How to Design a Walkthrough That Users Will Readhttp://uxmovement.com/mobile/how-to-design-a-walkthrough-that-users-will-read/ http://uxmovement.com/mobile/how-to-design-a-walkthrough-that-users-will-read/#comments Mon, 18 Jul 2016 13:02:01 +0000 http://uxmovement.com/?p=9590

If a new app is a new product, then the walkthrough is the instruction manual. A walkthrough appears when new users open an app for the first time. They get a brief overview of the app’s features before they start using it. This is necessary so that new users can use the app without confusion.

Excluding walkthroughs in your app can leave users confused. But making your walkthroughs hard to read and navigate can also leave them confused. Users will end up skipping them so they don’t have to go through the hassle.

Your walkthrough should motivate users to read it so they’ll know how to use your app. You do this by using clear navigation cues and making your text scannable. Users should also be able to retrieve your walkthrough again if they need to reference it. All these are necessary for a user-friendly walkthrough.

Scannable Text

Text that’s scannable is concise and to the point. Say what you need to say but use as few words as possible. Use headings that sum up your points in just a few words. You can put body text descriptions underneath the headings but keep them short.

Avoid making the user’s eyes work too much by placing the text near the navigation. This decreases the distance between the text and navigation and shortens their eye movement. They’ll be able to read and navigate faster with less effort.


Clear Navigation Cues

Some designers will exclude navigation buttons for their walkthrough. Instead, they’ll only display pagination dots and expect users to swipe. Not only is it easy for users to miss such a small visual cue, but it’s not intuitive that the dots mean swipe.

Don’t force users to figure out how to navigate. Use clear navigation cues such as a button with a ‘Next’ label so that users won’t have any doubt on how to navigate. Buttons are intuitive for tapping which every user understands. You can still allow users to swipe to navigate, but make sure there’s a button as well.


End with Call-to-Action Button

Placing your call-to-action button at the beginning of your walkthrough isn’t a good idea. This will tempt users to skip your walkthrough. Most users will skip it because they’ll feel like they don’t need it. But chances are they’ll end up a confused user looking for the help page if they skip it.

Place your call-to-action button at the end so you don’t give users the option to skip it. This is a more sensible and expected flow that’s better for the user in the long run.


Images Should Show How to Use App

Some designers will keep selling users in their walkthrough by touting their features. Once users have downloaded your app there’s no need to sell them on it anymore. Instead, they need to know how to use it. Your images should display the user interface and pinpoint what users need to tap or swipe to use a feature.


Retrievable Walkthrough

After users are done with the walkthrough they may still need to go back and reference it. You should make it easy for users to retrieve the walkthrough by placing a link to it in your navigation menu. You can label the link: tour, tutorial or how-to.

Make Walkthroughs a Walk in the Park

A walkthrough that’s a pain to read and navigate is one that users will always want to skip. But if you make yours short and useful they’ll have no problem viewing it.

A walkthrough is not a help and support page. It’s a quick overview of features to help users get started. In-depth details on how to use the app belong on the help and support page.

One reason people skip instruction manuals is because they take too long to read and are hard to follow. Although a walkthrough instructs users, it should never feel like an instruction manual. Instead, it should feel as easy to read as a sticky note.

http://uxmovement.com/mobile/how-to-design-a-walkthrough-that-users-will-read/feed/ 4
List vs. Grid View: When to Use Which on Mobilehttp://uxmovement.com/mobile/list-vs-grid-view-when-to-use-which-on-mobile/ http://uxmovement.com/mobile/list-vs-grid-view-when-to-use-which-on-mobile/#comments Tue, 03 Nov 2015 15:26:39 +0000 http://uxmovement.com/?p=8647

Figuring out your content layout is a tricky task on mobile devices. Desktop devices give you all the screen space to work with. But on mobile, screen space is limited. Users can only view a small amount of content at a time before they need to scroll.

This makes you wonder what the most efficient layout for viewing is. Should you use a list view or grid view? Your decision could affect how quick and easy it is for users to find what they’re looking for.

List vs. Grid View

List view displays your content in a single column list. It’s text heavy and there are no images. At most, you can display small icons or thumbnails next to the text. Users rely on reading the text to make their selection.

Grid view displays your content in two or more columns with images. The images dominate most of the space, and text is shortened to prevent too much textwrapping. Users rely on the images to make their selection.


List View Prevents Overscrolling

Many designers use grid view because it’s more appealing to the eye. But the problem is that grid view forces users to scroll more. Grid view includes images which make the page much longer. It’ll take users many scrolls to view all the available options. This is too much scrolling for their fingers.

List view prevents overscrolling by making pages shorter. The exclusion of images allows you to fit more options per screen. It also allows you to use accordions to add layers of suboptions on the same screen. Users find what they’re looking for by scanning text labels.


List View Prevents Hasty Selections

Not only does grid view force users to scroll more, but it causes them to make hasty selections. Users get so stimulated by images that they’ll select the first option that appeals to them.

This can often lead them to a section that doesn’t have what they’re looking for. The user then has to go back and scroll further. With so many stimulating images, it’s easy for users to get distracted and misled.

List view prevents users from making hasty selections. The text provides precise enough information to help them find the content they want. They’re able to make the best selection after reading through all the options.


Grid View Works Best for Examining Details

Aside from aesthetic appeal, grid view also helps users when they’re examining details. For example, if a user is shopping for a shirt, they’ll have a specific type in mind. It’s only after the user has narrowed down the content to a category that grid view is most effective.

A grid view display of clothes will distract more than help because only a few of those images will be of shirts. The user has to scroll to filter out a lot of irrelevant images when scanning.

But once the user is in the category of shirts they want, the images will have more relevancy. The user can scan the shirts and spot certain details they’re looking for with ease.


Final Thoughts

Most users are on the go when they’re on a mobile site. They need to be able to find the content they want fast. The layout you choose is key in making this happen.

There’s more flexibility with layouts on desktop, but on mobile, your choice matters. The view that allows users to see more content while doing less work is the winner.

http://uxmovement.com/mobile/list-vs-grid-view-when-to-use-which-on-mobile/feed/ 4
Why Users Miss Form Buttons Placed in the Action Barhttp://uxmovement.com/mobile/why-users-miss-form-buttons-placed-in-the-action-bar/ http://uxmovement.com/mobile/why-users-miss-form-buttons-placed-in-the-action-bar/#comments Tue, 02 Jun 2015 17:58:41 +0000 http://uxmovement.com/?p=8152

Where you place your mobile form buttons can affect task completion and efficiency. If they’re not in a place where users expect to find them, they could abandon their task and your form.

Even spending a few extra seconds looking for the button can frustrate them and cause them to hit the back button. As soon as they finish filling out the form, you should have the button right in front of them.

Many mobile sites get this wrong when they place their form buttons in the action bar (i.e. navigation bar). Research shows that users often miss submit buttons placed in the action bar (source). It also shows that they miss save buttons in the action bar and exit forms without saving their settings.

Unexpected Submit Buttons

The reason users miss action bar submit buttons is due to where they fixate their eyes when they complete the form. As they fill out the form, their eyes move from the top of the page to the bottom.


When they complete it, their eyes are at the bottom of the page. The absence of a submit button leaves them confused and uncertain of how to complete the form.

Most users don’t expect to find the submit button in the action bar. It’s an inconvenient place because it forces them to move their eyes all the way back up to the top-right corner of the page.

It feels counterintuitive because users were progressing in a top to bottom direction to complete the form. Moving back up to the action bar feels like going in reverse. It’s not what users expect, and it’s not where you should put the submit button.

Fixing Your Submit Button

Users expect to find the submit button at the bottom of the page when they finish filling out the form. But placing the button there could cause them to lose sight of it if they scroll through the form.


Users might scroll back up to check or change their field input. When they do, they’ll lose visibility of the button and have to scroll all the way down to look for it.

To prevent the extra work, place your submit button in a fixed footer so that it is has persistent visibility. This allows users to submit the form as soon as they’re ready.

Don’t give users extra work when they finish filling out a form. If they have to move their eyes or finger to find or scroll to the submit button, your mobile form isn’t efficient enough.

Unclear Save Buttons

What causes users to exit forms without saving their settings are the unclear action bar buttons. The action bar contains the back button, page title and save button. But the save button is the hardest to distinguish.


After users select their settings, they tend to tap the back button because they don’t realize they have to save. The save button is the primary action of the task, but it’s hidden as a gray check icon in the corner.

Users assume they saved their settings on selection because nothing else tells them otherwise. Not only that, but the page title also looks like the call-to-action when placed next to the back button. The lack of clarity in the action bar is what causes user error.

Fixing Your Save Buttons

Instead of using the action bar for your save buttons, use a fixed modal form. This gives users a clear save and cancel button without the confusing back button.


The cancel button functions as a back button. But the difference is that it tells users that they need to save their settings before they exit, or they’ll lose them. The save button has a label and is much more visible in size and color.

The only thing that should remain in the action bar is the page title describing the task. The save and cancel button should move to a fixed footer. This gives them persistent visibility so that users can complete the form quick and easy.

Final Thoughts

The action bar is a good place for buttons that navigate pages, but not for ones that complete tasks. Placing your mobile form buttons in a fixed footer makes them hard to miss and meets user expectations.

Form button placement has a big impact on how users complete tasks. Don’t stuff every button in the action bar just because you’re designing a mobile site. Think about task completion and efficiency, and put your form buttons where they belong.

http://uxmovement.com/mobile/why-users-miss-form-buttons-placed-in-the-action-bar/feed/ 13
Why You Should Avoid Using Modal Windows on Mobilehttp://uxmovement.com/mobile/why-you-should-avoid-using-modal-windows-on-mobile/ http://uxmovement.com/mobile/why-you-should-avoid-using-modal-windows-on-mobile/#comments Tue, 27 Jan 2015 21:14:32 +0000 http://uxmovement.com/?p=7622

One of the most frustrating things users experience on mobile sites is a modal window. On desktop, modal windows display without issue because of the large screen size. But on mobile, modal windows get cut off because of the small screen size. Users only see part of the modal window and can’t exit nor view it with ease.

Viewing is even more difficult if users have to use an onscreen keyboard. The keyboard will pop up and cover a chunk of the screen, forcing users to have to scroll awkwardly to see the what they’re typing. If you want users to view your modal window content with ease, avoid using modal windows on your mobile site. Use an inline accordion instead.

An inline accordion displays the content within the page. It doesn’t overlay it on top of the page like a modal. This prevents the window positioning and scrolling issues that users experience with modals. Not only that, but users never lose their context because inline accordions open on the same page. Modals take users out of their context when it covers up the screen.


The way an inline accordion works is when the user taps the button, a panel collapses below it. The panel content is fully displayed on the mobile screen. Users no longer have to deal with partial viewing or awkward scrolling.

The button should highlight so that users know what they tapped. The panel should have a title label that matches the button label. It should have an ‘X’ icon in the corner to close the panel just like closing a modal window.

Stop making users struggle to view your modal windows. Use inline accordions in place of modal windows on your mobile site. When users can view the content on their screen with ease, they can complete their tasks without the frustration.

http://uxmovement.com/mobile/why-you-should-avoid-using-modal-windows-on-mobile/feed/ 10