Use ‘Delivery Date’ Not ‘Shipping Speed’ – From UX Research to Implementation Roadmap

When it comes to shipping, our checkout usability study shows that what users really care about is not “shipping speed” but rather the date of delivery, as in: “When will I receive my order?”

During our large-scale usability testing, the subjects frequently had major trouble comparing shipping options that displayed shipping speeds rather than delivery dates. The subjects also often ended up misinterpreting shipping speeds and frequently miscalculated the arrival date. Meanwhile, the test sites that displayed delivery dates fared much better, and the subjects were even able to accurately interpret delivery date ranges.

Now this may perhaps seem like an obvious insight but a staggering 40% of the major US e-commerce checkouts we benchmarked show shipping speeds instead of delivery dates. If nearly half of major e-commerce sites fail on the presentation of their delivery speeds despite the serious capital and tech resources at their disposal, then it’s probably likely for even the best of us to stumble in this area.

At its core, the solution is pretty simple: display “delivery date” rather than “shipping speed”. That is, instead of the shipping option stating “2-4 day delivery”, it says “Arrives January 26-28”. That’s of course easier said than done. In practice, there’s a whole host of details to get right when estimating the delivery date, as well as changes in user perception that should be accounted for.

There are two plausible reasons an e-commerce site would display “shipping speed” rather than “delivery date”. One is that they designed this part of their checkout experience from a business-centric view and simply didn’t consider that delivery dates are much more useful to users than a list of shipping speeds. The other reason is that they don’t know how to accurately determine delivery dates.

Both of these reasons are poor, although the latter is more understandable – the implementation of delivery dates isn’t necessarily the easiest of changes you can make to your checkout process. It is, however, one of the more important changes, considering how big of an impact the price and speed of the available shipping options have on users (we’ve found that 61% of users have abandoned checkouts solely due to too-high extra costs, and 16% due to too-slow shipping).

The second half of this article is therefore dedicated to practical implementation advice, outlining two different approaches to implementing delivery dates on your site. The aim is to take you from usability research insights all the way through to a practical implementation roadmap. More specifically, this article covers the following topics:

• Why ‘shipping speed’ is problematic / not very helpful to users and how ‘delivery date’ resolves those issues
• How ‘delivery dates’ change user perception and the way shipping options should be presented (there are a number of details to get right)
• All the implementation details to be aware of and account for if relying on a Postal Service API to fetch estimated delivery dates
• How you may go about developing your own system to calculate delivery dates

The Problem: Delivery Date = Matrix of Multiple Conditional Variables

During our checkout usability testing the problem with shipping speeds quickly became evident: it forces the user to calculate a number of conditional variables (e.g. current weekday and time, order processing time, non-delivery days such as holidays and weekends, etc.) to determine the value they actually care about (i.e. when they can expect to receive their order).

Forcing users to perform fairly complicated multi-variable conditional calculations like this for each and every single shipping option they want to evaluate and compare obviously leads to a poor user experience.

During testing, on the sites that provided their users with “Delivery Date” for each of the shipping options within their shipping interface, the users didn’t have to concern themselves about whether the site had any order processing time and how long that was, the current weekday of ordering, if there were any holidays ahead, whether some of the available delivery methods would deliver on Saturdays or not, or if the site’s internal cut-off time for processing orders had passed or not. All the user had to consider was if they wanted to pay $2 extra to receive the order “Wednesday, April 2nd” rather than “Friday, April 4th”.

But can’t users estimate this themselves with some amount of accuracy? Is it really a big problem if the user miscalculates by a day here and there? Unfortunately, it can be. In fact, there can easily be as much as a 3-day difference between “2-Day” and “3-Day” delivery. For example, if the courier firm doesn’t deliver their “3-Day” shipping option during weekends and the “2-Day” delivery lands on a Friday (since the “3-Day” delivery would then get pushed to the other side of the weekend).

Similarly, users may end up disappointed if they pay for an expensive super-express shipping option that ends up getting delivered 3 days later due to holidays, or because of slow processing times. Indeed, during testing we saw how shipping names such as “Next Day” ended up misleading users because of internal cut-off times, which meant the order wasn’t handed over to the courier that day – which in turn resulted in the order being delivered two days later, and not “Next Day” as the shipping name had indicated.

It is unduly burdensome for users to account for all these factors themselves. The very complexity of the calculation is precisely why the site must do this, instead of leaving it for their users to figure out. Otherwise it’s simply too difficult for users to get an accurate idea of when they can expect their order.

Even more critically, without delivery dates it is extremely difficult for users to compare the shipping options, because they have to do all those calculations for each of the available shipping options, memorizing the results of previous options while they estimate the next one, and then at the end of it compare that entire matrix of price vs. delivery date for those options.

Only the most dedicated of users will do this in their head, and only the most arithmetically gifted of those will end up with an accurate result – unless they pull out pen and paper perhaps, but let’s be honest: if your users need to write down notes in order to use your checkout, you’ve failed.

Users Perceive ‘Delivery Date’ Differently than ‘Shipping Speed’

