text:
tag:baymard.com,2005:/blog Baymard Institute 2014-11-25T07:04:00+01:00 baymardhttps://feedburner.google.com tag:baymard.com,2005:Article/148 2014-11-25T07:04:00+01:00 2014-11-25T07:04:32+01:00 Product Page Usability: Recommend Both Alternative & Supplementary Products (Only 42% Get it Right)
While there's generally a correlation between good usability and "good for business", there are some instances where the two align exceptionally well. Suggesting both alternative and supplementary products is one of those instances: it's good for business and great for usability. Yet, when benchmarking 50 top e-commerce sites we discovered that only 42% tap into this "match made in heaven".

Users land on product pages for many different reasons and from widely different paths. Often times these users don't yet know the exact product which they need, but rather have an idea of what it is that they want. During our large-scale usability test of e-commerce category navigation we observed how suggestions for alternative products help the user find the "right" product, while suggestions for supplementary products help them find additional items to go along with that product to "finish the package" or "complete the look".

Microsoft doesn't offer any product suggestions on their product pages, making it tricky for users to find similar products (i.e. alternatives) and accessories (i.e. supplementary products).

58% of all major e-commerce sites only offer one of these cross-sells, or show both in the same cross-sell element. This severely limits users because the two types of suggestions serve different purposes. Suggestions for alternative products help increase product findability while suggestions for supplementary items enhance product catalog navigation and awareness. Users benefit greatly from both types of suggestions, and since they complement each other incredibly well, they should both be implemented.

In this article we'll look at the benefits and characteristics of product suggestions for both alternative and supplementary products respectively, and why both types of suggestions are needed, along with 4 implementation details to beware of.

Suggestions for Alternative Products

When users land on a product page and learn that the specific item doesn't match their criteria perfectly, they essentially have two options: 1) abandon the site or product search, or 2) go look for alternatives until they find an item that fits their criteria. Initially, most users will luckily opt for the latter option, continuing their product search, but after a while more and more users will drop off as they fatigue.

Now, users land on product pages from a wide variety of paths – sometimes from a category, other times from on-site search, and perhaps even more often, off-site search, social media links, not to mention "regular" referrals and ads. Yet, what they all have in common is that the user typically chose to open this particular product page so the item typically isn't a far-shot from what they're interested in or looking for either. In short: even if this particular product isn't a match, the user is typically looking for something fairly similar to it. Enter: suggestions for alternative products.

Kohl's lists alternative products with a "More to Consider" sidebar, giving the user quick access to other bedding products in case this particular quilt isn't to their taste upon closer inspection.

Suggesting product alternatives and substitutes are a great way to ease the user's product finding process. Instead of forcing the user to hunt around product lists until they find just the right product, product alternatives lets the user jump from one product page to the next until they find a relevant item. It's an effective way to keep users on product pages, taking them from one related product to the next. This facilitates scope-jumping too, enabling users to find relevant products outside their current category scope, e.g. to a sibling-category.

Ideally the product suggestions are sufficiently similar to remain relevant to the user while also being different enough to potentially match the user's criteria. Striking this balance can be tricky if the suggestions aren't hand-picked by a human being (which can be difficult to scale) but rather auto-generated by the site (which at the very least requires an array of variables to be combined to determine product similarities).

Whether the suggestions are manually curated or auto-generated, keep in mind that the purpose of suggesting alternative products is to help the user find the "right" product. They've landed on a item which upon further inspection wasn't the exact right match, yet because the product probably isn't far off from what the user is interested in either, showing similar product alternatives is likely to help them find what they're looking for.

Suggestions for Supplementary Products

When the user do find the product they want (possibly via suggestions for alternative products!), they often need or want various add-ons or accessories to go along with it. Yet finding such supplementary products can be an incredibly cumbersome task unless they are listed as product suggestions directly on the product page (and below the cart contents on the cart page).

During our usability test sessions we often observe subjects hunt around product pages in search of suggestions for supplementary products after adding the product to their cart – often looking to "complete the package" by e.g. getting a case and memory card to go along with that compact camera they just added, or "finish the look" by adding a pair of pants and shoes to the shirt they just found. In other words, users find recommendations for supplementary products to be available on the product page incredibly helpful and often expect them to be there.

While the "May We Suggest" suggestions for alternative products are great, this test subject had already found a dress (the product page she was currently on) and wanted to "complete her outfit" with a pair of shoes to go with that dress. Unfortunately, Gilt only offered suggestions for alternative products (i.e., other dresses) and not supplementary items (such as shoes, jewelry, makeup, etc).

One of the reasons supplementary product suggestions are so popular among users is because they ease navigation significantly by enabling cross-category scope jumping. Scope jumping is essential when looking for supplementary products because accessories are often located in a separate scope, which is why they are often difficult (or at least cumbersome) to locate from the product page. Suggestions for supplementary products provide a shortcut to those scopes – it's often less about the specific supplementary product suggested and more about accessing its scope via the product page (from which the user can either use the breadcrumbs to navigate to the general category scope or begin browsing any listed suggestions for product alternatives).

This also highlights another important function suggestions for supplementary product: product catalog awareness. By showing product recommendations for cases and memory card on the product page of a camera, the user will be made aware that the site also sells these types of items. This is particularly important for users landing on the page from external sources (off-site search, social media, ads, referrals, etc). It indirectly informs the user about other product categories offered on the site.

Suggesting supplementary products is therefore much more about enabling scope-jumping and enhancing product catalog awareness than it is about trying to suggest just the right accessory, as this can often be an impossible task. Of course, it doesn't hurt to suggest relevant supplementary products but the suggestions are far from useless even if they don't turn out to be the exact accessory the user is looking for.

Users Need Both Types of Product Suggestions

By now it should be clear that suggestions for alternative and supplementary products serve different purposes. The former is about finding the right product (by means of similar products), while the latter is about finding complementary items to "complete the package" (by means of add-ons and accessories).

There's an inherent sequence at play here: if the user can't find the "right" product, it's unlikely they'll begin looking for supplementary items for it. Product alternatives are therefore vital to the user's initial product search and their decision to buy from the site or not. If the user finds a product they like and decide to purchase it from the site, then they'll begin thinking whether they need any additional items to go along with it. That's where supplementary products enter the picture – both in terms of making the user aware that those additional product categories are available on the site and then helping the user easily navigate to those product scopes.

"Something which is similar, that other customers visited or bought", a test subject mumbled to himself when glancing over the sidebar. Tesco helps their users find both alternative and supplementary products by having both an "Others bought these alternatives" and a "Customers who bought this also bought" list in the sidebar on their product page. (They even get the labelling of the two lists right by clearly indicating they are based on the behavior of other customers.)

So while it may be tempting to only have recommendations for supplementary products (as this is where order value is increased), they don't work without suggesting product alternatives too. Also, even though product alternatives typically don't increase order value (items are substituted rather than added to the order), they can increase order volume since they often play a critical role in helping users find products they want to purchase in the first place – a prerequisite to the user purchasing anything at all.

While alternative product suggestions don't depend on supplementary products to work (it's a one-directional dependency), given the obvious business and usability appeals of recommending supplementary products, it's hard to see why any site would want to leave them out. Also, why it might seem like recommendations for supplementary products would be more suited for cross-sell suggestions in the cart, it's actually often better to place them on the product page since cross-sells in the cart can distract users from initiating the checkout process.

The takeaway? Have suggestions for both alternative and supplementary products (although as you'll see in the next section, make sure to keep the two types of suggestions separate).

4 Implementation Pitfalls & Details

While it's only 42% of sites that have both alternative and supplementary product suggestions on their product pages, testing found that implementation details also have a great say in the actual performance of those suggestions.

When implementing suggestions for alternative and supplementary products, there are 4 pitfalls and implementation details to be mindful of to ensure that the suggestions a) match user expectations, b) increase product catalog awareness, and c) enhance cross-scope navigation.

1) Transparency of Suggestions (Matching User Expectations)

During our research studies the test subjects generally respond poorly to product recommendations where it's unclear to them what the suggestions are based on. This has two implications: first, the suggestions should be labelled clearly, and second, the different types of suggestions must be kept separate.

Urban Outfitters mix suggestions for alternative and supplementary products, making it unclear what criteria the suggestions are based on. The problem is worsened by ambiguous thumbnail-only list items which makes it unclear to the user whether the recommendations are for the depicted shirt, pants, or jacket.

Keeping suggestions for alternative products separate from recommendations for supplementary products allows the user to instantly tell the two apart and work out their distinct qualities. Therefore, list the two types of suggestions in separate groups. This way the suggestions can also be given more specific labels, which can further increase their transparency. It's important to note that the two lists of suggestions don't necessarily have to be placed together or even in close proximity to one another.

It's ultimately about setting appropriate user expectations for the suggested products to enable the user to intuitively grasp their respective utility and rationale.

2) Assumptions Regarding Compatibility (Matching User Expectations)

When it comes to product categories where intercompatibility might be an issue, it's incredibly important to label the suggestions very carefully as most users simply assume that any recommended items are compatible with the product they're suggested from (be it on a product page or in the shopping cart).

While Tesco had spot on product suggestions on their product pages as we saw in an earlier example, they unfortunately messed up in the cart. "When they say 'Recommended for you,' I assume they will fit," this test subject explained, referring to the camera cases displayed after adding a Nikon Coolpix pocket camera to his cart. It turns out that one of the two recommended cases actually doesn't fit the camera.

Indeed, during testing the test subjects have generally assumed that any recommended product was compatible unless the suggestions were explicitly labelled as "Other customers also bought" or used similar phrasing which underscored that the suggestions were based on the behavior of other customers and not recommendations coming from the site or vendor. Users expect recommendations from the site or vendor to be compatible, the same way you would expect a salesman to only recommend covers compatible with the phone he just sold you. It's only when making it clear that the suggestions are based on the behavior of other customers that most users realize they have to be careful.

Of course if product compatibility can be guaranteed for the suggestions this isn't a concern. (This is yet another instance where a compatibility database can come in handy.) But if compatibility can't be guaranteed, then make sure to avoid labels such as "Recommended for you" and instead assign the suggestions designations such as "Other customers also viewed".

Note that some product categories of course don't suffer from intercompatibility issues at all. Apparel doesn't have this issue, for instance.

3) Ensuring Product Diversity (Increasing Product Catalog Awareness)

It's important to base the product recommendations on multiple factors to avoid the suggestions becoming overly one-sided. For example, during usability tests, we often observed highly monotonous suggestions when the product recommendations were based on a single dimension, especially if that dimension was behavior-based and for a low-volume product (which has a much smaller behavioral dataset to draw on).

The reason one-sided recommendations are problematic is that they do a poor job of increasing product catalog awareness – which in the case of supplementary product suggestions is their main raison d'être.

The diversity of Newegg's product suggestions is great – notice how the four suggested accessories are all from different categories. This implicitly tells the user that Newegg in addition to cameras also sell: lenses, memory cards, tripods, and backpacks for equipment.

The chances of the specific product suggestions being just the right item the user is looking for are typically fairly low, and the main value of the suggestions is therefore derived from making the user aware of the breadth of the site's product catalog and giving them a shortcut to access those scopes. In other words, a product suggestion can still be incredibly helpful to the user even if it isn't for the exact item they end up buying, because it increases the user's knowledge about the site's product catalog and enables cross-scope navigation.

