Product Discovery: What-If Scenarios for Smarter Decisions in Digital Twin

Story – The Challenge

You’re working on the digital twin product, where decisions rely on real-time data , but users often ask, “What happens if we change this?”

That’s when you realized the system needed to support what-if thinking, not just live visualization. During discovery sessions with process engineers, I noticed a recurring question:

“What if we change this variable — temperature, flow rate, or model input — what happens next?”

That question inspired a new exploration into what-if scenario design, where users could test different assumptions and immediately see results. The goal wasn’t visual immersion this time — it was decision confidence.

SIM 4200 Amine System – TSC Simulation

In most digital twin systems, we visualize the present vs. current states, live sensor data, and historical trends. But real-world decision-making is rarely about “what is”; it’s about “what could be.” During product discovery for Twin View, I explored how what-if scenarios could help users test assumptions, simulate consequences, and make smarter, data-driven decisions .

The Discovery Phase — Finding the real problem

In early interviews and workflow observations, we learned that engineers were:

• Manually cross-checking results from different tools to compare baselines.

• Re-running simulations outside Twin View, then importing results back in.

• Spending too much time figuring out whether the baseline data was even reliable.

Insight: Users didn’t need more visualization — they needed a safer space to think through decisions.

We mapped these findings in a user flow, connecting every step of the decision process: discover → observe → create → explore → compare → finalize.

This flow revealed multiple friction points, especially around baseline collection and variable comparison.

Defining What-If Scenarios

Clarify the concept for readers:

A What-If Scenario allows users to alter a parameter — such as temperature, production rate, or maintenance schedule — and immediately see projected outcomes.

Explain the design framing:

• Treat scenarios as temporary, non-destructive layers.

• Each scenario can be saved, compared, or shared.

• Encourage experimentation within safe boundaries.

Goal: Enable users to ask “what if?” and instantly see the answer — all inside the Twin View experience.

Use cases

Our core challenge:

Create a unified, intuitive workflow for what-if assessments, without fragmenting user tasks or overwhelming them with options.

So we started from first principles:

1. One entry point: All scenario creation — baseline, what-if, or assessment — starts from a single menu.
2. Step-by-step flow: Users move through a logical sequence — decide → collect → assess → compare.
3. Clarity of states: The interface always answers “Where am I?” and “What happens next?”

Goal: To reduce cognitive load and support fast, reliable decision-making in a complex industrial environment.

In the early whiteboards and flow charts (shown above), we collaborated with product owners, domain experts, and developers to visualize how scenario building would actually happen.

The flow evolved into a clean structure:

1. Discover: Find the right unit diagram and data.
2. Observe: Check real-time or historical data to confirm baseline readiness.
3. Create: Build or select a baseline; define the what-if scenario.
4. Explore: Run simulation results, compare outcomes.
5. Decide: Review tables and charts to make final decisions.

This systematic mapping helped us balance data precision with interaction simplicity — so the tool could serve both expert engineers and casual users.

Testing Insight

Early feedback surfaced several key insights:

• Users valued consistency over flexibility. Too many branching options led to confusion.

• Baseline comparison was more critical than scenario creation — users needed trust before exploration.

• A clear progress indicator made complex flows feel more predictable.

We iterated quickly, collapsing redundant menus and reworking button logic to follow user reasoning instead of technical structure.

Because we engaged users early and involved them in every step of the design process — from flow mapping to prototype testing — the final solution not only matched their mental model but also their expectations.

Result: The feature successfully passed User Acceptance Testing (UAT) with a 98% satisfaction rate, and the user adoption chart below validates that co-designing with users leads to clarity, confidence, and adoption.