Wp-calypso: Conversion: Add proper NUX checkout step

[apeatling]

The way that checkout works in the NUX right now is a little strange. Since the checkout process is actually after you have finished the NUX flow and are logged in, it's not in the flow at all.

This means you hit the "Continue" button like you're all done, and then get dropped into the checkout flow with no instructional information at all. You aren't even able at this point to change your mind and select a different plan. If you hit the "X" then you're dumped on the plans page with no instructions.

I propose adding a checkout NUX step that within the regular NUX flow. It should be right after the selection of a plan, and allow the user to go back and change their selection.

Checkout page before:

Checkout page as a NUX step (updated: v2):

[apeatling]

Going to keep tweaking this, need to take into account some other things that can go in the cart in NUX (google apps etc). Also I think showing the monthly price here so big is probably confusing at a glance.

[folletto]

This is a solid idea. My feedback at this early stage would be mostly in terms of full flow. Checkout is a complex process, so we need to have the design for the full branching journey before starting building it (what's the next step? how do we handle receipts and error messages in NUX? etc).

Smaller details specifically on that first screen:

1. The ← Back button should be centered as is in every other step for consistency.
2. I'd try to move the info text below, and make the button wider and clearer.
3. Having the summary on the side is nice, and has all the right bits imho to be effective. I wonder if it would be possible however to move it to the top, so one reads "plan, price, pay details, pay" linearly. The only downside would be that it would push the form down a bit, but if the first part at least stays above the fold it should work still better.
4. No PayPal option anymore? (it's in the first screen)

[apeatling]

Thanks for the feedback @folletto. One of the main goals here is to keep the primary action pay button above the 660px "fold", so it's not off the screen for more than half of our users. My first thought was to have a top version of the sidebar, but it's going to drop the button below.

I've made a few updates here, I'm going to have a think about the flows before and after. I think ideally we remove all the complexity of the domain registration details out of this particular step. This step would concentrate on converting users to paid in the most simple way possible, and offload more intense information gathering to later.

[folletto]

Ok, all clear 👍

[apeatling]

Here's a simple first flow, select plan, pay for plan, get notified of successful payment and then create account.

[apeatling]

I feel like creating an account should happen before any of the payment details, to ensure the user gets a receipt. This means it would need to happen very early in the NUX, before selecting a plan, which then means before a domain.

[folletto]

The flow seems good. So it would be already shippable for me.

I can throw in a few discussion / review points, just in case they are worth it:

1. I'd try to keep the same Plan header on the selection and payment steps, and avoid "Cart". Cart is a construct that is useful in some online shopping, but for us, and especially in this scenario, doesn't add any valuable information to the user. I'd just show: Plan header, extra stuff, total.
2. I'd move the disclaimer text below the "Pay" button, IF it's legally ok to do so as I expect.
3. I'd make "Or use PayPal" a link (underlined?) or something that feels more clickable. The visual weight is ok tho, so it's a balance there.
4. It's a good point on the creation of the account. The CC validation is already a good enough account verification method, but I agree the email is important and we could make it happen earlier. At the same time I agree with the flow above that ties together better selection + payment.

Quick mock:

Note: I keep surfacing that we should go away from _username_ everywhere, especially from signup (but editable later). ;)

[rralian]

IMHO, one important change we could do is not just the design, but in the workflow, I'd really like to put payment in front of the "Give us one minute and we'll move right along" step. I believe this setup time may have to do with tri-force, and creating the site with all of the default settings. I suspect we could squeak out a worthwhile bump in payment conversion by doing so.

[apeatling]

@rralian The above flow I posted would all be before this step.

[lamosty]

I like the new design @apeatling and @folletto. I'm trying to come up with smaller tasks/steps how to tackle this and have stumbled upon a few (implementation) questions:

1. Should we alter the original checkout components (so it will also apply to /checkout and everywhere else where we use it) or let it as it is for current checkout screens and add new components to NUX (while reusing as much as possible from the current ones)?
2. No mockups for PayPalPaymentForm, CreditsPaymentBox - not that important as we could change these according to the new credit card payment mockups but would help (PayPal form screenshot, CreditsPaymentBox screenshot)
3. What about FreeTrialConfirmationBox and FreeCartPaymentBox - when are they used? Should we take these cases into consideration too or is CreditCardPaymentBox, PaypalPaymentBox and CreditsPaymentBox enough?
4. Do we want to reuse the components which can be reused or write them from scratch as a part of refactoring?

Tasks

I/we will put the tasks below as new issues but before we do so, I'd like to get your opinions on them, whether they are any good, can be merged into one task or will require more sub-tasks:

1. Either we reuse (if possible) or write new checkout/secure-payment-form. It renders all the possible payment methods, decides which one to show/hide and also renders placeholders if data is loading.
2. Redesign/create new checkout/payment-box according to the mockups. It renders the "Secure Payment" title and then wraps the credit card details (takes child components).
3. Redesign/create new checkout/credit-card-payment-box and all the other "boxes".
4. Add the left column cart with plan name and items in cart. This will probably need to be a brand new component but hopefully we can reuse CartItems, CartTotal and CartCoupon.
5. Create new NUX step and add it to flow.
6. Put it behind a feature flag.
7. Add "Payment Successful" notification to the Create your Account step if the payment was successful. Probably also add payment unsuccessful so the user can try again (don't have mockups for this). Screenshot.

The issue I see here is that currently, the component hierarchy is not suitable for our new checkout designs. For example, the "Secure Payment" title is rendered in different component than "All fields are required" but in our new designs, they are on the same line so we'll probably have to create brand new components just for NUX while reusing only the essentials such as CreditCardForm (which renders the CC input fields) but that too will have to be modified with at least CSS.

It seems that it will be quite a lot of work from the first looks. Will add more info when I find any.

[apeatling]

I would consider this step as something separate from the main checkout form. Although, I think it should try and reuse as many components as possible, while keeping the scope small.

The old checkout form can still be used for registered users when purchasing outside of the NUX flow.

A couple of other complexities that will need to be considered:

• We are not gathering domain registration details in this step, so that needs to be handled once the user exits the NUX flow. This could be a notice asking the user to fill these in, with a link to settings page or modal form (this is assuming the domain can still work without these details up front).
• There is no user account at this point where the NUX payment step is currently inserted. It's possible a lot of the checkout code currently assumes an account exists, although work has been done to address scenario.

[lamosty]

I would consider this step as something separate from the main checkout form.

Alright, so will create brand new components for this just for NUX.

Although, I think it should try and reuse as many components as possible, while keeping the scope small.

Definitely. However, from what I've seen when analyzing the code, not much can be reused. Will see about this more.

[apeatling]

It's unfortunate we are building all of these components that can't be reused at all. It might be nice to understand the reasons why this happens, and in the future try and avoid the reasons. Might be a good topic for a Calypso hangout. /cc @mtias

[lamosty]

I split the task to smaller issues and put them into Plans: Maintenance milestone (which is probably not correct but I don't feel like creating new milestones. Could somebody else create a new one?). Hopefully the tasks are any good.

Another question: NUX steps are the same for both new users (with no account) and for current users who want to create a new site. Will this apply only to new users without an account? If yes, we don't have to recreate the CreditsPaymentBox because (I assume) new users don't have any credits.

[mtias]

@lamosty why do you think they can't be reused? It'd be good to have the reasoning before building new components that will just coexist with the others and will probably never converge.

[mtias]

For instance, I believe this popover content uses cart-item:

Which is reused here:

And both match conceptually what is shown here:

So the work should probably focus on updating the cart-item component with the design refresh, clean up the code while at it as necessary, and have a consistent result applied through our UI instead of a different component.

Of course, you won't be refactoring everything under the existing Cart, but isolating the pieces that are doable is how we can make steady progress.

[mtias]

The Cart Total sub-component should also converge:

See: https://github.com/Automattic/wp-calypso/blob/master/client/my-sites/upgrades/cart/cart-total.jsx

[lamosty]

@mtias I didn't say you can't reuse CartItems, CartTotal and CartCoupon. I've written (among other things) that:

Add the left column cart with plan name and items in cart. This will probably need to be a brand new component but hopefully we can reuse CartItems, CartTotal and CartCoupon.

Parts of the code can be reused but many not. Anyways, as soon as we start working on these things, we'll see exactly what can be reused and what not.

[mtias]

I was following from your last comment about creating brand new components for NUX. Again, I'm curious to see what can't be reused and why, so we can correct that.

[lamosty]

I see. Initially, I asked @apeatling whether we should use the same checkout page/components but just refactor/redesign them or whether to create new component(s) for the NUX checkout step for which he replied that we should keep the current checkout page as it is and create new NUX checkout step components.

Could you also please read my other comment here? I've never worked with checkout code before so did a quick analysis and wrote my findings in that comment.

[meremagee]

Wow, lots of changes proposed here. Ideally, we'd start with reskinning the checkout page to better match various flows before we change step order, functionality, and huge dependencies. If we're thinking of moving domain registration out of the signup flow and refactoring purchasing to not necessitate a user, then we need to be coordinating on a much deeper scale with Delta & Spectrum as this will have significant ripple effects in both teams' work.

Misunderstood the domain registration bit and thought the intention was to move the NUX domain step out of signup - instead @apeatling is talking about the domain details within the checkout step. Carry on and ping us for reviews :)

[apeatling]

@lamosty I think @meremagee has a good point here. A good first step might be to introduce some of these design changes to the existing checkout page and checkout step in NUX. If the components can actually be shared, then we are also setting the stage for moving the checkout step in NUX. Doing it this way means we can test/launch improvements sooner.

I'm happy to talk this through with you and figure out the scope and setup.

[lamosty]

Good points. So if I understand this correctly, this is the order of things to do:

1. Apply design changes, one by one, to the checkout page as it is now;
2. Use the components from checkout page for NUX checkout step (and create new ones if can't reuse them);

[rralian]

We're exploring one small step of this for now, how difficult it would be to avoid the "wait" step and let that background work happen while the user is on the checkout screen. That's being tracked here. https://github.com/Automattic/wp-calypso/issues/7497

[rralian]

I'm moving this to Plans: Maintenance since it isn't really related to free user conversion. Also removing @lamosty as this isn't an active project. Sounds like it might actually be superseded by some efforts in Delta. /cc @meremagee

[alisterscott]

There hasn't been any activity on this issue in nearly a year and the NUX process has changed quite a lot in that time. I will close this issue for now as it's been low priority for that time, we can re-open should this be considered important to tackle at some point.