Meta Issue of all Commerce 2.x UX changes and improvements, see related tasks for detailed work, this main issue will contain overall audits and discussion.

#38 D8DC2.Xcheckout-ui-side-by-side.png92.61 KBwebsiteworkspace
#28 Hint-Examples.jpg38.59 KBjjpoole
#26 (Acro)-Commerce--Alpha-Review-1.0-jp.png127.75 KBjjpoole
#21 2626948-checkout-07.png289.25 KBjoshmiller
#21 2626948-checkout-06.png307.07 KBjoshmiller
#21 2626948-checkout-05.png269.24 KBjoshmiller
#21 2626948-checkout-04.png249.25 KBjoshmiller
#21 2626948-checkout-03.png366.69 KBjoshmiller
#21 2626948-checkout-02.png82.99 KBjoshmiller
#21 2626948-checkout-01.png207.43 KBjoshmiller
#20 Customer Info - 1.1.jpg192.97 KBjjpoole
#19 Account Config - 1.0.jpg171.63 KBjjpoole
#14 Confirmation - 1.01.jpg115.48 KBjjpoole
#13 Cart View - 1.0.jpg156.23 KBjjpoole
#13 Customer Info - 1.0A.jpg193.29 KBjjpoole
#13 Customer Info - 1.0B.jpg228.62 KBjjpoole
#13 Shipping Method - 1.0.jpg153.99 KBjjpoole
#13 Payment - 1.0.jpg168.66 KBjjpoole
#13 Review - 1.0.jpg170.8 KBjjpoole
#13 Confirmation - 1.0.jpg63.06 KBjjpoole
#13 Data Field Styles - 1.0.jpg142.36 KBjjpoole
#10 Inline Field Validation.png55.5 KBAaronChristian
#10 Step Tracking.jpg41.83 KBAaronChristian
#10 Existing Users.png27.8 KBAaronChristian
#9 Tips and tools for e Commerce Businesses.pdf938.86 KBsmccabe
#4 Screen Shot 2015-12-01 at 4.51.12 PM.png1.03 MBgonz
#4 Screen Shot 2015-12-01 at 4.49.44 PM.png126.27 KBgonz
#4 Screen Shot 2015-12-01 at 4.50.24 PM.png120.44 KBgonz
#4 Screen Shot 2015-12-01 at 4.49.55 PM.png100.06 KBgonz
#4 Screen Shot 2015-12-01 at 4.47.52 PM.png152.28 KBgonz
#5 order-complete.jpg83.18 KBgonz
#5 responsive-mobile-example.jpg84.16 KBgonz
#5 checkout-p3-review-w-shipping.jpg110.49 KBgonz
#5 checkout-p2-billing-payment.jpg96.34 KBgonz
#5 checkout-p1-shipping.jpg93.25 KBgonz
#5 cart-sitewide-auto-updates-flyout.jpg208.71 KBgonz
Members fund testing for the Drupal project. Drupal Association Learn more


bojanz created an issue. See original summary.

bojanz’s picture

Issue summary: View changes
bojanz’s picture

gonz’s picture

I like the idea of having the cart displayed at all times through a short checkout process. This eliminates the need for a review screen as well.

ex: The Clymb

PS - sorry the screenshots seem out of order to actual checkout workflow.

gonz’s picture

Sorry about last set of images - these image names are more meaningful:

Looking through @Julien's the Docs - these followed many of the suggested guidelines:

  • I included a screenshot of the sitewide Cart Block "flyout" - when a customer adds a product to cart - the cart block reveals itself with updated content, saving and cost estimates in place with suggested products (not necessary - but confirms Julien's comment about NOT having them on actual "checkout" pages)
  • Form Labels - with limited and meaningful HTML 5 placeholders
  • Progress bar - they did a great job of consolidating: Shipping -> Billing/Payment -> Review/Shipping
  • Each section shows as much of the previous information as possible (ex: shipping address info shows up on Billing/Payment - this makes the customer feel confident and "less likely" to go back in the forward progression of the checkout (as it can be edited in place from this place)
  • This applies to the Review/Complete page as well - as you can see - the customer can edit Shipping and Payment info in place even at this final stage.
  • Shipping is combined on this last review page with the "Place order now" button clearly positioned as the final action to complete checkout
  • I made a Order Complete Page mockup (not The Clymb - although I can proably get a screenshot - I am a fan :) also shows a more complete order information to help the customer feel confident the order is placed correctly and in processing.
  • I also like the responsive stacking order - because the order is shown on ever section of the checkout - it is stacked below the current action item.
smccabe’s picture

Note about not requiring a review screen. While these examples do have the cart tagging along for each page, many payment gateways require a final review page after all information has been entered. I would recommend we keep the final review page as it is that sort of final check to prevent incorrect orders and help protect you from chargebacks as best you can.

PS. That clymb site requires you to login with email or facebook before you can even click any links? yuck

gonz’s picture

@smccabe - yeah - its a flash sale membership site. That why I left out the login screenshots before these checkout screens - it was already done.

I'm curious - can you give me an example of 1 or 2 Payment Gateways that require a final review page? We mainly use or Paypal Pro - and so far they do not require it - but I know we should be thinking and developing with as large of a user base in mind as possible. Maybe we can use their API guidelines in our UX strategy.

Also curious if a consolidated version like the clymb - would suffice as a final review page.

rszrama’s picture

PayPal EC requires an on-site order confirmation page in the event you use the Express Checkout button from the cart form to log in at PayPal and authorize payment.

smccabe’s picture

@gonz One I know off the top of my head is Moneris, I've attached their little quick checklist, although if you actually setup an account with them they will do a manual review that can be a little more in depth. Their wording isn't precise, so the clymb style may suffice, tbh it would probably come down to the individual reviewer.

The list might be helpful though, it give some technical details they prefer like return and privacy polices, currency display etc.

AaronChristian’s picture

Hey Guys,

I have a few notes on the UX of how the final checkout flow could be designed. I work closely with the Telus Mobility teams in Vancouver and Toronto and have solved some fundamental issues they have encountered with Checkout flows and conversion rates.

Some things I think we should consider/implement with the direction of the new D8 commerce project.

  • Returning Customers; We can query the db to see if the user has an account. If so, we can display a password field and a login/forgot password button. This keeps the checkout flow linear, without redirecting users and increasing cart abandonment.
  • Step Tracking; Display how many steps there are in total, the current step, completed steps and steps left in the flow (icons w/ text for accessibility).
  • Placeholders instead of labels; To keep checkout forms clean and simplistic, I suggest we hide (not remove) labels and * (required) notations, and instead use placeholder text with descriptive labels (ie. Email Address (optional)).
  • Avoiding Contextual Words; Keep the checkout buttons concise and descriptive (ie. Continue (Bad), Continue & Pay (Good)).
  • One Column; All fields should be listed in a one-column format, the address fields are guilty of bad UI and should look as some layout improvements.
  • Inline field validation; We could provide some inline field validation to reduce the number of errors that can arise with user inputted fields.
  • Feeling Safe; This can be controversial, but at least adding some sort of icon or image alluding to safe shopping can help the user feel comfortable with providing their credit card details. This can even be implemented through the step tracking system.

Some ideas I'd like to see implemented to reduce time spent filling out billing/shipping/payment details;

  • Google Address Autocomplete; Would allow the user to start typing their address and once selected would populate fields like (City, Province/State, Country).
  • Remove Card Type for Payment Processors; Most card types can be calculated by the card number. As a best practice, I saw this in the google doc (Checkout UX report - Final) about graying out card icons. This is a great idea.
  • One-Page Checkout; With the way commerce and panes are structured, its a great improvement. But the concept of having a one-page checkout would increase conversion rates tremendously.

I would be willing to contribute UX/UI improvements in regards to designs/mockups so we can get some of these proposed changes into action.

Some great UX/UI reads;

jjpoole’s picture

Hey guys,
Here is best practice/UX stuff we've gathered from different sources and our experience:

jjpoole’s picture

Hey guys,
Here's some UX recommendations our team has compiled.

jjpoole’s picture

Here are a series of mockups for the cart/checkout process. Most screens have a few notes at the bottom of the mockup.


  • Cart View
  • Customer Info A
  • Customer Info B
  • Shipping Method
  • Payment
  • Review (optional)
  • Confirmation
  • Data Field Styles (supplemental)
jjpoole’s picture

115.48 KB

Here's a revision to the Confirmation page, just wanting to give it a bit more love and try and make it more useful to the customer. Ideally the upsell products would be related the items just purchased.

bojanz’s picture

IRC feedback given to Shawn for #13 / #14:

1) Address fields have already been designed, we can't provide a single-field lookup out of the box because we'd need to depend on an external service. That's contrib material.

2) We need to think about the UX for reusing addresses. Related: #2633656: UX For reusing addresses in checkout and order edit.

3) We need to think about the login/register/continue anonymous step (or block shown on the billing information step).
Login is tricky cause it essentially changes the whole page (available addresses, header/sidebars, who knows what else).
Do we allow login as a part of the flow (perhaps its own page), or insist it's done elsewhere?
The register / continue anonymous can be done on the Billing information step.

4) Review is frequently tied to the payment step, cause the payment step executes the payment, so you can't offer review after payment (even doing just authorizations feels a bit like cheating).

smccabe’s picture

1) I'll get the comps redone without the google requirement and spin that out into a contrib options
2) We'll do some comps up for address options based on mglaman's research
3) ..I'll have to think on this one more
4) Switch the order? Review -> Payment? Review would be an optional page if it is required?

