Store Assessment App
Field reps for a leading German plant-based food manufacturer negotiate shelf space and assortment with retailers store by store — with no data to back that negotiation.
The store assessment app solves this problem by calculating and displaying a store's revenue potential — across assortment coverage, shelf space, product visibility, and secondary placement — using image recognition to gather store-specific data instead of manual input.
I owned the design end-to-end through the concept phase — from shadowing a sales store visit, through mockups, to the user stories that handed the concept to development.
To protect privacy and confidentiality, all logos, company names, and other identifying details have been removed or replaced. These adaptations ensure compliance with privacy agreements and safeguard sensitive information.
challenge
Hours before the pitch could even start
To back their negotiations with store owners, reps needed a way to quantify a store's revenue potential. An external consultancy designed the underlying logic — an Excel-based model that calculated potential from shelf space, assortment coverage, visibility, and placement.
The gap was in the data behind it. Feeding the model meant manually measuring shelf space, verifying product availability, and estimating placement effectiveness for every store. The team measured this baseline during testing: manual assessment took roughly 3 hours per visit. That capped how many stores reps could realistically cover, and how rigorously.
research
Shadowing & Workshop
I shadowed a sales rep on-site during a store visit to see how they actually worked and what problems they had. One of the pain points was lack of time — reps had to cover several stores during the day. Store managers also weren’t always in place and had limited time to talk through reps’ suggestions.
Following shadowing, I created a user journey and ran a Scoping Workshop with key stakeholders to map the end-to-end process and align on core functionality, technical constraints, and user needs — grounding the design direction in what was both feasible and strategically aligned from day one.
Pictured above: user journey map, features in scope
design
Tablet-first, table-heavy
The core challenge was adapting a flat, thousand-row Excel prototype into something usable on a tablet, standing in a store aisle with limited time to spare. Since the app revolved around tables, and stakeholders wanted to surface as much information as possible, I had to balance density against usability — avoiding horizontal scrolling. Rather than trying to fit everything in, I used the target-user definition from the Scoping Workshop as a standing filter to decide which information actually served the field rep. Everything else moved into table settings, hidden by default but still one click away. I also used data visualization whenever possible.
Pictured above: area share mockup
Pictured above: secondary placement mockup
Shadowing showed reps do two things in sequence: check what's on the shelf, then decide what to add. The original Excel prototype merged both into one dense table. I split it into two — current assortment, and the full orderable range behind an "add" button — matching the sequence reps actually followed.
Pictured above: current assortment table and orderable assortment table mockups
Automation with human check.
Automation with human check. The shelf recognition model was built by an external partner team in parallel and wasn’t ready to test during this phase. Since I couldn’t validate its accuracy, I designed the interface so a rep could always manually correct what the system detected — recognition speeds up input, but the rep stays the final check.
Visibility potential worked differently — it depended on rules a rep couldn't just read off a shelf, like whether a product sat at eye level or whether the shelf is structured by brand-blocks. I designed a survey flow that walked reps through each visibility rule one at a time, asking them to evaluate it on-site, and calculated the store's visibility potential from their answers.
Pictured above: visibility rules mockup
usability testing
The interface that match the conversation
Because of limited resources, we ran a mix of in-person (in an actual store) and online sessions with participants from the target user group. Testing on-site let us evaluate not just comprehension of the information architecture and task flows, but how real conditions — noise, lighting, time pressure, device handling — affected behavior.
Pictured above: on-site usability testing
Participants navigated the interface without guidance, but hesitated in the visibility section, where the connection between their answers and the calculated potential score wasn’t obvious. Rather than redesigning the interaction, I clarified the information architecture with explanatory headers — resolving the gap without changing the underlying workflow.
Landing page cards were originally ordered by potential impact — biggest opportunity first. Usability testing showed this didn't match how reps actually work: they talk to the store manager in a fixed sequence — first checking whether there's space for new products, then how to reorganize the shelf, and finally what to add or remove. I reordered the cards to follow that sequence instead of the impact ranking, matching the conversation reps were actually having.
Pictured above: landing page changes
reflection
The biggest challenge was turning an Excel prototype’s flat, thousand-row tables into something a tablet could handle, split around the tasks reps actually do.
Designing for an AI feature you can’t test is challenging. The recognition model was built by a separate team and wasn’t ready to validate during this phase, so I couldn’t design based on measured accuracy — I designed based on consequence instead. A rep would use this data in a live negotiation, so the interface had to treat correction as the default expectation, not an edge case for when the model got it wrong. When the AI behind a feature is still unproven, the safer bet is an interface that holds up regardless of how well that model performs.
Next Project
Skill Management System
© 2026 Daria Behrens