• Figma produces an intermediate product that requires translation to become a website or app, and project handoff is baked into the process. The effort that designers pour into Figma is ultimately throw away work, and unnecessary handoffs are not an efficient use of our time.
• Figma outputs also require mental translation to be understood by all parties. While everyone knows how to ‘read’ a website, not everyone can immediately read a mockup or understand the designer’s intent.
• Figma doesn’t directly contribute to the goal of rapidly iterating, testing, and improving increments of code. Figma is more aligned with waterfall processes that front load design.
• Figma is a tool for visual design, and while it does not dictate a polished outcome, it certainly encourages it. Design is a powerful tool of persuasion. A good looking artifact too early in the process gains buy-in too quickly and kills discovery. In this sense, it is anti-iteration.

I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. These companies invest billions of dollars building teams, processes, and tools on top of an immature discipline and an outdated waterfall model that ends up being detrimental to productivity, team happiness, and ultimately, the resulting experiences we bring to life.

The currently popular Figma has a tendency to push development teams into the waterfall direction and for that reason I avoid Figma in web development projects. I prefer to work with the materials at hand, HTML, CSS, and JavaScript (TypeScript). It avoids design handoff and allows to adhere to what lays in the materials.

It’s hard to even articulate this scenario with words and pictures. Sometimes you just have to feel it, use it, to understand the nuances.

This all might seem obvious — but the obvious is not always implemented. Sometimes it’s not as obvious as you might think. And sometimes the obvious is just too much work, so it gets skipped.

The point is: look and feel is hard to design, let alone spec, in a design tool. You need someone who understands what’s possible in the medium (and I mean the medium you’ll deliver the interaction in, not the medium you’ll design it in — those can be different).

You need someone who can do design work with code.

...You need either:

1. a person who understands and can work in both forms, or
2. two people who can work closely together to nail down all these details and make decisions along the way until you have something that feels right, that feels intentional, that feels designed all the way through — not “designed” then “implemented”.

Design Engineer is the latest label we're chucking onto the pile of obfuscatory design titles alongside interface designer, interaction designer, software designer, web designer, product designer, design systems architect, UI/UX designer, UX engineer, UI engineer, and front-of-the-front-end engineer.

...Throwing this extra label onto the pile feels necessary though. Design engineer captures something simple, important, and worth distinguishing: a person who sits squarely at the intersection of design and engineering, and works to bridge the gap between them.

The only difference between web design in 2004 and 2024 is that websites are now painted in Figma instead of Photoshop.