Should designers code? For years, my answer was a loud yes, 100%. Since 2018, I’ve been expanding my coding skills. It was a natural consequence of trying to grow in every direction as a designer.
Fast forward to 2025, and designers taking on more frontend work is becoming common. But with code easier than ever to ship, it’s also easier to get stretched too thin.
I’ve realized it’s more important than ever to manage your focus wisely. Your sense of empowerment with code should not limit you or prevent you from impacting the user experience on a higher level, or finding areas where your work can be real differentiator.
Being a technical designer
Some say that if as a designer you’re starting learning code now, you’re optimizing for the wrong skillset. Coding is no longer the bottleneck and you should focus on getting good at instructing bots what to do.
There’s a lot of truth in this. What’s still valid, though, is that by knowing your way around code, you can speak the same language as engineers. This makes collaboration so much easier and helps the team move faster.
I believe it’s key element that lets you be involved in conversations from the very start and throughout projects. Especially when you’re building a very technical product. Basically, you’re not being left behind.
It doesn’t mean you have to code—it’s more about understanding the medium you’re designing for. No one has to explain how the preview image generation service works because you’ve checked it yourself. Or you know that this panel can display different things in different scenarios because you understand what v-if is and can decipher the rendering logic on your own.
Ship—but be smart about it
The ease of testing ideas with AI-assisted tools has shifted the (sacred, for some) double diamond process.
It’s much easier to dive into code, ask bots to generate something that more or less works the way you want, and test it with others to see how it feels or how it fits into the larger system.
The question, though, is what happens next—once you decide to move in a certain direction.
A common pattern in the industry is handing your working prototype (no matter how messy) to developers and expecting them to figure it out and integrate it into the existing codebase.
I found this approach insufficient. It felt like another kind of handoff—just further down the line. Many of the details I cared about still got overlooked. Instead, I started pushing things closer to production quality myself, with guidance from developers in a constant handshake-style collaboration.
It’s a harder path, but it’s deeply rewarding. And your coding skills—combined with familiarity with the existing codebase—really help move things forward faster.
A tool that didn’t work (for me)
This year, I tested the Figma-to-Cursor (MCP) workflow twice. Even after doing everything I could to help Cursor translate my Figma files into clean, accurate code, it only got about 80% right.
The problem is that the missing 20% is too much for me to ignore. It’s not reliable enough to fully trust—especially when you care deeply about the details. And I do.
So I ditched that workflow. I started treating Figma more as a tool for direction and exploration, knowing that the final result will likely evolve once I start shaping it directly in code.
When to Figma when to code
Tight scopes and deadlines at Speckle mean that speed matters more than ever.
Defining clear boundaries for my coding work has helped me strike the right balance—contributing meaningfully to the team without becoming a liability.
Now, having more control over key parts of the production process, I have a greater say in which corners get cut. If developers tell me that part of the project should wait and I disagree, I can take it into my own hands—open a PR, get it reviewed, and have it merged without needing to ask for permission.
But—and here’s where knowing your way around code really matters—if you rely blindly on what bots deliver, the code review process becomes harder for your developers. Instead of focusing on their own work, they end up spending time explaining why the code you generated isn’t good enough—or rebuilding it properly (being AI-assisted as well).
With a deadline looming, this can get messy pretty fast—especially with bigger PRs. You’ll end up pulling your hair trying to get approval instead of focusing on the areas where your work truly makes a difference.
Adapt
Being smart about when and where to code has become very important for me. You’ll never be as proficient as a fully focused, AI-assisted developer, so it’s crucial to pick your tasks wisely.
My rule of thumb is based on confidence and clarity. If the unknowns about how things could or should work are low, I tend to jump into coding. But if there’s a lot of uncertainty, I know my impact will be greater if I focus on design, coordination, exploration, or research—bringing clarity to the project and the team.