A Year of Config-Driven Layouts: where are we now?
Just over a year ago, I shared insights into our Web Architecture project, focusing on config-driven layouts for Product Pages. Today, it’s time for an update.
If you haven’t seen my previous article, now might be a good time to take a look as it gives a lot of the context for what we’re going to talk about here.
A brief recap
The Web Architecture team has been working on a system to allow us to build different Product Pages using templates, components and configuration files on JohnLewis.com.
Our key objectives were to:
- Decrease time to market and cost of ownership
- Provide a consistent experience for customers
- Make building new experiences and capabilities easy
- Build components for use across product categories
Whilst retaining:
- Team autonomy and accountability
- Our core principles of being Lean, Simple and Fast in everything we do
Example
Here is an example of a Product Page — one of our fashion pages:
We’ve got components for the product title, price, reviews, size, colour, image gallery, Add To Basket button and more, all of which come from the Product Page component library (more on that later…)
So, how’s it going?
Well, we’ve successfully migrated 5 out of 7 Product Pages on the new system including fashion, beauty, electrical, standard and retired products!
- Streamlining Product Page Maintenance
We’ve massively reduced the cost of running and maintaining a Product Page applications, from 5 teams’ worth of work down to 1. Now each Product Page team only has to think about what our customers want and how to best deliver that, whilst all the security, maintenance, scalability, stability and performance concerns are taken care of by the Web Architecture team in one place. - Boosting Add to Basket Rates
We’ve increased Add To Basket rates by 1.1% (which might not sound like a lot but it is in the world of e-commerce!). This is mostly attributed to the increase in consistency across pages. - Rapid Delivery of New Page Types
We’ve created a whole new type of Product Page, our Outlet pages, in 1 day where previously it would have taken 6 months! - Accelerating Design Refreshes
We’ve implemented a site-wide design refresh, where Product Pages were updated in a couple of hours, rather than multiple teams taking weeks of effort. - Enhancing A/B Testing Capabilities
We’ve massively increased our ability to perform parallel A/B experiments across the Product Pages
So, it’s all good then?
Not quite… We’ve learned some important things along the way:
PDP Component Library
First of all, we had some really good intentions behind separating out the PDP Component Library (seen below) into its own NPM Package.
- Create a separation of concerns, and importantly ownership, between the underlying platform (Scaffold UI) and the components that build on top of it
- Enable a smoother migration onto the platform by allowing teams to create components in the component library and use them in their existing app during the migration phase to reduce duplicated work
As it turned out, however, teams went full-throttle into migrating their components into the new system, taking much less time that expected. This meant that the capability described in number 2 above wasn’t really utilised as no team decided to back-port components.
Also, testing and deploying pages and components became convoluted by this separation. When an Engineer wanted to make a change, they had to wait for multiple build pipelines to succeed before they saw their changes.
We still wanted to keep the separation of ownership, because the teams building the components were separate from the team building the platform, but we wanted to reduce the friction in the system. We achieved this by moving the PDP Component Library into the same codebase as the Web PDP Scaffold and relying on Gitlab’s concept of Code Owners to control which people have approval access to which files/folders. This has proved much more efficient, reducing our CI pipeline times by two thirds!
Configs, configs, configs…
Another learning has come from keeping track of all the experiments we’ve got going on at the same time, and not letting the amount of configuration files get out of hand.
Initially, teams created only a handful of config files to manage different page types. But, as enthusiasm grew, so did the number of configs, which could get a little out of hand — at its peak we had more than 50 different files!
To combat this, we introduced a couple of ideas:
- Apply sensible naming conventions to file names, such as [page type]-[experiment id]-[description].json. For example: electricals-1234-move-add-to-basket-button.json
- We send an automated Slack message to teams who own configs when they get old and aren’t used, for example:
Hi Team! The following pageConfigs owned by your team haven't been used for at least 7 days. Please remove any that are no longer needed!
Layouts, layouts, layouts…
On a similar note to the configs above, teams initially started creating multiple versions of the Page Layouts for each page type. These were all very similar in actual rendered HTML, so we gave all Layouts generic names. So, instead of FashionLargeLeftHandCol.jsx, we describe the layouts by their visual differences e.g. SixtyForty.jsx or EightyTwenty.jsx. This has reduced the amount of Layout files considerably and increased the consistency across pages, something our customers have thanked us for!
Ownership and Responsibilities
We’re still working through where the responsibilities lie for the Web Architecture (WA) team and the Product Pages teams.
It’s clear that the WA team are responsible for maintaining a performant and reliable platform and continually enabling the Product Pages teams to quickly iterate on new ideas. What is less clear is where the line is drawn around the various components, which are owned and maintained by the Product Pages teams, but any production issues are currently the responsibility of the WA team.
The goal is to find the sweet spot, putting enough safety nets in place to allow enough autonomy in teams while giving confidence that unnecessary bugs aren’t making it through to production.
What’s next?
The Web Architecture team is hard at work on migrating the next app, the Product Listing Page (PLP), onto the new stack. This is presenting new and exciting challenges for the teams to work through, such as “who actually owns the Product Card component that’s used across the website?” and “how do we enable teams to have different versions of it using nested configs?”.
We’re also enabling our teams Waitrose to adopt the same config-driven pattern as we bring out more Micro-Front-Ends in that area (more on that in a future article).
This transformation in how we build front-end applications has been remarkable, and I couldn’t be prouder of all the amazing people in our Engineering teams for making it such a huge success! 👏
