While there have been a fair number of changes made to COWA, there’s one last change I think is needed that will pull together all the other changes. On that point, I want to propose making a change to the checkout workflow. In a nutshell the I want to look beyond the normal “guest” checkout or one page check out workflows everyonwe seems to think are THE answer, and look to REALLY improve the checkout workflow based on more than simple fads everyone thinks are the end all be all. In my opinion “guest” checkout or one page check out workflows are faddish and only provide marginal improvements to the checkout process. I AM a fan of smoothing out and improving the entire checkout process by really looking at the entire process.

High Level Objectives:

Simplify the total number of steps to just two or three depending on admin configuration option selected. There will be two checkout options. Option 1 is a 2 step process; Option 2 is a 3 step process.
Creating a new account is an option that is offered AFTER the transaction is complete to keep the focus on completing the sales transaction.
Make all extraneous actions a linear process. Functions that normally take customers to other pages (adding shipping addresses, reset password form, etc) will open in a lightbox on the checkout page. Lightbox should utilize the colorbox library which will help minimize conflicts for those shops who have installed Zen Colorbox or Zen Magnific for images.
The order summary/review or confirmation pages must have a functioning back button. Many a times, the customer feels like going back to the previous page to check or confirm something or the other while going through the checkout process. In the current process there is no back button so customers have to start the whole process from the very beginning. This is quite a frustrating experience. It is very natural from a customers’ point of view that they want to recheck the order details or address provided by them. If this process becomes cumbersome customers are very much likely to leave the transaction incomplete.

Checkout Workflows

Checkout Option 1:

Step 1
1. Allow returning customers to log in. Upon a successful login, the default shipping and billing fields will be filled in.
2. Allow new and guest customers to fill out their billing and shipping information
3. Enter coupon codes, gift certificate & reward point renewals, and special instructions
4. Provide a return to cart button to return to the shopping cart
Step 2
1. Show order confirmation details
2. Allow customer to create an account

Checkout Option 2:

Step 1
1. Allow returning customers to log in. Upon a successful login, the default shipping and billing fields will be filled in.
2. Allow new and guest customers to fill out their billing and shipping information
3. Enter coupon codes, gift certificate & reward point renewals, and special instructions
4. Provide a return to cart button to return to the shopping cart
Step 2
1. Show order summary
2. Provide a back button to return to Step 1
Step 3
1. Show order confirmation details
2. Allow customer to create an account

Checkout Page

The Checkout page should look very similar (please read.. NOT IDENTICAL -- SIMILAR) to this: http://www.getelastic.com/wp-content/uploads/treatment.jpg

Login is an accordion link.. Similar to this: When you click on the link, the functionality is that it opens up to show the login form. Would prefer to use Bootstrap or Foundation accordions as opposed to javascript for this. The choice between Bootstrap or Foundation should be an admin choice so as not to interfere with existing Bootstrap or Foundation implementations.

The reset password link should open up the reset password form in a “linear” fashion as a lightbox..

Treat coupons in a similar fashion as the Login.. When people see a “Enter coupon code here” field, they feel less special. Many will stop the checkout to contact the shop owner to ask “How come I don’t have one?”. Many go to Google to find a coupon; many never return. Leaving the site in search for coupons is a common reason for shopping cart abandonment. Instead, would like to have a text link or button saying “Got a coupon?” or something similar, and clicking on the link makes the input field – like the one below – appear.

Text links are not visually very prominent, so less people will pay attention to them. Customers who DO already have a coupon code will be looking for a way to enter it – so they will find it and will be able to apply their coupon code.

Billing address fields are displayed only if the “Billing/Shipping Same?” checkbox is un-checked. The billing address fields will be presented as an accordion like the login or coupons as outlined above.

For logged in customers if billing and/or shipping information needs to be modified, this must be done in a “linear” fashion. Meaning that the customer should not be made to leave the page to make the change. Preferable that this be managed via a lightbox as it will be friendlier on mobile devices particularly smartphones.

