For years, “should designers code?” was a fun industry debate. People took sides, wrote think pieces, argued on Twitter. It felt philosophical. Then somewhere around late 2025, companies stopped debating and just started writing it into job listings. No vote. No consensus. The market decided. Now designers are staring at role descriptions that want Figma mastery, design systems ownership, and the ability to ship React components, and wondering when exactly the rules changed.
This issue breaks down what actually happened, what it means depending on where you are in your career, and how to respond without either panicking or sticking your head in the sand.
In this issue:
How we got here and why it happened fast
What “design engineer” actually means (it’s not one thing)
The real case for learning to code
The real case for not coding
What technical fluency actually looks like in practice
How to respond based on your career stage
Resource Corner
How we got here and why it happened fast
Three things converged and none of them are going away.
1. AI made the gap closeable
The old argument against designers coding was that it took years to get useful. That argument is dead. AI coding tools now let designers generate working interfaces, real components, functional prototypes, without deep engineering backgrounds. Designers can now bridge a technical gap that previously took years of computer science knowledge and coding experience to cross. Smashing Magazine Executives saw the demos. Some drew overblown conclusions. Others drew conclusions that were directionally accurate even if overstated. Either way, the expectation shifted.
2. Teams got leaner and handoffs got expensive
Post-layoff design teams are smaller. When you have one designer and two engineers on a product, the idea that the designer stays entirely in Figma while engineers translate everything into code starts to look like a bottleneck. Companies are not wrong to want to reduce that friction. The question is whether their solution (hire one person to do two jobs) is actually the right one. Often it is not. But the underlying pressure is legitimate.
3. Vibe-coding blurred the line publicly
Tools like Cursor and similar AI-assisted environments made it possible, visibly and publicly, for non-engineers to produce working interfaces. This did not make designers into engineers. But it made the distinction harder for non-technical stakeholders to understand, which is a design problem in itself.
The combined result: UX roles are increasingly demanding AI-augmented development, technical orchestration, and production-ready prototyping Smashing Magazine, often without a clear understanding at the hiring level of what those things actually mean in practice.
Quick interruption. This one is for you personally.
🎯 Not sure where you fit right now? This is for you.
If you’ve been laid off, watching your field shift, or applying and hearing nothing back, this workshop was built for that exact moment.
Four hours. Your real stuff. Your resume, your pitch, your positioning in a market that keeps moving. You leave with something finished and a clearer sense of what’s next.
No jargon. No coding. No theory. Just practical, hands-on work led by people who do this for a living, in a room full of people who are serious about their next move.
July 23, 2025 · 12:00–4:00 PM Silver Spring Civic Building, 1 Veterans Pl, Silver Spring, MD 20910
back to where we stopped….
What “design engineer” actually means (it’s not one thing)
This matters a lot before you apply for, accept, or stress about any role using this title.
→ Version 1: Design systems engineer Owns the component library at the code level. Works in Storybook and Tokens Studio. Ensures what ships matches what was designed. This is a real, specialized, well-compensated role that requires genuine engineering depth. It is not a designer who also dabbles in code.
→ Version 2: Prototyper in code A designer who can build functional prototypes precise enough that engineers use them as implementation references rather than interpreting static Figma files. This is about reducing translation loss, not writing production code. Much more achievable. Much more common.
→ Version 3: One person doing two jobs A company trying to replace a designer and an engineer with a single hire, usually without acknowledging that is what they are doing. Attempting to master two disparate, deep fields simultaneously will most likely lead to being averagely competent at both. Smashing Magazine This version is worth identifying in the job description and negotiating around, or walking away from.
Knowing which version you are looking at before you accept a role is not optional. Ask directly in the interview: what does the engineering relationship look like? Who owns production code? What does “production-ready prototyping” mean on this team?
The real case for learning to code
Learning to code at even a basic level makes you a meaningfully better designer. This is not hype. It changes how you think.
✓ You design more buildable systems because you understand how components work
✓ You stop creating flows that look great in Figma and collapse immediately in development
✓ You can prototype interactions that Figma cannot express, especially complex states, logic, and animations
✓ You reduce your dependency on engineers for information you should already have
✓ You have more credible conversations in design reviews when technical tradeoffs come up
Beyond craft, the market signal is real and it is not reversing. Designers with technical fluency are getting more interviews, more leverage in salary negotiations, and access to more interesting and senior problems. That is the honest picture.
The additional depth that coding gives you is not about becoming an engineer. It is about removing friction from every collaboration you have, every day, at every stage of a project. That compounds over a career.
The real case for not coding
Some designers have a legitimate argument here, and it is worth taking seriously rather than dismissing as defensiveness.
A principal UX researcher. A service designer working across organizational systems. A content strategist shaping information architecture at scale. These roles create enormous value in ways that have nothing to do with React fluency. Asking them to invest hundreds of hours learning to code is a poor allocation of expertise that took years to build.
The risk is not in saying “I do not code.” The risk is in how you say it.
“I don’t code and I never will” signals rigidity in a market that is visibly shifting. It closes doors even at roles that do not strictly require technical skills.
“My primary value is in research and strategy, and I have enough technical fluency to collaborate effectively with engineering” is a completely different statement. It is also more accurate for most experienced researchers and strategists.
The distinction is between refusing to engage and being clear about where your depth actually lives.
What technical fluency actually looks like in practice
The designers navigating this well are not trying to become engineers. They are building enough fluency to work without friction.
In practice, this looks like:
→ Reading and lightly editing code rather than writing it from scratch
→ Understanding component-based thinking well enough that your design systems translate cleanly into engineering
→ Using AI coding tools to prototype interactions and states that static design tools cannot express
→ Knowing enough to have an informed conversation with an engineer, not a helpless one
→ Understanding what is technically expensive before you design it, not after
The designers who thrive will be those who use AI to augment their design thinking, allowing them to test more ideas and iterate faster, without trying to replace the specialized engineering expertise that ensures designs technically work for everyone. Smashing Magazine
That is the line. Use the tools. Stay on your side of it. Do not pretend the tools make you an engineer, and do not pretend they are irrelevant.
How to respond based on your career stage
🔵 Early career (0 to 3 years) This is the highest leverage moment to build technical fluency because the learning cost is lowest and the compounding time is longest. Get comfortable with HTML and CSS at minimum. Understand how a component library like React is structured even if you are not writing it daily. Use AI coding tools to prototype rather than relying entirely on Figma for everything. You do not need to be good at it yet. You need to not be afraid of it, and you need to be actively learning.
The designers entering the market now who are comfortable moving between design tools and code environments are going to pull ahead of those who are not. The gap will widen.
🔵 Mid career (3 to 7 years) Pick your lane intentionally and build accordingly.
If you are moving toward product design or design systems, deeper technical fluency is a genuine career accelerant right now. The roles are better, the compensation is higher, and the work is more interesting.
If you are moving toward research or strategy, invest your learning time there instead. Build just enough technical literacy to collaborate without friction, then go deep in your actual direction. The market still has strong demand for genuine research expertise. Do not abandon what you are good at because of a noisy job market trend.
What you should not do is let the noise panic you into learning things that do not serve your actual direction. Scattered learning in every direction produces designers who are average at everything, which is exactly the problem the issue about specialization covered.
🔵 Senior and above The expectation shifts at this level. You are not expected to ship code. You are expected to never be surprised by a technical constraint you should have anticipated. The job is judgment: knowing what is feasible, knowing what the tradeoffs are, making design decisions that hold up through engineering. Deep technical fluency helps that. A willingness to engage with engineering as a partner rather than a recipient of your files helps more.
If you are senior and still treating Figma handoff as the end of your involvement in a feature, that is the pattern to change, regardless of whether you ever write a line of code.
📦 Resource Corner
The Design Engineer Handbook (Figma / Stripe Press) The clearest articulation yet of what design engineering actually is and what it is not. Read this before taking any role with that title.
Frontend Mentor Project-based HTML/CSS/JS practice built specifically for people learning by building real things rather than watching videos. Low friction, high retention.
Scrimba Interactive coding environment where you code inside the tutorial itself. Significantly more effective than passive video courses for actually retaining what you learn.
Every Layout (Heydon Pickering and Andy Bell) If you learn one coding concept as a designer, make it CSS layout. This resource teaches it better than anything else available, and the mental models transfer directly into how you think about design systems.
React for Designers (Design+Code) Specifically aimed at designers who want to understand component-based development without crossing fully into engineering territory. Practical and well-scoped.
Smashing Magazine Design Engineering Coverage Ongoing reporting on how this role is evolving across different company types and team structures. Worth following rather than reading one article and drawing broad conclusions.
💭 Final Thought
The debate was never really “should designers code.” It was always “how much technical fluency does this designer, in this role, at this company, actually need to do their best work.” The honest answer to that has always varied.
What has changed is the floor. The minimum viable technical literacy for a working designer in 2026 is higher than it was three years ago. That is just true and it is not reversing.
But the ceiling argument is also still valid. Nobody becomes exceptional by stretching themselves across every possible skill. The designers getting the best outcomes right now are not the ones who panic-learned React after seeing a scary job listing. They are the ones who got clear on where they are going, built the fluency that direction actually requires, and stopped apologizing for not being engineers.
Know your lane. Learn enough to drive in it without friction. That has always been the real answer.
