An analytical layer that makes a pricing simulation legible

Where running a simulation ends and reading it begins

Asper’s Pricing Simulator lets consumer-goods teams model a pricing change before going live. Scenario Analytics is the layer on top of a finished simulation, built for the Key Account Manager tuning prices to a target and the Category Manager weighing market impact. Until it existed, the only way to study a result was Scenario Comparison, which lines up whole scenarios but never opens one.

A pricing move ripples across margin, volume, and the full manufacturer-to-retailer chain, so a simulation is only useful if its result can be read. Otherwise the decision falls back to instinct, or hours in Excel.

I led the design end to end, with a junior designer assisting. The economic models came from the product team as spreadsheet logic; the design work was making them legible.

Running the simulation was the job. Reading the result was the part the tool never helped with.

Run a scenario, and to understand it you had two options. Stare at raw numbers, or export to Excel and rebuild the analysis by hand.

So the people who ran a simulation to decide faster ended up back in a spreadsheet.

Scenario Comparison, the one tool that existed, only lined up whole scenarios against each other. It could never open one and explain it.

No way to interrogate a single scenario after it ran.

Depth the comparison view was never built to give

Comparison could tell you which scenario won. It couldn’t tell you why. The solution was to give a single scenario its own space to be taken apart, without overloading the comparison view that already existed. Three decisions shaped it.

Four lenses, four questions. Rather than one dense analytics screen, each question a user might ask got its own lens. Change Analytics for what moved on a chosen KPI. Category Movement for volume and sales impact. Region Analytics for where it landed geographically. Channel analytics for how profit shifted across the chain.

A read before the deep dive. A user shouldn’t have to open a lens to know how a scenario is tracking. So the screen opens with a strip of small KPI cards, an at-a-glance pulse the moment the scenario loads. Users add or remove cards to match what they watch.

Making a handed-over model legible. The product team’s channel P&L arrived as one long Excel table, every tier’s KPIs stacked in a single flat list. It was too long to read, and the tier a KPI belonged to got lost. The redesign gave it structure: a nested tree grouping each KPI under its tier, with color-coded rows separating Manufacturer, Distributor, and Retailer.

Reflection

The nested tier table was the right call, but it made the hardest tradeoff of the project visible: density versus simplicity. Nesting made the channel P&L legible, but legibility came by hiding detail behind expansion. Cleaner to scan, slower to see everything at once. On a model this dense, that tension never fully resolves, you just decide which side to err on.

Two things I would revisit. The KPI cards start blank on first use. That was a deliberate call, preferences vary too much by user to fix a default, so the system learns and saves instead. Defensible, but it means every user’s first run is an empty screen. A better version would open with a sensible starting state instead of a blank one.

And Region Analytics was, honestly, a lens we had the data for more than one users were asking for. It earned its place less than the other three.

What holds up: it shipped, and it is still how a scenario gets analysed at the client today. The patterns underneath it, the KPI card strip, the nested tier table, the lens tabs, went on to be reused across the RGM suite. The clearest sign the information design worked is that it outlived this one feature.