It's therefore important to ensure a good level of diversity in the product suggestions to give the user the best possible insight into the types of products offered on the site. If an electronics site only recommends laptop sleeves on their laptop product pages, their users won't know if they also sell external hard drives, monitors, stands, and more. To ensure such product diversity, it is typically necessary to base the recommendations on at least a couple of different dimensions (or alternatively set up rules to ensure there's only one product selected from each category, though that approach might suffer from relevancy issues).

4) Accessing Enclosing Categories (Enhancing Cross-Scope Navigation)

As already mentioned, the odds of recommending just the right product to the user are slim, especially when it comes to supplementary items – yet the suggestions are still incredibly helpful because they increase product catalog awareness and enable cross-category navigation.

Because product suggestions are as much about accessing different category scopes and increasing the user's awareness of the site's product catalog breadth, it can therefore be a good idea to link directly to those scopes directly from the product suggestions. This lets the user access the categories directly and saves them from thinking of creative navigation patterns.

While Amazon does a great job of suggesting a diverse set of supplementary products, it's needlessly difficult for the user to access the enclosing categories of those suggestions.

Without direct links to the enclosing categories of the suggested products the user will have to show a fair degree of foresight, following a line of reasoning that goes something like this:

"Ok, so this isn't the exact accessory I'm looking for, but it is the class of accessory product I'm interested in, so I'll open the item's product page anyways, and then from there find some breadcrumbs, and click one of those links to traverse up to the accessory product's enclosing category scope…"

Now, that's a lot more demanding of the user than simply clicking a direct category link.

A mockup of how Amazon could have linked to the enclosing categories of the listed product suggestions. (The category links could also have been added below each individual product recommendation – this approach tends to increase clarity and visibility but can potentially lead to redundancy and hit area confusion unless it's very carefully implemented.)

It's therefore recommended to link directly to the enclosing categories of the suggested products (a strategy that should be considered for any featured product), either with links below each product suggestion or at the bottom of the section of recommendations (as depicted in the above mock-up).

Also note that while this is of course the most useful for suggestions for supplementary products which almost always reside in a completely different category scope, links to enclosing categories can also be helpful for alternative product suggestions which reside in sibling categories or for substitutes that are placed elsewhere in the site's hierarchy.

Avoid Trapping the User

At the end of the day, implementing suggestions for alternative and supplementary products is a way to increase the user's product catalog awareness as well as enable lateral site navigation and cross-scope jumping. This lowers the risk of users getting trapped in a category that's potentially too narrow for their product needs.

By combining the both types of product suggestions, the user is made aware of other categories and product types available on the site and they are empowered to easily access and explore those options. This is why both types of product suggestions are needed. Yet in order for them to work optimally, it's also important to consider the four above implementation details:

Transparency of Suggestions – Make the criteria which the suggestions are based transparent to the user.

Assumptions Regarding Compatibility – Avoid using labels such as 'Recommended' unless product compatibility can be guaranteed.

Ensuring Product Diversity – Maximize the user's product catalog awareness by suggesting products from a diverse set of categories.

Accessing Enclosing Categories – Enhance cross-scope navigation by linking to the categories of the suggested products.

Tip: Want product page inspiration? Browse 50 different product pages from top e-commerce sites in the public part of our Homepage & Category benchmark.

Post a comment

Related articles

Homepage Usability: Can Users Infer the Breadth of Your Product Catalog?

Featured Products Should Also Link to Their Categories (43% Get it Wrong)

Mobile Product Pages: Always Offer a List of Compatible Products

 Jamie Appleseed http://baymard.com/blog/product-page-suggestions tag:baymard.com,2005:Article/147 2014-11-04T07:37:00+01:00 2014-11-24T15:02:32+01:00 Form Usability: Getting 'Address Line 2' Right

While 'Address Line 2' may seem like an insignificant aspect of an e-commerce design or overall form design, we have observed this form field to be the cause of bewilderment and uncertainty for users during both our checkout usability and mobile e-commerce research studies.

Now, it should be noted that 'Address line 2' was never observed to be the direct cause of checkout abandonments during any test sessions. Poor 'Address line 2' designs did however contribute to a sub-par form filling experience during both studies, as the test subjects spent excessive time filling out forms or typed correct input in a wrong field, resulting in needless validation errors and warnings.

Given how easy it is to design a user-friendly and unambiguous 'Address line 2' field, it's worth taking a moment to fix it – it really is one of those low-hanging fruits in checkout and form design. In this article we'll therefore go over 5 tips to get the 'Address line 2' right.

1) Understand Current Usage

The first step is to query your order history and figure out how much the 'Address Line 2' field is currently being used, who is using it, and the type of information they are filling into the field. Understanding the field's current usage and utilization rate will be important when we turn to the field design options later on (tip #3).

The first step to getting the 'Address Line 2' right is understanding its current usage: which customer types are using it and what type of information are they entering into it? This data can easily be extracted from your order database for analysis.

Figuring out how much the field is currently being used should be fairly a straight-forward matter of querying your database and can therefore be determined with little manual effort. Understanding who is using the field and the type of information these users are entering into it, on the other hand, requires some data analysis. Things to look for are specific user types, customer demographics, and order types (business address deliveries, international orders, metropolitan areas, etc).

All of this can prove valuable insights when it comes to optimizing the field context (tip #2) with precise labelling and useful instructions and placeholder text. It may also help you better predict any edge use-cases (and by virtue thereof, better support those).

2) 'What Goes Where?'

The most commonly observed issue with the 'Address Line 2' field during our usability test sessions are field ambiguity, with users often wondering "should I enter company name, PO box, military address, or a C/O address in line 1 or 2?"

Even something as common as an apartment address, where it's clear that street name and number should go in the first address field, we time and again see test subjects turn doubtful as they have to type a floor level or room number.

Is floor level or room number supposed to go in address line 1 or 2? (Microsoft's checkout)

While one could argue that users are free to type this information in whatever field they prefer, we have repeatedly observed how users will go to great lengths to try and preempt validation errors during the checkout process. Most users feel very uncomfortable when presented with validation errors during checkout as they are entering highly sensitive information (their identity, often home address, and credit card details), and they therefore strongly prefer to follow a "safe example" and proceed successfully the first time around rather than guess by trial and error.

Thus to avoid making the user at unease during checkout, it's a good idea to give them examples that are "safe to follow" (since they otherwise have no idea if you require a special sequence or formatting).

With additional label descriptions below the two address fields it's easy for the user to know what goes where. (Amazon's checkout)

The "best practice" implementation of this is to provide an additional label description and input examples either in direct conjunction with the field label or below the "Address Line 2" field itself. Typically in a secondary smaller and greyed out font, specifying that this is the place for "Apartment no., C/O addresses, floor level, Att., PO box, etc". Meanwhile the placeholder text can be used to provide actual input examples (e.g. "Chestnut Street 2125").

(Note that this advice isn't exclusive to the 'Address' fields but goes for most form fields during the checkout process – form fields almost always benefit from additional label descriptions and examples.)

3) Labelling: Avoid 'Address 2'

'Address 1' and 'Address 2' is open to being misinterpreted as two different addresses – in fact, being strict it wouldn't even be a misinterpretation as that labelling actually suggest two different addresses if read out of context (commonly observed on mobile checkouts).

While misinterpreting the two fields as two separate addresses is not the most frequently observed issue, it does happen. Mostly for users who've been perplexed earlier in the checkout experience, and especially when testing users not native in english, or on sites which by their nature often require multiple addresses (e.g. gift and flower sites which often have both a 'giver' and a 'receiver', or orders with different billing and shipping addresses).

The 'Address 1' and 'Address 2' labels on Target could potentially be misinterpreted as fields for entering two separate addresses.

So while this sub-issue of misinterpreting the address fields as two different addresses is low in frequency, the severity of it when it does occur is very high. Indeed, we've observed it to result in completely shattered checkout experiences and lead to orders being completed with invalid shipping data.

Therefore to avoid this potential ambiguity, be sure to label the fields 'Address Line 1' and 'Address Line 2' respectively. (This once again underscores the importance of microcopy).

4) Explicitly Denote 'Line 2' As Optional

During our usability research studies we continue to observe just how singularly focused users can be. This is particularly true of form fields where users often focus only on the field they are currently filling out, largely ignoring the other fields in the form.

It's therefore important to good form usability that each field can be understood in isolation, and for this exact reason it's insufficient to simply mark all required fields with an asterisk. Any optional fields should be explicitly denoted as such too, so that users can read the field label and understand its context and conditions without having to infer them from surrounding fields.

Nike doesn't indicate which fields are required and which are optional, making it unclear if both address fields must be filled out.

Thus the proviso for both address fields should be explicitly denoted: the 'Address line 1' field must be marked as required and 'Address line 2' as optional. It may seem like a small detail, but it's actually especially important to get right for the address fields because they are related, and some users may therefore assume that if 'line 1' is required then 'line 2' is as well.

5) Consider Merging or Hiding 'Line 2'

If you've found there's a low utilization rate for the 'Address Line 2' field, you can consider removing or hiding it entirely. There are two dominant approaches.

Crutchfield does away with the address field ambiguity issues altogether by having just a single 'Address' field.

If you don't need to distinguish what data belongs to each address line, the most simple solution is to consider just having a single 'address' field. Depending on address standards and the postal service companies available where you operate, it may not be necessary to distinguish between address line 1 and 2.

Alternatively, the address field could also be made into a multi-line field, allowing the user to enter multiple lines while keeping the form design to a single (slightly larger) 'Address' field.

The new VISA Checkout displays a single 'Address' field by default to keep the form design simple, but with an embedded '+' icon allowing the user to add a second address line if they need to. (Do however note that icons can be ambiguous so if option for this solution make sure to provide a clear tooltip / hover text description.)

If you do need to be able to distinguish between address line 1 and 2 – whether the reason be for address validation mechanisms, shipping partners, or something entirely else – yet don't want to put too much attention on the field, you may consider a dynamic approach where the user adds the second address line themselves. This way the edge case users who are looking for the feature will be able to provide their address in multiple lines whereas the average users only has to deal with a single 'Address' field. (That said, some users won't notice this feature and simply fill all information in address line 1, so be prepared to handle those cases gracefully.)

Getting 'Address Line 2' Right

The 'Address Line 2' field certainly isn't that one single thing that will make or break your entire checkout experience. It is, however, one of those 10-20 smaller improvements that it takes to lift a checkout experience from good to great.

You should of course always start by getting the basics right. But once you've got that solid foundation in place, it's time to focus on the details. The 'Address Line 2' is one of those details. So make sure you:

Understand the field's current usage: which customer types are using it and what are they entering into the field?

Use additional label descriptions and examples to clarify what data goes into address line 1 and 2 respectively.

Clearly label the fields 'Address Line 1' and 'Address Line 2' (rather than the potentially ambiguous 'Address 1' and 'Address 2').

Explicitly mark 'Address Line 1' as required and denote 'Address Line 2' as optional.

Consider merging the two fields or hiding 'Address Line 2' if the distinction is only necessary in a few edge cases.

Tip: If you want to browse 97 different address forms from top retailers, you can do so in our Checkout Usability Benchmark sorted by Checkout Step Type.

Post a comment (9 so far)

Related articles

Add Descriptions To Checkout Form Labels (92% Get It Wrong)

Mobile Form Usability: Never Use Inline Labels

6 Mobile Checkout Usability Considerations

 Christian Holst http://baymard.com/blog/address-line-2 tag:baymard.com,2005:Article/146 2014-10-21T07:03:00+02:00 2014-11-03T14:49:15+01:00 Form Usability: The Pitfalls of Inline Accordion and Tab Designs
During our e-commerce research studies, particularly on checkout usability, we've found that tab-style and inline accordion form layouts can inadvertently confuse users, or even flat out violate their expectations.

