Skip to main content

Why devs should play an active role in design

Nicholas Villapiano Director, Front End Development, One North
An illustrated collage of abstract shapes in bright colors and bold patterns that allude to inspecting and annotating in Dev ModeAn illustrated collage of abstract shapes in bright colors and bold patterns that allude to inspecting and annotating in Dev Mode

Advocating for Dev Mode changed my team’s workflow. Here’s how you can do the same.

Imagine you’re given a design file. You’re clicking around, trying to figure out the margin values, when you accidentally nudge a button out of place. You hit “undo” only to discover that you didn’t actually move anything—but now you’ve erased someone else’s work. Panic sets in, and you start apologizing to your design peers for potentially messing up “their” file. You feel like a bull in a china shop.

Sound familiar? For years, we developers have operated under the assumption that design tools are for designers alone. We tiptoe through files or waste time switching between countless browser tabs trying to match code to design specs.

But we don’t have to accept this status quo. As products like Figma evolve to better serve cross-functional product teams, reinforcing those silos does us a disservice. With Dev Mode, Figma offers features that can improve our day-to-day productivity and collaboration with designers—and it’s up to us to advocate for it. While it may seem like another task on top of a growing to-do list, what we stand to gain is a better work environment with boosted efficiency, productivity, and morale.

Understanding the benefits of shared tools

Dev Mode recognizes that developers don’t just implement design—we’re active participants who need our own set of tools. Carving out a dedicated space within Figma allows developers to contribute meaningfully to the design process from concept to launch. By utilizing recognizable patterns and tried-and-true engineering practices as inspiration, we can do so in ways that feel natural to existing workflows.

CSS Flexible Box Layout, also known as Flexbox, is a web layout model that arranges responsive elements to fit the device screen.

It reminds me of when Figma launched auto layout, and developers immediately related it to Flexbox. Our designers were thrilled to have these smart spacing features, and developers loved seeing design files acting more like the web itself. But the unspoken gain was a new, shared touchpoint between designers and developers—a window into each others’ world. On a much larger scale, that’s what Dev Mode provides; it creates not just a window, but an entire framework for mutual understanding.

Dev Mode…creates not just a window, but an entire framework for mutual understanding.
Nicholas Villapiano, Director, Front End Development, One North

Why it’s up to us to make the case

In an ideal world, management would proactively champion these cross-functional tools. But realistically, they’re often a layer removed from the work itself and might miss the pain points we’re facing.

Luckily, as developers, we’re no strangers to piping up. From opening GitHub issues on open-source projects, to requesting changes on a pull request, to correcting misinformation on StackOverflow—making ourselves heard is part of our DNA. We should bring that same energy to advocating for a better toolset and developer experience, be that during 1:1s, sprint retros, or team meetings.

How to effectively advocate for what you need

When my team at a previous company was overhauling our design system in March 2020, we faced a perfect storm: a massive technical undertaking combined with a sudden shift to remote work. Figma, with its operating system-agnostic software and real-time collaboration capabilities, became an instrumental part of our workflow. It showed that, with the right tools, we could overcome even the most unexpected challenges.

Whether you’re taking on a huge project or trying to streamline day-to-day processes, clarity about what value and solutions a product brings to the table is key. And while some teams have gone back to the office or adopted hybrid work, the impact of having shared tools and language has not diminished. Here are three aspects that unlocked the value of Dev Mode for me and helped me advocate for better workflows:

Freedom to explore without fear

Remember that bull-in-a-china-shop feeling? Dev Mode is read-only by default, preventing those “Oh no, what did I do?” moments. I find this liberating! No matter what, I won’t be mucking up a carefully crafted file, and I won’t have to tiptoe in order to feel secure in the environment. It’s a shockingly under-reported feature inherent to Dev Mode that can boost navigational confidence within design files. Akin to branch protections on `main`, this freedom encourages you to click around and mess with stuff.

Clarity when comparing changes

Similar to the pull request and commit history functionality in GitHub, Dev Mode unlocks version history and allows you to compare changes. This soft layer of version control allows you to visually compare different versions of a design and see exactly what has changed, when, and by whom.

And just like a pull request, comparing changes gives you an itemized list of differences between versions. Resolve this copy change, update this margin, add this component variant, and you’re good. An explicit checklist of tasks created for any version change? Yes, please.

Ending the tab-switching tax

What do you call a dev who uses two monitors? Restrained! We were losing countless hours switching between design specs, documentation, and code. Code Connect changed that. If you’re not familiar, I encourage you to check it out—it’s very cool and nerdy. In a nutshell, it can link your actual living codebase to your connected Figma instance, making code more accessible for developers and helping design system adoption. After a few quick commands using their CLI setup tool, we could see our functional component code right in Figma’s inspect panel, complete with props and parameters.

The setup felt like extra work initially, but so did using Storybook itself when we first adopted the frontend workshop. Once it was established, the payoff was immediate. No more trying to remember component names or hunting through Storybook—everything we need is right there in the inspect panel.

Taking charge of our experience

It’s understandable that advocating for tools might not always be top of mind. After all, you have a lot on your plate with a full sprint of stories to tackle, bugs in the queue, and that re-platforming looming on the horizon. But our work environment directly impacts our productivity and satisfaction. By championing what we need, we can help shape a better developer experience for ourselves and our peers—meaning less miscommunication and context-switching, and more time spent in the flow.

By speaking up about what we need, we can help shape a better developer experience for ourselves and our peers.
Nicholas Villapiano, Director, Front End Development, One North

Got ideas to make Dev Mode better? Don’t hesitate to share them! Together as a community, we can keep improving and make sure our tools evolve to meet our needs. That’s the power of speaking up: We can help shape tools that work better for everyone. Let’s make our voices heard, and resolve our conflicts one merge at a time.

Nick is the Director of Front End Development at One North. When not trying to talk design systems with anyone who will engage, he enjoys bowling and making music.

Subscribe to Figma’s editorial newsletter

By clicking “Submit” you agree to our TOS and Privacy Policy.

Create and collaborate with Figma

Get started for free