Transforming an Internal Tool to Manage Stock Availability
Working with the Source and Supply product team to develop a new tool to help the Trade team manage stock availability rules and increase stock visibility.
Stakeholders: Technology, Product, UX, Trade, Change
Tools: Teams, Miro
Methods: Prototype Testing, Workshops, User Interviews, Severity Ratings, Journey Mapping
June 2023 to December 2023
Problem
Selfridges needed the ability to manage the availability of stock in its warehouse and stores so that it could be picked to fulfil online orders. Stock availability rules and thresholds were created to:
Switch items on and off for online fulfilment
Set where stock is fulfilled from (Distribution Centre (DC) and Store, DC only, Store only)
Apply a threshold to a product to determine its online availability
A solution existed but there were many problems with it:
It was a complex process involving many steps and different software
It could only be managed by 1 person in the business and there was a big lack of knowledge within the team who needed access to the tool
It was especially hard to manage during periods of sale or product launches
It didn’t work very well - there were a high number of order abandonments and inaccurate stock availability
There was a need to apply rules at a brand level as well as product / category level
Hypothesis
By building a new app to manage this process we would:
Give more team members access to the process and make it easier to manage
Reduce user error
Reduce order abandonments for stock we have wrongly displayed as available online
Increase stock accuracy
Save time for team members by providing more ways to implement the rules
Research Methods and Process
I was the only researcher supporting and it was the first time UX research resource had been used to support internal tool development.
Research Goals:
Better understand the users and the context around the problems with the existing solution
Test the prototypes to make sure it was fit for purpose and gather insights for future development
Educate the project team to get them comfortable running their own testing in the future
Process:
Worked with UX Designer to define problem and scope prototypes and testing plans. We had a lot to do in a short space of time so we chose to break the tool capabilities down into stages and test them iteratively - building a prototype and testing this, while the designer moved onto building the second prototype as the research was being conducted on the first.
Conducted user interviews with the team members using the existing tool to understand more about their needs, process and pain points. We also ran usability tests on the first stage of prototype - creating a rule. We combined the session to save time for participants and use the usability tests to learn / validate the pain points we had previously been told about.
Analysed insights and created a presentation containing all the findings so far. I ran an insights workshop with core team to feedback findings, discuss the issues and work together to establish a severity and plan of action for tackling each one.
Ran a second round of usability testing on the next stage - searching for existing rules and deleting rules.
Used Miro Assist AI tool to analyse the findings to see if it would speed up the analysis process. It worked well in identifying clusters although I still needed to go review the outcomes and change quite a bit.
Ran a second workshop with UX, Product Manager and Business Analyst to review all the findings and establish severity.
Developed a list of UX fixes and next steps for the project team which included tech fixes for now and features to go on the backlog.
Ran a workshop with users and product team to gather user feedback on revised prototypes.
Worked with change team to develop training for new tool.
Gathered feedback from the project team and the users we spoke to to understand how we could improve the research process.
Handed over testing to project team to run and manage going forward. Provided templates for note taking, synthesis and analysis.
Findings
Identified a number of issues with the prototype design which we were able to either fix or add to backlog for future development
Gained a deeper understanding of the different users and how they would need to use the tool differently depending on their departments / responsibility level
Impact
MVP of the first stage of the tool was rolled out in May 2024.
No quantifiable business metrics available at the time of writing, however, the tool has empowered the business users who need to apply the rules to do it on their own and made the process easier and faster.
Using research in this way allowed us to work quickly - the UX designer worked on the next phase while a previous phase was being tested. Testing in phases also allowed the tech team to start developing.
Inviting the core team to user testing sessions enabled them to see first hand the user feedback which in turn helped speed up prioritisation and understanding of severity of issues.
“This box is really simple and useful. You know what is there and what the new status is. The colour coding really helps. ”
Learnings
The whole project team for this was brand new. Running early getting to know you workshops helped build relationships and team spirit, and created a shared understanding of ways of working.
Iterative testing enabled us to design and research at the same time, and get designs to the developers more quickly.
Testing with internal team members gave them visibility of what was being worked on and crucial involvement in the project. However busy schedules meant they weren’t always available and we could have better planned this into the research phase. Luckily we all worked on the same floor so we were able to be flexible and grab a few minutes of someone’s time to get feedback in addition to the organised sessions.
Making time at the start of a project for gaining a full understanding of user needs would have saved time later on. It would also have helped reduce the amount of features that ended up being deemed out of scope. We didn’t spend enough time doing this as it was assumed by the project team that this work had already been done.