Helping retail stores place products on shelves

That plan is called a planogram. It tells store associates exactly where every product goes: which shelf, which position, how many facings, how much space. For the people doing this work, a typical shift starts with a stack of printed sheets and a day spent rearranging shelves to match the plan, while managing shopper interactions throughout.

At Blue Yonder, we built software for this. The product team had already designed and developed a mobile concept before reaching out to research. It was an innovative tool, but it had been built without direct customer input. When we heard about it, it was clear that research had to happen before release, rather than investing in a product without knowing what customers thought.

I chose to test the concept in person rather than remotely. We were short on time and had almost no existing customer context to draw on. Remote testing would have been faster to set up but harder to learn from. I felt that seeing participants in their actual environment would teach me more than they can describe over a call. Plus, explaining a brand new product to someone who can see it in context seemed more approachable than asking them to imagine it remotely.

I visited grocery, convenience, and mid-to-large format stores. Each field visit had two parts: walking through the mobile concept prototype with participants, then following them through their actual work, down aisles, watching them handle products to see what a real shift looked like.

First, I noticed that store associates used both hands constantly. Second, their attention was split between the planogram, the shelf, the product they were holding, and any customer walking past. They got interrupted often and worked quickly in short bursts.

One retail supervisor described her experience with large shelf resets.

The same participant reacted differently when shown the concept for new item cut-ins.

The contrast between frustration with large resets and genuine excitement about small, targeted tasks became one of the central findings. I noted that we had to find a way to accomodate both.

We began with the assumption that the product would be a mobile app with web support. My post-research recommendation was tablet-first, with paper kept in place for large resets. A web app would only work in the back office, used by store admins. A phone was too small and required too much hand use. A tablet mounted on an inventory cart kept hands free, had enough screen space to read a planogram without zooming, and could travel through the store.

The product team had invested a lot of time and energy into building an animation feature that showed products moving onto and off shelves, based on planogram direction. It was a feature they were all excited about. However, when I ran an A/B comparison between two interaction approaches: a task list of adds, moves, and drops to check off, and the animated visualisation, the task list won on efficiency.

Store environments move fast, and users didn’t spend time watching the animations. But they didn’t say “get rid of the animation” either. They could see value in visual confirmation, especially for smaller tasks where seeing exactly where something goes is quicker than parsing a list.

I received pushback on both of these insights when I presented them — there was a lot of investment, assumption, and confidence that had gone into creating the designs and the team was relunctant to make drastic changes.

Since it was my first time working with this team, I brought what I’d seen in stores: observations, direct quotes, and recordings of participants reacting to the concept. A few participants said directly they wouldn’t invest in a mobile-only solution.

Once stakeholders could hear what participants actually said, the conversation shifted from defending the feature to figuring out where it belonged.

When I found out the product had shipped as a tablet app, I felt proud. It confirmed that I could clearly present evidence-backed research that moved a product, even though it entered the lifecycle late.

After the concept testing and product release, I launched a discovery study to learn about users from the ground up. It was something we should have done before the product was built, but I knew doing it after would give us a proper foundation for future iterations. Better late than never.

And once I understood the full system, some of the friction from the initial research made a lot more sense!