Thomas
Brasington
User Experience
Opinion
Technology

Should Designers Code 2025 Edition

February 25, 2025

Designers have historically had strong opinions about physical materials. When crafting a fragrance box, the choice of paper stock, inks and embossing techniques directly impacts the overall feel. There's a tangible connection between design decisions and final product.

Similarly, magazine art directors don't take photos themselves. They commission photographers whose style aligns with their vision. You don't need to operate a camera to recognise great photography.

Product design should follow this same principle – understanding the materials without necessarily crafting them. But digital products present unique challenges.

The question isn't whether designers should code, but how deeply they need to understand the materials of software to create effective designs.

The key difference with software lies in visibility. A designer can immediately feel poor paper quality or see a badly composed photograph. But they cannot directly observe poor code architecture, security vulnerabilities, or future maintenance challenges. The quality of software implementation remains hidden behind a seemingly functional interface, with consequences that might only emerge months or years later.

The materials of software – code, frameworks, deployment pipelines – remain inaccessible to many designers. Unlike a physical box you can touch or a photo you can see, software functions through layers of abstraction. You can observe the interface but not the architecture behind it.

Software development, like design, encompasses countless specialisms and domains. Frontend, backend, infrastructure, security, performance optimisation – each requires years of dedicated focus to master. Learning to code isn't like picking up a new design tool; it's entering an entirely different professional universe with its own languages, paradigms and best practices.

Understanding Technical Constraints

Each layer of a digital product introduces its own constraints and possibilities. What seems simple in a design tool might involve complex technical trade-offs invisible to designers.

Designers can't judge what's possible because they receive information that conflicts with prior experiences. What was straightforward in one technology stack might be nearly impossible in another. A feature that took days to implement on a previous project might require months on the current one – not because developers are being difficult, but because the underlying technical architecture creates different constraints.

The Ever-Changing Material

Unlike print or physical products, software keeps evolving. Decisions made today lock you into constraints for years to come. Poor implementation gets hidden behind jargon and estimation processes.

It's unrealistic to expect designers to code alongside their existing responsibilities. UI, IA, UX, research, user testing, data analysis – the list of required skills keeps growing while software complexity increases.

Can AI Bridge the Gap?

AI coding tools like v0 and Bolt promise to make implementation more accessible to designers. The pitch is compelling – just describe what you want, and the AI generates working code.

But these tools introduce the same challenge in a different guise: how do you evaluate the quality of what's being generated? Without understanding code structure and best practices, designers still can't distinguish between sustainable solutions and technical debt.

Even when these tools produce functioning interfaces, generating code doesn't mean understanding it. You might get something that works today but creates maintenance nightmares tomorrow. The ability to create doesn't automatically confer the ability to evaluate quality or make informed technical decisions.

AI tools may change how we implement designs, but they don't solve the fundamental disconnect between design intent and technical reality.

Design Engineering: The Bridge

This is where design engineering bridges the gap.

Design engineers translate creative vision into technical reality. They speak both languages fluently – understanding user needs, brand requirements and technical constraints. They can evaluate the quality of AI-generated code, recognise technical debt, and maintain implementation standards.

  • In practice, design engineers:
  • Prototype with real code that can evolve into production
  • Advise on technical feasibility during the design process
  • Create component systems that maintain design integrity
  • Evaluate technical approaches against design requirements
  • Advocate for user experience in technical discussions
Real-World Impact

At Design Engineering Studio, we've seen how this approach transforms projects:

  • Marketing teams launch pages with complex motion and interactive elements in days rather than weeks
  • Startups validating ideas with functioning prototypes before committing to full development
  • Product teams reduce timelines by designing broad strokes while details are solved, evaluated and tested in code
  • E-commerce brands testing complex navigation structure changes with fully functional prototypes rather than static mockups
  • Design systems translating directly to code through design tokens and ready-to-use components that speed up development

Just as print designers understand paper stocks without operating a paper mill, digital designers should understand their materials without becoming full-stack developers. They need design engineers as translators and advocates to ensure that good design becomes good software.

Get in touch

moc.notgnisarbt@liam