The issue arises when users can't figure out which form fields will be submitted – whether it is only the fields in the currently active inline accordion or tab "sheet", or whether the collapsed "sheets" will be submitted as well.

In this article we'll dive into the observations from our test sessions, highlight the issues and design affordances that both inline accordion forms and tabbed form layouts produce, and touch upon some design alternatives.

During our mobile e-commerce study multiple subjects had issues with inline accordion forms, where other fields were placed above and/or below the accordion element or where the sections could be open and close ad-hoc. A good example of this is Footlocker's shipping methods – presented in an inline accordion form – which troubled the test subjects who were confused by the three options, how to select between them, and how the buttons were related to the fields in the inline accordion sections. For example, will the button 'Update' save just the three fields, or also the info typed in the other accordion sheets (collapsed), or will it update the entire page?

Similar issues are present in tabbed form designs where it's often not immediately apparent if the changes will need to be saved before going to the next tab, or changes can be made to all tabs before saving the form.

When designing user-friendly form layouts it's key to ensure that the user always instinctively knows which form fields will be submitted. Now, typically this is a non-issue since users assume all form fields will be submitted, and on most sites they are.

However, tab-style and inline accordion form layouts can muddy this relationship, making it unclear if the fields in each "sheet" are mutually exclusive or if switching between them simply toggles their visibility but not the actual form. This can make users uncertain as to which fields in the form will actually be submitted, which is highly problematic as this leads to a sense of unpredictability and the fear of potential data loss (obviously very undesirable sensations to invoke in a user filling out your forms, e.g. during the checkout process).

Lack of Predictability for Accordion and Tabbed Forms

Common questions that tab-style and inline accordion form designs invoke in users include:

"Do I need to save the changes before I open another tab?"

"Is it only the options that I'm currently seeing that will be submitted or will it submit all sections (including the 'collapsed' ones)?" (i.e. is it a partial or a "full" submit)

"Will clicking one of the other sections cause the page to reload, and if so, will the other entered data be persisted?"

Now, sometimes the options will logically imply whether they are mutually exclusive or not. For example, with payment options it is typically clear that they are mutually exclusive: either you pay with credit card or PayPal, but it's important to note that in these cases it's the content and not the design that's driving the affordance. Therefore, whenever the content could potentially be interpreted either way, it will be, and confusion and uncertainty is bound to arise. In fact, even the aforementioned "payment options" example could potentially be confusing since some sites actually do allow multiple payment types to be combined.

Another example of a tabbed form design that can cause confusion. As users make changes, will they need to click the bottom 'Save Changes' button for each individual settings tab? Or does the 'Save Changes' apply to all of the tabs?

Good usability is about predictability – does the user understand what will happen when they take XYZ action – i.e. can they accurately predict the consequences of a given UI interaction? Tab-style and inline accordion form designs tend to fail this test. It's the same reason multi-column form designs can be troublesome – users may become in doubt if all columns will be submitted or only one of them. With inline accordions and tab-style forms, users often can't tell if the "sheets" are mutually exclusive or if they are simply toggling their visibility.

Unlike an inline accordion form, a sequential accordion checkout design can work well because the user is able to see their input being saved as they work their way through the checkout flow. (Here, Apple's checkout process.)

This is why accordion checkout designs tend to work just fine, while inlined non-flow accordion designs cause trouble. When the accordion design is sequential and progresses the user from page to page (e.g. an accordion checkout process), it's clear that only the current section will be submitted, while previous sections display summaries of the entered data letting the user know they have already been saved, while the future sections won't be clickable at all as the user hasn't yet progressed to them. It's a linear flow that the user works their way through, step by step. (Indeed, our research finds that users perceive accordion steps as separate pages which is why it's so important to adhere to the user's back-button expectations when adopting this checkout design.) This stands in contrast to inline accordion forms where the user can open and close sections ad-hoc and where there may even be other form fields above and/or below the accordion element. Because of the indiscriminate section access, it isn't obvious what has been saved and what will be saved. Tabs of course suffer much the same fate.

Design Affordances for Accordion and Tabbed Forms

If an inline accordion or tab-style form layout must be used, there are some subtle design affordances to be aware of. It's key that the design affordance of these form layouts align with their actual technical behavior and implementation.

Left: Sheets open and close independently of each other, allowing multiple sheets to be open at once. Right: Only one sheet can be open at a time.

For accordion designs, it is possible to visually have multiple "sheets" be open at once (i.e. sheets open and close independently of each other – see left-hand example), or the implementation can restrict the accordion to only have a single sheet open at a time (i.e. opening a new sheet automatically collapses the currently active one – see right-hand example).

This creates an affordance as to whether all sheets or only the currently active one will be submitted. Allowing multiple open sheets suggests that all sheets will be submitted, although the user may be unsure if only the open ones will be submitted. If only allowing one sheet to be open at a time, most users will assume that only the active sheet will be submitted since the other fields auto-close whenever a new section is selected (i.e. the interface is mutually exclusive, therefore the options are perceived so too).

Tab-style form designs are a little more tricky because visually only one tab can be "open" at any given time. It doesn't have the same affordance available as the accordion-style design, making it more difficult for the user to figure out whether all tabs or only the open one will be submitted – the design can't imply this through its interface / behavior.

Accordion- and tab-style forms do however share an affordance when it comes to the primary button (i.e. 'Save' button). When the button is placed within the active sheet, it suggests only that sheet will be saved when it's clicked. However, if the button is placed outside the form element, things get a little more complicated. For tab designs, it suggests that all tabs will be saved. Whereas for inline accordion designs that allow multiple sheets to be open at time, it still remains unclear to the user whether the collapsed sections will be saved or not – the design only allows them to feel certain that the currently open sheet(s) will be saved.

Better Alternatives

So given these UI weaknesses of tab-style and inline accordion form designs, what are the appropriate alternatives?

If the content isn't mutually exclusive, consider simply listing all of the fields on the page or splitting them out across multiple form steps. Our research shows that good checkout usability isn't about the number steps but rather how user-friendly those steps are. Whether you have a 2 or 4 checkout steps doesn't matter that much, what matters is what users have to do at each step, and how they are asked to do it (i.e. are users able to seamlessly progress through the steps).

At Best Buy, radio buttons are used to indicate that the payment tabs are mutually exclusive. In the case of ad-hoc (non-exclusive) behavior, checkboxes may be used instead.

Alternatively, standard form elements like radio buttons and checkboxes can be used or integrated into the design. Since these standard UI elements have at least a decade's worth of consistent web usage, the vast majority of users will be able to instantly recognize them and intuitively grasp the form's behavior because of the strong usage connotations tied to those standardized UI elements.

For example, if the content is mutually exclusive, then use the standard UI element designed to indicate this: radio buttons. These can be integrated into a tab-like design, but it's important that the radio buttons are an integrated part of that as they clearly set user expectations. (Just make sure to watch out for potential radio button proximity issues, as described in Checkout Design: Payment Method Selection.) Meanwhile if the sections are optional and multiple may be submitted at once (i.e. ad-hoc behavior), checkboxes would be the way to go.

It all boils down to that core usability principle of predictability: when seeing and interacting with the form, will all users instinctively know what will happen? Is it clear what data has been saved and what will (and won't) be saved? Tapping into standard UI elements such as radio buttons and checkboxes can help clarify such form behavior – although a perhaps safer strategy is to avoid designs which provoke such concerns in the first place.

Post a comment (8 so far)

Related articles

Accordion Style Checkouts – the Holy Grail of Checkout Usability?

Form Field Usability: Avoid Multi-Column Layouts

4 Design Patterns That Violate Back-Button Expectations

Checkout Usability: Don't Use "Apply" Buttons (72% Get it Wrong)

Checkout Design: Payment Method Selection

 Jamie Appleseed http://baymard.com/blog/accordion-and-tab-design tag:baymard.com,2005:Article/145 2014-10-07T07:24:00+02:00 2014-10-09T14:46:55+02:00 Fixing Bugs – the Next 'Big Thing' in E-Commerce?

Technical errors can obviously be highly problematic as they can prevent the user from proceeding. Here Amazon is asking the user to fix a problem that isn't there.

Bugs can be pure poison to e-commerce sites. Layout bugs and flawed interactive features not only leaves a poor impression on users but can in some cases even lead them to think the site has been hacked. Page errors and site maintenance are even more disruptive as they can outright prevent users from proceeding.

During our usability studies we repeatedly get to observe just how impatient and unforgiving users are of such layout bugs, faulty interactive features, page errors and site maintenance. In fact, when faced with page errors and site maintenance, nearly all of the test subjects during our checkout studies abandoned their purchase.

"This looks a bit strange. Especially when you are about to pay", a subject explained during testing of Foot Locker, "This makes you think of some phishing or whatever." Layout bugs can make some users believe the site may have been hacked and are thus particularly critical when they appear on key pages and paths (such as the checkout process).

We've similarly observed how seemingly innocent layout bugs and quirky interactive features have caused test subjects to believe the site had been hacked or wasn't currently working properly, causing them to abandon their purchase due to a lack of trust in the site, even for major brands such as Amazon and Walmart. (If a user believes your site has been hacked, having even the most trustworthy of brands won't matter because they no longer think it's you.)

Despite just how critical these bugs can be to the user experience and site conversions, they are astoundingly common. For the past 5+ years we've conducted 4 large-scale usability studies and every single time the test subjects have stumble into a wide host of UI bugs and server errors, and for the past 3 years we've audited numerous multi-million and billion dollar sites and during every single site audit we've identified lingering technical errors, layout bugs or flawed interactive features (despite always testing in up-to-date browsers).

Server bugs and downtime are obviously critical too but they tend to be a lot easier to monitor with automated alerts bringing the issue to everyone's attention, making it obvious that something needs to be done urgently.

Now, if a server is down, the entire organization turns upside down with everyone rushing to fix the issue. Yet, layout and interaction bugs get to linger around for months or years before they're fixed. It's largely a visibility issue – if people in the organization knew about the bug, it would surely get fixed. However, because in-depth testing and quality assurance often isn't prioritized sufficiently, these bugs can go unnoticed for months.

Server errors and 404 pages are easy to monitor but they only represent a fraction of the bugs that we encounter when reviewing e-commerce sites. The much more common but unfortunately also trickier-to-spot bugs that are at the center of this article are the CSS layout bugs and flawed interactive JS-enabled features. Such layout bugs or interaction quirks don't invoke a server alert and therefore aren't brought to anyone's attention, making them much more difficult to identify – yet that doesn't mean their impact isn't just a harmful as a server outage.

Layout bugs on key pages can scare away users; especially those that haven't yet committed to buying a product are likely to simply head over to a competing site rather than try calling customer support if they feel unsure about the site.

Now, obviously nobody intentionally implements buggy features or deploy technical errors. Yet they undeniably happen, at major and minor sites alike, and the price tag is undoubtedly in the million dollar category. While some degree of bugs is probably unavoidable, and bugfixing like most other investments is subject to diminishing returns, nearly every single production site we've reviewed could benefit greatly from making it a bigger priority. But given resource constraints, where should e-commerce owners and developers focus their energy?

The rest of this article will outline strategies for how to deal with these types of bugs in a deliberate manner. In summary, there are three principles to follow:

In general: Focus on common and critical paths first, and revisit them regularly. (Typically: product pages, checkout process, search results and engine, homepage, popular categories, and the help section.)

In dealing with layout bugs and flawed interactive features: Minimize their occurrence by building a rock-solid foundation instead, and then progressively enhance that baseline with increasingly sophisticated features based on device and browser capabilities.

In dealing with server errors and site maintenance: Minimize their pain by making it as easy as possible to recover from page errors (e.g. via client-side data persistence), offering the customer useful alternatives (e.g. completing the order via phone), and incentivizing customers (e.g. with coupon codes) to make them return to your site later once it is working again.

1) Focus on the Critical Paths First

In e-commerce, the chain really is no stronger than its weakest link. You might have brilliantly designed product pages, but if the checkout process is ridden with bugs, potential customers will still abandon. And similarly, you may have a great checkout process but if users find your site suspicious or misinterprets product features due to layout bugs on the product page, many will never stick around to actually breeze through that brilliant checkout flow.

Now, for sites with thousands of pages, it may not be realistic to regularly test them all across a range of different use contexts, browsers and devices. However, sites should at the very least test all their key pages and processes on a weekly basis. Having bugs in the checkout process is simply unacceptable.

Here a front-end coding bug results in a rather contradictory set of messages to the user: first the user is told to review their address to ensure its accuracy, then a bolded line states "Address is not correct", then the user is told that they must "enter a valid street number", and finally, a new bolded line states "Address is correct", followed by a button asking the user to "Confirm address". Confused yet? Having bugs like this in the checkout process is a sure-fire way to drive up abandonments.

In general, e-commerce sites should focus their energy on all critical paths – pages and processes that all users must go through in order to purchase from the site. Specifically, this means the product page, cart, and checkout process. Once these have been thoroughly tested and are largely bug-free, other well-trodden paths (such as the homepage, search engine, search results page, popular categories, and help section) should be put through the testing mill.

Of course, a lot of these bugs tend to get squished during development and testing, and possibly shortly after larger deployments where some sites perform extra testing on their production systems. Yet, given how frequently these types of bugs pop up, it would seem that they often appear after those major deployments (for any number of reasons), and on-going testing of key pages in the production environment is therefore required. These pages and processes should be revisited regularly – preferably once a week – for testing across a range of browsers and devices. Furthermore, make sure to test the live production site rather than a test environment to ensure you get the exact same experience as your customers.

Amazon's sign in form provokes security errors. Toys'R'Us' checkout process yields errors for perfectly valid phone numbers. Footlocker's checkout has boxes flying around the screen, covering the 'continue' button and key information. Fandango tells the user they couldn't charge their card, but doesn't give them a way to try a new one. These aren't exactly minor errors, on obscure pages, on miniscule sites…

During our most recent usability audits we've run into checkout errors such as: the browser back-button breaking user expectations in accordion flows, credit card type detection only working when the card number is written without spaces, "Learn more" links opening the wrong help pages, the "Different billing address" checkbox not working when going backwards in the checkout flow, an "SSL Security" help page hijacking the entire checkout window, and users getting error pages when returning from a 3rd party payment page, and the list just goes on and on. The fact that these types of errors occur frequently during the checkout process on live production sites of multi-million dollar brands, underscores the importance of continuous on-going testing of key pages and processes.

In short: Focus on common and critical paths first, and revisit them regularly.

2) Layout Bugs and Flawed Interactive Features: Minimize Their Occurrence

