[mobile ux] "next" on checkout sometimes jump checkout sections, or bring too low > UX confusing and leads to errors

[myriamboure]

UPDATE 29.11.2018 After PR openfoodfoundation/openfoodnetwork#3047, on mobile when I click on "next" I am correctly taken to next section BUT too low, I see the bottom of the section apparently and not the top, it's confusing. Ex after address section when click on next: After shipping section when click on next:

Description

UX at checkout is confusing, both on desktop and mobile. On desktop, navigating through the 4 sections is not consistent, when I click on next sometime it doesn't bring me to the next section but jump some sections. Sometimes it goes too "low" on the page and I have to scroll up to be able to fill in info. It complicates checkout and frustrates shoppers. On mobile panels are closed and require Customer to click on 'expand', which is in small text and on the right hand side of the screen. So people get stuck.

Expected Behavior

I can navigate easily through checkout sections both on desktop and mobile.

Proposed behavior: when a Customer goes to the Checkout, any panels that require information to be filled in will default to open so that it is obvious that they have to enter information. If the Customer is already logged in or logs in, and has shopped previously, this will most likely be the Shipping and Payment panels If they are a new Shopper it will also be the Details and Billing Info panels

Actual Behavior

I can't navigate easily through checkout sections and it's hard to fill in checkout info both on desktop and mobile.

Steps to Reproduce

On desktop and mobile

1. Put products in a cart on any shop (I tested with a registered user).
2. When you reach checkout page, fill in content of first section of checkout (if registered user and info saved, unhide the info and redo the process as if no info were saved) and click on "next", it brings you to the second section.
3. Fill in and click again on "next", it brings you directly to the 4th section, skipping the shipping method !
4. On mobile, see that some panels are closed and you need to click small link to open them - not obvious

Animated Gif/Screenshot

Desktop behavior: https://www.useloom.com/share/4dc286a795fe44ad847aa3be66d0e268

Context

I regularly hit this issue, and especially today Irene from Sicily starting to use OFN hit it again in front of me and was distrurbed, she didn't understand how to checkout as she was sent directly to Payment and didn't see she had to choose a Shipping option, then got the error, etc. Pretty bad UX touching checkout. For mobile that was also reported by Kirsten in openfoodfoundation/openfoodnetwork#2485

Severity

S3, but pretty annoying S3 as most users are concerned at every checkout. They do with it but it's disturbing checkout.

Your Environment

• Version used: V1.18 French instance
• Browser name and version: Chrome
• Operating System and version (desktop or mobile): Ubuntu 18

[kirstenalarsen]

I just experienced this too - it definitely didn't used to be this bad, something has gone wrong! There is a card in mobile ready to "Default all unfilled Checkout panels to open" for mobile. Would this be something that should just apply to whole checkout (desktop and mobile) as a quick fix, and then we can refine from there @myriamboure ? If so it could probably be a 'good first issue'? https://github.com/openfoodfoundation/openfoodnetwork/issues/2485

[myriamboure]

Yes, maybe actually it would be good on desktop as well, what do you think @RachL ? It's not such a long page... it makes navigation harder actually to have to jump from one section to the other. Although some people might be afraid as we are asking quite a lot of info, I guess that's why the choice was made to hide and show step by step. But I think single page checkout works usually better in term of transformation, right? Anyway we can try and see how people react ;-)

[Matt-Yorkley]

I think it'd be a great idea to just have the 4 sections open and not jump around on the page, for both mobile and desktop. :+1:

[RachL]

Yes I agree. In the future, we could also consider having actual steps : one page per step, with a summary at the end. And for user with all info already there, a jump to summary with the hability to edit one section if necessary (like if the user wants to changes its address). But for now yes let's open everything by default!

[myriamboure]

I'm not sure steps are a good idea @RachL but we can discuss in the appropriate space when we decide to discuss it. For now it seems we have some consent emerging for deploying all sections by default at checkout.

[myriamboure]

I update the main thread with this as potential (and preferred) solution

[myriamboure]

@kirstenalarsen I have "merged" both issues in this one with a single solution then, can we close https://github.com/openfoodfoundation/openfoodnetwork/issues/2485? Add this one to the project then if you want. @Matt-Yorkley do you agree it's a good first issue? Even maybe hacktober fest @sauloperez ?

[Matt-Yorkley]

@myriamboure it should be fine as a first issue. A bit of Angular and playing with HAML templates. It's mostly deleting code, so not too tricky.

[kirstenalarsen]

To do as part of openfoodfoundation/openfoodnetwork#2485

