Yes, Designers Should Code

Design engineers are, put simply, designers who code — specialists who are strong in both the creative and technical sides of making digital products and experiences.

In the olden days of the web, these folks were often just called "web designers," and they'd move freely back and forth between slicing image maps and other assets in Photoshop or Fireworks, and integrating those elements into production code.

Over the last two decades, for (mostly) good reasons, the practice of web
design has expanded to include visual design specialists who work
primarily in tools like Figma, handing off design to web developers or
frontend engineers to be adapted into code.

However, websites are software, not printed material like a brochure. When
you split up design and development, and web designers just deliver static
mockups, a lot of important details are left for developers to figure out.
How do designs adapt to different screen sizes? How should a rich,
animated experience gracefully degrade for users who need reduced motion?
Won't someone please think about dark mode?!

You don’t need handoffs if it’s all the same person!

The best solution to avoiding awkward handoffs, we feel, is to avoid
handoffs — period.

By putting design engineers in the driver's seat of our projects, we ensure we deliver great systems that work for users under any conditions, not just the idealized world imagined in mockups.

Removing the handoff isn't just about avoiding lost details — it compresses the loop between intent and execution. A design engineer building an interaction in code can feel whether it's right in a way no static mockup can convey. Responsiveness, accessibility, motion, edge cases: those decisions don't get deferred to a translation step, they get made in the medium where they actually live.

Getting into code sooner also helps to get and incorporate client feedback that otherwise wouldn’t come up until late in the process. I’ve worked on so many projects over the years where clients or stakeholders had approved static mockups, understandably either not thinking about how interactions should play out or making a bunch of unstated assumptions. Later, when demoing the actual code, they’d see a bunch of changes that could have been made earlier.

Design engineering is the best approach for the AI era

AI has made generating a plausible component or layout nearly free, which pushes the real work somewhere new: knowing what to ask for, recognizing when the output is right, and shaping it into something coherent.

This isn’t to say visual design is dead — oftentimes, just as with a human stakeholder, the best way to clearly explain the intended look and feel of an element to an AI agent is to make a quick sketch or wireframe.

Whereas many designers used to be able to just stop there, now the jump from idea to production code is almost instantaneous. To be effective, digital designers need to think several chess moves ahead of AI, looking not just narrowly at art direction but broadly at how all the pieces are meant to cohere into a system.

Design engineers can direct AI tools with intent grounded in both craft and technical reality, and evaluate the results from both angles at once. A prompt without taste produces slop; taste without the ability to read the code produces wishful thinking. Holding both is what lets you actually ship.

A brief aside about “craft” and “taste”

These words have been thrown around a lot in the last year or two, attempting to describe the ineffable quality that humans still bring to the table in a world where everything else can be automated.

Naz Hamid and Dan Mall have both written smart things about this recently, both taking a position that these words craft and taste are being used euphemistically to refer to something really simple that AI fans seem really uncomfortable with: humans having opinions.

Naz quotes a speaker at a recent design conference who said, “the LLMs are getting very good at craft.” This is true, inasmuch as AI tools like Lovable or Claude Code can now put together a web page that looks nice, consistent, almost professionally made. It used to be that you could separate “good” designers — ones strong in craft — from “bad” ones by looking at the work and picking the folks who knew their way around a type ramp or spacing scale. That is no longer the moat; Claude knows hierarchy and structure better than I do.

What an LLM can’t do is decide on the right or best solution to a human problem given ambiguous or fuzzy input. It can auto-complete a screen or page flow, but it can’t know without being told how to delight a user. LLMs can’t break things (at least not on purpose); an AI couldn’t have come up with the recent neo-brutalist web design trends, though it can probably mimic a trend once a human has invented it.

These challenges, and the ever-stronger need for craft as an expression of culture, only underline the important role design engineers will play in years to come. For better or worse, design and technology are now fused together — you can’t practice the former without deeply understanding the latter, and folks who can code without also caring about design will likewise probably have a hard time.

Bits&Letters isn’t the first consultancy to align itself with the design engineering ethos. If anything, we’re aiming to bring web design back to its roots. I’m betting big on smaller, flatter teams working closely with clients and other folks with gnarly problems, leveraging craft, taste, experience — whatever you wanna call it — to deliver fantastic solutions.