Web Design Engineering

As usual, the designer builds the card component in Figma. Title, image, short description, “Read more” link at the bottom. The title is also linked.

In the design file, this looks fine – two visual elements that both take you to the same place. But in the browser, a screen reader user navigating by links hears every card twice: once for the heading link, once for "Read more." Now multiply that by a dozen cards on the page.

So the team decides that the whole card should be clickable and wraps everything in a single <a> tag. But now the screen reader reads the entire card contents as one long, uninterrupted link label: title, description, “Read more,” all of it. Or worse: the developer leaves the inner links in place, creating a link inside a link. Invalid HTML.

There’s a well-known pattern for building this type of card component – a single link on the heading, expanded to cover the whole card surface with a CSS pseudo-element. The pattern isn’t obscure. But the designer doesn’t think to spec it, and the developer builds what they’re given. It falls into the space neither side owns, the space where design and engineering overlap. That’s where I work.

Why the Design-Engineering Gap Exists #

Designers and engineers see the same product through different lenses. A designer sees composition, hierarchy, intention – what a user needs to feel at a particular moment. An engineer sees structure, state, constraints – what happens when the data doesn’t arrive or the content is three times longer than the placeholder.

Both lenses are important. But the sequential process most teams rely on – design finishes, engineering begins, a specification is the bridge – takes that difference and makes it destructive. No shared material. No feedback loops. Design intention disappears into the space between the two disciplines, one quiet decision at a time.

The product that ships technically works. But it feels like it was assembled from parts that weren’t quite designed to fit together.

Working in the Material #

I’m a web design engineer. Some people call this a designer who codes or a frontend design consultant. I think of it differently: it’s not about adding one skill to the other. A web design engineer is someone who holds both lenses at once – for whom design and engineering are not sequential phases but a single, continuous act of judgment.

I work directly in the browser – in HTML, CSS, and JavaScript – as a design medium. The browser isn’t where my designs end up. It’s often where they begin. When I design a layout, I’m already thinking about how the CSS behaves when the viewport narrows. When I write CSS, I’m making design decisions in real time, adjusting spacing and proportion and timing based on what the browser is actually showing me. These aren’t two separate activities I switch between. They’re the same activity, seen from two angles simultaneously.

What I produce isn’t a beautiful picture of a website that needs to be translated into the real thing. It is the real thing.

What Changes #

When someone on the team works fluently in both design and code, the work itself changes.

Design decisions get validated in the browser in hours, not after two sprints of development. There’s no need to spec every state and breakpoint across dozens of static screens, because the person making the decisions is downstream of their own designs.

Your design system starts working in code the way it looks in Figma – because the same person can audit both sides, close the gaps, and build the common language that makes the system hold together. The translation from Figma to CSS stops losing detail at every step.

Accessibility stops being a last-minute audit finding. When you prototype in the browser, you prototype with real keyboard navigation, real focus management, real semantic structure. That card component gets designed and built as one decision, not two.

And because you’re working directly in the medium, you discover things a design tool would never show you. A CSS feature that makes a layout possible nobody had imagined. A scroll interaction that turns a functional page into something that genuinely surprises. The browser doesn’t only constrain your ideas. It generates new ones.

The result is work that feels designed all the way through – not “designed” then “implemented.”

Nearly 20 Years of Experience #

I’ve been working this way long before “design engineer” became a job title people write blog posts about.

I’ve worked with teams at Bosch, SAP, Deutsche Bahn, Siemens Healthineers, and many more. I’ve run over 30 hands-on workshops for Adobe, teaching designers and developers how to prototype and bridge the gap between design and development. I teach Interface Prototyping at Muthesius Academy of Fine Arts and Design since 2012. And I’ve spoken about this work at conferences like beyond tellerrand, CSS Day, and Smashing Conference, because I believe the conversation about how design and engineering relate to each other is one of the most important conversations our industry is having.

I also love to write about the Web. About CSS, design, and building things with care. My newsletter, Own Your Web, reaches over 2,400 readers who care about the craft of making things for the Web.

Let’s Talk #

I work at the intersection of design and engineering with product teams ranging from early-stage startups to established SaaS and industrial companies, turning complex requirements into resilient, user-centered interfaces, websites, and design systems.

If you’re looking for someone who does both design and code – not as two separate skills, but as one practice – I’d like to help.