01 · Kroger Rush
A 30-minute promise, and about 1,000 items to keep it
Kroger Rush was quick commerce: delivery in 30 minutes or less from a deliberately constrained assortment. Roughly 1,000 UPCs, against the 30,000 or so a typical grocery ordering platform carries.
That constraint changes the design problem rather than shrinking it. A weekly grocery order is a search-and-list task. People arrive knowing what they want, and the interface's job is mostly to stay out of the way. A thousand items with a thirty-minute promise is a browse task. There is not enough assortment for search to carry the experience, and the whole proposition falls apart if choosing takes longer than the delivery.
02 · The pivot
It launched for office workers and found families in lockdown
Rush launched around a specific bet: hot bar items and last-minute dinner for corporate workers in the surrounding area. Then COVID lockdowns emptied those offices.
The audience did not vanish so much as change. Demand moved to meal kits and baby needs, from people at home who needed a few things quickly. The test pivoted to match.
The constraint that made Rush look limited is the same constraint that let it change its mind.
A thousand-item catalog is a liability when you are trying to be comprehensive and an asset when the market moves underneath you. Categories, merchandising and the browse structure could be re-pointed at a different shopper without rebuilding the product. Being quick to pivot was the real outcome here, more than any screen on this page.
03 · The team
Managing QA, two junior designers, and developers on the other side of the world
Alongside the design work I managed QA and two junior designers, and partnered with an offshore development team to get the products shipped.
The interesting part of that partnership was not process. It was context. US grocery shopping carries assumptions that are not universal, and some concepts simply did not translate on a screen. Handing over a comp and expecting it to land did not work.
So a real part of the job became walking developers through the reasoning behind a design rather than the design itself. Once the why was clear, the implementation questions largely answered themselves.
