Baymard Institute

Mobile Product Lists Need Very Distinct Hit Areas

2013-05-21T08:48:00+02:00

This is the 6th in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

When displaying search results and category lists on mobile sites & apps, users often simply have no idea where to tap in order to select a given item / product.

Can the entire “element” be tapped? Or is it only the product title? And what about the thumbnail? During the mobile commerce test sessions multiple issues arose as subjects were unsure of where to tap in order to select a given option in a list, what was even “tappable”, and where a link would take them when they tapped an area. Some even got completely stuck and, without knowing how to proceed, were unable to complete their purchase.

Lack of Hover State on Touch Devices

On touch devices users lack the subtle but crucial mouse hover states which provide instant indication if something is clickable or not. Often by changing the cursor from a pointer to a hand, changing link color, showing the destination url path (depending on browser), showing a link title, or by changing the visual appearance of entire elements by using a change in background color, borders, or even images.

But with touch devices’ lack of hover state these indications aren’t available to the user and interfaces must instead either be learned by trial-and-error (a sometimes acceptable trade-off for frequently used games and productivity apps) or the interface must at all times make it clear what is and isn’t clickable (clearly designed links and buttons). This proved a major problem during user testing of the mobile sites; especially on complex, navigation heavy sites such as mobile commerce sites.

A good example is inconsistent link styling. This is certainly a problem on Desktop sites too, but it is much worse on touch devices as users don’t have the hover state to assist them in clearing up hit area confusion (as previously mentioned, the problem was so severe in some cases that it lead to purchase abandonments). On Desktop, if the user is in doubt, they can hover the area with the mouse and get instant feedback on whether the area is clickable or not; on touch devices, users don’t have this affordance.

Note the very inconsistent link styles. Sometimes orange was used as a header, other times as a list item. Sometimes the separators were used to indicate a list item, while other times again it was used to separate elements of text. Some text was one shade of blue which sometimes meant it was a link but at other times didn’t, with some links styled in a different, darker blue and underlined. Confused yet? The test subjects were too.

Multiple Hit Areas Within the Same Visual Element

One particular issue that was observed at many of the test sites was when list items (e.g., a list of products within a category, a list of movies at a specific theater, or a list of different departure flights to choose from, etc) had multiple hit areas invoking different functions. The subjects were simply unable to determine which of the multiple elements they should click, and in most cases did not realize they lead to different places or invoked distinct features.

At Fandango, after having selected a specific movie to watch, users were shown the above list of theaters with specific show times. Here’s how the subjects interacted with the list:

40% first tapped the showtime they wanted (notice where the subject is tapping), but the showtimes are not clickable. (Also note how the blue “Share” link is clickable, whereas the blue “Digital” label is not.)
The spatial indicator (the arrow pointing to the left) is also problematic. Although it is often used to indicate an entire element is clickable, here the arrow is vertically aligned with the theater header. If a user clicks the arrow or the header, they are taken to a generic list of all movies at that specific venue – despite being within a specific movie scope. Another 40% did that and were taken to a page that did not make sense to them.
Only 20% hit the “Buy” button on the first attempt.

That’s an 80% failure rate! Quite simply, it’s very confusing to users when a single visual element has this many different (interactive and non-interactive) hit areas. Two other approaches would have been to either make the entire list item one large hit area, all leading to the next step in the process (the “Time Selection”, where the “Buy” button currently takes you), or have users select the wanted play time directly at this page (allocating much large hit areas for the time options).

Multiple hit areas were also a problem at Walmart when users had to select departments to narrow their results by. Here all the test subjects clicked one of the options, e.g. “Electronics”, but found the categories much too broad. None of them noticed that there in fact is multiple different hit areas in this view. Clicking the category title will select that category, but clicking the orange ‘+’ icon expands the category and shows sub-categories within the category (e.g. TV, Audio, Computers).

Generally speaking, one should avoid having multiple hit areas (for different paths or features) within the same list item and instead make the entire list item one hit area pointing to a single path.

Making Hit Areas Sufficiently Distinct

The above examples are only two of the many instances where it was unclear to the subjects either what elements were clickable, what the differences were between the different hit areas, and most importantly, where to click in order to select a given option in a list.

The sites with the far fewest issues regarding hit areas embraced multiple of the following recommendations:

