Curious by nature. Practical by experience.

I’ve spent more than thirty years at the intersection of design, technology, business, and people. The titles have changed. The questions that interest me haven't changed nearly as much.

I started in the early days of the commercial internet. At AOL in 1993, there wasn't a playbook for designing the experiences that would introduce millions of people to an unfamiliar digital world. Much of the work involved figuring out what people needed, what the technology could do, and how to make the two meet in a way that felt approachable.

That experience taught me to be comfortable with uncertainty. It also taught me that design is rarely just about the thing on the screen. It's about helping people understand something, make a decision, or do something they couldn't do before.

Different roles. A common thread.

Since then I've worked with agencies, founders, startups, and established product organizations. I've been the person designing the experience, the person writing code, the person helping a client untangle a problem, and the person responsible for building and leading a team. I enjoy the different perspectives those roles provide. They also make it difficult for me to believe there is only one right way to approach the work.

At Sqord, I helped build a company around the idea of encouraging kids to be more active through technology. At Relias, I grew the UX organization from two people to fourteen, with an emphasis on building a practice that could help product teams make better decisions, not simply produce more designs. I've also worked with founders through Techstars, where the right question at the right moment can be more useful than a polished answer.

Leading people has reinforced something I learned long before I had a leadership title: stakeholders are usually right from where they stand. Their requests make sense in the context of what they know, what they are responsible for, and what they are trying to accomplish. My job is often to help everyone see more of that context, so the team can make a better decision together.

Still curious. Still building.

When AI began reshaping the conversation about how products are built and how people use them, I wanted to do more than talk about the implications. I decided to spend some time exploring how it could deliver genuinely useful customer value.

So I dusted off my PHP coding skills, rolled up my sleeves, and began building SpotTake: a product that starts with a business's website and gathers public information from across the web to create a more usable picture of that business. The exercise has taken me through product strategy, UX, architecture, prompts, data, APIs, debugging, pricing, and all the other details that turn an idea into something real. It has also reminded me how much I enjoy making things myself.

I'm interested in AI, but I'm not interested in adopting technology for its own sake. The useful question is the same one it's always been: what problem are we trying to solve, for whom, and why is this a better way?

Really good reasons why.

I tend to challenge assumptions, including my own. Not because I enjoy disagreement, but because the first answer is not always the most useful one. I want to know the reasons behind a decision, the constraints behind a request, and the opportunities we might miss by treating familiar methods as rules.

I've come to think of my purpose as facilitating understanding. Between customers and teams. Between a business problem and a product opportunity. Between the people who need something and the people trying to build it. When understanding improves, the work tends to improve with it.

I value curiosity, candor, good humor, and practical progress. I care about the quality of the result, but also about the people who have to live with it and the team that has to get it done. After all these years, I still find the work fascinating—and there's plenty left to learn.

Read more about my work and approach