Optimising campaigns with reshuffling

Making it less scary to shake up a whole booking plan

Product Designer · Discovery to alpha and MVP · Worked with product, engineering and market users

The short version

Reshuffling lets the teams who plan and run campaigns re-plan everything already booked, across digital and paper inventory, so it all still hits its targets. It’s powerful, but on our legacy platform it was rigid and hard to trust. For the new Direct Sales platform at VIOOH (part of JCDecaux), I redesigned the workflow from the ground up, going from legacy research to a stripped-back alpha, then a fast-following MVP. It was well received at launch, and users complete a reshuffle in less time than on the legacy version.

The problem

Every campaign is booked onto specific frames, which are the screens and posters ads run on. Over time, new bookings, changes and problems like a frame going out of commission mean the plan no longer fits. Reshuffling asks the allocation engine to re-plan a whole set of campaigns at once, so everything still lands as close to target as possible.

The feature already existed on the legacy platform. But the new platform was a 0-1 build, and copying the old tool across would have carried all its problems with it. The challenge: keep the power people relied on, and make it faster, clearer and more flexible.

Discovery: unpacking the legacy tool

I dug into how people actually used the legacy feature, and what markets had been asking for. A reshuffle can change a lot in one go, which made some users nervous enough to avoid it altogether. The themes that stood out:

• Blunt range control: reshuffles worked in whole campaigns, so campaigns that only partly overlapped the chosen dates ended up locked out.
• Unclear locking: there was effectively one kind of lock, with murky rules over who could override it.
• Limited scoping: users wanted to restrict a reshuffle to what mattered, like resolving one out-of-commission frame, and leave everything else untouched.
• Hard to see the impact: people wanted to know what would change, and how far from target each campaign would land, before committing.
• Speed: it was slow, and volumes were only going to grow.

Ideation and feedback sessions

I ran ideation and feedback sessions with users, product and engineering, partly for the ideas, and partly to check that what I’d learned about the legacy tool matched their day-to-day reality. It also got everyone invested early, which helps when you’re about to ask people to change how they work.

Design exploration and a long-term vision

I explored a range of approaches, and mapped out a long-term vision for reshuffling before narrowing down to what we could build first. It gave us something to design back from, so the first release wouldn’t turn into a dead end.

Four design principles guided the decisions:

1. Repeatable: a consistent flow users can run again and again, and eventually turn into templates for common jobs
2. Flexible: control over the scope and range of a reshuffle, so users can shape it to the job in front of them
3. Transparent: show the impact on every affected campaign before anyone commits
4. Scalable: every new capability should slot into the same foundation, not need a whole new tool

The core flow

The flow starts where the problem shows up. When a campaign isn’t hitting its objectives, a notice in the allocation report points users straight to a reshuffle. From there:

1. Start from the campaign and set the date range, with the existing dates in view before choosing new ones
2. Review the campaigns in play
3. Set filters to narrow what the reshuffle looks at
4. Run the simulation, with a loading screen that explains what’s happening
5. Review the results, with the impact laid out campaign by campaign, current versus new
6. Confirm or decline the reshuffle

One detail I care about: if a user changes the criteria after running a simulation, we flag that the results are out of date and prompt a rerun (with an undo), so nobody commits on stale numbers.

Testing and stripping back

I tested prototypes with users who reshuffle campaigns day to day. [ADD: 2-3 specific things testing changed in the design]

Then delivery got real. The release was split into two phases: an alpha to unblock development and test the core functionality, then a fuller version closer to the original design vision. Sensible for delivery, but it created design debt. My original results view showed a rich picture of what had changed, including how campaigns moved, the logic behind it and frame-level differences, and the data for that wasn’t going to be available in the alpha.

So I went back to the designs and asked what we could show that was accurate, meaningful and trustworthy with the data we had. The alpha (our “MMVP”) shows a simple current versus reshuffled comparison of frames, impressions and price for each campaign, with a clear accept or decline step. I kept the structure, layout and language ready to scale, so the richer detail could slot back in later. The MVP fast-follows with more of it, including a simulation summary (campaigns edited, targets met and missed, objectives met) and the ability to change criteria and rerun.

Scaling the roadmap

Reshuffling is the foundation of a wider set of optimisation tools. I worked with product and engineering to align on how the roadmap would scale, starting with two features:

• Focused Reshuffle: lets users include or exclude inventory by criteria like product format, location and tag. It matters most in markets with long print lead times and strict rules, where an unscoped reshuffle can disturb units that are costly to change.
• Swap: a lighter way to move a booking onto a different frame, built into the same flow and following the same rules.

Because they share one foundation, they’ll feel like parts of a single tool rather than three separate ones.

Launch and feedback

Feedback at launch was well received overall. The main issue was system performance, which the engineering team is now fixing. I’m continuing to work with users to improve the workflow, analysing their feedback as it comes in and feeding it back into the roadmap.

Results

Not bad for a 0-1 product up against a mature legacy tool.

What I took away

• Ship small, design big. The alpha got us real feedback quickly, and the long-term vision meant nothing we built was a dead end. Cutting scope also creates design debt, so I kept the structure, layout and language ready for the richer detail to slot back in.
• Performance is part of the experience. The biggest complaint wasn’t about the design at all, it was speed. Users judge the whole thing, not just the screens.
• Launch is the start. The best improvements will come from staying close to the people using it every day.