Make the entire element area clickable, using an anchor content approach. In particular, make sure that the product thumbnail, product header and price are clickable and lead to the product page.
Style the title as a link (using your primary text link style).
Have an arrow or similar visual cue indicate the virtual space; showing that the entire list item can “move you to the next step of the process”.
Be very careful when implementing multiple different hit areas within the same visual element, in particular, links or buttons within a list item leading to different pages or invoking different functions.

You do not need to adhere to every single of these recommendations, but the more you adhere to the clearer the hit area will be to the user. Also, in some cases bundling different hit areas in the same visual element may be preferable for the sake of functionality but you must be very mindful when doing such implementations.

A simple test we’ve found helpful in determining whether hit areas in a list are sufficiently distinct goes as follows:

Grab your phone and scroll to a random place in a product list on your site
Hand the phone to someone (colleague, spouse, etc) who isn’t part of the dev or design team
Ask them to identify all the distinct hit areas of the page and predict the function / destination of each

If they immediately can identify the all the hit areas and can accurately predict the pages they lead to or functions they invoke, then odds are that the items are sufficiently distinct. If they have trouble identifying the hit areas you may want to revisit the design and see if you can make the distinction clearer.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

How Should Your Mobile and Desktop Sites Differ?

2013-05-07T07:43:00+02:00

This is the 5th in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

When defining, designing and structuring your mobile commerce site; should you slim down content and features, or try to stuff it all in the mobile version as well? During our mobile commerce usability study the test subjects encountered m-commerce sites adopting widely different approaches. It turned out that some approaches had dire outcomes. Here’s a glimpse into the complex dilemma of what content and features to share across the mobile and desktop versions of an e-commerce site.

Content should be the same

First off, it is very important to distinguish between both the type of site (e-commerce sites versus other websites), and between content and features. The following observations from the test sessions are specifically for an e-commerce context and user behavior might differ if your mobile site is a news portal, blog, company site, intranet, web service, etc.

Now with regards to the amount of content you should have in the mobile version, the findings are clear: during testing, a limited set of content lead to endless misunderstandings, poor shopping experiences and abandonments. The problem with limited content on the mobile site is that users very often don’t realize it is limited as they expect (and thus assume) all content will be available. Reduced content in the mobile version was particularly problematic for two specific types of content: 1) product catalog, and 2) Help & FAQ content.

(Note that there’s a distinction between having all “content” and having all “features” on your mobile site. Our research shows that you must have all content, but that features may differ where sensible.)

Product catalog

One of the tested mobile sites, H&M, only offered a highly limited product catalog and as a result, the subjects had, by far, the worst overall shopping experience at their site. It turns out that limiting the product catalog in the mobile version introduces an incredible complex communication task: telling the customer that something is missing, communicating what the missing content is, explaining why it was omitted, and directing the customer to where they can find it.

The mobile version of H&M featured 10-20 selected products and then dedicated the rest of the site to fashion news, events, etc. However, those 10-20 featured products mislead every single test subject to believe that the site featured the entire product catalog because they were able to find some products and thus figured the rest of the catalog had to be somewhere on the site. Some subjects ended up leaving the site after spending more than 10 minutes only looking for the entire product catalog, never realizing it wasn’t there.

This tendency was observed in other scenarios as well. For example, when a search query returned no results and the subject had already tried a few synonyms, they always ended up concluding that the site didn’t carry that particular item. Never considering that it might “just” be left out of the mobile version.

Considering how severe it is when users misunderstand limited product catalogs and given how incredibly difficult it is to explain, your mobile site should always feature the full product catalog. (Or have no catalog at all to clearly communicate to users that this isn’t a mobile commerce site.)

Help pages

Now the issues during testing were not related to limited product catalogs only. It proved equally important to mobile help sections, which at many sites were severely limited compared to the desktop version. Often only offering basic help or help relating to mobile devices (cookies, rendering issues, etc.).

At REI, one subject found it ironic that he could visit the mobile “Help” (first image), then the “FAQ”, and then the “Help: Shopping & Products” (second image), all without finding any indication of delivery methods and speed, but that when he left the mobile site for the full-site, he located the “Shipping Info” help page within seconds (third and fourth image).

In many cases something as trivial as learning more about the site’s shipping speed and costs, or the basic terms for returning an item, turned out to be so difficult for the subjects that they often gave up on the task. Typically because the info simply wasn’t there in the mobile version, or because it was buried somewhere in a 30 screen long Terms & Conditions legal text.

