This walkthrough follows a hypothetical team through the DesigningROI framework. It shows how the evidence assessment determines which phase to investigate first — and why the answer depends on what you already know, not just how the work started.
The team has a revenue target from leadership but no prescribed solution. In most frameworks, this would immediately route to problem-definition work. DesigningROI does not assume that. It asks what evidence already exists.
The value argument
Every product investment rests on a chain of claims. The team maps what they already know to each element.
Two parts of the argument have evidence behind them. Two do not. The tool will walk the connections in order to find where to start.
Diagnostic
The tool walks each connection in dependency order, asking whether evidence supports it.
The need is supported and the hypothesis is testable, but the expected changes have not been measured. The tool routes directly to Observe.
Route
A business goal routed to Observe, not Frame. The team already understands the problem and built a solution. What they lack is evidence of what happened next.
Phase work: Observe
The Observe phase asks the team to record what actually changed after the solution was introduced.
Create a record of observed changes.
The team instruments the reorder flow, compares customers exposed to the redesign with a comparable cohort, and checks for promotions, seasonality, and other changes that could explain the numbers. They find: reorder completion rate increased 18%, support tickets about reordering dropped 40%, and repeat-purchase revenue increased 2% — but overall sales growth reached only 3%, well below the 10% target.
Decision
With observed results in hand, the team reaches the phase decision.
Is the record complete enough to interpret?
The team has evidence now: reorder behavior improved, but the evidence suggests that the redesign explains only a small portion of the desired sales growth. They choose “Interpret the evidence” to assess what the data actually supports. The framework advances to the Interpret phase.
Phase work: Interpret
The Interpret phase asks what the observed changes mean for the investment.
Create an evidence-based value assessment.
The team assesses what they learned. Reorder completion improved 18%, support tickets dropped 40%, and repeat-purchase revenue rose 2%. The results are consistent with the redesign contributing to repeat-purchase revenue, but the overall sales growth of 3% falls far short of the 10% target. The redesign improved reorder conversion, but the evidence does not support treating it as the primary mechanism for a 10% sales increase.
Decision
With the value assessment complete, the team reaches the Interpret phase decision.
What decision does the evidence support?
The team selects “Make the decision.” The evidence is sufficient: the redesign improved reorder conversion, but it does not explain the full sales target. Continuing to gather evidence or revising the hypothesis would not change this conclusion.
Investment decision
The redesign reduced reorder friction, and repeat-purchase revenue rose 2% among customers exposed to it. But the evidence does not show that this mechanism can produce the full 10% sales increase. Continue optimizing the reorder flow as a reorder-conversion initiative, but do not scale it as the primary sales-growth strategy.
The framework produced a specific, evidence-backed conclusion. The diagnostic walked each connection in order: the customer need was supported and the hypothesis was testable, so the tool routed directly to Observe. Observe and Interpret filled the remaining gaps. The investment decision followed from the evidence — not from the starting point, and not from intuition.
In practice
The example above is hypothetical. The same reasoning shaped my work on AI-assisted photo curation for Kodak Alaris. Professional photographers were reviewing thousands of images by hand, and the existing automation gave them no way to correct it. The assumption worth testing was that photographers would hand off decisions to the AI. The evidence pointed the other way. They wanted AI to speed up their own judgment, not replace it. The product became recommendations they could calibrate, override, and reverse, with confidence signals showing how sure the system was. Review time dropped from about 18.5 hours to about 1 hour per project. Read the case study →
james@designingroi.com · © 2026 James Wondrack