By this point it is hopefully clear that delivery dates enable a superior user experience compared to shipping speeds. Yet our research also revealed that there are some differences in how users perceive delivery dates and how the shipping interface should be designed.

The most important difference between delivery dates and shipping speeds is in user perception: most of the test subjects regarded delivery dates as a promise. In other words, when a site stated that the order would “Arrive by April 4th”, the majority of the subjects took that as a promise that they would receive the order by then. This is in contrast to sites that displayed shipping speeds, which the test subjects didn’t interpret as strictly (likely due to their inherent ambiguity).

Because users are more likely to see the delivery date as a promise by the site, it’s important that the calculation is as accurate as possible. Too much safety margin and users may abandon because the delivery options appear too slow. Too little margin and users will likely end up disappointed by the site’s “broken promise”. While the latter may not have an immediate impact on conversion rates for the user’s current checkout session, it is likely to have profound long-term impacts if users’ perceive the site to be breaking its promise.

Delivery date calculations should therefore dynamically reflect extra order processing time during peak periods, any extra processing time required for the products in the order (oversized items, sub-suppliers, back- and pre-orders), take holidays into account, take the order’s delivery destination into account if it impacts delivery speed, etc. This is particularly important for sites with many gift orders and around the holiday shopping season where users’ concern for timely delivery may be extra high. (More on this later in the implementation sections.)

It’s important to note that a site’s internal cut-off times for “same day shipment” processing requires special handling. Obviously, this cut-off time should be accounted for in the displayed delivery dates, meaning that if the cut-off time has been surpassed extra time is added to the delivery estimate since the order won’t be shipped until tomorrow (or later, if orders aren’t processed during weekends, holidays, etc).

However, what if the cut-off time is simply close but not yet surpassed? In that instance, it’s advisable to display the cut-off time as a countdown in the shipping interface, for example stating “Delivered by April 4th if ordered within the next 43 minutes”. The main benefit of a countdown is that users don’t have to calculate time zone offsets if they happen to be in a different time zone from the e-commerce site.

Another interesting research insight is that users don’t seem to have any issues with date ranges. During testing the subjects interpreted date ranges just as easily (and correctly) as a specific arrival date. In other words, “Arrives April 3rd - April 9th” was as easy for users to understand as “Get it by April 9th” or “Delivered on or before April 9th”.

That said, displaying a range can allow for both an optimistic delivery date (making the option appear fast, and thus lowering the chance of users abandoning because shipping seems slow) and a pessimistic one (reducing the likelihood of falling short on the promised delivery dates), so there may be an appeal to actually displaying the range. However, our data isn’t sufficiently clear to confidently conclude this – all the data conclusively showed was that the test subjects read and interpreted the date range just as easily as the singular delivery dates. We therefore recommend you split-test different variations to see which performs better on your site with its particular shipping options and customer base.

Finally, a consequence of switching from shipping speeds to delivery dates is that shipping option names often become redundant. It’s simply not necessary to give the shipping options names like “2-Day Delivery” and “Next Day Delivery” because you’re able to provide the user with information that’s much more relevant to them (i.e. when the order is actually delivered). In fact, considering that we observed shipping option names like “Next Day Delivery” to mislead users, it’s advisable to either completely get rid of shipping names and speeds (which can also help declutter an already complex checkout page) or at the very least downplay them visually.

Now, there are two approaches to implementing delivery dates. You can either rely on a postal service API to calculate the date of arrival, or you can code your own system to calculate delivery dates. We’ll explore both of these approaches in the next two sections.

Implementation Option #1 – Relying on Postal Service APIs

Most postal services / shipping firms will offer an API to their customers which will typically include some sort of a “delivery calculator”. Given that predicting and managing delivery times is central to these businesses, they tend to be fairly good at calculating such estimates with a high degree of accuracy.

Furthermore, it reduces the amount of calculations needed on your end, since all calculations after the parcel has been handed over are taken care of by the postal service API. It’s important to note, however, that this is a reduction, not an elimination, since you’ll still need to accurately calculate your processing time. While most shipping calculators will respond even if you don’t provide them with a “date of shipment”, they do this by simply assuming it will be shipped on the current day. In order for the resulting delivery dates to be accurate it is therefore important that you calculate when your business will actually hand over the package to the postal firm and provide their API with that information.

For instance, if your internal processes mean orders placed after 4pm don’t get shipped until the next workday, and you don’t process orders on weekends, and the day is a Friday and the time is 5pm, then you’d want to provide the API with Monday as the date of shipment, which would obviously end up yielding very different results. Or if the customer has chosen gift wrapping for their order and place it at 3:45pm, will it still get processed the same day or does the extra handling needed for wrapping put it in next day’s queue?

Another important consideration when integrating parts of your checkout process with any 3rd party service is 3rd party speed and stability. By using an API to calculate the delivery date, you’re effectively making your checkout dependent on a 3rd party service. It’s therefore important that your checkout code gracefully handles scenarios where the postal service API is down or just slow. In other words, there should be a fallback that’s displayed in case of slow response times or worse yet actual downtime.

