The Problem
Updating Old Processes. In 2020, the world shut down for most people. Remote work became the new normal and software companies thrived. Kroger was in a unique situation, however. While the general operations employees could work their jobs remotely, their in-store associates were considered front line workers and had to go in to stores. This disrupted how much product designers were able to validate their solutions as access to their core users was limited by safety regulations. Such was the state of the product I inherited when joining Kroger in early 2021.
Fresh Production was the app being created to replace the old hardware and process for bakery associates to plan the amount of stock they needed for a given day. The team had seen heavy turnover in key leadership positions leading to a slow progress due to lack of direction.
Old Method of tracking production
Level Setting
I needed to get familiar with the current state of the app and how user's were reacting to it. After talking with my team and business parnters, I understood what we were trying to accomplish. Now I needed to know where we were in the solution and how our test stores were using the new process.
We had five test stores using our app, one of which was local to me in Cincinnati, OH. The rest were out of state. So, I set up Teams calls to discuss certain flows of the app and get feedback.
Talking to users is one of the best parts about being a Product Designer. You get to experience how that person interacts with your app, see their reactions and find out real problems they have that you can solve. In Kroger's case, I got to see how their bakery associates worked and what they had to do on a daily basis.
My Teams interviews were limited in what I could do to interact with my users. Usually they joined by a store phone which meant they couldn't share any screens. So, I had them walk along with me in the app, asking questions related to the flow and expected data. This worked well enough to determine that while the flow made sense, the data didn't and they frequently felt they needed to make more.
For the stores I was able to go in to, the Cincinnati store did not like, trust or use the app. The Michigan store used the app but didn't trust the data. I was beginning to see some repeating feedback. Users didn't want to change because the app wasn't accurate and ultimately wasn't predicting the needed items to make for the day. These interviews gave way to our first set of goals.
Success Metrics
KPI's. There were multiple KPI’s (Key Performance Indicators) we established from quarter to quarter. In the beginning we had three key metrics to measure for our success
- Adoption from associates
- Shrink Reduction in the amount of product thrown away per store
- Financial Savings by stocking appropriate product amounts
Current App
Three Tasks. Bakery associates were tasked with three methods of stocking goods on the floor. Today's preparation, tomorrow's preparation and thawing freezer items. Each one would show what food they needed to prepare, and how much. The associate then needed to enter in the amount they actually prepared for the day. This entry data would then be used to help produce accurate numbers for the following day.
It was important that the associate entered in the actual number of produced goods. We initially added a feature that asked the associate why they overproduced or underproduced. We found that associates rarely entered in meaningful data. When I interviewed some associates about this, they said they usually ignored this feature because it just slowed them down.
Even with correct entries, our recommendated amount to make was consistently off, especially in Thaw & Sell. We needed to figure out how to make that reccommendation more accurate.
They didn't trust the numbers and didn't want to get in trouble for under producing.
Solving Data
Where does the data come from? Kroger has an entire separate company devoted to their data analysis and engineering. So we reached out to our partner to better understand how our numbers were so off.
I can't devolve the exact algorithm for determining how much to produce for a given store, but we were able to determine the reason for why the data was off. We didn't currently have a way to know just what was in the freezer vs what was already on the sales floor. Those two areas were essentially the same number in our systems.
Because of this we couldn't give an accurate number. However, we now had a problem we could solve.
Solving Thaw & Sell
Design Thinking. I ran a several workshops with the team to brainstorm solutions for the accuracy issue. I knew this was the bigger deterrent in terms of user adoption, and I believe great solutions come from the entire team, not just the product designer.
Essentially I wanted the team to rapidly come up with ideas for solving how we can know salesfloor numbers vs overall numbers. We eventually landed on giving the associate a way to count a table after seeing one of our counterpart apps implement something similar.
Now I needed to come up wit the design solution. I like to sketch out designs when I'm starting off on a new screen. I find it helps me create ideas faster and not worry as much about the final details. One excercise I use is called Crazy 8's which lets me create eight screens in rapid succession.
Design Solution
Rapid Prototyping and Testing. I wanted the associate to be able to scan a certain display table and then count what was on it. This required multiple steps and a flow that needed to be both easy and accurate.
Before the scanning, which is an integrated aspect of the device used, could even happen, I needed to a way for the user to setup the table. Ideally this is a one time event that the associate had to perform, followed by an easy to edit flow in case they needed to change out what was on a table.
Once a table was setup, the associate would then be asked to count that table. With the scanning capability of the device, I wanted the user to be able to quickly scan a barcode on the table that would pull up the correct table in the app, allowing them to make an accurate count. The barcode was another solution we saw from other associate app teams.
The final piece was to make sure the associate could easily and quickly count that item. They have to perform multiple counts throughout their day for various apps, so we knew adding a new counting task wasn't going to be appreciated. I didn't see any other immediate choice given our data problems.
Above is an excerpt of the whole solution. The part shown is when the associate has already created some tables and is able to scan the barcode to access the counting flow.
From the counting flow the can quickly see what products they have to count on that table before doing their production. Once all tables have been completely counted, they can then start their daily production.
The Testing
Into the Stores. My process for testing was to wire up the mockups into InVision, do some basic interactions so the associate could tap through the flow, and pull it up on my phone to walk the associates through the new screens, asking questions along the way.
I would give the associate a high level overview of what they were going to be seeing, with the problem we were hoping to solve, but largely let them interact with the prototype on their own and observe any struggles they encounter or any validations of the designs.
Testing proved to be a little tricky to work through. They would notice things like wrong product imagery or incorrect product in the activity, which would distract them from what I was actually trying to test. They wouldn’t be sure what was tappable or not, a limitation of the prototyping tool and how I would not wire up the sections of the app I wasn’t trying to test.
For the new counting feature, I tested in a few stores that weren’t familiar with the app to get a fresh impression, as well as another trip to Michigan to test with our highest usage store. Using the process I mentioned above, I collected the feedback from the associates. Most of the non-familiar associates were comfortable with the process and understood the need and the outcome. For our Michigan store, they were not excited about having to count more, but said the process seemed quick and easy enough to complete. We found that giving them control of their table and products and that seeing the count they performed directly impacted the amount they produced, greatly increased the trust in the app.
They would notice things like wrong product imagery or incorrect product in the activity, which would distract them from what I was actually trying to test.
Once I had gathered the feedback and made any tweaks necessary, the team worked on developing this new process. Once development was finished we did another round of testing with the actual device in our test stores. This allowed us to continually fix issues, create new enhancements, and ultimately push this app out to all bakery departments across the country.
Deploy the App
Starting to Trust. This new solution took months to work out and develop. I spent countless hours with my product owner in stores and in meetings with business partners, making sure this solution solved the needs of the user and the business. We were confident it did. The feedback was positive on both sides.
We launched the app enterprise wide. We created training documents in the app as well as printable guides for stores. In tandem with our UI solution, we also spent time with our data partners cleaning and fixing our data.
The feedback we were getting from leadership and the stores I was able to talk with was positive. After the one-time setup of tables, associates found that counting the items was quick due to being able to scan the barcode as well as count on the list of items.
Through Google Analytics, we could see that daily usage of the app and daily completion of the tasks were on the rise. Associates were using the app to complete their work for the day.
Continue Reading
CLC Lodging
Product Designer & Business Analyst
Lead product designer for CLC Lodging's request for UX improvements to their mobile application. Heuristic Analysis revealed a need for more recognizable UI patterns and user flows. I led a small team in gathering requirements in order to enhance the application's user experience as well as update it's UI to a more modern feel.