Form can be different

While the entire product catalog and all the help and static page information must be in the mobile version, the form of that content can change for the mobile context (and often should).

Best Buy divided the product description into concise sections with short bolded headers for easy scanning and slightly more in-depth (but still very brief) descriptions in a lighter grey.

A good example of where a mobile-optimized format makes sense is product descriptions. On mobile, the product page description should be optimized for a mobile context with short and easily scannable bullet points and additional info in collapsed sections instead of displaying them directly at the product page or separate sub-pages (which often cause scope confusion on mobile commerce sites).

Similarly static help pages can be optimized for the mobile context where the 4" screen impose a need for text and copy to be very concise and easy to scan (typically with much narrower sections and sub-headers, prioritized order, etc).

In summary, all content (as in: “information and answers for your users”) must be in the mobile version, however, the formulation, formatting and position doesn’t have to be the same as the desktop version. So you must have the entire product catalog on your site, but the product page can look different. Your help section must include information on shipping speeds and cost on both mobile and desktop, but the layout of that shipping table can look different.

Features can be different

Our mobile usability research was only conclusive when it came to all content being featured on the mobile site; when it comes to features, the observations differ, and you will most often need to judge and test it on a case by case basis.

Animating carousels on the homepage are a good example of a feature that shouldn’t be on the mobile site despite being on the desktop site as they suffer from severe interaction issues due to lack of hover state on touch devices.

For example, in the prior article in this series ‘Mobile Product Pages: Always Offer a List of Compatible Products’ we described how removing compatibility list would be an oversimplification of the mobile product page. Whereas, keeping an animating carousel on the homepage (which is a quite common feature at most large desktop e-commerce sites) proved to cause great difficulty on the mobile sites in the cases it displayed anything other than products (e.g. when displaying features, site navigation, help, events, etc).

Furthermore the mobile site will often benefit from additional features that are not necessarily meaningful to the desktop version: location detection (via GPS), larger product images in landscape mode, context dependent search scope, smart defaults based on the user’s context, etc. Therefore, you may remove and add features to the mobile site where sensible.

User Expectations

Like so many other things in usability, this boils down to user expectations. Users expect to find all the products available on the desktop site; after all, why would a mobile site carry less products when the site / brand is the same? The same goes for product descriptions and help text – you’d expect to be able to find the same information since the selected product or shipping speeds shouldn’t change depending on the device you’re using to order. Meanwhile, you’d expect layout and formatting to change, after all, the screen is so much smaller. And you might be positively surprised when the mobile site detects that you’re physically in their store and offer you a “Ship for free to this store” option.

So to answer the question we started out with – “When defining, designing and structuring your mobile commerce site; should you slim down content and features, or try to stuff it all in the mobile version as well?” – we can say that all content (products and pages) should be in the mobile site but the articulation and formatting of the content may be different, and the site’s feature set should be different where it makes sense.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

Mobile: Never Use Native Drop-Downs for Navigation

2013-04-23T08:49:00+02:00

This is the 4th in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

Many responsive mobile sites are using native drop-downs (as in: a select tag) for main navigation and many plugins have been developed for this specific purpose, yet our usability research shows that this is a poor strategy. On the tested m-commerce sites that used native drop-downs for navigation, the test subjects showed decreased control and overview of the menu items.

During testing, nearly all subjects scrolled up and down category lists before selecting an option, many explicitly stating that they wanted to see all the categories before selecting one – even if they felt they had spotted a good match early in the list, the subjects still scrolled the remaining items just to make sure they knew what their other options were (before then scrolling back and selecting the good match). The subjects exhibited the same behavior on homepages where they often scrolled up and down to get an idea of what their options were, even if they saw what they were looking for right away.

This strong tendency towards scanning all options before selecting one is at the core of why native drop-downs are a poor choice for navigation. When open, a native drop-down only utilize ~50% of the screen, which made it needlessly difficult for the subjects to get an overview of their options.

With only half of the screen used to display the available options, users will have a difficult time scanning and comparing the available options. To make matters worse, the drop-down often starts out at the top with only 3 options visible to the user (left image), and even when scrolled to align optimally, no more than 5 options can be seen at once (right image).