Given the diversity of browsers and device capabilities out there, it's probably unfeasible to completely avoid bugs and flaws in the increasingly sophisticated layouts and interactive features that e-commerce sites are sporting. What we can do is minimize their occurrence by adopting good web design and development principles: in particular, progressive enhancement.

In short, progressive enhancement is when you gradually enhance a basic "baseline" user interface with increasingly sophisticated features based on the capabilities of the browser and device displaying it. This allows the site to always work perfectly fine in older browsers and on less capable devices because they are only tasked with displaying layouts and features they were designed to handle.

Meanwhile, users with a more modern browser will receive the more sophisticated layouts and features supported by their browser. Similarly, if a device has GPS capabilities, anyone visiting the site from such a device can be presented with geo-location features while users on devices without GPS will have to be asked to enter their location.

Here a layout bug is causing the focus outline of a field below the calendar widget to be displayed atop of it – causing the user to think a different date range had been selected.

Instead of relying on native technology to display input placeholders, BestBuy has rolled its own buggy solution which in older versions of iOS caused the placeholder text to behave as user input, forcing the user to delete the entire placeholder example before they could enter their own input. A better solution would be to progressively enhance the user interface with placeholder text in browsers that support the feature natively.

One of the benefits of progressive enhancement is that native technologies can be used instead of trying to simulate them with complex and error-prone CSS and JS. Native technologies tend to be incredibly well-tested and highly reliable (e.g. CSS3 animations, HTML5 History API, etc), as long as you only utilize the 'stable' features in the browsers and devices that support them. But what about browsers and devices that don't support them? They simply receive the simpler baseline interface elements.

A checkout process doesn't need a sophisticated grid layout or animating transitions between steps in an accordion layout. Of course these things can certainly make the user experience better – but only so when implemented flawlessly and displayed on devices and browsers that were actually meant to handle those features.

Decorative images can certainly make for a nicer layout but they aren't essential, so if they end up being misplaced due to advanced layouts the device isn't capable of handling, they will end up having the exact opposite effect and actually worsen the user experience.

By upgrading the user interface in accordance with the capabilities of each user's particular browser-device combination, the optimal user experience is ensured. They get the admittedly simpler but rock-solid and lightweight baseline elements in the areas where their browser-device combination is limited, while other areas of the page are upgraded to take advantage of more sophisticated features that the combo was designed to handle. This greatly limits the chance of layout bugs and flawed interactive features and ensures that the interface is as performant as possible because the user's browser and device are only ever asked to do things they were designed to handle.

All of this is done without compromising on the design or user experience, as devices capable of modern sophisticated layouts and features will receive those. In fact, because less capable browsers and devices don't have to support those features, new technologies can be adopted much more quickly, allowing sites to take advantage of the latest and greatest web design and development features.

Sites must be careful when reusing media assets and styles across mobile and desktop sites (particularly common problems include oversized images and illegible text), and try to avoid reliance on 3rd-party plugins.

In addition to adopting progressive enhancement and relying on native technologies, it's generally a good idea to build to be mindful of how media assets and styles are shared across device contexts. For instances, if reusing media assets on both desktop and mobile sites, it's key to develop and follow strict content guidelines to ensure text legibility. Also, when dealing with responsive web design, setting smart CSS defaults is particularly important to ensure good scaling of images and text across devices and contexts.

Also, try to avoid or at least limit the reliance on 3rd-party tools and vendors (and ads!). The problem with having these external plugins at the center of a design is that their unavailability can bring down key processes of the site regardless of how bug free your own code is. Again, implementing these 3rd-party resources following the principles of progressive enhancement ensures this won't happen – by only using external tools to improve the user experience if / once they load, users will be able to use your site perfectly fine even when they don't (i.e. their servers are down, code is buggy, etc).

In regards to running A/B tests, it's important to note that any layout and technical quirks will silently invalidate the results, leading to false conclusions about which test version is actually better. Monitoring the experiment performance across browser type and versions, and device types, can help spot any such edge-case quirks.

In short: Forget about fancy and advanced designs and features – focus on building a rock-solid foundation instead, and then progressively enhance that baseline with increasingly sophisticated features based on device and browser capabilities.

3) Server Errors and Site Maintenance: Lower The Pain

Now, we'd be remiss not to touch upon server errors and site maintenance, things that take down the entire site and prevent the user from proceeding. Obviously these should be minimized to the extent possible – that's a given. However, if we accept that some degree of server errors and the occasional site maintenance is unavoidable, then the question should be: are there ways to make that experience a little less painful?

There are three fundamental approaches to lowering the pain of blocking server errors and site maintenance: A) Make recovery easy, B) Offer alternatives, and C) Incentivize users to return at a later stage.

Server errors during checkout can be particularly upsetting to users – both due to the anxiety produced by errors happening when you're about to enter sensitive information (e.g. credit card details), and because of the potential data loss involved.

