Every product starts with guesses. The work is knowing which ones matter.

I help teams test the riskiest assumptions before they become costly commitments, translate what we learn into design decisions, and build the evidence for what’s worth building.

Most teams execute well. The harder part is agreeing early on what needs to improve for customers, and how that improvement is expected to help the business. That’s where design has the most leverage, and where I focus my work. It has three parts.

1Uncover the current challenge

I start by observing how people use the product today: their unmet needs, the steps that don’t need to be there, where it conflicts with how they prefer to work, and the workarounds they’ve built.

Often, that reveals the interface problem as a symptom of how the product works, and of the user experience that creates. The pattern runs through my work:

• Scientific software: a platform organized around instruments, reoriented around the workflows researchers actually run.
• Scientific workflow: a fragmented legacy platform, reorganized into one familiar input–compute–output flow.
• AI image curation: automation photographers didn’t trust, reframed as recommendations they could calibrate, override, and reverse.
• Fire and life safety: a task-centered model, shifted to the point-centered model that usability testing showed operators actually use.

This work usually sits at the seam between research, product, and engineering, translating what one discipline learns into what the others can act on. That seam is where the most consequential assumptions tend to live, and where they are least likely to be questioned.

2Design the path forward

A better solution only matters if it holds up in the product. I stay in the design work, testing and iterating with users until the direction holds up. I also define the interaction models, information architecture, and systems that let teams build it consistently.

That has meant defining the orchestration layer that turned 30+ computer-vision algorithms into a single calibration step, redesigning a life-safety system’s architecture from 128 destinations to 66, and establishing an enterprise design system that engineering leads estimated reduced implementation effort by about 20%.

Design is also how I test direction early. A prototype is a far cheaper place to be wrong than a codebase, and what people do with it is the evidence that tells us whether the direction holds.

3Test the case for the investment

Unexamined assumptions become requirements. Requirements become architecture. Eventually, what began as a reasonable assumption is expensive to question.

Testing the case is translation work: turning what we learn about how people work into the language of business decisions—from the human need, to the proposed solution, to the change in user behavior, to the business result. That lets teams decide what is worth building, revising, or stopping, not only how to build it better.

DesigningROI grew out of these projects. It is the framework I use to test the reasoning behind a product investment, making it visible and testable before assumptions harden into commitments.

Explore DesigningROI

I’ve developed this perspective over more than two decades of designing and launching 100+ digital products and web properties, in scientific software, life-safety systems, healthcare workflows, and AI-assisted tools—usually bridging disciplines rather than working inside any one of them. I’ve spent at least half of that time in consulting, working across organizations and industries to help teams understand complex problems, establish direction, and bring products to market.

I’m open to senior design leadership roles and select consulting engagements.

View selected work