Mind the Gap

For as long as I’ve been working as a designer, I’ve been fascinated by how the design tools we use influence the way we think and work together. When there are big shifts in the enabling technology landscape, our design tools evolve to take advantages of the new capabilities. When the changes are significant enough, we often discover something about how we really want to be designing.

Once such shift occurred when Figma was invented. Figma’s key insight was understanding that organizations of people design software, not individual designers. Most software is made by teams of people who all have an important role to play. They all need to see a design, and contribute to the design, and shape the thing the design represents.

Figma’s brilliance was to figure out that software makers need their design tools to live in the space that connects all these people together — just as the system of record for code needs to live in the space that connects developers together.

Figma outcompeted the Sketch + InVision combination because it collapsed the distance between designing and sharing designs. No upload was needed, no translation needed. No re-uploading and re-translating each time a design was updated. With Figma, read-only designs were simply a permissions setting, rather than a completely different data format. Figma eventually won because organizational designing was a more fundamental need than design review.

Figma utilized advanced web assembly techniques to build a design tool native to the web and browsers. When you have a web-native design tool, the cost of delivering a read-only view essentially goes down to zero, and the time to deliver it to eyeballs is the same as it is for designers that need to make changes in real time. Figma’s solution changed the economics of design collaboration by making it essentially free and able to operate in real time.

It’s hard to overstate how profound this is or how far ahead of the curve Figma was. The desktop CAD software industry has still not fully digested Figma’s key insight, which is now more than 10 years old. If anything, the design of buildings, infrastructure, and machines is even more an organizational activity than writing software.

---

Figma is an excellent demonstration of how shifts in the enabling technology landscape can help us to find better ways to use computers to design complex things made to operate in the real world.

Just as Sketch and InVision were built upon a foundation of ideas that were shaped by the capabilities and limitations of the underlying enabling technology landscape of their time, so too are design tools like Figma.

I’m going to use my journey of building this site as a way to call attention to some of foundational assumptions that may start to be no longer be true with the advent of useful LLMs that can write workable code in response to natural language requests.

Let me start by calling out the first:

One of the foundational assumptions behind Figma is that making changes to software is expensive. When making changes to software is costly, it’s a good idea to figure out what you want to build well in advance.

So what happens if making changes to software suddenly gets significantly cheaper? I think it gets much harder to make the argument that it’s worth doing most of your high-fidelity thinking about the shape of software independently from the software you hope to create.

---

When I was creating this site, there was a point where it made sense to stop designing in Figma and make the remainder of the design decisions in the site itself. This point happened far earlier than I anticipated.

The primary design challenge for this site was to figure out the responsive layout behavior. When you need to squeeze in a lot of content on something like a phone, it’s going to require a different solution than displaying the content on a 4K monitor. In the space between these two extremes, there are a lot of different devices to consider: big phones, landscape phones, small and large tablets in portrait and landscape orientations, 1080p monitors, 1440p monitors.

When you add all of these variations up, the design of the site ends up being a lot more involved than it would initially seem, and the challenge becomes laying everything out to make sure it fits, just as you would if you were moving into a new home and needed to make sure that all your furniture was going to fit into the new place.

In Figma, the more variations you have to deal with, the more effort it is to fully detail out the design. Figma does have some conveniences in place to make this easier, but generally these conveniences require being willing to utilize Figma components, component auto-layout, styles, and variables. These aren’t rocket science, but they operate according to their own logic which only superficially reflects the logic of web browsers and CSS. Many of these capabilities were added to Figma later in its gestation, so they’re nestled in weird corners of the design tool (yes, I’m talking about you, variables).

If you want the benefits of having design elements in Figma to approximate how they might behave as parts of live applications, then you need to fully take on Figma’s idea about how to lay out and organize all the different parts of a design on a two-dimensional surface.

It’s better to have these things than not, but they do come at a cost and can be pretty fiddly if you want to have the freedom to move things around and try a bunch of options.

I often think that the price of designing in Figma is that you have to be willing to think like Figma prefers. The more you want to take advantage of the things that make Figma good for designing websites in a production capacity, the more brittle and locked in the design becomes.

This isn’t a criticism of Figma — I think the choice Figma’s designers made here was a reasonable one to make — it’s just that if your mind isn’t particularly Figma-shaped, it’s hard to ever reach flow state with this tool. I much prefer to work loose first, and structure things only once I decide the design is ready for this.

One of the challenges I find with Figma’s auto-layout behavior is that it makes a lot of assumptions around how components will react to having their parent frames stretched and resized. Sometimes these assumptions are correct, but on many occasions they are not. Unfortunately, the rules that govern their behavior aren’t visible and can’t be easily tweaked, which is especially problematic for a design tool. Even something as simple as modifying the position of an element governed by auto-layout frequently can’t be achieved without breaking the component, repositioning the item you want, reassembling the component, and then turning auto layout back on.

The behavior of Figma’s auto-layout feature only approximately matches the way that browsers and CSS behave, but the differences are significant enough that you end up juggling the weirdness of Figma’s auto-layout behavior and the weirdness of browsers and CSS. All of this comes at some cognitive cost.

This is a lot of overhead to deal with if what you really want is a responsive website that behaves well when the screen is resized. Beautifully structured designs in Figma isn’t the goal, Having the website deliver content to eyeballs across a wide range of devices is the goal.

Up until quite recently, this overhead could be justified, owing to the fact that many designers don’t speak CSS natively and moving things around in Figma was considerably cheaper than moving them around in code.