Making recovery easy (#A) is a matter of making sure the user can seamlessly resume where they came from once the error has been fixed. A key aspect of this is preventing data loss. This can obviously be challenging in the case of server errors because the error can blast the usual data persistence mechanisms, causing the user's input to be lost. However, there are ways to prevent this by temporarily storing the user's input in a client-side database (check out localStorage) until the server responds with a success message. (Just make sure to implement this using progressive enhancement so it doesn't break older browsers!)

Compare the Walmart error to Macy's "Back in a few.." site maintenance page – one leaves the user with little other to do than leave the site, whereas Macy's give their users alternatives such as calling customer service.

Error pages aren't created equally. Offering users alternate ways (#B) to complete their goal or interact with your brand can be a great way to minimize the pain introduced by server errors and site maintenance. This can help salvage otherwise lost sales and turn a bad experience into a positive one.

"Bribes" are a great way to get customers to wait for your site to get back up again.

Incentivizing users (#C) with coupon codes or similar offers can give them the necessary incentive to wait for your site to return to normalcy. This is especially true for sites selling generic products that can be bought from other sites as well – here a coupon offering 10% off their order will give them a reason to wait for your site to get back up instead of simply heading to a competitor whose site is working.

In short: When errors do happen, make it as easy as possible to recover from them (e.g. via client-side data persistence), offer the user alternatives (e.g. completing the order via phone), and consider incentivizing users to return later with coupon codes or similar offers.

Make Testing A Priority

The numerous examples littered throughout this article should help illustrate the diversity of e-commerce bugs and how commonplace they are even on sites with millions of dollars in revenue. Clearly it's time to make testing a priority.

While most of the clients we work with tell us that testing is an integrated part of their development process, we often find that it isn't treated as an independent, on-going strategy. This is problematic because layout bugs and flawed interactive features are often introduced during smaller, on-going site updates, A/B test versions, and sometimes even caused by browser changes. Therefore, these very common yet difficult-to-monitor bugs often find their way into production sites and stay there for months because there isn't a procedure in place for continual testing of key pages and processes to uncover such bugs.

Even major brands have fundamental flaws in key processes – here a blank field in AVIS' booking process (what on earth are you supposed to enter there!?), and a rather unhelpful error message on United Airlines.

So before throwing yet another bunch of resources towards "the next big thing", maybe it's time to allocate a few people to finding and fixing bugs every now and then. Fix the holes in the leaky bucket rather than giving it yet another coat of glossy paint. And when you do, consider following the three principles outlined in this article:

Focus on the most common and critical paths first, and test them regularly.

Minimize the occurrence of layout bugs and flawed interactive features by building a rock-solid foundation and then progressively enhance it.

Minimize the pain of server errors and site maintenance by making it easy to recover from them, offering the user alternatives, and incentivizing them to return with coupons or similar offers.

Post a comment (2 so far)

Related articles

UI: Getting the Details Right

Handling Technical Glitches Without Losing Sales

4 Design Patterns That Violate Back-Button Expectations

How to Recoup 30% of "Card Declined" Abandonments

5 High-Level Mobile Commerce Design Considerations

 Jamie Appleseed http://baymard.com/blog/bugs-and-user-experience tag:baymard.com,2005:Article/144 2014-09-23T08:34:00+02:00 2014-10-10T13:47:02+02:00 Form Usability: Validations vs Warnings

There's a major difference between form validations and warnings. Form validations enforce a set of rules and won't allow the user to proceed, while warnings alert the user about possible problems but will allow them to proceed.

While e-commerce sites would do well in adopting both strategies, it's unfortunately few that make use of warnings (our checkout benchmark study found that 64% don't have 'address warnings'), and similarly regrettable we often observe sites enforcing overly restrictive form validations that completely block a (small) sub-group from completing their purchase.

Validators: "Incorrect E-mail!" (Obstructive)

The problem with form validators is that they effectively block the user from proceeding. This, of course, is their purpose, but unless the validation rules can be and are implemented 100% flawlessly (i.e. zero false negatives), users will eventually run into unintended roadblocks.

Here an e-mail validator rejects any input with a '+' character in it. Now, while this may be an uncommon character in e-mail addresses, it certainly isn't invalid. This validator unfortunately locks out any user with such an e-mail (a warning would have been a better option).

During usability testing, one of the most common examples we observe of this are e-mail validators during the checkout process. Here, users with atypical (but real and entirely valid) e-mail addresses are blocked by overly sensitive e-mail validators that effectively prevent the user from finishing their checkout (barring they go create an entirely new e-mail account simply to purchase from this one particular store).

Of course, that's not to say that validations don't have their merit. For example, it's great to validate that required fields aren't left empty, that numeric inputs are indeed numbers and dates are within required ranges. What's key here is that those types of rules can be implemented flawlessly – implementing a system that checks if an input field is empty, whether a numeric input indeed contains nothing but numbers, and that a credit card hasn't expired are all possible without invoking false negatives.

E-mail validators can be great too, they just have to be a lot more forgiving, because they are extremely difficult to validate meticulously without provoking false negatives. This is true of most open-ended text inputs. For example, while the inclusion of characters such as '+' and '_' will often indicate that the user misspelled, they are valid characters in an e-mail address and having a validator invoked on them will therefore be disastrous because it locks out all users with those characters in their e-mail address from using the site. Any validations therefore must be very basic and forgiving lest they run the risk of locking out users.

In fact, the inspiration for this article came after we've conducted site audits for three completely different and unrelated sites – all with more than $50 million in online sales – and none of them allowed users to have a '+' in their e-mail address.

But without strict validations how can sites ensure high-quality customer data with minimal typos and errors? The answer is warnings.

Warnings: "Are You Sure?" (Confirmation)

Form warnings are fundamentally different in nature from validators as they only alert the user to potential problems but doesn't prevent them from proceeding. This makes warnings ideal for inputs that tend to follow certain patterns yet can't be validated without invoking false negatives.

Take our earlier e-mail validator example. While only the very most basic rules should be enforced (e.g. checking for the existence of an @-character followed by a domain) a whole host of typical e-mail patterns can be checked for to determine whether the entered e-mail address is likely to be misspelled (e.g. the inclusion of uncommon characters, or a top-level domain not matching the usual options), and if so, a warning can be displayed, asking the user to double-check their input and make sure it is correct. The user may even be asked to re-type their input into a confirmation field on an 'error-fields only' page.

Walmart uses an address lookup database to detect possibly unrecognized addresses and suggest known ones that are similar. Also note how they let the user know that a recognized address will ensure the "order arrives on time".

The trick is to warn the user without obstructing them – you want the user to double-check and verify what seems to be an unlikely input without preventing them from proceeding if they so wish. Indeed, the user may even be alerted to the potential consequences of erroneous input, and be asked to "proceed at their own risk".

Because of the non-obstructive nature of warnings, sites can go a whole lot further in what invoke them (compared to validators). Alerts may be set for an e-mail address that appears flawed or a phone number seems off – even uncommonly short (2-3 characters long) street and city names could invoke warnings.

Target asks their users to verify potentially problematic addresses instead of denying them from proceeding. They even indicate what the issue might be.

Furthermore, warnings may prove particularly useful on mobile sites where our mobile usability study shows that users are even more likely to provide erroneous input due to mistyping, auto-(in)correct, and misinterpreted fields (provoked by a lack of context).

Ideal Partners in Crime

Form validations are great for any pattern that can be checked against without producing false negatives yet fall come up short in dealing with data that is likely to be wrong even if it is technically valid. Meanwhile form warnings offer us a great way to catch potential misspellings and seemingly erroneous input without unintentionally creating impenetrable barriers to those users who happens to have an uncommon e-mail address, live on a street without a street number, or in a country where phone numbers are only 7 digits long or formatted curiously.

This makes validations and warnings ideal "partners in crime". By combining the two a baseline of data validity can be ensured (through validators) while misspellings and other likely input errors can be sorted out as well (by warnings). This strikes the ideal balance between ensuring reliable, high-quality customer input without locking out users with rare or unusual data.

While implementing both validations and warnings may require a little extra work for the tech team, the investment is easily offset on e-commerce sites considering its upshots: a decrease in support cases (due to more accurate customer input being submitted), and a possible increase in sales (as users aren't prevented from completing their checkout because of edge-case inputs).

So consider this article a warning to all e-commerce owners who rely solely on validators. (Ok, we promise to skip the bad puns in future articles if e-commerce sites promise to begin relying on warnings as much as they currently make use of validators).

Post a comment (3 so far)

Related articles

Add Descriptions To Checkout Form Labels (92% Get It Wrong)

Idea: Error-Fields Only

5 High-Level Mobile Commerce Design Considerations

 Jamie Appleseed http://baymard.com/blog/validations-vs-warnings tag:baymard.com,2005:Article/143 2014-09-02T08:26:00+02:00 2014-10-03T15:20:00+02:00 Faceted Sorting - A New Method for Sorting Search Results

This is the sixth in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

Trying to sort site-wide search results on most e-commerce sites typically end up a mess, with irrelevant search results being propelled to the top of the list as users sort by price, customer ratings, etc – something that left the test subjects bewildered during our latest usability study on e-commerce search.

This is because sorting search results by attributes based on anything other than relevance very often cause low-quality results moving to the top of the list unless a well-defined scope is selected to filter them out – something very few users think to do in practice. Yet, our search benchmark reveals that only 10% of e-commerce sites actively address this issue.

In this article we'll present some of the test findings on this usability issue along with 3 ways address it, including a new sorting method, Faceted Sorting, which is related to (but should not be confused with) "Faceted Search" or "Faceted Search Filters".

Usability Issues When Sorting Search Results

Let's take a simple example of how wrong sorting site-wide search results can go. A user performs a simple search like "Plasma TV". Upon seeing the search results he wants to see those TVs listed by price. During testing, when users made such a decision, nearly all of them would logically reach for the site's sorting feature to sort the search results by price.

However, when sorting a site-wide search like "Plasma TV" by price, the top results will almost always end up being various accessories, such as TV cables and mounting brackets. This is because accessories and tangentially related products can include the user's search terms and be cheaper, and since the list is now sorted by price rather than relevance, any remotely related products will appear before the obviously more relevant Plasma TVs if they happen to be cheaper – which accessories typically are.

While this may be the technically "correct" response, it certainly does not align with user expectations, and of course completely baffled most of the test subjects whenever it happened during testing.

This subject tried to sort his "sofa" search by price, expecting to see IKEA's selection of sofas arranged from cheapest to most expensive. But what he got was a list of leather cleaning products, pillows, and lamps.

"Then I get all that stuff. This is annoying. Haha, I don't need any swim trunks…" a test subject said after sorting his search for 'sleeves 11' by price, "This doesn't have anything to do with laptop sleeves." The subject was of course hoping to see the cheapest of the 11-inch laptop sleeves available in his search result.

Any sorting criteria that isn't based on search term relevance will only be meaningful when applied within a well-defined scope because they otherwise place low-quality search matches at the top of the product list. When users perform site-wide searches without a search scope, sorting options such as price therefore rarely make sense because they tend to produce search results that don't match user expectations.

While the site's behavior isn't "incorrect" (technically those results do match the user's query and they do happen to be cheaper), we can't expect users to be mindful of such technical nuances – they won't stop to consider whether they are in an appropriate scope before trying to sort their search results. They've just made a clear search query (e.g., "Plasma TV") and received a list of perfectly relevant results. All the user wants now is to see the best-rated or cheapest items of these results and therefore they naturally use the "Sort by" feature the site has placed right there in front of them. When in this frame of mind – viewing an initial set of results consisting of highly relevant products – few users expect that sorting the results by price is going to return a list full of irrelevant products.

Luckily, there are a number of ways to solve this issue. In the rest of this article we'll focus on 3 different ways to deal with users wanting to sort their site-wide search results (i.e. sort a product list without a scope applied).

Tip: For more on search scopes in general, see E-Commerce Sites Need Multiple of These 5 'Search Scope' Features.

Solution 1: Suggest a Scope Within the Sorting Widget

Generally, if any given path or feature is highly likely to provide poor matches for the user, it shouldn't be promoted. In fact, features with a poor return on click investment may even be disabled or replaced with a more useful alternative. One way to solve the lack of sorting scope is to suggest the scope selection before allowing users to sort. This technique is perhaps best know from Amazon:

For site-wide searches Amazon removes the sorting drop-down entirely and instead asks their users to "Choose a Department to enable sorting" to avoid the issues of users trying to sort their site-wide search results.

Instead of providing users with an almost useless site-wide sorting tool, the entire sorting drop-down is instead used to promote a handful of relevant category scopes. It's only after applying one of these scopes that users can sort. By suggesting scopes within the sorting user interface, this approach cleverly exploits that the user is in mindset of wanting to sort their search results and therefore naturally looks here. At this point the site then asks the user to select a search scope first, before allowing them to sort (but with the promise that sorting options will be available after this selection).

Since users often conceptually mix sorting and filtering (during testing users often referred to filtering as "sorting", and vice versa), it makes good sense to not only display the search scopes as part of the search field or in a filtering sidebar (where they logically belong), but also position them in the search widget. This makes the search scope selection an integrated part of the user's path towards sorting their search results.

Solution 2: Suggest Both Scope and Sorting

In the above example from Amazon, notice how the sorting options have been disabled entirely. This can be an acceptable approach if this forced scope selection is limited to the first level of the category hierarchy and if the site contains a very diverse set of product categories. However, if the site deals with a more well-defined type of products, such as clothing or electronics, it's not advisable to disable the site-wide sorting options entirely, as there can be cases where a user needs to sort across multiple categories.

A simple mockup we've created illustrating the concept of a sorting widget for site-wide search results which suggests category scopes but still allows for sorting the site-wide results.

This evolves the sorting interface to feature both scope suggestions and sorting options, encouraging the user to select a search scope while still allowing them to sort across multiple category scopes when truly needed.

Sorting across scopes can be necessary if the category scopes are either overlapping or the same type of product could be in multiple categories – this is the case for 68% of the top US e-commerce sites, as found in our Homepage & Category Usability study.

(This is yet another example of how one shouldn't simply copy Amazon's implementations 1:1.)

Solution 3: Offer "Faceted Sorting"

While promoting scope selections in the sorting widget is a good start, one may perfect the solution by offering Faceted Sorting suggestions. That is, suggesting a list of category-specific sorting options for any highly relevant subset of the search results.

A simple mockup of how Faceted Sorting suggestions could look for a site-wide search such as "Plasma TVs". Notice how the Faceted Sorting suggestions include category-specific sort types such as "Screen size" from the matching "TVs" scope. The traditional site-wide sort types are appended to allow users to sort any results that may overlap multiple scopes.

Promoting the selection of a highly relevant scope over sorting site-wide searches will not just avoid a poor sorting experience in itself. It will also enable the site to display a much better palette of sorting types. Instead of sticking to the generic site-wide sorting types such as price, name, and ratings, the user can now also be presented with category-specific sort types such as "Screen size" for a TV scope, "Capacity" for a washing machines scope, "Heel height" for a stilettos scope, and so on, whenever one of these scopes are sufficiently relevant to the user's search query.

This approach works because it effectively makes the user select both a scope and sorting criteria at once. In the above example, the site-wide search for "Plasma TV" triggers sorting options such as "TVs by: Screen size" and "TVs by: Thinnest display" – choosing these would apply both a "TVs" scope to the search results and of course sort them by the selected criteria (screen size, display thickness, etc.).

In other words, when chosen, Faceted Sorting suggestions also apply a scope to the site-wide search results along with the new sorting direction. This also means that generic sort types which aren't based on relevance (such as price) may be suggested, e.g., "Sort TVs by Price", because they apply the scope necessary to produce meaningful search results.

Faceted Sorting thus enable users to quickly access the product list they are most likely looking for, namely a well-defined product group (such as TVs) sorted by an attribute they care about (such as price).

Implementing Faceted Sorting

When implementing Faceted Sorting there are two particularly important implementation details: 1) Relevance and 2) Labelling.

1) Relevance – Faceted Sorting should only be presented when a scope can be clearly determined as highly relevant to the user's query. This goes beyond looking at just the number of aggregated results for each category scope – the relevancy score of the results should be taken into account too.