bojanz’s picture

How about merging the Review and Payment steps? First half review, second half Payment. I believe 1.x did it that way too.

smccabe’s picture

Isn't that pretty much what the payment page already is? it has full part and shipping info on the side already. The idea was to have an optional review page to toggle if payment gateway requirements needed it. I see now though that having a page in-between payment info and submit would be a functionality nightmare for many payment integrations. At this point maybe we should just drop it? I know UX wise Jason hates it because it is an extra step that does nothing.

jjpoole’s picture

171.63 KB

Here's some direction for Account Configuration (login options).

jjpoole’s picture

192.97 KB

Updated Customer Info (1.1) page that doesn't rely on Google auto-complete. We do want to leverage the postal/zip code to populate as much other data as we can.

joshmiller’s picture

Updating the summary with content from the report by request of Bojan.

bojanz’s picture

Issue summary: View changes

Improved the notes.

drewmacphee’s picture's checkout has a lot of the elements we're looking for.

Their optional login is simple.
Enter your email address, link to a modal login/registration form for "Express Checkout"

Updating shipping address updates shipping methods and total in the review. (Pick Canada vs US and the shipping prices change)

Also has promo codes and gift certificates add links like discussed elsewhere. (modal though, instead of reveal)

Shows what additional panes would look like (Gift wrapping / Donations)

I believe the site is running on Demandware and is likely a one page checkout add-on.

bojanz’s picture

Their optional login is simple.
Enter your email address, link to a modal login/registration form for "Express Checkout"

I did list that in the issue summary as a possible option for contrib.
However, we'd need to find and implement a good modal solution first.
This one looks promising:

Commerce still needs to support checkouts that require login/registration, so the Apple-esque step 0 needs to be coded anyway.

drewmacphee’s picture

Not sure it's the best UX but if an account is required it could force the modal to open?
Although this all sounds like a contrib version rather than the default.

jjpoole’s picture

Issue summary: View changes
127.75 KB

Here's a UI review on an alpha we setup, didn't have shipping/payments setup so didn't review those areas. Realize some of this stuff is theme/style related but thought I'd just add all them comments anyway.

bojanz’s picture


