Hand-coding in a Figma world

The dominant pattern in design education and design hiring, in 2020, is for designers to make a thing in Figma and hand it to a developer. The developer translates the Figma file into code. The designer reviews the result. The cycle continues.

This is not the only pattern, and not, I think, the best one for small studios.

The minority pattern, which the studio has been operating on for a few years now, is for the designer to make the Figma file as a sketch, throw it away, and write the front-end code as the actual deliverable. The HTML is the design file. The CSS is the spec. There is no handoff because there is no separate handoff layer.

The advantages, in plain order.

The design responds to the medium. Decisions made in code take into account, automatically, the things the medium does well and badly. Letter-spacing on a Mac at 1x looks different to letter-spacing on Windows at default scale, and the designer who is writing CSS sees the difference immediately. The designer who is signing off Figma files does not see the difference, often, until the site is in QA.

The cost of a small change is small. The biggest single source of friction in the Figma-to-developer model is that small changes (move this 4px, lighten this colour by 5%) take disproportionately long to round-trip. In code, they are immediate. The designer can iterate to the right answer rather than guessing once and committing.

The deliverable is the deliverable. The Figma file is not a thing the user ever sees. The HTML is. Treating the Figma file as the deliverable, when it is in fact a sketch, is the mistake at the centre of most of the deliverable-versus-implementation gap that designers complain about.

The disadvantages, in plain order.

The designer has to know how to write the code. This is, in 2020, less of a barrier than it used to be. The CSS needed for a typical small-business marketing site is, in 2020, a small subset of the spec. A working knowledge of HTML, CSS, and a little JavaScript will cover ninety per cent of what the studio is asked to ship.

The team scaling argument. Once a studio is more than a few people, the hand-coding model creates a coordination problem. The minority pattern is, in practice, a small-studio pattern. It does not generalise to fifty designers and a thousand engineers.

The model that I think works best for small studios is: the designer-developer is the default role; the pure-Figma designer is the exception, used when illustration or visual specialism is required; the pure developer is added when the project’s logic exceeds what the designer-developer is comfortable shipping.

A few designers writing about this approach more thoroughly than I am: Trent Walton, Ethan Marcotte, and Jeremy Keith. All three have been working in this mode for years. All three are worth reading.

The Figma-first model has its place. The Figma-only model produces, in my experience, a worse class of work, by designers who have outsourced the part of the job that mattered most.