[mllocs]

Hey, I started working on this one 😄

Some notes:

• By default, all the steps will be expanded, both in mobile and desktop.
• Clicking "Next" won't hide the completed section, it will only scroll down to the next step.
• It will still be able to hide/expand sections if you click to the Hide/Expand text.

[myriamboure]

I reopen the issue and updated the main thread, we noticed with @RachL something confusing on mobile, when click on next it goes till the bottom of the next section so we don't see the top options, we have to scroll up again. This remains to be fixed. I don't know how hard it is @mllocs ? If it's possible to fix this little remaining bug that would be awesome. The PR has been merged and this little bug was not blocking merging anyway, so you can open a new PR. Thanks in advance, you rock !

[Matt-Yorkley]

I'm looking through this and the work that has been done previously and it's not clear what the expected outcome is now. It looks like there are still some issues with the sections jumping around when the "next" button is clicked and the current and previous sections open and close at the same time.

We could just remove the "next" buttons entirely and not open/close the sections that way (they would still have an expand/close button). It also means the main "Place order now" button is the only primary-coloured button on the page, which is nice and clear.

Thoughts?

[daniellemoorhead]

@Matt-Yorkley as far as I can see the only remaining thing to be done is what Myriam mentions above:

I reopen the issue and updated the main thread, we noticed with @RachL something confusing on mobile, when click on next it goes till the bottom of the next section so we don't see the top options, we have to scroll up again. This remains to be fixed.

So all that's left is for you to make sure that the next button takes the user to the top of the next section, rather than down to the bottom. That's my read of this bug, don't think we need to remove the next buttons to achieve this?

[Matt-Yorkley]

The scrolling was previously removed (in openfoodfoundation/openfoodnetwork#3047) because it caused issues. Now the next button just closes one tab and opens the next, but even this can cause problems if the tabs are different sizes. I don't think we want to re-add the removed scrolling?

[Erioldoesdesign]

@Matt-Yorkley after checking this in live yeah it looks like clicking next basically does the same operation as closing the expanded tab and there's no 'snap' or 'scroll' to the next section.

As a user, when you click an action like 'next' you do expect to basically have the next fillable field in your immediate vision even if it's pre-filled with saved info to just 'review'

I imagine the original problem this issue described was that it was 'scrolling' to the top of the tab div and/or the 'expand' button and then the expand animation was happening and I can imagine all the movement on the screen along with how humans naturally keep a thumb or finger on the touch screen made this quite unpleasant exp wise.

@Matt-Yorkley what do you think about having about the next button press snap to the next (likely empty) field in the next expanded section? and does not close the section just completed? I don't think we must have all this expand/open functionality, users can see what's been filled if they scroll up and down and the green tick signifies a 'completed' task.

Though snapping to the next empty field like gonna be not a great exp for those of us with pre-fill info in our browsers (like lastpass/google autofill etc.)

Essentially at this point, I think we're after anything that reduces things opening/closing moving around.

[daniellemoorhead]

Agree, thanks Eriol.

Let's go with that for now as a best case scenario and then one day we'll completely redesign the checkout experience and make it more schwinnng :)

[daniellemoorhead]

@Matt-Yorkley you ok to get this change through? Been 16 days of sitting since last activity...

[daniellemoorhead]

@Matt-Yorkley would be super wonderful awesome sensational if you could sort this out in my final week so that we wrap up as much mobile work as possible pretty please with a cherry and all the best toppings on top 🙏

[Matt-Yorkley]

We've had maybe 4 or 5 iterations of this idea where "the user clicks the Next button and is taken to the next panel" idea over the years and all of them have been broken. The current iteration is probably the least bad. Each iteration has involved clicking the button and then some kind of jarring and confusing variation on: scrolling, jumping, or shifting of the page content, and it's never worked.

We've also had users think they have submitted the order after clicking the big primary Next button, but they hadn't clicked the Place Order Now button because they couldn't see it :see_no_evil:

Here's an example with the current iteration:

Can we please just remove the Next buttons entirely and not move the page or the content around at all? :pray: Instead of being "jumped" to the next section, the user just has to scroll down a tiny bit. It looks like this:

[lin-d-hop]

Thanks for this suggestion @Matt-Yorkley I agree these buttons create checkout problems.

Questions: Are you just proposing to remove the Next button from the 'Shipping info' section or would you also be removing it from the 'Your Details' and 'Billing Info' sections? I would be in favour of removing them all. Note you only see the first two when you checkout as guest or new user.

