👈 Home

Worry-Free Transactions: No News is Good News

Reframed a stakeholder request at OneSpan to unlock a more valuable problem — then built the business case and blueprint before a single screen was designed.

Worry-Free Transactions notification and inbox

Impact

~$140K

Estimated cost saved per customer by automating manual transaction monitoring.

~40%

Expected reduction in failed transactions by alerting users before expiration.

~90%

Expected resolution rate for at-risk transactions within 12 hours.

Figures are directional estimates used to build the business case — the feature was deprioritized before shipping.

The Request Behind the Request

A stakeholder asked for better transaction logs. More visibility into what was happening with documents in flight.

Before designing anything, I pushed on the underlying need. What I found: users weren't asking for logs because they wanted to read logs. They were manually monitoring transactions to catch problems before they expired — babysitting documents because the product gave them no other way to know when to intervene.

The real request wasn't "more logs." It was "tell me when something needs my attention."

That reframe changed everything about the solution.

Working Backwards Before Building Forward

Rather than jumping to screens, I wrote a mock feature announcement first — articulating the problem, the solution shape, and the expected outcome in plain language before any design work began.

This approach, borrowed from Amazon's Working Backwards method, served two purposes: it forced clarity on what we were actually trying to solve, and it created an artifact that could survive shifting priorities — a durable blueprint that didn't require design ramp-up time to reactivate.

Mock feature announcement for Worry-Free Transactions — Worry-Free Transactions notification and inbox

The Business Case

To justify prioritization, I built a directional estimate of the opportunity:

~$140K estimated cost saved per customer by automating manual transaction monitoring ~40% expected reduction in failed transactions by alerting users before expiration ~90% expected resolution rate for at-risk transactions within 12 hours.

These were back-of-napkin figures, not tracked outcomes — but directional estimates are often what it takes to get a feature on the roadmap. The goal was to make the opportunity cost of not building it legible to stakeholders.

The Solution Shape

A predictive risk-scoring system that identifies at-risk transactions, surfaces them in a prioritized inbox, and notifies users via email before documents expire — giving them a window to intervene, snooze, or resolve before a transaction fails.

Email notification for \“at risk\” transactions — Email notification for “at risk” transactions

Transactions inbox sorted to prioritize \“at risk\” transactions — Transactions inbox sorted to prioritize “at risk” transactions

\“Snooze\” options via transactions inbox — “Snooze” options via transactions inbox

When Priorities Shift

The feature was deprioritized before it shipped — resources redirected to escalating customer requests.

This is where the Working Backwards artifact earned its keep. The mock announcement and high-fidelity specs — built on a mature design system — gave Product Marketing a head start and engineering a ready-to-go blueprint. The work didn't die. It's waiting.

The lesson: you can't always control the roadmap. You can control how much of your thinking survives the next planning cycle.

👈 Home

Let's connect

I'm always up for a chat about design, working together, and .