Another issue with the navigation options only taking up 50% of the screen is that the scroll area for those options is similarly small. The smaller scroll area resulted in less accurate scrolling as there was so little room to “drag” the content that many subjects flicked to scroll instead (which of course is a much more inaccurate way of scrolling).

Finally, we also observed a few instances where subjects mistook the navigation for filtering options. This was especially true of category and search result pages where subjects were on the lookout for filtering options and then simply jumped to the conclusion that the drop-down was such a feature.

Solution: Custom UI Drop-Downs

It’s very important to underscore that drop-down navigation isn’t bad at all, it’s native drop-downs (as in: a select tag) which are unsuitable for navigation due to the way they have been implemented in the major smartphone operating systems (such as iOS and Android).

While the navigation at The Boston Globe is very similar to how the native drop-down works in terms of interaction (you first click “Sections” and then a set of simple items are revealed) it is significantly better because the options aren’t limited to a dialog but can take up the entire screen if necessary. In the above all 10 items are shown at once; quite the improvement in terms of overview, scannability and “scroll control” when compared to the meager 5 items that can be shown in a native drop-down dialog. (The navigation items on Boston Globe are, however, on the short end, being only ~5,3mm tall.)

Another benefit of implementing custom drop-down UIs for navigation is that you have complete control over the design of the options. This means you can optimize the design and layout of the shown options (which you can’t with a native drop-down). CSS-Tricks, shown above, is a great example of this where, when expanded, the menu items are displayed in two columns and each has a descriptive icon next to it. It can also be more subtle, like the earlier Boston Globe example where arrows have been added to indicate virtual space.

During testing the subjects had no issues using these types of custom UI navigation as long as they followed basic design conventions, had adequate hitarea sizes (device manufacturers recommend a minimum of ~7×7mm), and the trigger element was designed as a link / button (so that the subjects knew it was clickable).

It should be noted that native drop-downs are not poor for all purposes – they can work well in forms where keeping page context can be as important as the options themselves. However, native drop-downs should not be used for main navigation as they simply afford too little overview of the available options and are needlessly difficult for users to scroll accurately.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

Mobile Product Pages: Always Offer a List of Compatible Products

2013-04-02T08:47:00+02:00

This is the 3rd in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

When testing 18 of the largest mobile commerce sites compatibility-dependent products in particular proved to be difficult to find for the test subjects. A “compatibility-dependent product” is any product that is dependent on being compatible with another product that the store also sells or the customer already owns, e.g., an adaptor for a laptop or a case for a digital camera.

These are typically high-profit accessory products and it therefore makes good sense both usability- and business-wise to make it easy for users to find such compatibility-dependent products.

Finding Compatible Products on Mobile

While finding the right product in general wasn’t an easy task for subjects during testing, it required a significant amount of extra effort (research, navigation, verification) from the test subjects to find compatible products. As a result, they often only reluctantly looked for compatability products, and did so with limited success.

Since a list of compatible products was not listed, this subject resorted to copy-pasting the camera dimensions into the iOS “Notes” app so he could compare them against the camera bags later.

If a list of compatible products are not shown, the user has to write down or memorize various product details, for instance, the dimensions of a camera, and then browse various camera bags, looking at their inner dimensions to determine if the products are compatible. During testing numerous subjects miscalculated or misinterpreted product dimensions and consequently discarded products because they deemed them incompatible (or at least were unsure if they were compatible). Even products that in the product description or title explicitly stated that they were compatible with the item in question were discarded if the dimensions looked off.

While this could also be a daunting task on desktop, there are some vital differences, in particular in terms of overview of the options, tabbed browsing, and ability to view multiple windows next to each other. On mobile the subjects focused very intensely on one product at a time (as opposed to full-site product finding which often involves tabbed browsing, multiple searches in parallel, etc.), which made it cumbersome to validate a long list of products up against a specific set of compatibility attributes (e.g. internal dimensions).

A search for “Macbook charger” yielded good results, but this subject did not know what the 60W and 85W options represented and was unsure if only one of them would be compatible with his Macbook.

Other times the issues weren’t related to locating and comparing the compatibility attributes, but rather understanding them at all. This was particularly true of technology products where many of the test subjects were confounded by various technical compatibility aspects, such as the power rating of a laptop charger (as seen above) or the regional limitations of a Blu-ray player.

In all these instances, showing a list of compatible products would have helped the user greatly in finding (and ultimately buying) these compatibility-dependent accessories.

A List of Compatible Products

It is recommended to display a list of compatible products on the product page. This can be implemented in many different ways and there’s not one preferred design; however, it is important that the compatibility list is easy to find and scan.

If you carry the items, they should furthermore be links so the user can go straight from e.g. camera to a compatible camera bag. If you don’t carry the items in your store, it is still advisable to show a compatibility list. For example, even if you don’t sell a particular Asus laptop, it will be very helpful for the user to see this laptop listed as a compatible product when looking at an Asus charger, as it will allow them to identify their own laptop in the list and thus feel confident that the two are compatible without worrying about the technical details.

At the product page of a digital camera, Amazon presents the user with a compatible camera case, and links to the product page to make it easy for the user to further investigate the product.

When listing compatible products it is very important to be consistent in the inclusion or exclusion of model series vs. specific models. For example, do you list just the model series “Dell Inspiron” or do you list the specific model names “Inspiron 5150, Inspiron 8600, ..”? The subjects got very confused on the sites that on one page listed model series and on another specific model names, as they suddenly started doubting if the series name included their specific model as well. Therefore, consistency is important in this regard (at least within the same category of products).

Finally, you may consider showing compatible products in the cart too, especially if you redirect the user to the cart when they add a product to it (since they in this instance won’t be able to open any compatible products listed on the product page they were directed away from). Just make sure that when listing compatible products in the cart they are very clearly separated from and secondary to the actual cart contents (to avoid the two being confused), and that the list is placed below the “Proceed to Checkout” button (to ensure the user instantly and always knows how to proceed if they are happy with their current items).

Compared to Full-Sites

When comparing to desktop usability research this is a very interesting observation, as users perceptions of such compatibility cross-sells differs between full-sites and mobile sites. On mobile, users are mainly positive, as the listed products are perceived as quick cross-navigation. On desktop, the reception is more chilled and it is more often seen as ads for other (compatible) products – although still found useful when needed.

Therefore, avoid any temptation to remove such compatibility “cross sells” from your mobile site in an effort to simply the product page, as this really will be false simplicity. In fact, depending on your current full-site cross sells and your industry, you might consider experimenting with the opposite for your m-commerce site, adding more thorough and extensive compatibility cross-sells lists on your mobile product pages.

Adding compatibility lists to your product pages, especially with products you carry, is clearly a no-brainer given the typically high profit-margin on these types of accessory products. Do however take note of the ‘compatibility’ part; this more positive attitude towards compatibility cross-sell lists doesn’t necessarily apply to more generic cross sell lists.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

Mobile Form Usability: Place Labels Above the Field

2013-03-19T15:29:00+01:00

This is the 2nd in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

On mobile, should the field label go to the left of or above the field? After completing a large-scale usability study of 18 m-commerce sites, which included test subjects completing more than a thousand mobile checkout form fields, the answer is: above, with one exception.

The Issues with Left-Aligned Field Labels on Mobile

The main issue with left-aligned field labels relates to the smartphone display size and aspect ratio. Quite simply, if a left-aligned label needs to be in front of the field, the narrow screen leaves very little space left for the field itself. This is a severe usability issue since the form field will often not be wide enough to display the user’s entire input; think an e-mail address, which will often exceed 20 characters, or a credit card number which is most often 16 digits, a full name, or an address line consisting of street name and number.

Not being able to see their input caused trouble for numerous of the subjects during testing. First off, it made it much harder for the subjects to spot any typing errors before submitting the form, leading to more erroneous forms being submitted. But more problematic was when a form containing erroneous input was submitted and returned to the subject, as it (predictably) proved very difficult for the subject to spot and fix validation errors when they could not actually see the entire “invalid” input (since it was truncated due to the short field length).

This forced the subjects to fiddle around with the quirky text selection / panning tools. Many subjects ultimately just decided to delete their original input and retype it because they were not able to spot the error or because they simply found it faster to delete everything than to fiddle with the text selection tools.

Given that spelling accuracy decreases on mobile (and the odds of validation errors therefore goes up) due to the tiny touch keyboards, having errors be this difficult to fix, let alone identify, is highly problematic.

Label Above the Field

The main benefit of placing the label above the field on mobile is that you can have the form fields extend the full width of the display, making them large enough to display the user’s input in its entirety (in a decent input font size).

Additional benefits are the much better opportunities for writing clear and meaningful field labels as they don’t have to be limited to 1-2 words, more space for clearly indicating required / optional, and the possibility to easily include field descriptions (e.g. the important explanation of why you require the customer’s phone number).

The main downside of placing labels above the field is that it takes up more vertical space, which means users have to scroll more – however, during testing the scrolling gesture itself proved very intuitive to the users and not a hindrance to completing a form. Thus it’s only in the case where the form is so short that a complete form overview is achievable with the left-alignment vs. above-alignment (with the keyboard open) that left-alignment might be defensible on mobile in portrait mode (forms for address, payment or account sign-up will hardly ever be this short, while a newsletter sign-up asking just for the user’s e-mail address would).

Dynamically Change Label Position in Landscape Orientation

Now as mentioned in the beginning there’s one exception. It’s landscape orientation.

The keyboard in landscape mode severely limits the actual viewable area. For instance, when in landscape mode on an iPhone 4S, only 33% of the screen displays the actual webpage with the form the user is filling out. On some Android devices it is even worse, e.g. a Samsung Galaxy S Plus in landscape only has 18% of the screen allocated to the actual web page. Both seen below:

Now just look at those images again. With this little form context viewable the form gets very difficult to complete correctly. In the Android example the field label for the active field (that the test subject is trying to fill out) is not even viewable. This extreme lack of page and form context in landscape mode caused severe issues to the subjects. For instance, in the image to the left, the subject has begun completing the email field believing it’s a part of a checkout contact / address form he has to fill, not noticing that it’s actually the sign-in fields for existing customers with an account (the “checkout as guest” button is out of view).

So why would anyone want to fill out forms in landscape mode given these constraints? Well, it is actually perfectly understandable, as the hitarea of the keyboard’s letters increases significantly in landscape mode compared to portrait mode. For example, on an iPhone 4S the letter hit area increase by 32% (52px*76px versus 83px*63px), seen below:

Since there is a group of users that strongly prefers the larger touch keyboard, these issues of filling forms in landscape mode should be taken into consideration when designing for mobile. To better accommodate these users, you should consider dynamically changing the label position to be left-aligned when the device is turned to landscape mode. This includes repositioning any form descriptions, tooltips and input examples (possibly below the field, in close proximity).

The problem of too short fields where the input is truncated (which forced us to position the label above the field in portrait mode) is much less of an issue in landscape mode because the screen is so much wider in this orientation. This means there’s room enough for a left-aligned label and a field that’s long enough to display most inputs (e.g. on an iPhone the ~300pts wide field we had in portrait mode when the label is above, still leaves ~150pts for the field label to the left in landscape mode).

Keep Input Visible Yet Maintain Context

Unlike the discussion of label alignment on desktop sites, which mainly concerns the best eye path for scanning the entire form page, on mobile, the issue revolves around fields being so short that the user cannot see their entire input when a decent sized input font is used. Not only making it very difficult to validate inputs before submission, but also even more difficult to correct them. Therefore, on mobile, the field labels should be placed above the field by default.

Yet the matter is complicated by enormous keyboards when the phone is in landscape mode, with only one third of the screen being dedicated to the actual form (and in some cases even less than that!). Therefore, to alleviate this extreme loss of page context, you should reposition field labels to be left-aligned in landscape mode.

This is a great example of how responsive design thinking can help us, even if we’re working on a stand-alone mobile site. Responsive layout adjustments like these can greatly improve the user experience of your mobile site, e-commerce or not.

You may take responsive design to the next level and dynamically decrease the input font-size a notch as the user’s input approaches the viewable number of characters (like YouTube did with their dynamic headlines). Imagine you have an input field which can display about 30 characters; as the user enters his 25th character you could decrease the input font-size by 10% so that the field would fit a handful extra characters.

Speaking more generally about mobile design, especially m-commerce site design, this article illustrates just one of the many complications induced by the new interaction method mobile brings forth (touch input on a 3-4” rotatable screen), and offers a glimpse of how complex m-commerce sites are to design.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

M-Commerce Usability: Exploring the Mobile Shopping Experience 2013

2013-03-12T07:32:00+01:00