Personally I would like design input on this as a critical workflow step on the most critical process in the system! Ping @Erioldoesdesign

[Matt-Yorkley]

All of them :fire::fire:

[sigmundpetersen]

Looks like current behaviour is different on mobile than on desktop? Maybe @filipefurtad0 could help out with browserstack to get an overview of the different current behaviours?

[filipefurtad0]

Hey, sure. I had a quick go at different mobile devices, and my own desktop. This seems to depend on the screen size and current zoom of the device. With the defaults, a less optimal "jump" - scrolled down too much - is observed on all of these below, when clicking "Next", after inserting the customer address. In older devices (smaller screen) this is also happening when going for the payment method (see iPhone 6):

Firefox and Chrome - on Samsung Galaxy S20

Firefox - Samsung Galaxy Note

Chrome - iPhone 6 iOS, v8

-> payment methods

Chrome - iPhone 11 Pro iOS, v13

On my desktop (Firefox/Ubuntu) this was not an issue, because all the checkout fields fit on the screen, on the default zoom and full screen window size. So the next buttons didn't make any weird jumps. But if I zoom in too much, or try to check out on a smaller window then this is observed as well, when clicking "Next", after inserting the customer address.

[Erioldoesdesign]

So what we have re. next buttons, is pretty non standard I agree but i don't think removing the next buttons will solve our bigger problem, just fix the very specific problem of the jerky snapping animation. So tl;dr, yes, removing the next buttons solves this issues problem. Most people will indeed scroll their mouse or touch-swipe down to get to further fields needed to complete checkout.

It's longer, but please read if interested ❤️ The people that won't scroll are you're less tech savvy people or people with older devices and/or conditions like Parkinson's or arthritis which make touch-swipe actions harder. But generally, the platform's accessibility beyond this section needs work to help these kinds of folks.

Most multi-step processes on checkout screens are across multiple pages, so the next button in this case takes you forward and backwards in a page. It removes the need for scrolling. But I also don't think we need separate pages as we don't have many form fields to fill in.

I also have a hunch the expand/collapse is not really useful even on mobile, I'd want to remove it.

Also the box outlines are a bit odd, headings and then form fields are fine.

annnnd finally, for a better exp overall, vertical alignment for all fields would be fine, 2-columns for form fields are not really standard anymore and 1 column makes mobile responsiveness easier.

[RachL]

Aligned with @Erioldoesdesign .

I believe our biguest problem on this page in not the next button, but more people thinking there are done by just landing this page 🙈 .

I would like to propose to close this issue for now, and see how we can prioritize a complete v2 of that page in the future (I agree that having several pages would be awesome, but it needs some work and thinking).

How do you guys feel about this proposal?

[Erioldoesdesign]

@RachL I second this proposal, if closing this issue includes removing the next buttons.

I'd like to see if anyone sends a Customer Support request if the next buttons are removed being confused on how to complete an order.

and maybe, if folks are nervous about that do a usertest to see if I can find some evidence that removing buttons would not increase errors.

[RachL]

@Erioldoesdesign our biggest support request in FR with that page is that people don't understand that by landing there they are not finished. Most of the time it's because they didn't see the next button after the address. So if we remove it, I'm afraid on our side it will translate by even more people believe they are done when they are not.

So when I was proposing to close this issue I was proposing to not change anything to the current behavior.

But maybe instead of doing nothing we could start to set up Matomo events on these next buttons and see how much they are used?

[Erioldoesdesign]

@RachL that sounds like a good idea re. Matomo but it does sound like you have good evidence that they are not noticed and therefore users are not filling out correct information needed to progress.

So I'm happy for us to not remove next buttons and, as a bigger piece of work gestures broadly fix this part of the process.

[RachL]

@Erioldoesdesign yes but I have no evidence of the percentage of users. So I do have evidence, but only partial evidence :(. Maybe for all the other cases where the button shows up they do help users to understand how the checkout works 🤷 That's why I'm not so sure about solution to remove them completely. Anyway :)

[jaycmb]

Agree with @Erioldoesdesign to close the issue with removing the next buttons.

Like this we get rid of the jumpy animation + potentially reduce the number of users who think they are done when using the button - to me it seems to be less confusing from a user perspective, if there is only one Call-to-Action on the bottom of the page (hypothesis!). Possibly users are more likely to scroll down then because they look for some way of to confirm after entering their data - that´s learned from Standard E-Commerce processes.

To then also address the users that do not don't understand that by landing on that page they are not finished (@RachLs point) , this could then be part of a V2 bigger makeover.