Prior to building with the help of AI, If you wanted to have as much control over the final product as possible, doing the detailed design work in Figma was the price you needed to pay. You had to make the detailed pictures so that when you handed the design over for building, your front-end developer could understand what the work would entail and what you wanted the final product to look like. Going to the effort to be thorough in the ask is one of the ways that designers show their respect for the challenges that come with getting web browsers to do what you want them to do.

After building this site, I’m not so sure that this is how designing is going to continue to work in the future.

---

When I started this project, I decided that I’d only lay the basics out in Figma to ensure the site was going to work in principle. The rest of the design work would happen directly on a working version of the site itself in Cursor. I wanted to understand whether incorporating AI into my process would result in my having more or less control over the shape of the thing I wanted to create.

The experiment worked far better than I could have anticipated. I built the site up key feature at a time, and worked through the responsive behaviors as they came up.

I even built some tooling in the site to help in the process — a debugger overlay that displayed the current screen width and the breakpoint range. This made it possible for me to describe the changes that I wanted such that Cursor could understand what I wanted without fail.

Cursor made working with the content management system, HTML, and CSS feel like working with clay. It allowed me to rough out a fully functional but basic site, and then sculpt it until it was just as I wanted. I was able to work by tackling the big rocks first, followed by smaller rocks.

This fits my style of thinking far better than Figma does, which is organized around the idea of content being contained in nested frames whether you’re ready for this or not.

The thing that was interesting to notice was that it was much faster and easier for me to make design decisions on the site itself than it would have been in Figma. I didn’t need to wrestle with the Figma’s auto-layout behavior. I could make style changes and have them cascade appropriately across elements that shared the same CSS. There was no drift between an idealized design and the working site as is typical.

Building and designing with Cursor gave me significantly more control over the layout than I could do in Figma, and the whole process was much faster than if I had detailed everything out in Figma and then had to translate this into HTML and CSS, grappling with the inevitable mismatch between as-designed and as-built.

I was also interested to observe that I didn’t design more of the site than I needed to. When coding is expensive, it’s common to attempt to design a lot more than will ever actually get built. You try to anticipate all of the possible edge cases you might run into, just to build confidence that the core of what you’re going to build will handle enough of the key problems. I didn’t need to do this. When there was a problem with the design, or something I missed, I could see it instantly and come up with a new solution, and see if that made it better within the span of minutes.

Essentially, this project incorporated a much higher percentage of my design time because the act of designing had merged with the act of building.

And by designing at the point where ideas turn into working code, the site got better faster — as did my ideas. The more I understood how the underlying content management system worked, the more sophisticated I could get in what I asked for. The rate of improvement accelerated over the duration of the project and I got to be surprised by where it (and I) ended up.

This sense of surprise is perhaps the most profound part. When the design tools we use condition us to supply them with every detail of the design before our ideas can be turned into software, then the design tools we use ultimately ask us to narrow our thinking — and limit our expectations for what we’re making. By specifying how we expect the final, dynamic product to be through static pictures, we leave very little room for it to become something else, or something more.

---

Coming back to earth, one designer using AI coding tools to build out a custom blog isn’t the same as an organization designing a software product meant to serve a large number of people. I had the luxury of taking shortcuts and could move to coding before having everything worked out. It’s hard to imagine an established product team being willing to do this — yet. Figma still offers a great deal of value.

It’s also worth noting that this blog wasn’t asking very much from a technology perspective. Because this site is made of the same stuff as the web, and this is what LLMs have been trained on, anything I asked for was a relatively simple pattern matching exercise. If ever there were an LLM-shaped problem, it’s this project. It was almost purely happy-path from an AI usage perspective and so it’s not a real test. Making software under real-life conditions is a lot messier and dynamic than this, and the consequences for fucking up are much greater.

By doing the rough designing in Figma but making all detailed design decisions directly in working software, it helped me notice how static designs are far harder to evaluate than a working product. No newsflash here. We always notice the things we missed when we can see our designs moving.

Being able to resize the window and see how the site reacted, and then make changes directly to the site was significantly easier and faster. Just dealing with the quirks of layout in web browsers was far more direct than having to cajole Figma to be able to handle all of the variations I thought I might encounter. There’s a big difference between trying to imagine all of the possibilities versus dealing with them directly. The first gives you the illusion that you’ve anticipated everything, and the second just lets you solve the problems as they occur.

Another benefit of shifting design over to working software as quickly as possible is that while I was making changes, I was using the thing I was making. Clicking on links, reading text, looking at images, watching to see how the site responded to different screen widths, etc.. I was directly engaged with how the content management system operates, and gained first-hand knowledge of how it “thinks”. The more you understand the underlying capabilities and limitations of the technologies you’re building with, the more effectively you can design for it. This also seems like an important signal.

---

My experience building and designing the site with AI coding tools makes me think about the gap that Figma originally collapsed between designing and design review.

People tolerated this gap and assumed it was just the cost of doing business when there weren’t any alternatives. We believed there was a distinction between designing and collaborating because that’s all the technology would allow.

Once people started to see the benefits of designing in software meant for organizations of people, and once they saw that it was possible to do without the impedance of having to prepare and curate designs for sharing, Figma took off.

My experience of designing and building this site with the help of AI coding tools leads me to think that just as Figma enabled organizations of people to design software, I think we’re going to see a new set of technologies and tools change the nature of designing again.

It won’t be because the computer industry finally figured out how to make the easy button that can one-shot a fully realized design that does all the things. It’ll be because designers can directly shape and learn from the actual things they are helping to invent, and that’s honestly how it should be.