If there aren't any scopes of sufficiently high relevance, a set of Faceted Sorting suggestions should probably not be displayed, as it may lead the user on detours and confuse them if suggestions that aren't overtly relevant to their search query are displayed. Much of same the relevance logic used in Faceted Search filter suggestions can be used for determining Faceted Sorting suggestions.

A simple mock-up of what faceted sorting could look like in practice. Notice how the "Plasma TV" query leads to the highly relevant 'TVs' scope for the Faceted Sorting suggestions, and how the user can sort their query, within that scope, by price or product attributes.

2) Labelling – Since Faceted Sorting is an unconventional feature that invokes a scope when selected, naming and labelling is extremely important. It's crucial that users understand the implications of their selection so there's alignment between site behavior and user expectations.

For example, Faceted Sorting suggestions for a "Plasma TV" search query should not read "Sort by: Screen size" because this doesn't clearly indicate that a search scope will be invoked upon selection. Instead, the option should include both scope and sorting attribute (e.g. "TVs by: Screen size"). This clarifies that the returned results will be restricted to TVs, sorted by screen size.

Improving the Sorting Experience for Search Results

While sorting site-wide search results can cause usability issues, most of them can be solved by suggesting a scope before allowing users to sort (suggestion #1) – a strategy that works best for multi-industry sites such as mass-merchants. Meanwhile sites with a more focused product catalog should suggest the same (relevant) search scopes within the sorting widget, but alongside the standard set of site-wide sorting options (suggestion #2).

Our search usability benchmark shows that these techniques are currently only utilized by 10% of top e-commerce sites, making it one of the most overlooked aspects of e-commerce search usability.

All sites can then further improve their users' sorting experience by taking advantage of Faceted Sorting (suggestion #3) whenever a site-wide search query closely matches a category scope, suggesting sorting options specific to that scope. This allows a basic search for "Plasma TV" to show sorting suggestions such as "TVs by: Lowest price", which applies both scope and sorting option when selected. This can be taken one step further by offering category-specific sort types, where the user can even sort by product-attributes, such as "TVs by: Thinnest display".

Faceted Sorting suggestions will be particularly relevant for (the fairly common) Product Type search queries, since such searches will often have a single well-matching category scope. Furthermore, when performing Product Type searches users typically haven't decided on a specific product yet and are therefore more likely to want to sort their search results by various product attributes.

Post a comment (11 so far)

Related articles

ROCI: Return On Click Investment

Mobile Form Usability: Never Use Inline Labels

E-Commerce Navigation: Show Sibling Categories for Easy Scope Adjustment (47% Get it Wrong)

The "Just Copy Amazon" Fallacy

Article series

Deconstructing E-Commerce Search: The 12 Query Types

8 Design Patterns for Autocomplete Suggestions

E-Commerce Sites Should Include Contextual Search Snippets

E-Commerce Search Field Design and Its Implications

E-Commerce Sites Need Multiple of These 5 'Search Scope' Features

Faceted Sorting – A New Way of Sorting Search Results

 Jamie Appleseed http://baymard.com/blog/faceted-sorting tag:baymard.com,2005:Article/142 2014-08-18T14:14:00+02:00 2014-08-19T19:16:31+02:00 External Article: The Current State of E-Commerce Search

On-site search pages of top grossing US e-commerce sites – you can find all 50 usability evaluations in our e-commerce search benchmark database.

In today's article, we'll go over 7 guidelines from the E-Commerce Search Usability report.

The article is published as a guest post at Smashing Magazine and explores 7 key aspects of the user's on-site search experience in an e-commerce context. The article also includes an analysis of the current state of e-commerce search based in-depth usability reviews of 50 top e-commerce sites:

The Current State of E-Commerce Search

Related articles

E-Commerce Search Usability: Report & Benchmark

Deconstructing E-Commerce Search: The 12 Query Types

8 Design Patterns for Autocomplete Suggestions

E-Commerce Sites Should Include Contextual Search Snippets (96% Get it Wrong)

 Baymard Institute http://baymard.com/blog/external-article-state-of-ecommerce-search tag:baymard.com,2005:Article/141 2014-08-13T08:08:00+02:00 2014-10-03T15:14:34+02:00 E-Commerce Sites Need Multiple of These 5 'Search Scope' Features

This is the fifth in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

Search scopes are one of the key differences between e-commerce on-site search and general web search. E-commerce sites have their products organized in categories which in turn can be used as "search scopes". This allows users to limit the boundaries of their search to a specific category.

During our large-scale usability study on e-commerce search, allowing users to "search within a category" (i.e. selecting a "search scope"), was found to dramatically increase the quality of the returned search results, and by virtue thereof, improve the users' success rates.

Throughout testing we've identified 5 different implementations for setting and changing the search scope that all helped improve the user's search experience. Unfortunately, when benchmarking the search feature of 50 top grossing US e-commerce sites, most of the sites had only implemented 2 out of those 5 search scope suggestions:

Autocomplete Scope Suggestions – implemented on 32% of the top 50 sites

Manual Search Scope Selectors – 100% implement it (when relevant)

Suggest Near-Perfect Scopes on the Results Page – 46% implement this or auto-direction (#4)

Auto-Direct Users to Perfect Scopes – 46% implement this or suggestion of near-perfect scopes (#3)

Suggest Scope Selection Within the Sorting Widget – 10% implement it

In this article we'll present these 5 different types of search scope suggestions that can help improve the user's e-commerce search experience.

1) Autocomplete Scope Suggestions

The best time in the search process to encourage users to specify a scope selection is while they are performing their search. At this juncture, the user has just entered (or is still typing) their search query and therefore hasn't yet shifted their mindset to that of scanning search results. By including search scope suggestions in the autocomplete results, we can achieve this critical timing, with the scope selection being presented to the user at just the right time in their search flow.

Suggesting a search scope in autocomplete suggestions is ideal timing, as this is where users are deciding on what to search for. Basically asking "You've typed 'coff', do you want to search for 'coffee' within 'Electrics' or within 'Food'?" Notice how the search scope here at Williams Sonoma are styled in blue, making it instantly obvious to the user that "coffee in Electrics" isn't a simple query but rather a query for "coffee" within the "Electrics" scope.

We've previously looked at 8 patterns for how to design a clear and useful autocomplete search suggestion widget. An important aspect of the design of autocomplete suggestions is allowing users to distinguish the suggested search scope from the suggested search query (as illustrated above). Therefore be sure to give search scopes a distinct style in the autocomplete suggestions to make it clear that they are not part of the actual suggested search query. This is typically done by styling the scope in italic, giving it a different color and/or adding indentation.

Despite the autocomplete being the ideal place to include search scopes, a whopping 62% of the top e-commerce sites fail to implement scope suggestions here. (However, of those that do, the vast majority give the suggested scope a clear and distinct style – browse our Autocomplete Suggestions design database for 41 examples.)

2) Manual Scope Selectors

Encouraging users to search "within a category" by manually selecting a search scope – either prior to performing their search or as a modification to a current search – can make sense on large sites with vast and diverse product catalogs. In practice, this will often be the case for mass merchants and multi-store sites, where a search scope is often needed to provide accurate results.

However, testing also revealed that poorly designed scope selectors can potentially lead to site abandonments, as users selecting overly narrow search scopes without fully realizing the consequences were unlikely to ever get useful search matches. It's therefore paramount to have a self-evident design for the manual search scope selector to avoid users misinterpreting the selected scope.

Home Depot offer a manual search scope selector allowing users to narrow their search to a specific top-level category. For sites with vast and diverse product catalogs, there's an increased risk of search results "pollution" where products in categories irrelevant to the user still match their query and thus end up cluttering the search results unless a search scope is applied.

When it comes to the implementation details, make sure that the:

Search scope selector design is kept secondary to the search field design.

Selector and search field are in close proximity.

A specific scope is never selected as the default value (this lead to multiple site abandonments when testing Tesco).

Scope selection is presented using a drop-down (native or custom).

Of the 50 top grossing e-commerce sites, it's only 24% that implement a manual search scope selector. However, if we weed out all those sites where a manual scope selector isn't strictly necessary, and only focus at the mass merchants and multi-store sites with vast and diverse product catalogs, it's all of them who implement a manual search scope selector.

3) Suggest Near-Perfect Scopes on the Results Page

When users search for products, they frequently query on terms that either directly map or strongly relate to a specific scope or category on the site. Of the 12 query types identified, this will often be the case for Product Type search queries, e.g. "leather sofa" or "laser printer". Yet, those searches will typically also yield a few products from other categories, which means tools such as category-specific filters and sorting options won't be available (or they will be mixed from different categories).

Target suggests near-perfect scopes, here for the generic Product Type search query "shoes". Note how the user is strongly encouraged to select a search scope by the position and use of thumbnails, compared to if the scopes had simply been yet another set of values in the filtering sidebar.

When there's a "near-perfect" scope, or if there are multiple search scopes which could be relevant, point the user towards these scopes by promoting them on the search results page. This nudges the user towards scopes where they are likely to be more successful, without being intrusive to the user's search flow and experience.

By pointing the user to a better matching search scope, the site is able to display more contextual filtering and sorting options. Furthermore, any scopes the user may have taken for granted (e.g. due to their current frame of mind), can be selected – e.g. a man searching just for "shoes" might actually mean "men's shoes" (see above example and the Implicit Search query type). With these scope suggestions available the user is encouraged to make such intents explicit.

Of the top grossing e-commerce sites, 54% don't suggest a near-perfect scope nor auto-direct users to perfect scopes.

4) Auto-Direct Users to "Perfect" Scopes

In addition to suggesting near-perfect scopes on the results page, there's also the case where there's a "perfect" match between the user's query and a category.

When the match between user query and site category is sufficiently strong, it can make sense to auto-direct the user straight to the category page (bypassing the search results page). This will provide the user with a category page which can be optimized specifically for the type of product it presents (compared to the generic search results layout), offering the user additional category-specific filtering and sorting options.

At Toys'R'Us, Product Type queries that match a category will auto-direct the user straight to that page. For example, searching for "water slide" will take the user to the "Sprinklers & Water Slides" category page.

The success of the auto-direct will depend on how close the returned category page matches the user's search query. During testing the subjects clearly expected to see results highly relevant to their query, and we therefore recommend limiting auto-directs to "perfect" matches, and mainly use it for generic Product Type queries that match the high-level product categories (e.g. "womens shoes" or "LED tv") where "relevant matches" can be better achieved by a curated page.

Also, the auto-direct should only occur if the category pages actually offers additional value to the user. This can be anything from improved sub-categorization, help content, guides, additional filters (in particular category-specific ones), optimized layout, etc. Finally, as with most interpreted and automatic actions a site performs on the user's behalf, the user should always be offered an option to revert to the "normal" results.

