Ligma

Figma has been in the news lately, probably as a result of their Config event where they announced a bunch of new features. Vercel’s CEO gave a talk about something-something React Components, I think. That, in turn, seems to have spawned a few takes about Figma really being an unnecessary intermediate step: designers should just write HTML and CSS. I disagree.

The speed of thought

I feel like I should probably establish my credentials first! I’ve been doing web development for over twenty years now, about evenly split between frontend and backend. I’ve coded up and documented design systems in CSS, I’ve hacked together unholy tag soups using shameful position: absolute !important rules, I’ve been a Semantic Classnames stan, I’ve been a BEM convert, I’ve been an insufferable Tailwind proponent, I’ve seen attack ships on fire, etc. And while I would never consider myself a “good designer” I’ve taken design and typography courses, made illustrations and logos, and designed websites from scratch for friends and family. So I think I’m fairly well positioned to deliver my ultimate take on designing with markup, which is:

It’s just too slow.

Just as with programming, you need a tight feedback loop. Design involves a lot of exploration. Things like “maybe I can improve hierarchy by moving the help text into its own column over to the left” or “there should be a chevron there, but it probably needs to be in a circle or it’ll look awkward.” Design is usually the place where you SHOULD explore: making a couple of design versions of a feature or a page is cheap, simple to distribute, and can be done in whichever fidelity you like. Having to fiddle around in markup to make your grid resize correctly and align your icon vertically instead of just plonking that chevron down where you think it should go? Way too much friction.

And what’s the artifact you produce at the end of the day? Do you produce standalone static HTML, which developers then have to translate into real code with all its messy loops, data fetching, and null checks? That’s just as much doing-it-twice as drawing it in Figma. And speaking as a developer, when implementing a feature it’s often easier to write your own code from scratch with a visual reference, rather than copying and pasting and adapting things that others have made before filling them with real content.

Do you work directly in your app? Progress will be even slower! You’ll have to set up test data, maybe get your system in the state you’re designing for, open PRs as you go, break tests that require help to fix. These things are okay if you’re actually building out a finished, specced feature, but entirely unsuited for more open-ended exploratory work.

Sketch, Figma, Photoshop and friends allow skilled designers to move at an incredible pace. Like any art form, whether it’s composing music or writing blog posts, the quality of the end result is ultimately very dependent on your working memory and your ability to quickly follow a thought where it wants to take you. Yes, some of that speed is achieved at the cost of not having to think about viewport sizes or buttons line-breaking in Finnish (Sisäänkirjautuminen anyone?) but I promise you those issues will crop up even if your designer hands you an HTML component. It’s hard to make the case for designers tearing their hair out trying to remember the syntax for radial-gradient when the color picker in Figma lets you effortlessly throw those hues and handles around.

Limits and constraints

The other thing that’s often touted as an advantage of having to design in-browser is that it forces designers to know their limitations. If you can’t get it on the screen, it’s not meant to be. It’s against the grain of the medium: implement it or forget it.

The problem I have with that is that CSS is hard. Way harder than people give it credit for. Any fool can get a decent flexbox layout going, but design ideas like adding animated underlines or a padded background color to every other line usually means finding someone with a proper-ass specialization who knows how to conjure these tricks from the browser with just the right amount of position: relative; and pig’s blood. It’s great if a designer knows these things, of course! But the argument that “designers need to stick to what they can reliably put on the screen” just seems to add another level cap to your app’s design: it’ll never be better than your designer’s skill at CSS, even if your frontend dev is a wizard. You might use words as sensible or pragmatic if a designer is limited by their knowledge of markup and CSS, but you could just as easily say conservative and risk-averse.

Priors

I guess, as with most things, that everyone’s opinion on this is going to differ depending on where they come from. I’ve been fortunate enough to work with some spectacularly talented visual designers in my day and we’ve all grown up alongside the Internet, probing at its limits, trying to stand out and see what we could get away with. I’ve also greenfielded a whole bunch of projects, which maybe skews my opinion here ‒ if your experience of design work has been one of slow iteration and feature building on a mature project with a rich and reliable design system you might draw different conclusions.

But the fact remains that I absolutely love being handed a beautiful Sketch file by someone who knows how to make typography, hierarchy, and color sing. I get to consider how to slice it up, how to re-use, how to standardize, how to get data to where it needs to go. I’m good at that. Doesn’t matter if starts out a bit janky when your German translation gets a case of Langwortfröhlichkeit or the tablet mode is kinda half-baked: your design is your plan, and no plan ever survives contact with the enemy. As long as your designer is good at what they do and fun to work with, you’ll tackle it together. And if they’re good at Figma, if that’s how they translate what’s in their brain to what’s on the screen, let them use Figma. No need to hamstring them by demanding they use their Web Inspector and the other side of their brain.