Dear (Future) Designer: Don't Learn How To Code
Literacy beats fluency for designers
At some point in your career someone will tell you to learn to code. They'll mean well. Don't listen.
This isn't anti-code. Code is useful. Code is interesting. Code is, for many of the interfaces you design, the actual material you're working with. What we're against is the specific cultural assumption, still everywhere in our profession, that designers should be aspiring developers in disguise. That learning Swift or React or whatever's popular this year is the ceiling your career is trying to reach. That if you can't also ship, you're only half a designer.
You're not half a designer.
What "learn to code" usually means
Most of the people telling you to learn to code aren't telling you to build applications. They're telling you to be less annoying to engineers.
That's a real problem. We've watched designers hand off Figma files with pixel values that don't align to any grid, colors that aren't in the design system, and interactions that don't work because they weren't considered. But the solution to that problem isn't "write more code." It's "understand what you're handing off."
These are different things. The first is a massive time investment that produces a mediocre developer who isn't being paid to be one. The second is a week of focused curiosity that makes you a better designer.
The actual skill
What you need is literacy, not fluency.
When you design a button in Figma, know it maps to a <button> element in most web interfaces, and that your button has states you might not have drawn yet: hover, focus, active, disabled. Know that applying a 16px border-radius in your mockup means something specific in CSS. Know that your neat horizontal scroll section is going to behave differently on a phone than on a desktop. Know why your engineer is asking about "empty state" when you haven't designed one.
This is a short list of knowledge. You can absorb most of it in a month of working next to someone who already knows it, if you pay attention. You don't need to build React apps in your spare time.
The test is whether you can have a two-minute conversation with your engineering counterpart about a specific component and not get lost. When that conversation goes well, design and engineering converge. The feature ships faster. The bugs are smaller. Everyone is less frustrated.
Why fluency is a trap
Here's what nobody tells you about designers who become good at code.
They either become designers who happen to write code, which is fine, or they become developers who happen to do some design, which is a different job. The first is rare. The second is more common, and it usually ends with the person leaving design altogether, because the market pays better for writing code than for drawing rectangles and arguing with product managers about button placement.
This isn't moralizing. It's structural. If you spend a year becoming a competent developer, competence in developing becomes the thing you can sell. Design becomes the side dish. The instinct for what should be built, which was the thing you were hired for, atrophies while you're busy learning npm.
Pick carefully.
What to invest in instead
If you want to be more effective at your current job, invest in what engineers can't.
Qualitative research. Interviewing users and actually hearing them. Reading your product's support tickets. Watching session recordings until you understand why people keep bouncing off that one screen.
The argument for design principles, and why they're worth writing down. The ability to run a critique without it collapsing into taste fights.
The ability to say no. Clearly. To your PM, to stakeholders, to yourself. Most designs get worse when everyone gets what they want.
These are the skills that compound. They're also the skills that don't have a boot camp, a certification, or a tutorial series. Which is probably why "learn to code" is what gets suggested. It's a more legible answer.
To the designers already halfway there
If you've already invested real time in learning to code, you haven't wasted it. Code literacy is a strength. If you can prototype in the browser when Figma can't represent what you need, that's a real advantage. If you can read your app's codebase and know what's cheap to change, that's valuable information. If you can pair with an engineer on a hard interaction, you'll ship better work.
The argument isn't that code is worthless. The argument is that you should know what you're trading for the time you spend on it.
One last thing
If you're early in your career and the pressure to learn to code is weighing on you, we'll say this plainly. Your job is to think clearly about people and products. The tools change. The medium changes. Figma will eventually be replaced by something we can't predict. Code will keep evolving.
The thing that doesn't change is your capacity to see the problem, understand the person, and choose what gets built. Nobody else in the org is doing that job. Nobody else is paid to.
Keep being a designer.
This is part of the Dear (Future) Designer series. Other entries:
