The Eternal Debate
"Should designers code?" It's a question that sparks heated debate in every design community. Purists argue that specialization matters -that designers should focus on design. Pragmatists counter that understanding code makes you a better collaborator.
After a decade in this industry, I've landed somewhere specific: senior designers should absolutely understand code. But they should also know when to stop.
What "Knowing Code" Actually Means
Let's clear up a misconception. When I say designers should code, I don't mean they should be shipping production features. I mean they should understand enough to:
- Speak the language - Know what developers mean when they talk about state, props, components, or APIs
- Understand constraints - Recognize what's easy, hard, or impossible in code
- Prototype meaningfully - Build interactive concepts that go beyond static mockups
- Review implementations - Identify when something doesn't match the design intent and articulate why
This is technical literacy, not technical proficiency. There's a crucial difference.
The Business Case for Technical Literacy
Faster Design-Dev Cycles
When designers understand technical constraints upfront, they design within possibility. Fewer ideas get killed in implementation. Fewer "that's not how it works" conversations happen in handoff meetings.
I've seen design cycles cut in half when designers prototype in code rather than static tools. Not because code is faster to create, but because it surfaces implementation issues earlier.
Better Design Decisions
Understanding how things get built changes how you design them. You start thinking in components, not screens. You consider loading states, error handling, and empty states naturally. You design systems, not pages.
Some of my best design decisions came from understanding the technical architecture underneath. When you know how data flows, you can design experiences that feel coherent rather than bolted together.
Credibility with Engineering Teams
Let's be honest: designers who understand code earn more respect from engineering teams. Not because code skills are superior, but because it demonstrates effort to understand their world.
This credibility translates to influence. When you can have nuanced conversations about implementation trade-offs, engineers listen to your design opinions more seriously.
The Spectrum of Technical Skills
Not all technical skills are equally valuable for designers. Here's how I'd prioritize:
High Priority: Understand These Deeply
HTML & CSS This is the fundamental layer of the web. Understanding how elements are structured (HTML) and styled (CSS) is non-negotiable for web designers. You should be able to:
- Build a responsive layout from scratch
- Understand the box model and positioning
- Work with flexbox and grid
- Write maintainable, organized styles
Component-Based Thinking Modern development happens in components. Designers who think in components create more implementable designs. Understand:
- What makes a good component
- Props and how they create variants
- Composition and nesting
- State and how it affects appearance
Medium Priority: Understand Conceptually
JavaScript Fundamentals You don't need to write complex JS, but understanding these concepts helps:
- Variables and data types
- Functions and how they're called
- Events and interactions
- Conditionals (if this, then that)
- Loops (repeat this for each item)
APIs and Data Know how applications get their data:
- What an API is and does
- How data structures work (objects, arrays)
- The concept of async operations (loading states exist for a reason)
Low Priority: Nice to Have
Frameworks and Libraries React, Vue, Svelte -these change frequently. Understanding one gives you intuition for others, but don't invest too heavily. Concepts matter more than specific syntax.
Backend and Databases Useful for full-stack thinking, but diminishing returns for most design work. A conceptual understanding is sufficient.
When to Stop Learning
Here's where most advice on this topic fails: it never tells you when to stop. Let me be specific.
Stop When You're Optimizing for Impressing Developers
If you're learning code to prove something, you've gone too far. Technical skills should serve design outcomes, not ego.
Stop When It's Slowing Down Your Design Work
Time spent coding is time not spent researching, ideating, or testing. If your technical learning is crowding out design fundamentals, recalibrate.
Stop When You're Making Engineering Decisions
Your job is to understand constraints, not to choose technologies. Once you start having opinions about which framework to use, you're in someone else's territory.
Stop When "Simple" Becomes "Easy"
There's a dangerous point where technical knowledge makes you underestimate design complexity. You start thinking "that's just a modal" instead of "what problem does this modal solve?" Step back.
How I Use Technical Skills
In practice, my technical skills show up in a few key ways:
Prototyping Complex Interactions
When I need to test an interaction that Figma can't capture -something involving real data, complex state, or nuanced timing -I build it in code. These prototypes aren't production-ready, but they communicate design intent perfectly.
Design System Contributions
I work directly in our design system codebase to ensure components match design specs. This creates a tighter feedback loop than throwing designs over the wall.
Technical Feasibility Conversations
Before committing to a design direction, I can have informed conversations about implementation complexity. This helps prioritize features and set realistic expectations.
Debugging Implementation Issues
When something doesn't look right in production, I can inspect it myself, identify the issue, and provide specific guidance to developers. "The padding is 16px but should be 24px" is more useful than "it looks off."
The Mindset Shift
The real value of technical literacy isn't the skills themselves -it's the mindset shift that comes with them.
When you understand code, you stop seeing development as a black box that magically produces your designs. You start seeing it as a creative partner with its own constraints, possibilities, and elegance.
This changes how you design. You become more collaborative. You make fewer assumptions. You ask better questions.
Getting Started
If you're convinced and want to begin, here's my recommended path:
-
Start with HTML & CSS - Build simple pages. Understand how structure and style work together.
-
Learn responsive design - Media queries, flexible layouts, mobile-first thinking.
-
Pick up basic JavaScript - Focus on events and DOM manipulation. Make things interactive.
-
Explore a component library - Try building with something like Chakra UI or shadcn. See how component APIs work.
-
Build a prototype - Take a real design problem and prototype it in code. Experience the full cycle.
-
Then stop and practice - Don't keep adding skills. Get good at what you've learned.
The Balanced Designer
The goal isn't to become a developer. It's to become a designer who can dance with developers -who understands their world well enough to collaborate at a higher level.
Technical literacy is a superpower when applied judiciously. It's a handicap when it becomes your identity. Find the balance.
Your primary job is still to understand users, solve problems, and craft experiences. Code is a tool that helps you do that better. Never let the tool become the goal.
How much code do you think designers should know? I'm curious where others draw the line.