This is the last in a series of 8 articles on mobile commerce usability that draw on findings from our m-commerce usability report 2013.
In the seven prior articles of this series we’ve covered very specific usability findings for mobile commerce sites such as: inline labels (7), hit areas in product lists (6), drop-downs for navigation (4), single input entities (1), label positioning (2), and lists of compatible products (3).
Beside the specific improvements these seven findings hopefully also offer a glimpse at the level of detail one needs to consider when designing a mobile commerce site. However, these are really just the tip of the iceberg – in our m-commerce study alone we demonstrated 147 mobile specific guidelines. And so, to round off this Mobile Commerce Usability articles series we’ll zoom out and focus on some of the more high-level, conceptual design concerns you should pay close attention to when designing mobile commerce sites (and mobile sites in general):
1. Touch Interfaces
Touch devices have (rightfully) been praised for generally being much more intuitive to use compared to a desktop mouse or laptop trackpad since users simply tap what they see and “push” sheets of content around with their finger. However, touch as a website interaction method also suffers from a host of severe limitations when compared to the computer mouse and keyboard which has been the primary input methods for OS and web navigation since their introduction three and four decades ago (respectively).
Touch devices have no hover state and no right / left click, but instead utilize a number of “hidden gestures”. Touch is also much less precise (mouse offers pixel-precision while touch has fingertip-size precision) – this is particularly felt on touch keyboards which typically have puny letters despite typically taking up half of the already small screen (and as much as 82% of the screen in landscape mode).
During the m-commerce study, 50% of the test subjects had trouble tapping the intended element despite testing the mobile sites of 18 of the largest e-commerce brands in the world. Now, we will refrain from participating in the trend of calling this the “fat-finger-problem” – after all, the human finger anatomy predates the invention of touch smartphones by roughly 150,000 years, so it only seems reasonable to conclude that it is the mobile websites which are poorly designed when half of the users have problems hitting the intended link.
Rants on misguided descriptions aside, these different touch interface limitations lead to some basic mobile design dispositions:
1.a) Due to the dichotomy between small device screens and human finger anatomy, one often needs to increase the relative size of hit areas as well as increase the spacing between clickable elements considerably compared to what is normally used on full sites. Microsoft, Nokia and Apple have all done research in this area, and they all stipulate a minimum hit area of approximately 7×7mm, and spacing between clickable elements to be a minimum of 2×2mm. (Measured on the end-users smartphone display, so account for increasing display resolution / PPI as technology evolve).
1.b) Due to the lack of hover state interfaces must 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 (as in: links and buttons must be overtly and immediately obvious). This proved a major problem during user testing of the mobile sites where inconsistent link styling and non-clickable icons proved much more severe than what we normally observe at desktop e-commerce sites.
1.c) The small touch keyboards on smartphones result in slow and error prone typing. Therefore one should always invoke custom keyboards (numeric, phone, email) where appropriate as the hit area often increase significantly; e.g. the hit area of the numeral input keys is 471% larger on the numeric keyboard than the traditional touch keyboard (209×108px vs 52×76px).
2. Screen size
Here’s a simple test: Take a business card you have laying around at your desk and hold it in your hand and judge its size. What you’re seeing is roughly the frame size your mobile users have available to view your entire commerce store. And of course they in practice often have even less as space is also needed for OS and browser chrome, touch keyboards in forms, and finger interactions such as scrolling and tapping links. Smartphones have display sizes of 3-5 inches and no matter how much display resolution improve, the displayed content will always be limited by the physical size of the screen.
During mobile testing the small display often lead to an extreme loss of context – and as a consequence users often felt “lost on the page”. Thus:
Any help and clarifications must be placed exactly where the doubt occurs. This makes inline help such as tooltips and form field descriptions a vital asset in preventing users from getting stuck during shopping and checkout in particular.
Good microcopy is more important than ever. When there’s less context, having each label name and header written in clear and unambiguous terms is paramount – and if they can help set and reinforce context, so much the better. 37signals is known for saying “writing is design”, and in the case of m-commerce this is certainly true.
Progressive disclosure is an effective way to simplify complex content and options, and can also help deal with the lack of hover state. During testing subjects were often observed using the content above the fold to determine what they could do or find on a given page (they absolutely scroll past the fold, but what’s above the fold does largely shape what user’s expect of a given page). It is therefore important that all major options are shown at the top of the page and progressive disclosure is an effective way to ensure this, be it via fold-out boxes, accordion-style forms, pop-out help texts, etc.
3. Mobile vs Desktop
There has been much research and debate about whether all the features and content from the “full-site” also needs to be on the mobile version as well or if it is better to have a specially curated set of content and features for mobile visitors. (Indeed, when calling it “full-site” we indicate that the mobile site is somehow limited or inferior to it.) However, during user testing, a limited set of content on the mobile site version lead to endless misunderstandings, poor shopping experiences and abandonments. Reduced content was particularly problematic when it was the product catalog or help content which was limited.
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? Test subjects were observed to browse around H&M for 10 minutes trying to find the full product catalog, never realizing that H&M only has a very small curated set of 10-20 featured products on their mobile site. These subjects typically abandoned the site either (unjustly) blaming their own browsing skills or thinking the mobile site was broken. Therefore, you should always have all content on your mobile site too.
Features and layout, on the other hand, can (and often should) change on the mobile site. For obvious reasons the layout and formatting of the content should change to be optimized for the smaller screen and touch interaction. Similarly, features may adapt to be more mobile-oriented. For example, geo-location and “send to e-mail for later desktop browsing / purchasing” often make good sense on m-commerce sites. Therefore, you should adapt features and layout to the user’s device screen, input and context.
So in short: Content should be the same, while features and layout can be different. To read more on this see our prior article which discuss mobile vs. full site in detail.
4. Recoverability
During testing we repeatedly observed just how prone the smartphone experience is to inaccurate and accidental clicks, spelling typos, and external interruptions (push notifications, etc). While much of this is beyond your control, what you can influence is how easy it is for the user to recover from these things when they eventually happen on your site. Consider:
How gracefully you handle validation errors – do you reload the entire page and let the user hunt for the one field out of 15 which contains an error, or do you gracefully guide them towards the error? (e.g. error-fields only approach)
How easily does form errors even occur? Do you allow each user input in all common formatting and then just re-format it in your back-end for consistency? Do you suggest proper spellings when you detect a close address match, or only tell the visitor that you don’t recognize the typed address?
How well do you support the native browser back button? During testing we observed an extreme reliance on this feature, with user often going back 5+ times in a row to get to a prior shown product page or search result. Typical places where support for the native back button is important is for getting back to a search query or category page where users applied filters or a non-default sorting direction. Perhaps the most important place to support the native back button (yet unfortunately also where support seems to be the weakest) is during the checkout process: as we mentioned when discussing accordion checkouts, in Footlockers mobile checkout if a user taps the back button e.g. at step 4, he will be taken back to the cart page and not step 3.
Do you allow users to “edit” prior selections and data inputs? If, at the review order step during checkout, a user spots a typo or changes his mind about the order quantity, how easy is it then to edit that info?
Can the user undo critical actions? For example when deleting records or submitting forms, is there an option to undo that action? A major benefit of undo is that you don’t constantly need to ask the user to confirm their action. This makes undo a must-have for productivity apps and the like, but advanced m-commerce site may benefit from undo as well.
Much of the above will require solid technical deployments and rigorous testing. However, it will certainly be worth the investment as poor recoverability generally lead to a very high degree of mobile abandonments due to the severe disruptions lack of recoverability caused in users’ mobile shopping experience.
5. Performance
Slow load times have a significant impact on the user experience and the user’s willingness to explore your site. During the mobile study every single subject complained about poor page performance at some point – with some sites consistently taking more than 30 seconds to load (on a DSL WiFi connection). That’s because mobile website performance is much more than downloading pages and media assets – page rendering and JavaScript parsing take up a significant amount of time too. While this is true of desktop sites / computers too, the problem is much more pronounced on mobile devices due to their inferior processing power. Therefore, you must be particularly thoughtful in the coding of your m-commerce site in order to achieve even tolerable page performance.
Without getting too technical (this is a major topic and thus outside the scope of this article), you will want to look into:
Proper asset caching (make sure all assets are cached infinitely and then simply use timestamps or fingerprints to expire them).
Keep your layouts simple and clean without needless ornamentation that slows down page rendering (for example, only use borders, gradients and shadows on critical elements and when it adds to the user’s understanding of the page or element).
Use native technologies whenever possible (e.g. use the native placeholder input attribute instead of a custom JavaScript solution; same is true for CSS – better use the native border-radius CSS style).
If at all possible, load your JavaScript in a non-blocking manner so the user can see and interact with your page while JavaScript is being downloaded and parsed. Indeed, this last point feeds into an important idea that has gained popularity in recent years: progressive enhancement.
To ensure your site loads fast and feels snappy, have a barebones baseline version and then use feature detection to progressively enhance the page’s features and user’s experience based on the capabilities of the device. As native capabilities are detected, these can be used in place of custom CSS and JavaScript implementations, resulting in vastly better performance (not to mention that native implementations are typically more robust). Progressive enhancement is of course an effective way to support a wide range of devices too, with older smartphones and OS versions seeing the more slimmed-down “barebones” version while newer and more capable devices get your beefed up version.
On the matter of supporting legacy devices, we’re frequently asked about support for “feature phones”. The truth is that if you want to support true feature phones then progressive enhancement likely won’t cut it – these devices often parse HTML and JavaScript so poorly that even the most barebones mobile site will break on them (often not rendering anything at all). If feature phones are therefore an important part of your mobile strategy, then you should develop a separate site for these. We’d also recommend looking into creative alternative services for these devices, such as e-mail and SMS texting to look up information (depending on your business: stocks, weather, product details, etc), reserving tickets or other types of bookings, or even placing orders.
We could go on about performance and support for legacy devices, but suffice it to say that these are absolutely crucial components in the user’s mobile shopping experience. Users feel performance on every interaction and page load – if your site is fast and lightweight, the user will experience your entire site as snappy and responsive; if your site is slow and heavy, every page interaction will feel sluggish and frail.
We’re All Still Learning
Mobile browsing has exploded over the past five years and mobile shopping is right on its heels. But of course five years is little when it comes to establishing best practices for design and interaction and programming. We’re all still learning – researchers, designers, and users alike. Over time users will start behaving more uniformly, giving designers more affordances and best practices to tap into – with UX researchers hopefully speeding up that process by exposing and analyzing user behavior and translating that into useful knowledge readily available for designers. At Baymard Institute we aspire to the latter, and hope that this article series as well as the m-commerce report can provide designers with useful insights, observations and design guidelines that can be put to good and immediate use when venturing into this brave new world of mobile e-commerce.
Post a comment
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
Mobile Form Usability: Never Use Inline Labels
5 High-Level Mobile Commerce Design Considerations
Related articles
3 Examples of Inline Help
8 Limitations When Designing For Mobile