Split Checkout

[jaycmb]

Description

EDIT/ UPDATE Apr 13th (to summarize outcomes of inception)

The Checkout will be split into 3 steps/pages

1. Your details
2. Payment Method
3. Order Details

This will address

• the perfomance issues (prices calculated only after shipping details entered)
• the incorrectly displayed prices (final prices calculated after shipping details entered, but before user places the order)
• addresses the legal requirements (providing a order summary page before user confirms the order)
• and improves the user experience :)

Designs are here: https://www.figma.com/file/mwC9b6iUJxP29G4COnfkbC/Checkout-Overhaul?node-id=0%3A1

Original Issue Description ++++++++++++++++++++++++++++++++++++++++++++

Initiated by the work on adjustments and the way how tax calculations influence the final price, we would like to explore splitting the checkout in 2 pages alongside improving the overall UX and legal compliance of the checkout process.

- 1. Legal Compliance: Currently OFN is not compliant to the "Double-Click-Rule": EU law requires a checkout process to have an order summary page where

For the order to be validly concluded, you must have been able, before confirming it :

• check the details and the total price
• and correct any errors.

Your consent is given by a double click (2 mouse clicks) :

• the 1st click enables you to validate your order,
• the 2nd click allows you to definitively confirm your order after having checked it and, if necessary, corrected it.

In the absence of a double click or information on the obligation to pay, the sale is considered invalid.

Further details and acceptance criteria will follow below in comment

2. Correct Tax Calculations

Tax rates can be dependent on the address that the order will be delivered to, so in some instances this means that the rates will be different depending on the customer's location (eg. different rates in different states) In this case, the final prices on the order can only be sensibly calculated after the order explicitly has an address already saved on it,

3. Performance Currently all fees and taxes are re-calculated any time a line item is added or removed (or quantity is changed), even whilst the order is in cart state -> This is not needed until a user gets to the checkout,

as any of these tax calculations and adjustments will be removed and re-calculated after the order's address is formalised. Eg: until the address is fixed, any tax-related adjustments are provisional . Same applies to order-level fees that don't affect line item prices.

There's no reason to create them before checkout, but we re-create them every time the cart is touched.

4. UX As discussed earlier, the checkout process could do a general UX uplift.

Getting rid of Next Buttons / Jumping Sections https://app.zenhub.com/workspaces/product--inception-pipe-5f82e534db531f000f8c09ff/issues/openfoodfoundation/inception-pipe/30 https://app.zenhub.com/workspaces/product--inception-pipe-5f82e534db531f000f8c09ff/issues/openfoodfoundation/inception-pipe/21

From a UX perspective, splitting checkout should be considered, as there are also advantages for keeping a single-page-checkout since it´s easier and more convenient for the user to have all steps on one page. Splitting in to 2 steps might increase cart abandonment.

User Testing of the Checkout flow currently in play here: https://app.zenhub.com/workspaces/product--inception-pipe-5f82e534db531f000f8c09ff/issues/openfoodfoundation/product-pipe/21 will provide additional insights.

[jaycmb]

This is going to be a work in progress for legal requirements.

• [ ] Add clear indication for placing an order is connected to a payment

Customers must confirm they know they have to pay a price

When customers click the final button to confirm payment, it must be clear that they are agreeing to pay at this point. The customer must see the final amount, with a description of all they are paying for, including the products and any additional charges, such as delivery or credit card fees._

[jaycmb]

An attempt to explain the various implications of tax & shipping calculations on price.

[tschumilas]

Correction to the tax model for 'display price inclusive of tax': the decision point re: available shipping methods is, I think, the first decision point that needs to happen. IF this is a delivery/shipping method - then zone of the buyer determines the product tax, the shipping tax and the tax on fees. IF this is a pickup method, then the address of the buyer is not relevant. The address of the distributor (the place of sale) determines the product tax, shipping tax and fees taxes.

[jaycmb]

@Matt-Yorkley wrote a discourse pos ont splitting the checkout here: https://community.openfoodnetwork.org/t/splitting-the-checkout/2173

[jaycmb]

Kick-Off Call today: We decided on an approach that will split the checkout into 3 steps:

1. User enters their details (Name, Address)
2. User enters their Payment details) -> CTA: Check Order Summary
3. Order Summary Page, where they can check their Order Details (Products / Cart, Shipping & Billing Address, Payment Details, Final Price) -> CTA: Place Order On this page the respective sections are not editable, but the user can go back edit these sections

Like this Tax Calculations & Performance issues are handled and the compliance issue addressed

[Erioldoesdesign]