Confirmation Page

The Confirmation page should look very similar (please read.. NOT IDENTICAL -- SIMILAR) to this: http://www.getelastic.com/wp-content/uploads/create-account.jpg

Show the following on the thank you page:

Order summary including product, billing, payment, and shipping data
Option to enter a password and create an account (making registration a value added process)

Apart from Amazon, registration is optional for most of the top grossing ecommerce sites. Sites like Sears, WallMart and even Amazon have attached a tangible value to registration. They have outlined the benefits of getting registered to encourage more and more customers to create an account prior to the purchase.

Admin Configuration

Include an admin configurable optional order summary/review page. Depending on whether or not the confirmation page is active, the button at the bottom of the consolidated checkout page will also need to change as follows:

Click to complete order – Submits the order and takes customer to the thank you page (there will be CLEAR ON-SCREEN text to let the customer know that this is what will happen when they take this action.
Click to review order – Takes customer to the order summary/review page where they can then review and submit the order. (as in Option 1, the submit button takes customer to the thank you page)

Well, I certainly agree - but I tried to do something similar many years ago - it's rewriting so much core code that it becomes something like a mod not to be named that I hate due to the scale of it.

NOTE: From a PCI standpoint, it's important that any credit card information NOT be stored, nor submitted and re-sent back to the browser for re-submission on another page. Keep that in mind as you consider the option of doing order-review ... as you might need to re-ask them to enter their card information again. The page on which they enter the card number must also be the page from which the transmission of the card number occurs. To accomplish this might require rewriting the rest of the DOM via ajax/javascript for all page updates or other functionality if you intend to not ask for those details again.

@wiztechinc - yep I know that this requires re-writing core code to implement. However, perhaps it's time to examine the core code and consider if a change is in ordet.. Other parts of the core code are getting a once over in v1.6 and because COWOA is being included in the v1.6 core perhaps it's time to really look at the checkout process as a whole..

COWOA, FEC & FEAC all include a guest checkout feature. There are usually two trains of thought supporting guest checkout..

Faster checkout - This argument never made sense as you have to enter your shipping/billing address each time you checkout. So I'm not sure how that is considered a "faster" checkout workflow.
Safer checkout - This argument always makes me chuckle since minimally any online store is going to have to create SOME kind of record to collect some minimal data for shipping, or taxes or other record keeping purposes. The main reason some shop owners and shoppers cite to advocate a guest checkout flow has more to do with the perception that guest checkout is somehow "safer".

COWOA attemps to improve the checkout flow by incorporating the late Clyde Jones' Tabless Order Steps module. In the current version of COWOA, this has been lighted up by using the Awesome Fonts library instead of image files for the arrows & pointers.

FEC and FEAC attempt to improve the checkout flow by implementing a "one page" checkout. It's been a while since I looked or used FEC so I cannot speak directly to their one page workflow, but I do know that like MANY modules by this author, there is a requirement that the CSS/JS Loader is REQUIRED to install/use these modules. This has always been a requirement that I felt was unnecessary.. The CSS/JS Loader impacts the core code and every module where there is a module specific CSS or JS file. The instructions for it have ALWAYS been vague to the point of being incomprehensible, and unlike caching plugins written for other CMS' (Joomla and WordPress for example) this one is not flexible.. other minimizing caching modules provide options for excluding certain CSS or JS.. The CSS/JS Loader is all or none and this is the BIGGEST reason why I don't install FEC or FEAC for my existing clients and why I routinely convert new clients who are using them to COWOA..

Regardless of the differences, my focus was analyzing the current checkout processes of COWOA. My analysis lead me to realize that perhaps the logic behind COWOA was based on some possible slightly myopic assumptions. These assumptions may have assumed that the default checkout flow was fine and all was needed was guest checkout & checkout visual cues. Perhaps the original COWOA crafters felt that anything which altered the default checkout was to be avoided like the plague..

In my analysis and subsequent conclusions, I was willing to look at the process, and proceed as if no process at all existed.. I did not constrain myself to ANY existing workflow. So if that lead me to realize/conclude, that the default files would require a change or even replacement/retirement then that would be the path.

I would assert that none of the current modules COWOA, FEC, nor FEAC fully got it right.. For one thing they ALL put the decision to create an account when purchasing or purchasing as a guest as the FIRST step of the checkout and this step is prioritized ahead of the actual purchase steps. Changing the order of operations puts the checkout workflow focus back on the sales TRANSACTION completion/conversion goals versus customer ACCOUNT creation goals. Creating an account could (think should) be a post sales transaction option as most of the required data is collected during the checkout. In implementing such a worflow, I am asserting that perhaps it's time for a re-evaluation of the default checkout worflow. This may mean that it WILL indeed require a core re-write of the whole thing.. I'd love to see the core code, move into this same direction (which is why I asked DrByte to weigh in his thoughts on this proposed change). If the core devs disagree that an overhaul to the default checkout processes is needed at this time, I still think this is the right next logical direction for COWOA to evolve..

@DrByte.. You raise a point that I should have been more explicit about in this proposed spec. I will revise accordingly, and probably need to examine how selecting PayPal Express will impact the workflow as well.. on that note I probably also need to fully flush out the desired behaviors for coupons and gift certificates when the back button is pressed..

Interesting.. I've been dragging my feet on finishing up due to some design ideas... on the same line, the idea of two type of setups is driving me nuts. Some sites during the checkout process offers the option of creating an account by adding a password, no password and it's a guest checkout. A simple solution would be to do one setup and the only change would be in the password with User created or code created deciding on account type... which is the direction I'm thinking of going in. Will have to dust of my sandbox and see how that plays with PayPal..

Popups, lightboxes really annoy me during checkout... especially right when I'm about to click on a button... popup blocks it! Lately a 'Do you want to chat' box... yap.. if I needed help, I wouldn't be about to hit the conformation button! That usually makes me leave... but useful popups like when I click for shipping info, privacy or something I like to know but don't want to leave the page I'm on, they I like and created..

I think the default layout for checking out works will as is, but I'm one that wants my site not to be the same as yours too...

If things ever slow down at work, maybe I'll get it done... I am changing the code to flow more outside the box so upgrading ZC is easer... just finished redoing my auction mod so I could install it into my new site... I'll go through your list and see which ones are also on mine..

the idea of two type of setups is driving me nuts.

This is really very simple.. Option 1 is the entire checkout process on one page. The cart will be visible as is all the payment, shipping, discounts, and credit information. Upon entering all the correct data, the shopper clicks the submit button and is taken to a the confirmation/thank you page where they will be given the opportunity to enter a password and create an account.(or not, and this becomes a guest order)

Option 2 simply adds ONE layer to the workflow from above and that is an order summary/review page will be presented before submitting the order. The customer can then submit their order from this summary/review page or go back and make changes. Once the shopper clicks the submit button they are taken to a the confirmation/thank you page where they will be given the opportunity to enter a password and create an account. (or not, and this becomes a guest order)

Some sites during the checkout process offers the option of creating an account by adding a password, no password and it's a guest checkout.

The workflow I propose provides the same thing.. However, the option to create an account is presented on the order confirmation/thank you page AFTER the sales transaction is completed. In my proposed workflow the emphasis is on sales conversion NOT account creation. This is why account creation is moved to the END of the process after the sale has been submitted. The customer need only enter a password and then an account is created, otherwise the submitted transaction is treated a guest checkout.

Popups, lightboxes really annoy me during checkout... especially right when I'm about to click on a button... popup blocks it! Lately a 'Do you want to chat' box... yap.. if I needed help, I wouldn't be about to hit the conformation button! That usually makes me leave... but useful popups like when I click for shipping info, privacy or something I like to know but don't want to leave the page I'm on, they I like and created..

My workflow doesn't propose ANY popups.. A popup window is an opportunity for the customer to leave the site at a time when I do not want them to leave. Also I cannot control where/how popups open -- as the customer's browser settings will dictate this. All non-linear activities related to checkout are contained in either toggles (login & coupon forms) or lightboxes. The proposed workflow doesn't include any unnecessary lightbox interactions either. Only those interactions which in the current checkout process may cause the customer to leave or divert from the checkout pages (changing shipping addresses, updating account information, reset password form, etc..) Lightboxes IMHO are much more elegant than popups which are defeated by those who chose to employ popup blockers and they have the added benefit of keeping the customer on the page which is clearly visible in the background. Once dismissed they are back on the checkout page where they can continue the checkout process. Utilizing the colorbox library falls in line with discussions of POSSIBLE inclusion of lightbox functionality into the Zen Cart core. The use of the colorbox library also will ensure that those using the two popular responsive modules based on colorbox will not be in conflict.

I am changing the code to flow more outside the box so upgrading ZC is easer... Since it's most likely that implementation of this proposed workflow will require the development of new files, the potential upgrade of the supporting files needed will only be impacted by PHP or mySQL changes required as part of any future Zen Cart upgrade. The core checkout files would be largely untouched

I am also going a step further here and proposing a core code overhaul of the default checkout process. (again this is why I asked DrByte to weigh in on this proposed change to COWOA) Since Zen Cart v1.6 will come with COWOA as part of the core, I am proposing more that just a COWOA for Zen Cart v1.5.4+ enhancement, I am proposing a proof of concept suggestion for an overhaul of the Zen Cart core default checkout workflow altogether.

proposing a proof of concept suggestion for an overhaul of the Zen Cart core default checkout workflow altogether

Just to be clear: We are in agreement about the need for significant improvements to the overall checkout workflow. And @zcwilt has been working extensively on a number of components for it, including the ability to add code for custom workflows. Those changes aren't written in stone yet, and we're actively watching this discussion for concrete recommendations in order to refine the specs.

I thought the option for creating an account at the end was good at first. But then I started thinking about how I shopped. If I can buy something and they present me with the offer of creating an account at the end, I'm going to ignore it cause I'm done at that point.

The biggest problem with "creating an account" vs "checking out without an account" is simply that the public thinks the website doesn't keep their information. That's never true but that's what they think.

All cart owners think there should be a quick way to buy and get out - without creating an account because of how large sites facilitate that option and that perception. I do not buy because a checkout is easier or faster. I buy because the site has what I want at the price I want and reasonable shipping fees. But I get folks asking for me to do it like Amazon - saving credit card numbers etc. Ow.

My template that I'm presently using does have COWOA in it. Do I think it's necessary? No, never have.

That said, the present checkout is clunky. I redid it years ago and wrote a blog post entitled What's Wrong WIth the Zen Cart Checkout. Some of my thoughts then are pertinent now. But what I did was just adding in the COWOA steps and providing the ability to create an account on the first page as well as the COWOA option. It's nearly all visual and text changes. This was all based on a study done about checkouts...... Maybe we need to see what data/studies are out there now. What actually works the best.

I tried to create the one page checkout early on. At the time there was one mod for it and it was terrible. The biggest thing is it needs to be clear about what it takes to finish checking out- whether that is one page or 4 pages. The more you put onto one page, the harder it gets to actually buy - too much visual "stuff" is harder. If you can see all the blanks you need to fill out at once, it's just overload. That early mod did just that.

The COWOA checkout has two columns. Fast and Easy has three. I prefer two. Less cluttered.

Add in some wizardry and do some showing and hiding so that only the task at hand is shown when needed.

I would need to do some heavy thinking to come up with more than that. I'm on a trip in New England and simply don't have the time or the brainpower for that now so more later....

Just to be clear: We are in agreement about the need for significant improvements to the overall checkout workflow. And @zcwilt has been working extensively on a number of components for it, including the ability to add code for custom workflows. Those changes aren't written in stone yet, and we're actively watching this discussion for concrete recommendations in order to refine the specs.

@drbyte :+1: Roger that! That was the whole point of my evil plan in dragging you over here.. :laughing:

I thought the option for creating an account at the end was good at first. But then I started thinking about how I shopped. If I can buy something and they present me with the offer of creating an account at the end, I'm going to ignore it cause I'm done at that point.

And that's a bad thing because???? :laughing:

Honestly what is the purpose of the checkout workflow?? Shouldn't the goal be finishing the sale versus the account creation?? That said, this is a MINOR thing in my opinion as it can be resolved with GOOD on-page content and CSS styling to clearly communicate what's going on and help make sure that this isn't lost or forgotten by those who do in fact want to create an account.. Also creating an account can be reinforced in communications to guest shoppers. Like say the page that allows them to view their order. They enter their order number and on the same page where they view their order, they can be (gently) prompted to create an account. The same gentle reminder can be included in guest shoppers order communications as well..

All cart owners think there should be a quick way to buy and get out - without creating an account because of how large sites facilitate that option and that perception. I do not buy because a checkout is easier or faster. I buy because the site has what I want at the price I want and reasonable shipping fees.

Those folks who want to create accounts on those will do so, those that don't won't.. Is account creation more important than sales conversion?? Because in my opinion the current process seems to support that notion.. Isn't it time we all let go of that and focus on what the checkout's purpose REALLY is.. SALES CONVERSION.. It took me a while to get to this point myself, but I realized that in my own store selling the WordPress/Zen Cart integration modules that I DON'T care about customer signups, just sales.. I collect the buyers contact info as a function of making that sale, and that's enough for me..

The biggest problem with "creating an account" vs "checking out without an account" is simply that the public thinks the website doesn't keep their information. That's never true but that's what they think.

Agreed.. Hence the reason the option needs to be part of any checkout workflow.. Would rather my clients chase sales not perceptions.. All they can do is communicate as clearly as possible that their store is safe.. After that if giving those reluctant buyers some sense of security (albeit irrational), then do it and let's be done with it.

That said, the present checkout is clunky. I redid it years ago and wrote a blog post entitled What's Wrong WIth the Zen Cart Checkout. Some of my thoughts then are pertinent now. But what I did was just adding in the COWOA steps and providing the ability to create an account on the first page as well as the COWOA option. It's nearly all visual and text changes. This was all based on a study done about checkouts...... Maybe we need to see what data/studies are out there now. What actually works the best.

Let me be clear.. I didn't make these changes or these suggestions lightly or without doing my homework.. As a Business Analyst, I did what I do best, ANALYZE processes and workflows.. I did a lot of research on the topic along with listening to what my clients and their customers had to say about the default as well as COWOA processes.. Relying on what people "think" was not enough here..

In doing my research I ran across your article.. Some (not all) of your article's suggestions made their way into the currently available version of COWOA along with some (not all) similar suggestions from Eric Leuenberger's website (http://www.theecommerceexpert.com)..

But I also did indeed look at data/studies out there now.. that's where many of the additional changes added to COWOA from the last few months come from (and I have been clear about this). This proposed workflow change for COWOA directly comes from that same research.. I believe that Melanie Prough posted links for some of those recent studies.. My proposed changes for COWOA come DIRECTLY from those and other recent studies..

I'm back!!! Okay, I just used square to check online instead of in someone's place of business. It was so simple, clean and fast. No questions about creating an account - it does that with your email address without telling you. I only realized it did that when I used it more than once and got a receipt by email without requesting it.

I guess what I'm saying is an additional step of creating account to track purchases a that point would have been reasonable.

Clean, fast and efficient. That's what's important.

No questions about creating an account - it does that with your email address without telling you.

It actually does kinda tell you.. just that most of us are in a hurry and don't see/read the "fine" print.. But to your point yes we agree.. Account creation needs to be a simple process, and it needs to be a secondary activity in the checkout flow since the point of the checkout process is supposed to be about completing the sale.. Creating an account is more a function of customer retention.. This should come AFTER the sale is completed.

Here's a little road map where I'm at... Login (rebuilt) Has the top existing customer login.. email, password, forgot password link, login button.. (returning customers) next box down, if cart is empty, has create account button, if cart is full, has continue button (new customers ether way) step1 Customer billing and/or shipping address, (shipping has a switch so it can be turned off.. not needed for ether new account type) contact info box has password field with instructions, (Enter a password or leave blank if you wish not to create an account!) idea, password and it's a standard account, no password and it's a COWOA account.. step2 shopping cart is live, billing and shipping address displayed with edit buttons Shipping options displayed with radio buttons, changing updates shopping cart now Payment options displayed with radio buttons, changing updates shopping cart (this to display any fees) Comment box and redemptions box displayed, step3 confirmation display step4 think you your done page...

Basically, 4 steps to buy, reason not one or two, mobile... I need to slap it around and run some tests, then clean and do a final check before uploading to my site where I can finish looking at PayPal and how it plays. Not looking forward to stripping back to the basic green template.. I've converted my forms to use HSF, Ninja code, so the normal user may have a hard time understanding how to integrate it into their site.

I still have about 3 wish items to fix yet like the shopping cart is still using tables.. but it resizes to mobile screen just fine.. The visual order steps need responsive coding... so on...

The design is a direction I wanted to take my new site too, pulling out the code and placing it on github will hopefully help others, I don't plan on making a mod out of it and it wont follow the COWOA path very well ether especially if I don't strip it back to the jolly green default..

I'll email you a link and instructions once it's live.. some of the forms are now

Basically, 4 steps to buy, reason not one or two, mobile...

Would love top hear why you think this.. I would think that brevity and efficiency would be MOST important to mobile users in a checkout flow.. why not instead don't you simply create a separate flow for mobile if four steps are indeed needed for mobile (not seeing why this is though..)

I'd be interested to see your flow though it still seems to want to keep account creation as a part of the checkout, and IMHO that seems counter productive.. if the REAL goal of the checkout flow is to complete the sale, why include ANY account creation as a part of that..

Would love top hear why you think this.. I would think that brevity and efficiency would be MOST important to mobile users in a checkout flow.. why not instead don't you simply create a separate flow for mobile if four steps are indeed needed for mobile (not seeing why this is though..)

I spend allot of time buying, what makes me leave a site is no ssl or strange url's or external page loads/tracking code, never the process of checking out. short checkout or lacking information requests, make for bad service, and I had bad service from site that ask to many questions.. I think working the page design for a 5" screen is grate, but if I want it to work at 2", then I'll design an application to feed web content instead of forcing a browser to that size. also, the 4 page is the max, account holders is 3 or less and depending on how google/paypal works, could get it to 1 or 2... I think the flow is what I'm working mostly on, does it make sense! I hope. Right now I have a lost shipping ['id'] that's driving me nuts...

Thanks for the insight.. I am of the belief that 4 steps don't require four pages to achieve.. All 4 basic checkout steps can happen in fewer pages.. (AND POSSIBLY one) Shortening the number of pages in a checkout process doesn't shorten the collection of the information required.. What I am sure of (based on the studies done versus my OWN personal experience) is that the checkout process should remain focused on it's primary purpose, completing the sale. Other activities (like creating an account) are secondary distractions/deterrents to this primary purpose, and are best left for after the sale is complete..

With regards to mobile, I think it goes without saying that the checkout process for mobile WOULD be different.. and I think that a combination of mobile specific pages and along with a good responsive design is required so that the flow is tailored for smaller devices.. My immediate focus is on improving and streamlining the desktop checkout experience first, and then addressing how this is accomplished for mobile afterwards.

DivaVocals / zen_COWOA

Improve Checkout Workflow #20

High Level Objectives:

Checkout Workflows

Checkout Option 1:

Checkout Option 2:

Checkout Page

Confirmation Page

Admin Configuration