Bloomreach Grid Editor

Bloomreach's search engine could rank and personalize thousands of products automatically. But ecommerce teams still needed to intervene. Campaigns change. Inventory moves. New products launch. Business priorities shift. Sometimes the product a merchandiser needs to promote isn't even part of the result set the algorithm would naturally return.

The challenge wasn't replacing automation with manual control. It was building an interface where algorithmic ranking and human merchandising judgment could work together. I led the redesign of the Product Grid Editor, bringing ranking logic, visual merchandising, content placement, and real-time preview into one operational workspace.

The grid became the control surface

The redesign started by changing the relationship between configuration and result. Instead of asking merchandisers to configure logic in one place and inspect its consequences somewhere else, I made the product grid itself the primary workspace — the result set became the thing you edited directly.

Merchandisers could work with the grid the way they thought about the page: boost or bury a product, exclude it, lock it into an intentional position, add a missing product into recall, or apply a product- or attribute-based rule — and see the effect immediately.

One page. Three different systems.

What that replaced was a workflow split across three legacy environments. Ranking Rules was engine-level and largely text-driven — conditional rules like if Brand = X, boost by 1.5 that shaped the whole grid but lived apart from the page itself. Visual Merchandising gave the opposite: you could drag tiles and pin positions, but the global ranking logic wasn't visible beside those moves. And a third, slot-based environment handled banners and inline marketing content as a parallel system — even though shoppers experienced products and content together.

A merchandiser had to hold ranking logic, product placement, and content placement across three interfaces in their head and reconcile them mentally. I wanted the product to behave like the page they were actually building.

Different ways in, one intent

Because a single merchandising model now sat under the grid, different workflows could start differently and still resolve to the same result. You could act on one product card, select products in bulk, drag within the grid, or bring a product in from the supporting panel. The interaction changed; the intent didn't.

Balancing business intent with algorithmic ranking

The hardest problem wasn't drag-and-drop. It was deciding how much control a merchandiser should have over an intelligent system. Some wanted fine-grained control over nearly every product; others preferred to let the algorithm do most of the work and step in only where strategy demanded it. The interface had to serve both.

Position locking became the way to express that balance. A merchandiser could intentionally place or lock specific products while the rest of the grid kept adapting around those choices — preserving a campaign, a launch, or a commercial priority without hand-designing every position on the page.

Sometimes ranking isn't enough

One small feature shows how deep merchandising goes: Add to Recall. Boosting only reorders products already eligible to appear. Picture a merchandiser launching a new promotional product — they might boost it hard, but if the search algorithm doesn't consider it relevant to that query or category, there's nothing to boost. It isn't in the recall set at all.

Add to Recall gives them an explicit way to introduce it. Once the product is in the result set, they can decide how prominently it shows using the rest of the system. That's where the editor moved past rearranging tiles and became a way to express business intent directly against algorithmic search behavior.

Rules needed context, not more complexity

The editor also had to carry the less visual side of merchandising. Rules could run against searches or categories, target different audiences or durations, and use products or attributes as conditions. Rather than flatten all of that into one dense configuration surface, I organized the experience around the context users were already thinking in — start from a query or category, refine who and when it applies to, find the relevant products or attributes, and watch the effect resolve back in the same visual grid.

Real products have to explain conflicting states

A happy-path editor wasn't enough. Rules overlap. Changes arrive from elsewhere in the system. A manually placed product interacts with a global rule. A product added to recall inherits other behavior. Bulk operations run into practical limits. So the design had to communicate not only what the user had done but what other forces were shaping the result — states for conflicts, external changes, recall behavior, and system limits, all readable without leaving the editor.

Designing a system, not a screen

Unifying three legacy environments also meant unifying years of interaction patterns. Product cards, selection states, merchandising actions, rule states, conflict messaging, drag behaviors, filters, and feedback all had to feel like parts of one product. I worked them as a system rather than solving each feature on its own, so the foundation could keep evolving after launch.

That system got built while the features shipped, not before them — established in motion, on a live product, rather than handed down from a finished spec. It's slower and more political than a clean foundation. On a product already in customers' hands, it was the only way it was going to happen.

Shipping was part of the design

The Product Grid Editor wasn't a speculative redesign. It shipped, and it's used by real Bloomreach customers. I stayed the primary designer through implementation — resolving interaction details with engineering, testing edge cases, and adapting the system as production exposed constraints that weren't visible in Figma. The reasoning ran at both ends of the project: early whiteboards where the interaction model first took shape, and weekly testing that kept it honest against how merchandisers actually work.

What I took away

Simplifying complex software doesn't always mean removing complexity. Merchandisers needed sophisticated controls because the decisions they were making were sophisticated. The more useful goal was to make that complexity easier to reason about — to keep the relationships between action, state, system behavior, and outcome clear. When those are legible, a product can stay powerful without making people feel like they're operating the machinery underneath it.