Journey to a Responsive Checkout
By Front End Developer Gemma Voakes
Our migration of legacy desktop and mobile applications into a single, smooth, responsive site.
Why are we doing this?
Cohesive customer experience. Consistent, maintainable tech stack.
We currently have two separate applications driving our basket and checkout pages; one for mobile and one for desktop.
Mobile
- Angular
- Four pages (basket, delivery address/date, contact details and payment)
Desktop/Tablet
- JQuery, with a bit of React thrown in for good measure
- Five pages (basket, delivery address, delivery date, contact details and payment)
Our order confirmation page, where customers land after payment, is already responsive. Everything between basket and payment however, remains duplicated, existing in both our Angular mobile site and our JQuery desktop site.
These two applications have different designs (although similarly AO branded) and they work in slightly different ways. Crucially, work being planned in to any of these pages has to be duplicated, increasing its lead time.
The plan
Using modern technology, we plan to replace these two legacy applications with one fully responsive checkout, thereby reducing the duplication of effort. This will enable us to deliver new features more quickly. It also means that we will have a single, consistent codebase to maintain, making it easier for developers to work on and more efficient for new team members to get acquainted with.
How did we start?
We knew we had some big pieces of work coming up for our payment page so we decided to start with that. If we could create a new responsive payment page before these projects were due to start it would mean that we’d be able to do the work way more efficiently; on one responsive codebase, rather than two legacy codebases. Some of the technology we decided to use to develop our new payment page includes:
- React
- TypeScript
- Webpack
- Jest (for unit tests)
- AO Strata CSS Framework
To account for the existing design differences between the mobile and desktop sites, we needed UX help to envision a new unified payment page design. Our talented UX colleagues therefore came up with a design that would work well for mobile and desktop without looking jarringly dissimilar to the rest of the checkout journey. As a bonus, they also included some user-friendly UX updates to improve on what we had before. We hope you agree!
We made improvements to various bits of functionality within this page such as our billing address lookup and payment type selection. We also took the opportunity to align our new page across all three of our territories; AO.com, AO.de and AO-business.com. We aimed to keep any differences between these sites to a minimum, in order to maintain efficient working practices.
We needed to be able to continuously deploy our changes with confidence. As an online retailer, our checkout site is a crucial part of our business! We can’t risk putting changes live that will result in deteriorating the checkout experience for our customers. The following tools helped us to mitigate these risks:
- Maxymiser allowed us to route a small percentage of traffic to our new responsive page, increasing this percentage gradually over time as we gained confidence that the new page was performing well.
- We used New Relic post-deployment to quickly alert us to anything amiss which would allow us to revert back to the non-responsive page if required.
- Adobe Analytics tracked dropout rate and conversion trends split out by device type. This meant we were able to easily see if there was a significant drop-out on mobile for example. Although our New Relic reports gave us confidence, Adobe Analytics enabled us to monitor if there was a significant drop off in conversion, due to a worse user experience, for example. Combined, these tools gave us increased confidence that the new page was performing well.
Having completed the new payment page, we were able to immediately pick up payment-related work such as implementing our new AO Finance payment method. Having just one, modern codebase to work from rather than two legacy codebases, vastly improved our speed to deliver on this project. Success!
What’s next?
Although we do still have the two legacy applications supporting our basket, delivery address/date and contact details pages, we have now freed the payment page and started on a responsive journey which we can continue. Next up we plan to roll out a responsive contact details page, followed by our delivery address/date and basket pages. We will continue to add UX improvements where we can, as we did with the payment page. Gradually we will remove all dependencies on the legacy applications until we are left with a single responsive basket and checkout: coders nirvana!
Want to know more? Why not come and chat to us at one of our upcoming North West Tech Talks.
