I've seen the light, and it's not canvas-based

There's been a lot of debate about the future of design tooling. Specifically, whether the future of product design is canvas-based or code-based.

I think it's mostly going to be code-based.

Over the past few years, I've completely transitioned off canvas-based tools for product design, and I think designers who develop these skills now will have a meaningful advantage over those who don't.

We've seen this before

When Sketch launched in 2010, most interface designers were still working in Photoshop. Designers had years of templates and muscle memory invested in Photoshop. Why switch to a more constrained tool?

But Sketch was purpose-built for interface design. It was lighter, faster, and better tuned to interface-design workflows. By 2015, it had become the standard and paved the way for Figma, which added real-time collaboration.

The people who resisted switching weren't wrong about the tradeoffs. Photoshop really was more powerful in many ways. But the tradeoffs were temporary, and the benefits of the new tool compounded over time.

For designers who are great at using Figma but have only dabbled in code, the skill gap is very real. It's hard to learn a new way of working when you have teams depending on you to execute. So when there's critical work to be done, you reach for the tool you know. Which means you never get better at the new one.

The real source of truth

Most designers have experienced the persistent gap between what they design and what gets built.

Most of us have worked at companies with beautiful design documentation and landing pages, but a less beautiful app. Most of us have spent hours doing visual QA to get an engineer's first build close to our polished designs.

But there's a deeper problem. Products feel different in Figma than they do in the hands of a real user. A table looks fine with three placeholder items. It looks different with 200 real entries, loading states, empty states, error messages, and text that wraps in unexpected places. An interaction feels snappy when you click through a prototype. It feels different when it's waiting on a network request. You can't fully evaluate a design until you're experiencing it in the same medium as your customers.

And that medium is code.

Some will argue that the canvas is better for exploration, that the freedom of an infinite canvas leads to better creative outcomes. For some kinds of work, that's true. But most product design doesn't need that kind of freedom. It needs constraints. When I worked at Uber, the vast majority of design was constrained by the design system and existing conventions in the app. You weren't reinventing the visual language. You were solving problems within a system. The same is true at most product companies.

Plus, when you're designing in code, you're working directly in the real medium. You experience real components and real interactions. You have access to creative outlets that canvas tools can't touch: animation, motion, 3D, audio, video. In many ways, the expressive range is actually wider in code

Most importantly, you feel the product as your users would in the real world. And you don't have to spend time on the work that exists solely because design and engineering speak different languages: preparing specs, adding measurements, marking up screenshots, writing handoff documentation. Instead, you're directly polishing and refining one source of truth.

My personal journey

I've lived this transition over the past three years.

I've been a full-time designer for over 10 years and a part-time one for over 15. I've designed interfaces in Photoshop, Illustrator, PowerPoint, Sketch, Figma, VS Code, and Claude Code.

In 2018, I taught myself some HTML and CSS and asked our engineering team at Bread to set me up for local development so I could fix bugs and help with design polish. It felt like a superpower.

I started a company near the end of 2022 and had to implement my own designs, so I taught myself JavaScript and React. Through 2023, I was still designing full high-fidelity flows in Figma before building them. By 2024, I'd only design a few key screens for major features in Figma, and for smaller features, I'd start directly in the codebase.

Sometime in mid-2025, things completely flipped. Our design system lived in code. I could feel the designs better in the browser. I could design with real data and real AI responses. And with AI-assisted coding, it became faster to generate greenfield concepts and iterate on them in code. I stopped using Figma for product design entirely.

As a result, I can ship features or even brand new products in days. I don't deal with handoff, specs, measurements, or marking up screenshots. And the work I'm producing is some of the best of my career, because I spend all of my time on the parts that actually matter: understanding the problem, exploring solutions, and polishing the experience.

What designers actually do

Nothing about the role of a product designer requires a particular tool.

Product teams need designers to make sure solutions are tailored to how humans think and interact with software, and to add delight and beauty to the experience. We do this by exploring broadly, collecting feedback, and using our taste to narrow and polish the solution into something more usable and beautiful than it would have been without us.

Sure, some design work still belongs on the canvas, but I now firmly believe that code (with the help of AI) is the future of design. It gives designers the agency to directly shape the product that end users experience, rather than producing artifacts that we must rely on others to translate.

And if you're a good designer, you don't need to worry. You'll need to adapt to new tools, but your taste and skills are what will continue to make you valuable. The light is there. You just have to walk toward it.