Everybody is talking about mobile. Some e-commerce sites are venturing into it. The potential for m-commerce is enormous: ComScore predict the number of mobile users online will surpass desktop users online in 2014, while eMarkter reported an industry wide 81% growth rate in mobile sales from 2011 to 2012 ($25 billion) and forecasts it to account for 24% of all online commerce by 2016.

This is why we decided to invest the better part of a year at Baymard Institute to conduct a large-scale usability study focusing specifically on m-commerce. We set out to explore the entire mobile shopping experience, from the user’s conceptual understanding of m-commerce sites, to how users interact with form fields. More specifically, we tested category navigation, product search, filtering and sorting of results list, the layout of product list, product page design, cart functionality, the checkout process, the homepage, privacy concerns, mobile payments, account steps, shipping selection, booking processes (rentals, aviation and tickets), as well as help pages, error messages, basic mobile form field usability, and technical performance.

After completing the most exhaustive m-commerce usability study done to date, it is easy to understand why some researchers cry out for caution. SeeWhy reports a staggering 97% mobile cart abandonment rate, and IBM has documented m-commerce conversion rates to be around half of what the full-site e-commerce equivalents are seeing. And despite testing the mobile commerce sites of 18 multi-million dollar businesses, including Walmart, Amazon, Avis, and United, numerous of the test subjects were unable to complete their purchase at the majority of the sites they tested. Note the word used is unable, not unwilling. The usability issues were that disruptive.

We’re therefore excited to release the findings of this study in our new M-Commerce Usability report with 147 research-based design guidelines that will help you steer clear of the many pitfalls of mobile shopping and overcome the design challenges introduced by smaller screens and new interaction methods.

Learn more about the M-Commerce Usability report

Mobile Form Usability: Avoid Splitting Single Input Entities

2013-02-12T08:41:00+01:00

This is the 1st in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.

During our recent M-Commerce Usability study we observed subjects struggle with inputs that were split across multiple fields, such as a phone number divided into three fields (area code, central office code, and subscriber number). While the intention is good, these fields proved difficult for the subjects to both understand and interact with on a mobile device.

Specifically, the subjects had a hard time navigating between such fields (Issue #1: Interaction), found it unclear if they were all required (Issue #2: Ambiguity), and sometimes found the division illogical (Issue #3: Perception). In this article we’ll go over each of these three types of mobile form usability issues related to dividing a single input entity into multiple fields.

Issue #1: Interaction

Users generally have a difficult time navigating between fields on mobile devices. Surprisingly few of the test subjects used the ‘Next’ and ‘Previous’ buttons on the touch keyboard – instead they generally navigated to new fields by tapping them on the screen.

On Macy’s, the phone input is divided into three fields (three-digit area code, three-digit central office code, and four-digit subscriber number), which made the input needlessly difficult to enter. See video clip here

To enter a phone number on Macy’s m-commerce site, you must: 1) Tap field. 2) Switch to numeric keyboard. 3) Type first three digits. 4) Keyboard auto-closes (Macy’s for some reason finds it a good idea to auto-close the user’s keyboard). 5) Tap the next field. 6) Switch to numeric keyboard again. 7) Type the next three digits. 8) Keyboard disappears again. 9) Tap the last field. 10) Switch to numeric keyboard once more. 11) Type the last four digits. (And then, to make matters worse, at the last field, the one place where the keyboard could reasonably auto-close, it does not). Even if the keyboard did not disappear as each field is completed, the number of interactions required to fill a phone number in the three fields remain the same (you’d still need to either tap the field on the screen or the ‘next’ button on the keyboard), and the typing flow of the 10 digit phone number would still be abruptly stopped twice. Not to mention all the issues related to editing a phone number split across multiple fields (in case the user spots an error).

While the intention of dividing the phone number into multiple fields is good and indeed serve as a very strong input formatting example, it simply does not work very well on mobile. (On a desktop site where advancing between fields is easier for users the division might be acceptable; our full-site checkout usability study showed no conclusive data on this.)

Issue #2: Ambiguity

Another issue arising from dividing an input entity into multiple fields is the ambiguity of required vs optional fields. Our research studies show that you should always clearly indicate both required and optional fields (with explicit markup for both), however, almost all sites indicate this in the label. This presents a design issue when some parts of the divided input field are required and others are not, as seen on Southwest’s mobile site below:

On Southwest the ZIP code input is divided into two fields (the basic five-digit code followed by the four additional ZIP+4 digits), however, it’s only the first field that is required while the second field is optional, but the user really has no way of knowing this from Southwest’s form design.

