Blog
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
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.
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.
Gert Hengeveld
Contact
Let’s discuss how we can support your journey.