A reasonable solution is to initially show the (less-than-ideal) shipping speed and then perform an AJAX-request immediately upon page-load to fetch the actual delivery dates, and then replace the shipping speeds with those once they are returned. This way, the page load times of your checkout process aren’t impacted by the 3rd party service at all and can load instantaneously, and if the postal service API returns the estimated delivery dates fast, they get replaced more or less immediately, yet if the service happens to be slow or down, the user still has information about the shipping options (it just isn’t optimal).

Of course, additional conditions could be implemented if the content replacement switch from shipping speeds to estimated delivery dates appears too jolting. For instance, the shipping options could be displayed initially with a spinning load indicator, suggesting that the dates are being fetched. This may make the content replacement slightly more transparent to the user since they wouldn’t first see shipping speeds only to have them replaced by delivery dates a second or two later.

And that’s really the core tradeoff when relying on a postal service API to calculate your delivery dates: the actual date calculations are simplified (although not eliminated) but in turn you have to build fallback solutions to avoid making the stability and speed of your checkout dependent on a 3rd party system. Which neatly brings us to the next implementation option: calculating the delivery dates yourself.

Implementation Option #2 – Calculating the Delivery Dates Yourself

If you don’t want rely on a 3rd party system in your checkout process, or if one or more of your postal service partners don’t offer a “delivery calculator”, you’ll need to calculate the delivery dates yourself. Now, it’s not too complicated to calculate a delivery date – what’s complicated is calculating an accurate one, for any order, at any day and time of the year.

While it may not be easy, it is absolutely possible to develop a system that calculates estimated delivery dates with reasonable accuracy. Let’s break down the three primary steps that must be calculated in order to estimate a delivery date:

1) Current Date & Time – You need to know the current date and time in order to determine if the order falls within certain time cut-offs and if there are any non-delivery days (e.g. weekends and holidays) that should be accounted for. This will serve as the baseline for your delivery date calculations.

2) Processing Time – It’s important to know how long it will be before the order is actually handed over to the shipping company. Will the parcel be handed over to the postal firm today or tomorrow, or perhaps even later?

There are a wide range of internal factors that must be accounted for such as:

• Your business’ cut-off times for same-day shipment
• Stock availability of the products in the order (and if not in stock, their expected re-stock time)
• The days on which your business processes orders (i.e. do you also handle orders on weekends or only during weekdays? Are there any upcoming holidays which you need to account for?)
• Whether the customer has opted for gift wrapping, if that has an impact on your processing times
• Current transaction volume vs. available processing capacity (e.g. staff shortages during flu season and high-volume seasons such as Christmas may lead to increased processing times)

Based on step #1 (the ‘Current Date & Time’) and all of the above factors, you’re able to calculate the date of shipment.

3) Transit Time – The final step in estimating a delivery date is the most obvious one: once the parcel has been handed over to the shipping firm, how long will it take for them to deliver it to the customer?

The two main considerations here are the speed of the shipping option along with the non-delivery dates for that option. It’s important to note that there are very often differences in the non-delivery days depending on the chosen shipping method. For instance, expedited shipping is often (but not always) delivered on Saturdays. Some shipping couriers will even deliver on Sundays with their premium “express” shipping option (but again, it varies from postal service to postal service).

Converting business days to actual days thus increases in complexity as you add more shipping options, firms, and destinations (since holiday calendars will vary from country to country).

Using the calculated date of shipment (calculated during step #2) as start date, you now add the transit time while accounting for both the speed of the shipping option along with its non-delivery dates. And, finally, you have an estimated delivery date.

Phew, that’s quite a bit of calculations! However, it’s important to keep in mind that even when using a postal service API, you still need to perform all of the calculations up until step 3 since you need to provide the API with an accurate “date of shipment”. If you’ve already developed the system to account for weekdays, weekends, holidays, and seasonal variance, as part of step #2, then much of that same logic should be reusable for step #3.

Of course you could also build your own system and then test it against the outputs of your postal service vendors (where applicable) to determine how well they align when given the same date of shipment.

The ultimate benefit of developing your own system is of course that you avoid any dependency on 3rd party systems and can display delivery dates for your shipping options without any fallback solutions or post-page load fetching.

Checkout Information Should Be User-Centric, Not Business-Centric

While shipping speed may make sense to shipping companies and the e-commerce site, it isn’t what users care about, and it makes it needlessly difficult for users to figure out how much faster they’d get their order if choosing a more expensive option (i.e. the speed-vs-price tradeoffs of the available shipping options).

It’s somewhat similar to order costs, where what users really care about is the total cost of their order (and not the sub-total), as is evident in our checkout abandonment research which reveals that 24% of users have abandoned an order within the past three months because they couldn’t see / calculate the total order cost. It’s not that the sub-total is completely irrelevant to the user, but it only gives them a vague idea of the metric they really care about.

At the end of the day, good checkout process design must be user-centric, not business-centric. This means that the information presented throughout the checkout must be optimized for the user and their needs. If something is difficult to calculate, that is all the more reason for the site to perform that calculation, since putting such burdens on your users is a sure-fire way to a mediocre checkout experience.

This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.