Figma, I love you but you’re bringing me down

When a toy becomes the whole playground

Designers are not the tools they use. But designers are constantly learning, and the things we learn are heavily influenced by the tools we use, the features they offer, and the problems they solve. When Adobe acquired Figma in 2022, I was bombarded with advice and thought leadership telling me that we are not defined by our tools. As much as I’d like to believe that, I can’t ignore that I’m a big Figma nerd, I track Figma’s update releases closely, and I’ve solved many problems at work just by being an early feature adopter and teaching techniques to my team.

In my most recent design career pivot, I’m working more with design systems and component libraries. Design systems are so much more than just component libraries, but my individual focus is on building UI components. I was recently asked to reflect on my design system skills and where I find my flow. Upon reflection, I realized just how much my favorite skill hindered my most recent project. The following is a summary of my epiphany.

Geeking out on layers

One of my best skills — if not my strongest, at least the one I’m most passionate about — is building components. Not the visual style of a component. Not writing the specs or guidelines for a component, but the actual asset creation part. And what I enjoy the most is getting deep into the layer architecture to make components flexible yet systematic.

Last month, I needed a way to align the many different modals we use around our product. Defining this is much easier by giving myself atomic building blocks to swap in and out and align to auto-layout rules. And ideally, these building blocks can become elements of the final component in the library or available as templates for other designers to use.

I had a deep-dive building session. Several hours went by effortlessly, and that’s how I knew this was my jam.

A zoomed out view of a Figma UI. A frame is titled “Component building blocks” and contains many small UI elements that are copied to form responsive columns of content.

The basic building blocks for the modal component. At the organisms level, each content block is configurable to responsive column sizes.

The build session was fruitful. I walked away with a couple of different size options for the main component and used 4, 6, 8, and 12-column size blocks to demonstrate (and also guardrail!) how designers could or should arrange their various content. And it’s really clever too. Using just the single base component below, you can arrive at any of the nine common content patterns we use across modals. So you only need to change one base component, and everything else will update as we tweak the visual details later.

A screenshot of a Figma UI showing one block of text containing a timestamp, a title, body text, a large icon, and a small icon. Below it are nine different combinations of some, but not all, of those elements. Words and an arrow show that these nine combinations are all made from that first piece.

It’s also very detailed. It might look messy here with so much text, but I wanted to make sure all our possible bases are covered. For every bit of main content, you can reconfigure it as any combination of columns.

And that’s great because it only took me a few minutes to churn out all of the final modal components we could ever need. And from there I could quickly adapt all of the placeholder content to match our real examples from the product. Since every layer of the underlying structure uses frames, and every frame uses auto-layout whenever necessary, it doesn’t matter which configuration of content blocks you choose; everything locks in with the correct padding, margins, and spacing between blocks.

A collage of screenshots from Figma showing the main component frame, which runs off the page with more than 10 variants of modals with different combinations of content columns. On the right is the Figma design panel UI showing how at the topmost level, you can choose the size and layout of the modal, then drilling down a level lets you configure each content block.

Where I went wrong

So far, this all sounds like I’m patting myself on the back. But this is where I started to realize that maybe these Figma manipulation skills aren’t always a good thing. You see, I made this component to be really really flexible. It’s elegant, but it’s complicated. If I were to expose all the nested flexibility here to the end user, it would look pretty messy.

A screenshot showing one practical example of a modal using this component. On the right is the Figma design panel, where at least 25 variant properties and toggles are visible, with many more running off the page.

I can dial back how much of this flexibility is exposed to the end user. Figma’s Nested Instances make this pretty easy to control. But it would still be pretty hard to pick up this component from the library and use it to its full potential without understanding all the structure built into it.

Two side by side screenshots of practical modal examples. With more of the properties hidden, there are only about 10 variant properties visible, but with names like “.Content Row/Layout” and “.Molecules — Modal Footer/Show Carousel,” it isn’t immediately obvious what each dropdown and toggle controls.

The thing is, to make base components work their best, you need to make sure every variant has the same underlying layer structure, showing or hiding the parts you need for each variant. Please don’t look under the hood. You won’t like what you see…

A side by side view of the layers panel next to an example modal. There are more than 30 layers in the list, with more running off the page, and the layers are nested at 6 layers deep. Various layers have their visibility turned off.

The lesson

Ultimately, my point here is that I over-engineered this component. Figma has the capacity to be much more than a design tool, and sometimes I use it to engineer a UI. Clearly I enjoy doing that, and I even get lost in the weeds to achieve a deeply technical solution.

But design systems and asset libraries are just as much a user-centered design problem as any other publicly facing product. The whole reason we have design libraries is to keep components attached to a source of truth that the design system can govern. Our job is to provide easy-to-use components that don’t need to be detached by feature designers (the end user), and enough documentation to let the feature designer adapt to the pattern as needed. Over-prescribing, over-providing, and over-complicating the component will only increase the odds that the end user won’t be able to reverse-engineer its flexibility, get confused, and ultimately detach from the library anyway.

The simple solution

I learned this lesson the hard way here. While I’m proud of what I originally created for this modal guidance, I had to scrap a lot of it from the final deliverable. The modal that ended up in the library is simple — just a single resizable component with a placeholder to fill in with content from the end designer. I also created a couple of molecules and organisms that are available as templates (i.e., not structurally part of the component) which designers can use to guardrail their content.

Collage of screenshots showing the final deliverable. At the top left is a simpler selection of a few text elements that get reused on the modal. Top right shows those text elements in a stacked auto-layout frame. Bottom left shows a simple modal component with a title, 12 column grid placeholder, and a footer. Bottom right shows a couple templates that repurpose the text frames aligned on top of the modal’s placeholder 12 column grid.

Rather than rely on a bloated, overloaded component, my deliverable leans much more heavily on the accompanying guidelines. Designers can take the pieces and parts that are useful to them, but I know I can’t predict every future use case; I had to empower them to make some of the decisions themselves.

I don’t think I’ll ever stop exploring the depths of Figma features. I just enjoy testing the constraints of design tools. It’s no different than when I would pull Lego kits apart to see what else I could make with the pieces. But just like the wise designers at Lego know, their job isn’t to experiment with those possibilities themselves; it’s to deliver a kit that anyone can use.

Source: Joe Bernstein via UX Collective