Hey folks,

There's 3 options for how to split the checkout currently here on Figma: https://www.figma.com/file/Y4i3BrRIo5dnmE0MNH0NrD/Checkout-Splitting-UI?node-id=0%3A1

This now needs Product and Developers to take a look as assess:

1. Are there any big AC's for design missed?
2. Which options fit our scope of dev time and also solve our user story

If there's anything to come back to design the issue will go back to 'Needs Design' for changes and then cycle back into QA/Review until finished from a product, design and dev pov

The community then gets a look via discourse!

(the radical changes is WIP benched due to time and resources, it was quite ambitious 😅 )

[jaycmb]

In general, I think from the versions the V1, titled as "Estimated Shipping View" is more in the scope of what we are trying to achieve than the V2, "Full Pop-Out Basket" version: it solves

• the perfomance issues
• the incorrectly displayed prices
• addresses the legal requirements
• and improves the user experience :)

Although I personally find having the cart visible during the checkout process could be helpful for the user, I would keep this for a next iteration.

Feedback step by step, for the "Estimated Shipping View" designs

1 - Your Details

"Pre-Summary" box

As discussed, I think we can get rid of the "pre-summary" box on the right side.

• we cannot display final prices here, since shipping (& tax) can only be calculated after the user entered their details in this step
• solves performance issues

Cons: users might wonder about the order size, but - order summary will be shown in final step (nr. 3)

Delivery / Shipping Address

Probably just a "copy-paste" error, but to avoid confusion for development: if "delivery address is same as billing address" is checked, then no form for shipping details should be displayed to the shopper, only the "any additional comments" field Design: Actual:

-> By the way, I find in the current flow, for cases where the shipping address is different from the billing address, the user flow is overcomplicated (enter shipping details "hidden" behind the checkbox). But that might be scope creep to touch ;)

2 - Payment Method

CTA: "Back to Edit Basket" -> Would it not be back to "Your Details"? And/or can the user click on the steps in top bar to go to the previous the step(s)?

Textbox: Info text for Paypal sounds a bit odd. That´s placeholder only, I assume? Or is this info text provided by the admin user?

3 - Order Summary

Product Section I prefer V2 of the Product Section as it´s much nicer for the user to see the products. Since it´s using the same component as the order confirmation, I assume the effort to include it here already on the order summary should be not too much but that´s for @jibees to estimate.

Price Overview Box: missing Tax

CTA Button: Again, I think the CTA should not be "Back to Edit Basket". We offer the option to edit the basket below the "Cart Section" and I think it´s better to have this functionality only once on the page. It could be "Back to previous step" or, I prefer not having it at all another CTA up there.

We have the main CTA in the bottom of the page, which should be "Place order now" From a Checkout/ Conversion optimisation perspective, the "Back to Shop" option below should not have the same emphasis as the "Place order now". Maybe just having this as a simple link?

[jaycmb]

Ah sorry, just seen that for the 3rd version "No Summary View options" the CTAs are different and actually pretty much aligned with what I proposed above :) So for the purpose of focus the decision on whether to go with or without summary view, would be good to adjust CTAs so that the rest of the flow is equal?

[jibees]

Hi,

Thanks a lot for your work @Erioldoesdesign and your feedbacks @jaycmb : I agree many of yours, and I do prefer the V3 (No summary view option) version with the order summary component displayed like on other pages: I think it's better from user's comprehension and point of view but also from a developper point of view: I do not know well this part, but generally using same components (if it's previously well developed, and I have no doubt about it ;)) is faster than created new ones.

[RachL]

Hello :) I'm not looking at this into detail: I trust you guys and will have a look only once it is out for community feedback ;) . Just a question for my general knowledge: this new checkout view will still be developed in Angular?

[Erioldoesdesign]

Cool unless there's more internal product and dev feedback (@Matt-Yorkley ?) then this is ready for community feedback round!

https://www.figma.com/file/4C4ACKK3B5G9NDkMRnCTgd/Splitting-the-Checkout-v2?node-id=0%3A1

[Erioldoesdesign]

Thumbs up from Matt! - this is going to community feedback with this in the Discourse:

https://community.openfoodnetwork.org/t/a-new-split-checkout-community-feedback-on-designs/2235

[jaycmb]

Latest Designs here: https://www.figma.com/file/tseK3VLv18myB5BSES0mtm/Splitting-the-Checkout-v3

[jaycmb]

What´s still missing to finalize the design / inception phase, was a decision on how to do the 'Order Total' on the Order Summary Page, blocked by the discussion how to present tax.

