I learned enough code to know it wasn’t my path, but it still changed how I design. At Sparkbox, having a team with a wide range of skills has always been a strength, both for our work and for our clients.
The Ongoing Debate
For a long time in the design and tech space, there’s been an ongoing debate: Should designers learn to code? I’ve experienced both sides and learned a lot from sitting in the middle.
When I first joined Sparkbox, I was determined to become the kind of designer who could also code. I felt a real pressure, from the industry and the direction things seemed to be moving, to pursue it as much as possible.
I started learning frontend development through the Sparkbox apprenticeship program. I picked up the foundations of HTML and CSS, and dabbled a bit in JavaScript. I never became a full-time developer and honestly, I never wanted to. But I can say this with full confidence: I don’t regret a second of it.
Here’s why I’m glad I learned to code, even though I eventually stepped away from it.
Learning to Code Changed How I Design
Once I saw how the code came together behind the UI, I couldn’t design the same way again.
Learning to code opened my eyes to all the layers that go into designing an interface, not just the UI, but the relationships between components, their behavior, and how they adapt and scale across multiple devices and products through reusable design patterns.
Building Scalable, Maintainable Systems with CSS and Tokens
Understanding CSS basics, like how classes are applied and how styles cascade, helped me make sense of the logic behind interface styling. Pairing that with learning how design tokens work gave me clarity on how to build systems that scale and stay maintainable over time.
Inside Figma, I started setting up variables and styles in a way that mirrors how things are named in code. I try to match things one-to-one, whether it’s color roles like color.text.primary or spacing tokens like spacing.200. That consistency makes conversations with developers faster and handoffs clearer. We’re speaking the same language, just using different tools.
Using features like Figma variables and Auto Layout made it easier to apply those decisions consistently across themes and components. It not only improved the final design deliverable, but also freed up my time for more creative exploration, strategic direction, and solving unique UX problems.
Accessibility Starts with Design
I’d always heard about the importance of accessibility, but it wasn’t until I started learning to code that I really understood how it worked. Writing semantic HTML and experimenting with screen readers showed me how things like heading levels, focus states, and keyboard navigation directly impact the user experience.
One moment that really stuck with me was realizing how differently designers and developers can think about headings. I used to treat headings mostly as visual styling: just pick a size that looks right. But learning HTML taught me that heading levels aren’t just for looks, they create a structural outline that screen readers rely on.
It helped me connect the dots between design decisions and real-world usability. From then on, I started designing with accessibility in mind from the start. Things like semantic markup, heading hierarchy, focus states, keyboard navigation, and visual cues like color contrast and error or success states aren’t just developer concerns, they’re intentional design decisions. These guidelines create clear, inclusive feedback that helps users understand where they are and what’s happening within the experience.
How Code Literacy Improves Collaboration
Learning the basics of code gave me a shared language with engineers, which made communication smoother and more focused. Instead of talking past each other, we could collaborate, solve problems together, and land on solutions we both felt confident in and proud of.
One small but meaningful shift for me was learning about rem values. I used to hand off designs with random pixel values, just whatever looked good in Figma. But once I understood how developers use relative units for scalability and accessibility, I started using rem in my own thinking and communication. Now when I pair with developers, I’m not just throwing over a set of numbers; I’m speaking in the same units, aligned with how the system actually works. That shift made our conversations faster, clearer, and more collaborative.
It also helped with handoffs. I could better anticipate technical constraints and explain design decisions in ways that made sense from a development standpoint. Clearer expectations meant fewer revisions, saving time and effort on both sides.
Most importantly, it built trust. I wasn’t just handing off static screens, I was in the conversation early, thinking through how things would actually be built and experienced by real users. That kind of cross-functional partnership is something we practice every day at Sparkbox, and it’s a big part of why our teams, and our clients, benefit from working this way.
Once I saw how the code came together behind the UI, I couldn’t design the same way again.
Let Curiosity Guide Your Design Journey
Learning to code gave me more than just technical skills; it changed how I think about design. It helped me see beyond individual screens and start designing systems with scale, accessibility, and real use in mind. It also made me a better collaborator: more thoughtful in handoffs, clearer in conversations with engineers, and more aware of how things actually get built.
But you don’t have to become a developer to gain those benefits. Even a basic understanding of how code works can shift your perspective and strengthen your practice.
If you’re curious, follow that curiosity. Explore code on your own terms, not to become something else, but to grow in what you already do.
In the end, it’s not about writing perfect code. It’s about bringing empathy, curiosity, and collaboration to the work, because that’s what takes you from being a good designer to a great one, and in turn, makes your team stronger.
