| Role | Product Designer |
| Team | Me, 1 PM, Design Manager, Engineering |
[IMAGE: Hero shot of the campaign dashboard or campaign management screen]
In a NutshellSpresso helps retailers run pricing experiments by comparing optimized pricing against a control group. Originally, the system was built around individual products. Even when retailers ran coordinated experiments, each product had to be configured separately and linked manually through a Campaign ID. As the product moved toward beta, it became clear this model didn’t scale. Retailers needed to think in terms of campaigns as the primary unit of work, not individual product configurations.
I led the redesign to shift the system from a product-first model to a campaign-first model—where shared experiment settings are defined once and inherited across products, with controlled flexibility at the product level.
Context
Spresso’s users are retailers managing large, complex product catalogs and running pricing experiments across multiple SKUs.
In the original experience, setup started at the product level. Each product had to be individually configured with settings like: profit weight, min/max price, test dates, exclusion percentage, status and Campaign ID.
While Campaign ID suggested grouping, it wasn’t a real system object. There was no way to create, manage, or view campaigns holistically. This meant even coordinated experiments were effectively fragmented across multiple product-level configurations.
As we prepared for beta, Product defined a key requirement: retailers needed a true campaign-level structure to manage experiments more efficiently.
My role was to translate this into a scalable product model and end-to-end workflow in collaboration with Product and Engineering.
Design
Decision 1: Moving from product-first to campaign-first
The core shift was redefining the system hierarchy.
Previously:
Product → Campaign ID (attribute)
This created fragmentation and made it difficult to reason about experiments at scale.
In the new model:
Campaign → Products → Product configuration
Campaigns became the primary object. Retailers now start by defining a campaign—its name, dates, exclusion percentage, and status—creating a shared foundation for all associated products.
Once created, the campaign acts as a workspace where retailers can: view all associated products, manage shared settings and add/remove products.
This change aligned the product with how retailers actually think about pricing experiments: as coordinated initiatives, not isolated configurations.
Decision 2: Preserving flexibility through intelligent defaults
A key challenge was ensuring the new structure didn’t reduce control for edge cases.
Instead of enforcing strict standardization, I designed campaign settings as inheritable defaults.
When adding a product to a campaign:
- Campaign-level settings (e.g. dates, exclusion %) are prefilled
- Users can accept or override them per product
- Product-level settings (e.g. min/max price, profit weight) remain fully configurable.
This same model extends to bulk workflows. In CSV uploads, SKUs can inherit campaign defaults by default, while additional columns allow targeted overrides when needed.
This approach balanced consistency at scale with flexibility for exceptions, which is critical in enterprise retail environments.
What changed
| Before | After |
|---|---|
| Price optimization started at product level | Campaign is the primary entry point |
| Campaign ID manually assigned per product | Campaigns are first-class objects |
| Settings repeated across products | Shared defaults applied at campaign level |
| Products managed in isolation | Products managed within a campaign workspace |
| Bulk setup required repetition | CSV supports inheritance + overrides |
Impact
The redesigned experience shipped as part of the beta release, covering campaign creation, product association, and management workflows end-to-end.
While post-launch metrics were not available within the project timeline, the most significant outcome was structural: the system successfully transitioned from a fragmented product-level model to a unified campaign-based architecture.
This established the foundation for how pricing experiments are now organized within Spresso.
Next Steps
If I continued this work, I would focus on validating how the campaign model performs in real usage at scale.
Key questions:
- Where users spend the most time during campaign setup?
- How often product-level overrides are used vs campaign defaults?
- Whether campaign structure improves manageability for large catalogs
These insights would help refine the balance between standardization and flexibility, and identify opportunities to streamline bulk campaign workflows further.