Replatforming A Leading British Retailer

Overview of some of the difficulties we have had to contend with as a business:

• Next have a digital presence in 140 countries
• Next have 6 partners dependent on the existing Total Platform Service
• Delivering the project alongside the existing roadmap
• 20+ years of legacy infrastructure and lack of documentation
• Migrating from local physical servers to a cloud based solution

To understand areas of difficulty

'There is a link for ‘Victoria’s Secret’ on the home page which I cannot reach using the tab key, I would require help to use the mouse to select the link.'

While rebuilding the infrastructure, we were also afforded the opportunity to revisit the overall experience of the website.

As such, we commissioned a site wide report to evaluate areas of difficulty for users with mixed abilities and determined that 45% of the checkpoints failed AA compliance.

This formed our basis for quantitative usability improvements with the aim to steadily reduce that count.

To make it usable

The online arm of the business has grown at such a rate that we have ended up with adaptive web experience that offers different experiences on each platform.

A repercussion of that means that we have struggled to provide some our most popular device types (tablet users) with an interface that is built for purpose.

Despite this, our customers have continued to shop on a site where they have to work extra hard to buy what they want. The least we can do is allow them to make a clear and informed decision on what they want, and iron out the things that make online shopping less pleasant.

To be more inclusive

There has been a big push on making sure that public sector websites and mobile apps meet WCAG AA standards; a legislation that is also due to affect online retailers too.

Working with this, we took to tearing down every component of our browse and shop experience and doing appropriate contrast checks, semantic HTML checks, focus orders, keyboard navigation and looking for ways to implement better error handling.

To build better processes

Every team aims to do their job to the best of their ability, but there will always be a moment where two wider teams need to collaborate and this is where small details become bit issues.

Keen to break the cycle, both myself and a colleague inducted ourselves into the development processes, attended every standup, refinement, ceremony, ATDD session, demo, you name it and made ourselves 'available' whenever required. This shift in working relationship meant that we enabled the developers to push back, query, suggest and even enhance our vision for the site and most importantly build that trust that we're here to deliver this solution together.

The result meant that we were in the loop and able to understand every technical decision, and the technical team were able to understand and learn more about the user centred approaches we hoped to build.

Redesigning a 20 year old adaptive site

Over the last few years, we've pulled together a design system that houses the atoms of the site, from browsing through to checkout. During the process it became apparant that is is a huge disparity between the desktop site and the mobile site. Rectifying this adaptive approach became our priority.

With the help of the data science team, we were able to make educated decisions on what elements should be shown at which breakpoint and what could look to be removed. By decluttering and unifying the experience across all resolutions, we have started to take steps towards ensuring that the our customers have a consistently satisyfying experience regardless of the device they use.

Regular communication with stakeholders

Pages with the highest conversion are often the most contentious when it comes to updating, so keeping stakeholders up to date throughout the development process is very important.

By bringing the designs up to date with accessibility standards and not compromising the screen real estate, we are able to prove that being inclusive doesn't come at a cost.

Defining a site wide, cross partner theming framework

Part of Next's vision of the future is to use the new Total Platform Solution as the basis for their partners.

The architectural problem this poses is how can we give the partner the UI they want, but without duplicating the code base?

The proposed solution? Creating and defining partner specific themes. By building out the framework of the website, I was able to determine the key variables that change from site to site and build a generator to document, test and export these themes.

Writing interaction design acceptance criteria

Being given the autonomy I was afforded with this project meant that I was able to be a bit more hands on with some of the more interaction intensive user stories.

The Business Analysts asigned to the project were largely responsive for populating the acceptance criteria, but would often work alongside a designer (namely myself) to write these in accordance with the interaction designs and prototypes that we had built.

Championing accessibility

We're lucky to have some great advocates for accessibility within our team, so with their assistance I compiled and presented a document on how each team can look to play their part. This has formed the foundation of a wider education piece we are looking to share with the business.

Taking these findings, I then worked with the front-end development team to support them with interaction design, focus guides and testing.

Front-end development

The only thing I love as much as designing experiences is attempting to build them.

A few years ago, in an attempt to help me better understand the difficulties that developers go through when interpreting designs, I started to build out the designs prior to handover. This generally stood me in good stead with the developers, allowed me to reduce load on the QA teams, and design with the end interface in mind as well as the user.

The teams I worked with on this project were just as receptive and I would often create POCs to make sure we build the right thing and then they would make sure it's built correctly.

This section has a slightly misleading title as it's still very much an ongoing process and will continue to be. We are launching the new components iteratively and staggered across the next year as not to interfere with the day to day running of the website and to have full confidence before moving to the next release.

What went well

• Having experts in their area being allowed to take accountability and ownership
• Working with teams remotely
• Deployment time down from 2 weeks to daily for microservice elements, a reduction of 93%
• 3 out of the 6 partners dependent on the existing Total Platform Service now using a modernised service

What didn't go well

• Testing processes, result of partial cloud and partial local environmental factors
• Cross business communication at times (Covid 19 partially at fault here)

What we're going to do better

• Write small and regular success stories
• Give regular updates in a way that everyone can understand
• Celebrate the small victories