Hayneedle's search logic auto-directs users searching for "manual espresso machines" to the "espresso machines" category/scope with the "manual espresso machines" filter enabled. This approach is more transparent and allows the user to easily revert the site auto-direction by de-selecting the filter.

Suggesting near-perfect scopes (#3) and auto-directing to perfect scopes (#4) complement each other – in some cases suggestions are appropriate, while other times auto-direction is preferred. This strongly resembles the way Google and other web search engines handle misspellings. When there's a very high likelihood that the user has misspelled a word, Google will automatically correct it on their behalf (but always with an option to "fall back" on the original query). For less clear-cut misspellings, Google will suggests the alternative (i.e. "Did you mean [xyz]?").

In essence, when confidence in the correction is sufficiently high, auto-apply the change (i.e. auto-direct to the scope, #4) with a way to revert to the traditional site behavior; when less certain in the correction, suggest the changes instead (#3).

5) Suggest Scope Selection Within the Sorting Widget

It's quite natural for users to want to sort their site-wide searches to see, for example, the "highest rated" or the "cheapest" results related to their query. Yet, when the test subjects tried this during testing, it almost always resulted in completely irrelevant products being presented to them unless a scope had been applied first.

Without a scope applied to the search results, any product matching any part of the user's query will typically be returned. This is normally fine because the results are sorted by relevance, and "low-quality" results are therefore hidden far far down the search results page. However, if a new sorting method such as "highest rated" or "cheapest" is chosen, numerous low-quality results will suddenly be presented at the very top of the list because they are technically a match and happen to be cheaper or higher rated than some of the high-quality search results. (This is a case of a poor, possibly even negative, Return on Click Investment.)

"Then I get all that stuff. This is annoying. Haha. I don't need any swim trunks or … That doesn't have anything to do with a [laptop] sleeve," a test subject said after sorting his search for "sleeves 11" by price, in hopes of seeing the cheapest 11-inch laptop sleeves available. Instead, a collection of irrelevant products ended up at the top of the results list because they were technically the cheapest items and happened to match something – anything – related to the subject's query.

Users simply don't consider whether they are in a scope appropriate for sorting or not. And why would they? They've just made a clear search query (e.g., "sleeve 11") and received a list of perfectly relevant results – now all they want is to see the highest-rated items of those results and therefore naturally decide to use the "Sort by" feature the site has placed right there in the search interface. When in this frame of mind, having provided such clear intent and now viewing an initial set of highly relevant results results, few users will think that sorting the results by "Price" or "Ratings", etc. will yield a list where the majority of products are completely off.

It's only when a search scope is selected that sorting methods based on other factors than relevance will make sense, as the search scope ensures that mainly relevant matches are returned (making all results "high quality"). A dilemma thus arise: sorting parameters such as highest rated and price therefore mostly make sense once a search scope is selected, yet users won't stop to think of this before sorting by these parameters. Suggesting search scopes within the sorting widget solves this quandary.

For site-wide searches Amazon removes the sorting drop-down entirely and instead asks their users to "Choose a Department to enable sorting". This allowed Amazon to avoid site-wide sorting issues during testing.

By promoting a scope selection within the sorting widget, users are pointed towards a useful page instead of being lured in by the promise of a sorting method that ultimately won't deliver what they are looking for. It allows users to pursue their natural search flow where they attempt to apply a new sorting parameter to their search results, yet then asks them to select a search scope once they actually attempt to do so, ensuring that the user ultimately end up with the results they wanted.

It's important to note that simply disabling sorting of site-wide search results and placing a text instruction to "Select a category to enable sorting" is unlikely to be understood by users – during testing a very large part of the subjects did not distinguish between filtering and sorting (often referring to both filtering and sorting as "sorting") – and the suggested scopes should therefore be presented within the sorting widget, or in its place. (Bonus: in the next article we'll present a lot more of the test findings for sorting of search results along with a new sorting concept.)

Suggest Scopes in Multiple Ways

From the test sessions, it's clear that applying a search scope is not a natural part of most users' thought process. Rather, users are thinking of the type of product they want and trying to come up with search queries and terms that may prove well-suited for producing such results. For example, if a user is looking for the latest movie with James Franco, few would stop and first select a "Movies" search scope to filter out books by and about the artist – it's only when users are reminded that there are many other product types related to Mr. Franco that they'd move to apply a suitable search scope.

Autocomplete Scope Suggestions (#1) are ideal because they present the scope suggestion at just the right time in the user's search flow, encouraging the user to proactively apply a search scope. Manual Search Scope Selectors (#2) can be applied proactively too but it's on the user to remember to do so and our testing shows that users mostly use manual search scope selectors retroactively (i.e. once they've received a set of irrelevant search results after applying a different sorting method to a site-wide search). Suggesting near-perfect scopes (#3), auto-directing to perfect scopes (#4) and suggesting scopes within the sorting widget (#5) are all retroactive in nature, aiming to help the user "correct" or improve their search. This is great for users who missed the autocomplete scope suggestions or weren't prepared to make the selection up-front.

Given the numerous different stages a user may go through in their search flow and that most users don't consider search scopes until they are presented with them, it's important to utilize a combination of these 5 types of search scope suggestions.

Post a comment

Article series

Deconstructing E-Commerce Search: The 12 Query Types

8 Design Patterns for Autocomplete Suggestions

E-Commerce Sites Should Include Contextual Search Snippets

E-Commerce Search Field Design and Its Implications

E-Commerce Sites Need Multiple of These 5 'Search Scope' Features

Faceted Sorting – A New Way of Sorting Search Results

 Christian Holst http://baymard.com/blog/search-scope tag:baymard.com,2005:Article/140 2014-07-30T08:14:00+02:00 2014-11-06T09:03:30+01:00 E-Commerce Search Field Design and Its Implications

This is the fourth in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

In previous articles we've examined the e-commerce search engine logic (12 query types), autocomplete suggestions (8 design patterns), and the actual search results (contextual snippets) – but what about the search field? In this article we'll go over our research findings on the design of the search field, and showcase how it can directly influence the user's entire shopping and search behavior at your site.

The search field represents the initial step of the user's search process (they must interact with it to even see the search results page), and the search field design is therefore a key aspect in crafting a great search experience. However, our recent large scale e-commerce search usability study shows that the design of the search field is instrumental at an even more fundamental level – the field design can influence the user's entire approach to how they find products on the site.

To a large extent user's see the prominence of the search field as an indicator of how strongly the site "recommends" search as a way to find products, versus the alternative of navigating categories via the site menus. During our usability testing the subjects adopted search as their primary product finding strategy much more frequently on sites that had a very prominent search field, while the test sites with a muted search field design saw increased category navigation.

Etsy features a large search field in the very center of the page header – a design that encourages users to search.

How Prominent Should Search Be?

In other words, the search field's prominence (determined by its design and placement) influences the user's likelihood of adopting search as their primary product finding strategy. It's therefore paramount to ensure that the field's prominence aligns with the importance of search to your site.

In industries where search is the preferred product finding strategy, it can be beneficial to "promote" the search field with a prominent design and placement, especially on the user's landing page (e.g. the homepage). Meanwhile a more subdued search field is warranted on sites where category navigation is preferred. This is obviously highly unique to each site, though the preference for search vs category browsing typically falls as follows:

Search is preferred when .. the user already knows the specific item they want (e.g. "I want a Toshiba Satellite C55-B5246") or the sites with a very extensive product catalog (e.g. mass merchants such as Amazon). This will typically be the case for spec-driven purchases, purchases based on extensive third-party research (e.g., via review sites), or purchases based on price comparison shopping.

Category browsing is preferred when .. the user doesn't yet know the exact product they want (e.g. "I want a laptop") or the site's hierarchy is very flat. During testing, visually-driven industries such as apparel and home decoration in particular saw a clear bias toward category navigation – both in terms of the subjects' initial preference and their subsequent success rate.

In terms of design and implementation, there are multiple ways to visually subdue or emphasize the search field in your overall layout. The exact method to employ will vary from site to site, depending greatly on the context the search field appears in (i.e., the overall site design). Let's look at three examples, ranging from a highly subdued search field to a dominating one.

Urban Outfitters has hidden the search field altogether and simply show a loupe icon, clearly encouraging category browsing as the product finding strategy. This makes sense considering Urban Outfitter's industry and their focused product catalog.

Hayneedle's search field stands out a little more but with no clear preference between search and category browsing – they are equally prominent on the page. This is likely a function of some users knowing exactly the item they want (search preference) while others just know the type of product they are interested in and want to browse Hayneedle's catalog first (category navigation preference).

Newegg offers up an example of a more dominating search field that nudge users towards adopting search as their primary product finding strategy. Given the size of Newegg's product catalog and the type of products they carry, this seems a sensible design choice.

Tweaking Search Field Prominence

In terms of aesthetics, our e-commerce search study shows that site designers have a great degree of freedom so long as there's agreement between the search field prominence and the importance of search as the primary product finding strategy.

In terms of design, there are three main factors that designers can tweak to increase or lower the search field's prominence while still retaining a bespoke field design that matches the unique aesthetics of their brand:

Position – Depending on where the search field is placed on the page it will either receive more or less focus. The most common search field placements are in the top-right corner of the header (typically gets less attention), in the center of the header (tends to get a lot of attention), or integrated into the navigation bar (amount of attention drawn depends highly on implementation and context). The other page elements surrounding the search field obviously has a major impact on the field's prominence, so make sure to position it wisely.

Contrast – The search field's contrast may similarly be tweaked to increase or decrease the field prominence relative to other elements on the page. Increasing the contrast of the field's border, input text, search button, etc. can make it pop out on the page, while subduing these elements can allow the field to recede into the overall page design, allowing other elements to draw the user's attention.

Size – The larger the search field (and input text), the more prominent it will appear, and the more users will perceive it as the site is encouraging a search strategy. Keep in mind that certain page positions may constrain the possible size of the search field (e.g. if the field is integrated into the main navigation bar alongside the top level categories).

Let's look at a handful of "real-life" search field implementations to see how these three factors combined can influence the field's prominence.

1) Position: A less prominent appearance can be achieved by placing the search field above the main navigation menu, as seen here at Williams-Sonoma with the search field located in the upper right corner of the header.

1) Position: Overstock draws more attention to the search field by placing it in the center of the header, next to their logo (which due to its graphical nature gets a fair degree of focus from users).

2) Contrast: The graphics of the search input field consist of many sub-elements such as the field's border and background color, input font and size, placeholder font and size, etc. The more these sub-elements, as a whole, blend into the header, the more subdued the appearance – as is evident in this example from American Eagle Outfitters.

2) Contrast: While the search field on Dick's Sporting Goods has a white background like the one at American Eagle Outfitters, the colored header background provides more contrast and the field consequently becomes a lot more prominent. Increasing the contrast between site header, search field and search button, is often one of the most effective ways to put emphasis on the search field while retaining a relatively calm header appearance (as opposed to, e.g. thickening the field border or making the input text bold, which tends to induce a more cluttered feel).

3) Size: By making the search field physically small, its visual prominence is greatly lowered, as seen here on Ann Taylor. This sends a strong signal to the user that category navigation is the preferred product finding strategy for this site.

3) Size: Toys'R'Us boasts one of the largest search fields among the top 50 US e-commerce sites. The search field stretches 60% of the 950-pixel-wide header layout. A field this wide yells "search" to the point that it's likely that some users will interpret this as Toys'R'Us implying that search is the only viable product finding strategy on their site (essentially communicating "don't use categories").

