Product Detail Page Migration, Part 2: Streamlining Collaboration
In the first part of this series you read about how 2019’s patchy product detail page (PDP) was optimised. This second part explores the extraordinary level of collaboration involved in the migration project. I’ll cover the problems we tackled, the team dynamics, and the bottleneck we overcame.
Examining the root of the problem
Optimising the PDP helps our customers and delivers on our business goals. We want to show customers detailed and relevant product information in the most efficient way possible and help them find products they love with ease. If customers are better informed about the products we present and more confident about making a purchase, it is more likely that they will keep their items — and subsequently save Zalando hundreds of millions of euros in returns.
Our initial research exposed UI inconsistencies that were a symptom of previous work streams being added one on top of the other without a comprehensive approach. New styles and features were released and clashed with older iterations, meaning our customers had to work harder to discover basic product information. We wanted to move away from just adding banners, buttons, and links to achieve short-term goals. Taking on a redesign for the entire process, we decided to update our UI to reduce the information density as well as the effort required for delivery and maintenance.
As the designer on this project, I wanted to make sure we delivered a scalable solution, leveraging the customer insights from user research, and the robust centralised design system we use at Zalando. The payoff from a design point of view was potentially huge as it could empower and enable other teams to collaborate and contribute seamlessly, where before there had been a bottleneck.
Who worked on the PDP migration?
At Zalando, different teams work together on a project like this. Embedded designers like myself work in product teams made up of developers, product managers and data analysts and have a great depth of knowledge on their premise. Our team has our own KPIs and customer goals and is responsible for the PDP and product cards. I design features with our product team that we can test independently, but we need to collaborate with specialist, centralised teams to release features fully.
As the PDP is so critical in the customer journey, we worked with the Voice of Customers team to help us understand our audience, and therefore ensure that we build the right features in the first place. We were able to draw from a wealth of insights the user research team had gathered from in-home interviews and usability and concept tests. Another specialist team we worked closely with was the Zalando Design System (ZDS) team. To achieve a consistent and coherent experience across app and web, they helped to ensure accessibility standards were met at implementation.
Zalando’s supportive culture helps reduce barriers to collaboration, and despite there being so many individuals and teams involved, there are fewer limitations to getting things done than you may imagine. Zalando did, however, have a legacy of gatekeeping…
The Bottleneck
The mechanics of our codebase meant that our team had become the gatekeepers of all features and changes that were implemented on the PDP. Yes, we retained a huge amount of knowledge about our own page, but other teams with great ideas still had to go through us which wasn’t the most efficient way of working (especially if teams had different priorities and timelines). We wanted to move away from having conversations that sometimes went:
Team A: “We’ve got this great feature we know is perfect for the PDP.”
Our team: “When do you need this feature built?”
Team A: “As soon as possible.”
Our team: “We can do it, but we need to fit it in with other projects we’re working on.”
Team A: “Ok, so…?”
Our team: “We’ll get back to you…”
Obviously this is a dramatised dialogue, but generally we had a siloed approach to delivering features that made it harder to work with other product teams.
Migration to a new code framework has allowed us to use fully accessible and responsive components from our centralised design library for the first time. In addition to the reduced time it takes to build, deploy and maintain features, sharing a common technical and design language allows multiple teams to contribute to the premise — no more gatekeeping!
Learnings
Aside from achieving AA accessibility, meeting our core KPIs, and looking at our success metrics, this project was about enabling other teams to both use our components in their work and contribute their own to our newly migrated page. The PDP redesign sets a foundation, and although that might not be so sexy on the face of it, it means we can push more conventionally exciting projects where we can have a bigger impact for our customers. We’ve been able to establish a solidity that was missing in the design and content hierarchy, develop components that can grow with our ambitions, and improve the way we present and sell products to customers. All of these updated components have seen us collaborate across the business and establish relationships that we can go back to, helping our team’s visibility in the process.
