I love building for the web.

The fact that a single set of standards — HTML, CSS, and JavaScript — has been refined over decades to grow impressively more inclusive, to support so many new contexts, all while being entirely backwards compatible, is remarkable. A feature can take endless forms when it reaches the end user, and trying to work with that unpredictability, along the grain, is what I like about my work.

This perspective is something I've grown into over time. Early in my career, I was more interested in ambitious prototypes and funky experiments (“look what I made!”) but these days I prefer using the platform as it was designed, leveraging its strengths. There’s often a straightforward, well-supported way to solve a problem, and I enjoy finding it. It rewards curiosity, precision, and care.

Allowing that curiosity to take the lead, I’ve spent the last decade working at the intersection of design and engineering. To make something resilient, accessible, and fast, you have to think in systems and care about details. And to shape those systems meaningfully, you have to understand users, flows, and interface patterns.

My official titles have leaned towards engineering, but much of my day-to-day work has lived near the edge of product design. At Fora Health, working with vulnerable user groups taught me to notice the emotional impact of my design choices. Designing in problem spaces like clinical depression and dementia, I learned firsthand how even a single misplaced word can have a dramatic effect on how someone feels walking away from an interaction — a lesson in empathy that I've found applicable in every design problem I've faced since.

At Griffin, I led the design and development of a design system powering complex banking apps, marketing sites and internal tools. But in parallel, I continued designing on a higher level for product areas like 2FA, billing and payment operations. I was constantly zooming in and back out, across the pace layers of process, from the outer orbits of innovation to the quality of individual interactions at the core.

Changing contexts like this daily helped shape my philosophy towards design engineering as a discipline. Providing teams with a shared UI language is only the baseline. At a higher level, I've come to see it as firmly rooted in empowerment and enablement — lowering the barrier to quality for everyone involved in building the product, through education, inclusion, and making the right thing the easiest thing to do.

Design systems are one tool — a robust UI library will scale quality. But alongside that, accurate developer documentation will foster adoption, higher-level design guidelines will create trust, working with product designers and PMs spurs innovation, and fixing papercuts will demonstrate care, while setting the bar high. As one founder explained his vision to me, it's as much about guiding designers towards excellent code as it is about guiding other engineers towards UI excellence — and there is so much more to that than design system ownership.

In practice, this kind of work can take many forms. It could mean maintaining a record of design decisions. Sometimes it's providing an alternative declarative API in an otherwise compound component¹. Or formatting design guidelines as flowcharts to better support complex decision-making. Adding automated accessibility checks to the testing suite. Publicly celebrating papercuts fixed. Refining the build pipeline to better support theming. Other times it's pairing with other engineers or joining RFC discussions to keep design infrastructure grounded in the realities of how teams actually work day to day. And calling it infrastructure matters — it's not the layer on top, it's what gets built with.

This kind of glue work helps make quality the default outcome in teams without enough design-focused engineers to go around. And for a solo UI engineer in a mostly backend-leaning team — as I've found myself in many past roles — the need for this connective tissue ends up shaping much of the work.

But I still get enormous pleasure from the craft itself, and I’ve missed working closely with likeminded engineers who enjoy refining the details that make a UI feel solid. I've recently been going through a preview of Rauno Freiberg's upcoming Devouring Details interaction design course, and it's been a welcome reminder of how much joy there is in chasing quality at the level of individual interactions² — not just for the polish, but for the confidence this instils that the same quality is also present in the parts of the product that the user can't see.

Paco Coursey captures it perfectly:

Animate those icons. Brand that scrollbar. Polish that :active state. Load a single typeface glyph to render the world’s best ampersand. Make it fast. Make it accessible. Add keyboard shortcuts. Add tooltips. Animate the transition between two open tooltips. Manually measure text and avoid line wrapping widows. Design favicons that reflect app state. Convert internal URLs to rich previews. […] Design a whole new stylesheet for printing. Design a whole new page for mobile. Dynamically generate video thumbnails and use them in a custom video player. Optimize your re-renders.

It’s the sort of work where aesthetics, accessibility, motion, and psychology meet frontend performance and CSS craft, and where I slip into flow most easily.

---

Working with thoughtful, principled engineers and talented designers over the years, I've picked up enough from both to navigate the intersection, acting as glue when needed. The pull between disciplines often feels like a tension — a choice on which edge of the split I want to fall on. But the balancing act itself is also what keeps me attentive, and the work rewarding.

I'm taking this mindset to Plain, and I'm curious to see how the lines continue shifting in a new context — especially now, as AI is redefining in real time how we design and build for the web. Methods change, but the results will depend on the same core principles. There's plenty still to work out!