As seen in these six examples, designers have a lot of freedom in terms of the aesthetics of the search field – what's important is that the field's position, contrast and size is tweaked, so the prominence of the search field is in tune with the site's specific context (industry, scope of products, category hierarchy, etc).

Dynamically Adjust the Field's Contrast

On the typical e-commerce site, some pages (such as the homepage) tend to be significantly more cluttered than other pages (such as a 2nd-level category page). Since the prominence of any given element is determined by its relative dominance to the other elements on the page, a search field which stands out on the less cluttered pages (i.e. nested category pages, help sections, etc) may be less obvious on the more busy pages (i.e. the homepage, product pages, etc).

"I didn't see that [the search field, ed.] until now. Else I would have used it before, when I looked specifically for it. It's very light. It almost disappears up there," a subject explained, continuing, "That's really odd I didn't see it before. I'm absolutely sure that I looked for it up there." The search field has trouble standing out on Gilt's homepage due to the large attention-grabbing graphics.

This creates a dilemma when trying to design a search field with the appropriate level of prominence: should the field design be optimized for the busy pages (and thus stand out a little too much on the more calm pages)? Or should you design for the less cluttered pages but then suffer from a slightly too subdued search field on the livelier ones? Well, luckily we don't have to trade one for the other: simply adjust the contrast of the search field dynamically so its relative prominence is always kept at the appropriate level to your site.

A mockup of how Gilt could dynamically tune the contrast of their search field to keep its relative prominence intact across calmer and busier pages on their site. One could easily imagine the top version being used on category pages while the bottom version would be suitable for product pages and the home screen.

Dynamically altering the field's relative prominence on the homepage can be done by tuning things like borders and backgrounds ever so slightly, enhancing the field's contrast a little so it can better "compete" with the many attention-grabbing graphics typically present on the homepage. Meanwhile category pages (which, if the user is here, also suggest that they have already chosen a category browsing strategy) can benefit from having the field's contrast tuned down a little.

While position and size could theoretically be manipulated too, we don't recommend dynamically adjusting these factors as they can potentially confuse users – the changes should be subtle and ideally not be consciously noticed by the user. If the search field suddenly changed position users may have trouble finding it, think the site is buggy, and the "new field" carries another function. Tuning the contrast of the search field, on the other hand, doesn't fundamentally change its appearance on the site.

Designing the Search Field

When designing the site's search field, there's a lot of freedom in terms of its aesthetics – a unique visual style that suits the site's general design and brand is perfectly fine.

However, because the prominence of the search field influences the degree to which users will adopt search as their primary product finding strategy, it's important that there's agreement between these, with the search field accurately indicating the "appropriateness" of search to this site's particular context.

There are three main factors that you can tweak to adjust this dynamic while still retaining a unique search field design. They are: field position, contrast, and size. These factors can be manipulated to nudge users towards either search or category browsing. Search is typically preferred when users generally know the exact item they are looking for, while category browsing tends to be preferred when most users only know the type of product they are looking for.

Finally, in order to deal with the dilemma of varying levels of graphics across page types, you may want to consider dynamically adjusting the search field's contrast to ensure its prominence is always kept at an appropriate level in relation to other page elements throughout the site.

Tip: you can browse the search field designs of 50 major e-commerce sites in the public part of our search benchmark database.

Post a comment (4 so far)

Related articles

Homepage Usability: Can Users Infer the Breadth of Your Product Catalog?

8 Design Patterns for Autocomplete Suggestions

Article series

Deconstructing E-Commerce Search: The 12 Query Types

8 Design Patterns for Autocomplete Suggestions

E-Commerce Sites Should Include Contextual Search Snippets

E-Commerce Search Field Design and Its Implications

E-Commerce Sites Need Multiple of These 5 'Search Scope' Features

Faceted Sorting – A New Way of Sorting Search Results

 Jamie Appleseed http://baymard.com/blog/search-field-design tag:baymard.com,2005:Article/139 2014-07-15T08:07:00+02:00 2014-09-02T16:43:41+02:00 E-Commerce Sites Should Include Contextual Search Snippets (96% Get it Wrong)

This is the third in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

When testing the search experience of 19 large e-commerce sites, 57% of the test subjects were at some point during our study in doubt of why or how the search results were related to their search query. The subjects simply could not figure out why one or more of the search results had been deemed relevant by the search engine, because none of the data listed for those products appeared even remotely related to their search.

It's therefore important to include contextual search snippets with excerpts of the matched data so that users can see how each result is related to their search query. Contextual search snippets have been used by traditional web search engines for a good decade, but amongst e-commerce sites 96% do not include such snippets (as identified in the e-commerce search benchmark).

"I don't understand why they have this", a subject said after searching for "sleeve mac 15" at Zappos. Without search snippets to show her why the backpacks were included as results, she could only guess or visit multiple irrelevant product pages to read all the descriptions (some backpacks had laptop sleeve compartments). Either option makes this already-poor search experience even more frustrating to the user.

In this article we'll go over our research findings on why search snippets are so important to the user's search experience, and see how they can be implemented in an e-commerce context (which differs from their implementation in a more generic "web search" context).

Pre-Defined Product Info for Search Results Hurts the Search Experience (and Your Brand)

Search is open-ended, so the list of search results can contain a mix of any product the site carries, and may include scarcely-related products. The relationship between the user's search query and the search results must therefore be established for the user, to answer questions such as: Why was this search result included? How does it relate to my search query? How is it relevant to me? How does it differ from the next result?

"Did he direct this?" a subject pondered after searching for "steven spielberg" at Amazon. Unable to see how each item related to his query, the subject opened a handful of movies to check that they were in fact directed by Spielberg – only to go back immediately, as he was never interested in buying any of them.

Another subject searched for "cloud atlas movie" and wondered aloud, "So why does Life of Pi come up here? This is a… erhmm, I don't really know why…"

Displaying the same product attributes for each search result – regardless of the information matching the submitted search query – was observed to lead to needless "pogo-sticking," where users go back and forth from the search results list and product page, only scanning the product page with the purpose of figuring out why and how the product is related to their query. This obviously makes it difficult for users to get a proper overview of the relevant search results, and users quickly grow tired of this tedious back-and-forth information process.

For "closed" navigation types, such as category navigation, it makes good sense to display the same type of product attributes for every single product, as the very categorization ensures that the products are somewhat similar, and the display can therefore be curated as its context is predefined. This is not the case for open-ended searches where the context is user-defined (by the search query they enter).

"You have to wonder why it says 7"–10", when my laptop is 12", a subject reflected at eBags after selecting his specific laptop model in a Laptop Finder wizard, continuing, "You don't really trust that it's going to fit. So their search kinda fails here. You can't trust it after all."

For Compatibility search queries – such as the subject seen here, who searched for "Charger lenovo ideapad" at Best Buy – the test subjects often found it unclear how each item was related to their search query and often overlooked the compatible items in the list. Compatibility aspects are absolutely vital to include in the list item for this particular type of search query, as incompatible products are irrelevant for the user to explore (it's a dead-end).

All these wasted clicks and "pogo-sticking" can lead users to lose confidence in the site – or rather in the site's search engine – as seemingly irrelevant items are included among the results. This was observed to lower the probability of the user making a new search, and can therefore be a great source of site abandonments. However, our usability testing found that the repercussions can go even further than that, as this loss of faith in the site's search engine in some cases lead to permanent brand damage, with the user perceiving the site as poorly built – if not in general, then at least in terms of search.

Why Search Snippets Matter

Search engines have used contextual snippets for decades. This provides the user with insight as to why each result is being shown and how it is related to their query. As a bonus, it also makes it dramatically easier to choose between the results.

Traditional web search engines such as Google and Yahoo figured all this out more than a decade ago – and have implemented contextual search snippets as the dominant part of their results' list item information. Yet, search snippets are rarely found in e-commerce search result designs. In fact, only two of the 50 top grossing US e-commerce sites have search snippets on their results page. Within e-commerce Amazon have it for most searches (but not e.g. in the movie scope as seen in the prior examples) and Walmart for all searches.

Walmart's inclusion of contextual search snippets helps establish the necessary connection between the user's search query and the returned search results. For this particular search on "high quality kettle" the contextual search snippets allow the user to infer that these kettles are being displayed because their description includes the words "high quality" (and not because Walmart has categorized them as especially good items).

Contextual search snippets are based on what the user searched for and display the text that matched the user's query on the page of the search result (i.e., the content that triggered the search engine to deem the result relevant). Search snippets thus provide users with insights on why and how each given item is relevant to their search query and can save them from spending time on irrelevant items.

This is particularly important in the case of low-quality results – while the user will lose some faith in the site's search engine due to the irrelevant search result(s), this is at least partially redeemed by showing the user why it was included (i.e., users can appreciate why the result is being displayed even if it isn't relevant to their particular shopping session).

Lastly, contextual search snippets can also help speed up the process of choosing between the search results, since the contextual snippets tend to include the information and context that the user is most concerned about. Since users naturally include the product attributes that are the most important to them in their search queries, displaying that information and its context for each search results makes it a lot easier for the user to compare the products across the attributes they care about.

Search Snippet Design for E-Commerce

Search snippets within an e-commerce context differs from search snippets in traditional web search, as the type of results are different (product pages vs. any type of webpage).

Where snippets within traditional web search will often draw on vast sections of coherent text from the destination page, e-commerce product page information will typically rely on relatively short descriptions, especially when it comes to the product spec sheet and metadata. Thus, besides the product title and description, an e-commerce search engine will often be triggered by a specific:

Feature from the spec sheet (typically the case for #5: Feature search queries);

Product variation (color, size, material, capacity, etc.); or

Compatibility aspect (often the case for #7: Relational and #8: Compatibility queries).

Since this data is often structured and semantically categorized, you have more options when designing contextual search snippets on an e-commerce site – the dynamic content doesn't just have to be a long text string with highlighted keywords (as is typically seen for web searches). In an e-commerce context, the results may include some dynamically selected product specifications that match the user's query and display those alongside the pre-defined product attributes.

For select product types Amazon include dynamic search snippets to help users understand why and how the results are related to their query.

The structured results data give e-commerce sites more opportunities, when it comes to the formatting of the search snippet. E-commerce sites can for instance move beyond just including a simple text string with the 30 characters on either side of the keyword's appearance in the product data and instead display the matching content in a structured list of bullets or spec sheet or similar customized data layout.

Search Snippets Summarized

When relying entirely on pre-defined search result information, users will often have to open the product page of a search result just to determine how it is relevant to their query.

During testing this was observed to not only lead to extensive pogo-sticking but also site abandonments as the subjects lost confidence in the site's search engine as it repeatedly returned seemingly irrelevant results. This was especially the case for Feature, Symptom and Compatibility search queries.

E-commerce sites should therefore include contextual search snippets for their search results to help their users understand why and how each result relates to their search query. This goes beyond simply highlighting keywords but requires the information included for each search result to dynamically alter based on the search query submitted by the user.

Post a comment (1 so far)

Related articles

Checkout Usability: Apply Changes Immediately and Near the Input

Deconstructing E-Commerce Search: The 12 Query Types

Scannability: How to Highlight Text on the Web

Article series

Deconstructing E-Commerce Search: The 12 Query Types

8 Design Patterns for Autocomplete Suggestions

E-Commerce Sites Should Include Contextual Search Snippets (96% Get it Wrong)

E-Commerce Search Field Design and Its Implications

E-Commerce Sites Need Multiple of These 5 'Search Scope' Features

Faceted Sorting – A New Way of Sorting Search Results

 Christian Holst http://baymard.com/blog/search-snippets