Sainsbury’s has around 40 thousand products that they sell both in their stores and online. During my time there I was part of the product onboarding and maintenance team also called MDM (Master Data Management) leading from a UXD perspective how products are onboarded and maintained within the wider ecosystem.
Working as the Lead UXD for the product domain the company was going through a digital transformation. This meant that the databases of Sainsbury’s, Argos, Habitat and TU were merging in the interest of providing better product data for users and colleagues.During this time I was involved in several projects.
The data was not communicating between the different domains, this meant that a lot of the products were duplicated so users would get the same product with different prices in Argos and Sainsburys.
I started by organising a series of remote workshops with the team comprised of Backend and Frontend engineers, testers and a PM to plan an approach in solving this problem.
In the first workshop, we have mapped together questions on the product, stakeholders, expectations from XD and outcomes. There was a need for rapport build-up as remote working puts extra barriers in newly formed teams and interpersonal relationships.
The second workshop was focused on the problem statement and catching up more with the team. After that workshop, we have defined the problem statement.
“There is no clear way of unifying the product data in Argos and Sainsbury's. This means our colleagues are unable to have single identifiers for identical products, meaning we are unable to align on our offering across channels, providing inconsistent data for our end customers. How might we unify product data so colleagues can offer a unified customer experience across channels?”
The third workshop was focused on defining a plan that all can agree with in terms of times and prioritisation of work. The key was to have flexibility in terms of the amount of research, ideation and discovery work needed to achieve a product that is easily used.
Once the plan was agreed upon I started meeting up with stakeholders to understand their approach of setting up the new team, their needs and pain-points. In the same time, I wrote the discovery questionnaire for user testing and set up the meetings with the main users that were going to be part of the newly formed team.
Before moving to build a prototype we had to agree on data points that were going to be used for the product but also on the type of features we needed to have to be able to get the product going. I set up 4 workshops, 2 with users to discuss data, and features and prioritisation and 2 to discuss the same things with the team and SMEs. Using Miro I have gathered all the data that was necessary to prioritise the features and move forward with a prototype.
In the meantime, I researched design patters used in matching 2 sets of data and how other platforms do it. I also researched various patterns used in understanding how users look at 2 sets of data from UX resources.
After gathering all this data, it was time to converge information gathered and start to design the prototypes. I started by using a sketchbook to map out the overall flow and look at possible ways of matching products.
Using Figma I have mapped out the processes and started creating the screens to move forward with a build. I presented the sketches and progress to the overall design team to get feedback on the design patterns used and if we can use any other components from LUNA (Sainsbury’s design system) that I might have missed. In the same time, I presented these sketches to Stakeholders and engineers to get early feedback on the journeys I was proposing.
After getting early feedback from both the team and stakeholders, I was writing the script from user testing and setting up the meetings. This process helped engineers start mapping out the stories in the sprint and to start building.
Having the first working prototype working I tested it out with users and got some good feedback. One of the problems that I encountered with the protoype was that users needed more information to make a decision on if the matching was accurate.
I have solved that by adding more information to the product. The information was regarding the volumetrics of a pair of products. This prompted to the next user testing session, where the product volumetrics was introduced and also ironed out other smaller issues. The second round of usability testing did not surface any more major problems except a new next-previous button.
During the implementation, I had regular catch-up with engineers to align interaction patterns and iron out any errors and notifications that needed to be surfaced. We also needed to source the data to go in the matching API. The product went to users and we implemented Analytics and User Zoom to understand how users interact with the product on a daily basis and for the next designer taking over the project to have an easy transition.