Why I moved on from Figma

Fed up with front-loading design? This is what I do instead.

Photo by JACQUELINE BRANDWAYN on Unsplash

First, this is not an anti-Figma post. We need many tools and processes for the many designers and design challenges out there. This is a post describing why I no longer use Figma and what process has proved more efficient for me.

Figma is an ambitious—and pretty cool—piece of software: it improves collaboration and makes project handoff tidier than previous tools.

My work, like yours, is a particular flavor of UX and Design: I work in web development; Our programming team works in 2-week agile sprints; we’re a non-profit; and so on. For me in my current role, and despite its cool features, I found that Figma was building in inefficiencies and contributing to misunderstandings on our team’s path towards a working product.

Below I share the drawbacks of Figma we ran into, an alternative workflow, and it’s benefits.

Drawbacks

1. With Figma, handoff is baked into the process. As described on their own website, Figma can “create responsive components that map closer to code, making developer handoff more seamless.” Closer to code is a long ways from being code, and a more seamless handoff is still a handoff. Just one example of this is Figma’s lack of breakpoints: any breakpoints you want to demo must be build by hand in Figma, and then redone in code. Unnecessary handoffs are not an efficient use of design time.
2. Figma can’t directly contribute to our agile team goals of building, testing, and improving by incremental product iterations for a simple reason: it generates a design artifact and doesn’t contribute to the product itself.
3. Everyone can understand a website, not so with a mockup. Figma’s outputs also require accompanying descriptions and documentation of intent to be understood by all parties, or we risk creating comprehension debt.
4. Figma’s front-loading of design is more aligned with waterfall processes. I am not anti-waterfall, it is a great pattern when specifications are known up front and change is unlikely… but that does not describe any software project I have ever worked on.
5. Programmers who rely on assistive technology are blocked out of…