When Figma starts designing us

I first encountered Figma in 2013, when Dylan Field demoed an early prototype to me at O’Reilly’s Foo Camp. I remember the pen tool feeling surprisingly elegant, but I missed the bigger picture: the radical implications of a design tool that ran in the browser. A decade later, Figma is a core part of our creative process, and without it, we wouldn't have been able to build a fully remote design practice. That’s probably why Dylan is a near-billionaire and I’m not.

However, over the course of the last five years, I’ve grown increasingly worried about what Figma is doing to the field of design by pushing designers toward an engineering-centric way of working. This can be seen in their feature releases: Smart Components, Variables, Auto Layout, and Interactive Prototypes. These features are often celebrated as steps toward parity with engineering, but in practice, they encourage a mode of working that narrows the field of possibility at precisely the moment when it should be expanding.

A concrete example is Auto Layout. It may seem harmless at first to introduce a DOM-like layout mechanism in a design tool, and it certainly has advantages in mature design files where the structure rarely changes. But many design teams today use Auto Layout to create full page designs of their digital products from the get-go. In practice, this locks the design in place and severely limits the possible expressions. You can’t drag things around freely or try odd combinations of layouts. You can’t simply paste something into a frame without it snapping to the bottom of the stack. The result is that designers are nudged into thinking like engineers during the earliest stages of exploration just when they should be working messily, freely, and loosely. It might feel convenient at first, but it comes at a cost. Have you ever opened a Figma file and tried to make a small change, only to find yourself wrestling with the layout? I’ve encountered this more often than I’d like, and it seems to be increasing in frequency.

Another feature is Dev Mode, which, in theory, is the missing bridge between the design specification and the technical implementation. However, it enforces a mindset where designers polish designs far away from the technology they are designing for, and where enormous amounts of time are spent on building complex prototypes, only for them to be discarded and rebuilt in code. This is all done in the name of making something ready for development. This is contrary to my belief that any digital design process should start with rough sketches, but move quickly into code and iterate from there. Those sketches might even be done in code. A design is never “ready for dev”, because a lot of what we consider to be design decisions – interaction, animation, loading of data – can really only be prototyped in code. “Ready for dev” implies that the creation is done and that the developer is merely there to execute the designer’s vision, implicitly preventing them from questioning any of the decisions when the rubber hits the road.

These are just two examples, but it illustrates a worrying trend towards a premature optimization of design. These features encourage designers to make decisions too early, to over-structure ideas before they’ve had a chance to unfold. The result is a narrowing of the design space, where the flexibility needed for creative discovery is replaced by enforced consistency and structure. This comes on top of the incredible number of structured tasks that most modern design teams adhere to. This inevitably contributes to the growing monoculture in digital design where everything starts to look and feel the same, not because of shared intent, but because of shared constraints.

I’ve spent the last 15 years advocating for deeper collaboration between designers and engineers, so it might seem contradictory to critique a tool that brings those disciplines closer together. But interdisciplinary work doesn’t mean collapsing into one way of thinking. The goal isn’t for designers to adopt engineering practices, but to bring distinct perspectives through an interdisciplinary way of collaborating.

Figma is extremely powerful, but it is bending us toward a way of working that prioritizes structure over spontaneity. As designers, we should remain alert to this shift, not because Figma is inherently bad, but because the values it encodes can quietly reshape our practices. The best design work rarely starts with order. It starts with questions, with play, with a lot of mess. We need tools that make room for that. Because if everything is neatly aligned from the beginning, we may never discover what lies just outside the grid.