I look for the structure behind the surface.

How a product is organized, where that structure conflicts with the way people work, and what it could become instead.

That instinct started early. As a kid, I was more interested in taking apart the official Lego design to see what else the same pieces could become. I did something similar with bikes—repairing them, replacing components, and continually adjusting how they worked. Today, I apply that same curiosity to complex products: understanding how the parts fit together, making the system visible, and helping teams decide what should be preserved, reconsidered, or rebuilt.

I’ve done that across scientific software, life-safety systems, healthcare workflows, and AI-assisted tools. The domains differ, but the underlying challenge is often the same: the product reflects one model of the work, while the people using it follow another.

Years later, redesigning a fire alarm control panel, I learned the existing system the way an operator would. The menu paths followed no logic I could find. Acknowledging one alarm took steps that made no sense unless memorized.

The client had no map of how the system was organized, so I built one by tracing every menu, duplicate function, and dead end. That document is what finally moved people. Making the structure visible helped them see the problem.

On another project, I was looking over a researcher’s shoulder at a spreadsheet he’d built to track results. The table was simple and organized very differently from how the data appeared in the proprietary software I was redesigning. I asked where the format came from. He mentioned, almost in passing, that it matched how compositions are documented in a patent filing. Every researcher we spoke with recognized the format, even though they hadn’t independently organized their data that way. We adopted that familiar structure in the interface. I wouldn’t have found that in a requirements document. I found it by being curious about a spreadsheet.

Later, I was asked to design screens for a complex platform that had grown for almost two decades into the primary tool a large group of specialists depended on. I worked on the screens, but I also mapped the larger system. That created tension: the team wanted a more usable interface, while I believed the deeper problem was how the product was organized.

At first, I thought we disagreed about scope. The issue was simpler: we were using “design” to mean two different things. They meant improving a product that had already been defined. I meant helping decide which problems the product should solve. That distinction is close to the center of how I still work: less about executing a solution well, and more about making sure it’s solving the right problem in the first place.

Deciding which problem a product should solve means working with researchers to understand how people actually work, with engineers to understand what change would require, and with the people responsible for the business outcome to understand what the organization is trying to protect or improve. I’ve learned to move across those conversations without treating any one of them as the real one and the others as inputs to it. The direction that survives usually comes from holding all of them at once, not from a single function handing off to the next.

The more recent version of that same question shows up in AI-assisted work. A recommendation engine or a scoring model is still a kind of structure, one that’s easy to treat as neutral just because it’s automated. The same instinct applies: understand what it’s actually doing before deciding how much to trust it. The system I helped design made recommendations understandable, adjustable, and reversible, so the expert remained responsible for the judgment, not just the interface.

These experiences shaped how I work. I pay attention to visible friction without assuming I know its source. I look for how things are actually organized, not just how they appear. I ask how people work before I propose how they should.

The goal is to help teams develop a shared picture of the problem before committing to a solution.

I’m most interested in complex product work where design can help shape direction, not only execute it. That might mean becoming part of a team or partnering with one through a critical period of definition, modernization, or change.