Also to indicate that scrolling is necessary, especially on mobile, screens should be done in a way that some piece of content is partially visible.

Re V2 & Multiple Page Checkout: one aspect we have to have in mind here is that even when leaner having steps on separate pages, especially on mobile it has to be considered that each page has to be loaded, which likely leads to cart abandonment

[RachL]

potentially reduce the number of users who think they are done when using the button

@jaycmb are we sure we have some? That's why I think it would be good to first gather data before deciding anything...

[jaycmb]

Ah no sorry, I assumed there was evidence for that case based on

We've also had users think they have submitted the order after clicking the big primary Next button, but they hadn't clicked the Place Order Now button because they couldn't see it 🙈

[Matt-Yorkley]

We've also had users think they have submitted the order after clicking the big primary Next button, but they hadn't clicked the Place Order Now button because they couldn't see it

I was referring to that user feedback from memory of a previous bug report, I'm not sure where it actually is.

[lin-d-hop]

This is certainly a case where I wish we could do AB testing to see if removing the buttons made things better or worse.

We have support requests weekly saying 'I didn't get my order' or something similar, from an order that was never placed, that we have always put down to a flaw in the checkout process. Now that we have improved the mobile shopping experience we may well see this more often as more people choose to order on mobile. But the evidence we have is only anecdotal.

Tangent - Part of what scares me is that we clearly need 3 full time designers and we have 1 part time designer. We've always been under resourced... but now we are dealing with being under resourced in one section of the pipe in relation to others. Its a different type of under resourced that we need to navigate. But is does beg the question - when will we fit in the Checkout flow redesign?

Right now I see:

• 1 expert instance manager saying 'This change will likely make things worse'
• 1 dev with a good design eye saying 'This might help things'
• 1 product person with strong UX skills saying 'This will make things better'
• 1 designer agreeing checkout is bad and on the fence with this change
• and me - traditionally erring on the side of wreckless.

Based on the fact this is evidence-less, anecdotal, and we have one person saying this change will make things worse I am erring on the side of not changing right now.

However, just quickly, is there any agile step we can take while we wait for a real re-design? Is there are way we can gather more evidence? Can we deploy the change (looks like you got something we can play with @Matt-Yorkley) to a staging server and ask a few folks to test it out on mobile? Am I creating unnecessary work and we just put this in the queue?

[Matt-Yorkley]

We can stage it at any time and play with it, if that's useful.

[lin-d-hop]

I'm having weird fantasies of everyone asking their most tech illiterate friend to place an order on 2 different stagings and telling us which checkout was easier....

[Erioldoesdesign]

A small agile move forward might be indicating that if a user research OSS designer wanted to pick up doing user testing on this they could and that wouldn't be my resource, but would move us towards evidence based information to make a decision on this.

So maybe adding the design label and I can post on our design circle channel and mayyyyybe even we can post on the opensourcedesign.net job board for gratis work. This is all, work/time though!

[jaycmb]

We could also run a simple quantitative A/B test with Matomo, comparing Order Success from Checkout Page with (original) vs. without (variation) next buttons. Like this draft here.

But that would require to implement the changes on production for one instance. We can also choose to send only 30% (or less) visitors into the A/B test. Alternatively we can run it on staging but depending on the number of testers we can get that might not be too insightful.

Also, by this we would learn only about if removal of the next buttons would increase order success, but not about the why (do they really think they are done or just annoyed by poor usability?). For this the let´s ask some users to check it out on mobile approach would provide more insights.

[Erioldoesdesign]

Someone product wise needs to approve design time to do user testing if we want that to be managed by UX resource.

[jaycmb]

This one is inception now -> Hopefully tracking usage of "Next Buttons" vs scrolling to "Place Order Now Button" very soon

https://app.zenhub.com/workspaces/product--inception-pipe-5f82e534db531f000f8c09ff/issues/openfoodfoundation/inception-pipe/21

[RachL]

thanks @jaycmb ! Should we move this issue there as well? I mean, it's not "in dev" anymore is it? So do we want to keep it in the main repo or the inception repo?

[jaycmb]

@RachL Only seeing this comment now. Yes, since there is an discussion ongoing around on how to best track this and user testing in planning, let´s move it to inception pipe until we have clarity.

[Erioldoesdesign]

Just linking the issue for the user-testing that included understanding this problem: https://github.com/openfoodfoundation/product-pipe/issues/21

[jaycmb]

Closed as it was decided to redesign & split the checkout, by this we are also getting rid of the next buttons