I look for the structure behind the surface.

I’ve always enjoyed figuring out how things are put together—and what becomes possible when you take them apart and put them back together differently.

The Lego sets I had as a kid used simple, generic pieces. I’d finish the instructions fast, then take the model apart and build something else. Nothing was wrong with what I’d built. I just wanted to see what else those pieces could become.

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—walking 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 over 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.

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. That’s where most of the real work happens.