Design Engineer & Senior Product Designer

The problem and the outcome, not just the screens.

I like being involved early enough to understand the user problem, the business reason we're solving it, and what success should look like. Then I want to stay close enough to the work to see what actually happens after we ship.

Sometimes that means research and product decisions. Sometimes it's interaction design, systems work, prototyping, analytics, or getting into the frontend. The boundary matters less to me than moving the product forward.

I don't think design decisions exist separately from business decisions.

I like understanding what we're trying to move, whether that's activation, retention, revenue, adoption, or something else, and using that context to make better product decisions.

I'm comfortable talking through priorities, tradeoffs, metrics, and scope with PMs and founders, not just what the interface should look like.

Technical enough to build and ship some products end to end.

My background is in computer science, and I've built products myself from the database and application logic through to the frontend, deployment, analytics, and everything around it.

Most of my day-to-day engineering work is closer to the frontend, using React, Rails, HTML/CSS/JS, and modern web tooling.

I'm still a product designer, not a backend engineer. But working this close to the code means I understand how products actually get built, can prototype beyond static screens, and can work with engineers without treating implementation as a black box.

Yes. The site is small selection rather than a complete archive of everything I've worked on.

Some projects aren't public, and I haven't had the bandwidth to turn every project into a case study.

If you're hiring and want to see work that's closer to your product or problem, I'm happy to walk through additional projects and the decisions behind them.

Small, ambitious product teams where designers are close to the product, engineering, and actual users.

I like having enough ownership to question the problem, not just execute the solution, and working with people who are comfortable iterating quickly when we learn something new.

A lot. I use AI across research, exploration, prototyping, coding, and iteration, while still treating judgment and craft as the important part.

I also spend an unreasonable amount of nights and weekends experimenting with new models, tools, and workflows.

Yes. With the right team and problem.

I work remotely and regularly overlap with EST and CST teams.