Of course one way to solve the issue Southwest runs into is by adding “required” and “optional” labels below each field or as inline text, but why divide the fields in the first place? It adds unnecessary complexity to the form design and suffers from the interaction issues described in the previous section. Also, suddenly changing the position of “required” and “optional” labels will result in an inconsistent form design unless you of course change it for all fields in the form which seems like a rather drastic design change just to be able to divide a ZIP code input across two fields.

Issue #3: Perception

Lastly, there is an issue of perception where an input is commonly presented as separate fields even though users perceive it as a single coherent entity. This is true of “name” fields that are often split into “First name” and “Last name” fields.

Toys’R’Us ask for “First name” and “Last name” instead of a single “Full name”. We saw countless subjects enter their full name in the “First name” field, only to discover they had to split it into separate fields.

During both our E-Commerce Checkout Usability and (the upcoming) M-Commerce Usability studies users consistently considered their name a single whole – I am not “James” and “Newman”, I am “James Newman”. Therefore, users often enter their entire name in the “First name” field and then upon advancing to the next field, discover that they must now enter their last name. They then go back to delete their last name from the “First name” field, only to advance to the “Last name” field again to complete it.

While numerous sites ask for the user’s name in two or more fields it simply is not good usability. Of course it can be difficult to discover this if you’re not doing usability tests since all subjects we observed noticed and corrected the error before submitting the form (thus not showing up in most form tracking web statistics). It is therefore not a critical error to make but it does introduce needless friction to the checkout experience. Amazon seems to have reached the same conclusion and instead asks for the user’s “Full name”:

Amazon only uses a single name field on both their desktop and mobile sites, which matches the user’s perception of their name as a single entity.

Another issue related to multiple name fields concerns middle names and titles. If “First name” and “Last name” are separate fields then logically “Middle name” and “Title” should be separate fields too. Suddenly you end up with four fields instead of a single field, or a subpar experience where the user will have to guess whether their middle name should be appended to the “First name” field or prefixed in the "Last name” field. With a single “Name” field you avoid this issue altogether as users simply enter their name from start to end, including any middle name(s) and titles.

Conclusion

As we can see, seemingly innocent and sometimes even common divisions of a single input entity into multiple fields can lead to interaction issues, required vs optional field ambiguity, and misalignment between the user’s perceptions and your site’s form design.

On desktop sites, there may be instances where dividing a single input entity across multiple fields may be acceptable if all the fields are either required or optional and there’s no misalignment between user perception and form design. However, on mobile – even under those narrow circumstances – you should avoid splitting single input entities across multiple fields due to the interaction issues previously discussed.

Article series

Mobile Form Usability: Avoid Splitting Single Input Entities
Mobile Form Usability: Place Labels Above the Field
Mobile Product Pages: Always Offer a List of Compatible Products
Mobile: Never Use Native Drop-Downs for Navigation
How should your mobile and desktop sites differ?
Mobile Product Lists Need Very Distinct Hit Areas

Stay tuned for the next 2 articles to come…

Baymard Institute

Mobile Product Lists Need Very Distinct Hit Areas

Lack of Hover State on Touch Devices

Multiple Hit Areas Within the Same Visual Element

Making Hit Areas Sufficiently Distinct

Article series

Related articles

How Should Your Mobile and Desktop Sites Differ?

Content should be the same

Product catalog

Help pages

Form can be different

Features can be different

User Expectations

Article series

Related articles

Mobile: Never Use Native Drop-Downs for Navigation

Solution: Custom UI Drop-Downs

Article series

Related articles

Mobile Product Pages: Always Offer a List of Compatible Products

Finding Compatible Products on Mobile

A List of Compatible Products

Compared to Full-Sites

Article series

Related articles

Mobile Form Usability: Place Labels Above the Field

The Issues with Left-Aligned Field Labels on Mobile

Label Above the Field

Dynamically Change Label Position in Landscape Orientation

Keep Input Visible Yet Maintain Context

Article series

Related articles

M-Commerce Usability: Exploring the Mobile Shopping Experience 2013

Mobile Form Usability: Avoid Splitting Single Input Entities

Issue #1: Interaction

Issue #2: Ambiguity

Issue #3: Perception

Conclusion

Article series

Related articles