My product is store stock management. I product-manage multiple apps which allow store workers at retail giant Tesco to manage stock and provide an excellent customer service.
Tesco store apps include all the stock control routines: deliveries, reductions, counts, waste, training, product search and so on. I was surprised to learn (less so when I saw the ugly interface) that these apps had been built as long as 10 years ago and never redeveloped. There have only been small tweaks and iterations along the way.
The main problems that store workers were facing was a slow network, a lack of understanding of the interface and device breakages. The handheld devices and apps were slowing down their routines, such as counting, merchandise rather than speeding them up.
Before joining Tesco I worked on consumer facing apps and websites – but I found that internal products are a different world. I’ve spent the last 11 months looking for ways to improve the way that Tesco’s internal apps work and looking at how to improve the overall experience for staff using them.
The importance of the user
As a Product Manager I love interacting with users. You learn so much from usability testing – either because you don’t use the software every day or you’re not knowledgeable enough about returns processes and counting routines.
My first step was to shadow some routines, such as wasting out of date products, and build a relationship with staff in various stores. From this and focus groups, I was able to develop personas for our users and introduce them to our development team.
Multi-location and agile gaps
A key part of being a Product Manager is your development team and how you communicate the upcoming work to them. Prior to this project, most of Tesco’s development team was based in Bangalore. This baffled me at first. How could the development team understand our stores and users if they couldn’t even visit a store? On a visit to Bangalore, I introduced our developers to our user personas, insight from user interviews and, what they found most interesting, a review of what our users found frustrating. By making the users more human and less distant the development team became more engaged and together with product vision work I had done with our business owners, I was able to build a product vision with the developers. This vision is to enable our colleagues in store to work efficiently so that they can enjoy their work and serve Britain’s shoppers a little better every day.
The main success of this trip to India was that our developers gained the understanding that they were developing for real people. They became more engaged in developing in an agile, iterative way and in understanding user feedback.
Regular usability testing
Another brilliant new thing for this product was that usability testing had never been tried before. Apps were developed and then shown to the end user once they were completed. This change in process meant store workers had an input to all our early designs. They were delighted to see that their opinion could lead to changes and that they were contributing to their future.
We created prototypes and flat wireframes to test in store and used remote testing for quick feedback.
Using a design library
Consistency is something that should not be underestimated. While there were many poor designs across the 11 applications – deliveries, reductions, waste, gap scanning, counts, product search, merchandising, returns, newspaper deliveries, food donations and price checks – inconsistency was the main issue for users.
These issues became apparent from observing colleagues in store. They had to learn patterns for each application rather than understanding patterns and functions easily because they were common across them all.
Our customer-facing apps were more consistent so I sought out the owner of the consumer pattern library and started using and contributing to the designs. The key benefits of using such a library were that the patterns and designs had already been usability-tested so it was merely an extra test to see if they worked for our applications.
Selling analytics and crashlytics
The development was delayed by our lack of data and reliable insight. None of the old apps had any performance data. The approach I took with the new applications, was that they would all have analytics and crashlytics to ensure that we can review their performance and make important changes.
A number of business owners requested new ways of working and for routines to be reimagined, however we did not have the insight to make such changes. The best approach was to keep the same physical routines so that we understood how to design the applications. By adding analytics and crashlytics, we would be able to make data driven decisions. One great takeaway I have from this experience is; don’t try to reinvent the wheel unless you have the research to back you up.
Blockers – new device, internal vs public app strategy and completing the team
Perhaps blockers isn’t the right word. I was ready to get going with development from day one but there were a number of laborious but important decisions that needed to be made before we could build anything new.
First we needed to decide on a new device so that we understood the platform we were designing for. The handheld computers used in stores were six years old and the apps on them were about 10 years old. We had to choose the operating system (Windows, iOS, Android), the device support and repair service and costs. We chose a ruggedized computer with the features and benefits of an Android phone. It is simpler to use and easier to hold than the old devices.
The next task was to create a consistent strategy with our public facing apps. I worked with the groceries app team to form a strategy. We decided that our colleagues should be treated the same as our customers in terms of their app experience. We wanted consistent design across all apps, analytics for regular iterations and natively (directly on the device) built apps. Once we had this strategy in place, we were ready to build.
Once we knew it was an Android device and a native app (downloaded to the device) rather than web app (effectively a website) we realised we needed experienced Android developers. I then had to research various agencies to upskill our current team and grow the knowledge within Tesco. After inviting several agencies to tender, I chose the company that best suited our ways of working.
Once we had a device, strategy and fully fledged team we were able to get going with the redesign.
Feedback, the pilot and full scale roll out
Live testing began in various stores in October and we have gained positive feedback from focus groups, shadowing colleagues in store and we have made changes to the applications. For example, we now know that gap scan – scanning shelves for gaps so that that we can request a new order of that product – has improved dramatically.
The pilot is now in six stores of various sizes – express (small), superstore (medium) and extra (large) so that we can gain feedback from the first six applications out of the eleven.
We will continue development for the remaining applications for the rest of the year and continue to usability test along the way. We have cut out the business-owner middleman and for the first time, our apps are being designed with the main focus being the in-store colleague as the end user. It has been a huge change in mindset for Tesco to focus on the user and to test and iterate quickly.
Discuss this article