Frictionless checkouts for GAMMA and KARWEI

Over the years, Xebia has been the driver of Agile software development at Intergamma, known for the GAMMA and KARWEI DIY stores. A year ago, we set out to replace the checkout process for their webshops. The existing checkout was slow and cumbersome to use, and no longer on par with other parts of the website. We knew there was a lot of room for improvement. In order to justify the investment we needed measurable results quickly. Within a year, we’re consistently seeing a significant conversion rate improvement.
Before starting out to replace the checkout, we discussed the technology stack and general approach. We had prior experience with React and Next.js, but decided against Next.js because of the complexity it adds. A checkout app also doesn’t need to be indexed by search engines, which is why you’d otherwise want to use Next.js. We decided to stick with a standard React setup, which enables us to focus and keep things simple. In order to measure our success, we set up A/B testing to directly compare the old and new checkout running in parallel.

Minimum Valuable Product

Our initial goal was to go to production as soon as possible. This meant building a minimal version of the new checkout, without sacrificing quality or usability. We call this the Minimum Valuable Product. Because we were shipping this product to our customers, we couldn’t compromise on quality, usability or performance. However, we could omit features that are hardly used, especially with control over who’s seeing our new product. Taking the Minimum Valuable Product approach means you should:

• Minimize the work required to go live
• Offer a working, usable product
• Not compromise your quality standards
• Measure your results, and adapt

Our approach was twofold: reduce the number of features and keep things simple. In order to get away with delivering less features, we set up our cart page to direct a customer to the old or new checkout based on the contents of their shopping cart. This allowed us to avoid implementing complex parts of the checkout such as in-store delivery, big parcel handling and separate shipments, as well as dealing with logged-in users and multiple languages. We also initially offered only iDEAL and credit card payments. However, the features that we did build were fully functional, including any edge cases. With this approach we were able to go live in just a few months.

Reduced friction, improved performance

Reducing friction for the customer was our main goal for the new checkout. We did this in many ways:

• Avoiding page reloads by putting everything on one page rather than 3 separate pages and calculating shipping costs on the fly.
• Change the order of steps so we avoid asking for information we don’t always need (i.e. phone number) and explain why we need it if we do.
• Make sure the browser can properly autofill the form fields, and offer suggestions for possible mistakes, such as a typo in the email address.
• Offer a zipcode autocomplete, but also allow entering the address manually.
• Integrate directly with our payment service provider to avoid navigation to an external payment page.
• Automatically scroll the viewport when necessary to reveal form fields.
• Validate user input as soon as possible and provide actionable error messages.
• Provide ARIA hints for screen readers and allow keyboard navigation.

Improved performance was the second goal of the project because it has measurable impact on customer satisfaction and ultimately, conversion. Unfortunately many parts of the process are hard to optimize, and we didn’t want to touch the back-end too much. We focused on improving the perceived performance instead. This means having the site’s skeleton load as quickly as possible, showing signs of progress while data is loading in the background. The front-end is essentially a static website, served entirely from a Content Delivery Network (CloudFront) for optimal performance. This is known as the App Shell Model promoted by Google.

Component-Driven Development

The webshop we built for Intergamma is whitelabel, used by its two brands in two countries. This means being able to change the site’s visual branding and serving it in multiple languages. To manage complexity, the various parts of the webshop are built as separate web applications, currently including Shopfront, Checkout and MyAccount. To make sure these parts form a consistent whole, we reuse a lot of components between applications. These shared components are built separately as part of a design system, using Storybook for development, collaboration and documentation. The components are published on a private npm registry so they can be downloaded from a central place. Each component is dynamically themed to match the brand experience and translated based on user preference.

One great aspect of Storybook is being able to build components in isolation, so developers can focus on building the user interface, without the need for a fully functional application. First we focus on building individual components, then we group them together to form a greater whole – first sections of the UI, then entire screens. In development we work with fake data to iterate faster and be able to cover every use case. This approach is known as Component-Driven Development.

Going live

Part of our strategy was to release the new application as quickly as possible, so we could start gathering customer feedback early on. The deployable application shell is fully static – just a bunch of JavaScript files and static assets. This has great benefits: hosting files on AWS S3 is cheap and files are served by the CloudFront CDN to make it load as quickly as possible. We did however need to setup Lambda@Edge to dynamically add CORS and CSP headers. Luckily all of this is automated using Terraform from our CI pipeline, so there’s no manual work involved.
We deployed the new application in parallel to the existing one, and used dynamic routing to direct customers to the new or the existing application. This was done based on a set of predefined rules, such as the type of products in the shopping cart and whether or not the customer is logged in. That way we could direct customers with “complicated” shopping carts to the existing checkout, while customers with “simple” shopping carts had a chance to be directed to the new checkout. This allowed us to go live in a very short time, with only a subset of features.