Summary from conversation with @matt-yorkley and community feedback:

1. How to present tax for different instances V1: We will have 2 different versions of how to present tax for instances with tax included vs. tax added V2: Eventually we are trying to unify the way of how to present tax for both types of instances. But this needs further investigation, from tech side of the adjustments work (upcoming adjustments changes will be changing the way taxes are recorded for US and Canada). So we can iterate on this in a next version.

2. The tax breakdown (i.e. detailed tax on every position) might be too complicated at the moment so

V1: we go with one field aggregating all taxes: ‘Tax included’ for instances with tax included, listed below the order total (as Konrad pointed out, otherwise it reads like tax is added up), and ‘Tax’ for instances with tax added, listed above the order total V2: Eventually we can think if & how (unified for all instances) to present taxes separately for each tax type

3. Not specifically on tax, but on the ‘Order Total’ we do the joined ‘Order Total’ table at the bottom of the page, instead of having 2 tables on the order summary page (‘Produce Subtotal’ and Your Order=Produce + Fees, Shipping + Tax). @matt-yorkley confirmed it doesn´t make much difference for tech side, but clearly much more user-friendly and less-scrolling.

Other decisions of this final round of feedback:

• On scrolling concern we will test having a 2nd CTA ‘Complete order’ on top of the page, right side column

Possible other change, to be confirmed by @Erioldoesdesign: Could the ‘Order ready box’ moves somewhere below, to follow the 'One column only' Design?

[Erioldoesdesign]

Okay I updated the Figam file: https://www.figma.com/file/tseK3VLv18myB5BSES0mtm/Splitting-the-Checkout-v3?node-id=0%3A1

With changes to tax area and also a quick go at:

"Could the ‘Order ready box’ moves somewhere below, to follow the 'One column only' Design?"

There's a lot more improvement that can be made to the 'header' section of these pages but so for, this is a good quarter-way to improving layout from 2-column to 1 column responsive.

Just an FYI @jaycmb I gave you edit access to this V3 Figma file so you can make essential edits while I'm offline for the next week. I trust you! but also if it's critical I step in to push something along, do contact me and I'll make time to change things ready for delivery.

[jaycmb]

Last minor design changes discussed

• we decided to add a note to the shopper on the order delivery page before placing the order -> this is a "proxy" to the doubke-click rule, i.e. making extra clear to the user that they are giving a go to process the order without having changing CTA buttons

• we decided to go with the 2 CTA 'Place order' on the top and the bottom of the page as the "default" and evaluate in user testing and product analytics

• [ ] @Erioldoesdesign to check with @Matt-Yorkley how to handle having the 'Agree to Terms & Conditions' check twice on the page

• [x] @Erioldoesdesign to share final design file.

Moving this Epic to Delivery Pipe and start creating issues :muscle:

[Erioldoesdesign]

Final design file: https://www.figma.com/file/uhgmuHCznpkoYnaM8AZESt/Splitting-the-checkout-for-dev?node-id=0%3A1

Discourse post updated: https://community.openfoodnetwork.org/t/splitting-the-checkout/2173/9

[Erioldoesdesign]

Asked Matt for some time this week to chat through the dev bits

[drummer83]

Just wanted to point out that it was agreend NOT to change the address input fields of the checkout processs compared to what we have now (see this Slack conversation). This should be explicitly mentioned to developers because the Figma file still contains changes.

Discourse post still seems to be private. Should it be public because community feedback was requested?

@Erioldoesdesign @jaycmb

[jaycmb]

Thanks for the reminder @drummer83 - that´s true, we agreed to keep the current implementation. That must have gone under the radar, slack threads are not the best place for documenting decisions ;)

[Erioldoesdesign]

I can change the designs but I strongly advise that the first improvement ticket for this work after live is to remove 'Address cont.' in favour of street etc. because of the user-testing evidence.

[jaycmb]

Agree that 'Address cont.' is not intuitive and that users can be confused of where to put in the house number. We are mixing up 2 things here though:

1. order of input fields
2. ambiguous input field description

1) Ideal case would be to have the precise description of the input fields ('house number' , 'street') but with the order of fields localized for the instance. But that´s certainly overkill for now 2) This could be addressed now already if we want, by renaming the 2 lines to something like:

• Address (Street + House Number)
• Additional address info (optional)

But also good to just keep it like it is, and validate text with users.

[Erioldoesdesign]

Figma file changed and updated

[RachL]

10636 will definitely close this, but as it's the last issue I'm closing here to have a clearer dev ready column. We can reopen if needed.