Here are some responses:
- It's up to the site to theme the Item column to contain a thumbnail. We don't ship with an image field, so we can't do that by default.
- The -dev release ships with a checkout progress block, you probably need to enable it manually in the Blocks page (composer create-project gives you that automatically).
- The cart summary is being tracked in #2710985: Add an order summary and is a priority.
- Can you provide example field hints?
- Search/combo box for the country is a job for the (optional) select2 module (it did it automatically in d7, we should make sure it still does in d8 once it's fully ported).
- The VAT ID field will show up automatically if added to the billing profile. Nothing for us to do.

jjpoole’s picture

38.59 KB

Here's a couple examples of field hints (or field descriptions). Fields seem very obvious to us, but typical users can get confused by simple inputs. This can turn into a major issue if a user doesn't understand what is being asked for on required field.

It can also set the users mind at easy when you tell the customer why or what you are doing with the information you are asking for (why do you need my phone number?).

A couple of examples in the attached image. Note, it can be very userful to have hints on buttons as well.

smccabe’s picture

Title: Decide on default checkout UX » Commerce UX Meta

Changing this slightly to be a Meta issue for various UX work, since the review work here needs to be spun off into child issues for individual fixes.

smccabe’s picture

Issue summary: View changes
bojanz’s picture

Title: Commerce UX Meta » Checkout UX Meta

Various UX work around checkout. Let's be more specific.

#2710985: Add an order summary has landed. We can open issues for the rest (marking optional fields, adding hints...)

rszrama’s picture

Recovering the deleted issue summary that included research and screenshots. Let's try not to delete this sort of information in the future:

Initial Report

Sharing initial research done by Julien Dubreuil last year:
Raw data:

What we're missing from the report is what the rival ecommerce solutions (Shopify, Bigcommerce, Spree, Sylius, WooCommerce) are doing.

Based on report I'm assuming we'll want to continue having a multistep form (and not an accordion).

Checkout forms will be swappable for people willing to experiment with drastically different designs.


Checkout Layout

Commerce currently has an Address page which collects both shipping and billing information.

The payment method (saved cards / new card) is selected on the Review step, below the review pane.

Problem: We’re asking for the billing address before we even know if it’s needed. A payment method such as “cash on delivery” doesn’t actually need a billing address. And if we select a saved card, then it already has a billing address, making the checkout entry useless. Conceptually, the billing address is tied to the payment method, and this design divorces them.

Solution: Tie the billing address to the payment method form.

In Europe the billing address is the one that controls taxes, so selecting a billing address will change the order total (and might even change the currency). That means that the payment method form is only for selecting a payment method (and tokenizing card details if supported), the actual payment is executed later once the order total is final.

Having this distinction (selecting a payment method VS executing a payment) is very helpful for single page checkout too. Here’s a proposed flow:

Account -> Order information -> Review -> (Payment) -> Complete

The (Payment) represents the sometimes used page used to redirect the user offsite, or show an iframe.

The order information page now actually has all of the information entry:

  • Shipping address
  • Shipping method (refreshed via #ajax if the methods have address conditions)
  • Payment method selection (none shown in case the user is anon, or the gateway has no wallet support)
  • Billing address (collapsed by default using the “Same as shipping” checkbox)

Since that billing address might change the order total, we must place the Review on the page after, to show the customer the changes. The review page has a “Place order and pay” button which actually triggers the payment (do redirect, show iframe, capture amount based on token, etc).

Checkout Example

It’s also recommended by: under “Asking for Credit Card Info Last”


There are two (very different) use cases here:

  1. Customers should be able to stay anonymous (guest checkout, common for shipping websites)
  2. Customers must register before checkout (common for subscription websites)

“Allow guest checkout” & “Show registration form” are settings of the Login checkout pane.

I suggest implementing the UX seen on and many other websites:

Login Register Example

It is a very simple page, which gives you the opportunity to login, or a big button to press if you just don’t care about accounts. As a customer I’ve always liked this design, and it simplifies the next steps (since you don’t need to repeat the login form).

If you continued as Guest, the top of the next page has an Email field (just like on 1.x) and the checkout complete page has a pane that allows you to create an account once you’re done. Example:

Register after checkout example

Sites that require registration usually enforce it on the Login screen, so we’d (optionally) replace the “Proceed as guest” column with the registration form. This is the same as the commerce_checkout_redirect UX in 7.x

ASOS used to do interesting thing, since they had a long registration form, they’d replace “Continue as guest” with “Continue and register”, then show the registration form as the next step:

Register at beginning example

That would be perfectly doable on a per-site basis, for clients that need it.

UX Alternatives:

A site could also easily implement the Adidas UX, where the “Login” pane and page are disabled, but the next pages have an ordinary Drupal login block in the sidebar (above the order summary block).:

Login Block example

An interesting contrib-worthy UX is the Forever21 one, where you get all three account options as radio buttons (and the form underneath shifting via ajax). It feels a bit harder on the brain than making a quick login/guest decision on the previous screen, but it does remove an extra page with minimal effort.

All 3 registration options as radio button example

Initial UX design for Drupal Commerce by Acro Media, Inc.

This is the initial login UX design for Commerce 2.x done by Acro:

commerce 2.x ux example

The checking for matching accounts in the background is impossible to do quickly, and is also a security issue (reveals the presence of emails in the system). The switching via AJAX between two very different screens felt confusing. The only sane version of this UX is an Email field that has a “Have an account?” link below, opening the login form in a modal. Shopify’s looks that way, but it doesn’t use a modal, so I get redirected to a separate page and feel lost.


Do note that these sites get redesigned often, Newegg looks nothing like the site in the report, for example.


- At the end of anonymous checkout, e order will be assigned to an existing user with that email, if found. If not found, there's the pane for providing a password for a new account.

- A review page is required by law in the EU, and generally a good practise elsewhere

- I like the idea of a cart summary being shown on the right side of the page (instead of on top like in 1.x). Shopify also allows coupons to be applied here.

steveoliver’s picture

Added another checkout related issue.

Lukas von Blarer’s picture

One of the biggest UX issues I had with commerce 1.x that I never resolved is this one: #2815115: Resolve UX issue with the AJAX callback

IMO this one is really critical since it can lead to data loss, makes tabbing between fields impossible and can be very frustrating for the user.

AaronChristian’s picture

websiteworkspace’s picture

Following thread.

Submitting D8 Commerce 2.x software problem reports to help make DC 2.x the best it might be.

Lukas von Blarer’s picture

@DrupalWebsiteBuilder please use the follow button at the top of the page on the right side as described here:

websiteworkspace’s picture

After working with the current default side by side checkout form, illustrated as follows:


it seems like a vertically stacked default checkout form, with the order summary above the payment information, having both the order summary and the payment information forms with similar styling, and both in a similar field group, would be a better default setup.

A vertically stacked checkout page layout leaves more room for detailed product descriptions in the order summary and for showing product pictures in the order summary, horizontally left of the product description. The current narrow side by side setup would require product pictures to be stacked vertically above product descriptions and other information, in what is a rather narrow column, as the sample image illustrates.


The checkout page example above uses the default, out of the box, commerce checkout forms, and only adds CSS inherited from the drupal theme.

bojanz’s picture

We won't be changing the default layout of the checkout page.

Sites are free to implement to override commerce-checkout-form--with-sidebar.twig.html to merge the sidebar into the left column if they wish to do so.