Should we expect UI designers to build their designs?

Whenever I’m discussing the topic of the skillset that UI designers should possess, I tend to use the analogy “I bet Michelangelo knew how marble behaves before he started carving David”. While UI development is a very complex field, I’m always a bit baffled when I meet a UI designer who has never written a line of code of any kind, or even more bafflingly, doesn’t know CSS. But I recognise these are my own biases, because I’ve carved my way into the industry with, what I think, is a pretty basic knowledge of writing HTML and CSS and an adventurous mindset that has led me to poke my forks into the codebase (often to the chagrin of the devs).

I’m more of a form follows function kind of guy and perhaps not the most detail-oriented person when it comes to pixel perfect, eye-candy filled designs, which explains my stance. But when we’re building a product with our team at Sakeus, we believe that the best way to understand the customer needs and validate both the customer’s assumptions and our own regarding the problem and solution space is to get our hands dirty and build something.

So what is the issue? Can’t designers just do their designs in Figma and then hand them over to the devs? That seems to be what a lot of companies are doing, but I think there are several issues with this approach:

1. The designer may have designed something that is not technically viable to implement, leading to developers having to figure out (lazy or haphazard) solutions to make it work.
2. The designer may have designed the UI for the feature in isolation, without holistically considering the user journey and the overall product, leading to inconsistencies and a disconnect from the user’s perspective.
3. The opportunity to iterate on the designs doesn’t come around until the developers have built the feature instead of the designer being able to iterate on the designs as they’re building the feature.

Design Systems International’s Rune Madsen also wrote about this in The Gulf Between Design and Engineering blog post last year (you should read the whole post if you haven’t already):

The most crucial mistake in the collaboration between designers and engineers happens when we conflate this division of tools with a need for a strong division of labor. Treating design and engineering as two completely separate processes leads to an isolated waterfall workflow where designers first get to dream up ideas in static tools, and engineers then implement the desired features when they are ready for development. The design handover, this supposedly magic moment where design has finished and engineering begins, is the root cause of many of the collaboration problems that product teams have. The process is extremely slow because designers build complex prototypes that are completely detached from the complex systems developers build. This approach effectively doubles the work while also affecting the quality of the product. When the initial phases exclude viewpoints from engineering, it’s harder to make early decisions that can improve the outcome of the project. Likewise, when designers are not an integral part of the development process, they miss integrating crucial design decisions that could not be anticipated in a static simulation, and risk losing focus on the user experience for the betterment of a simpler codebase or a faster sprint cycle. All in all, the waterfall process between design and engineering makes for bad digital products that take a long time to build.

These issues can be mitigated by involving a non-developing designer in other ways, like having them test the features and give feedback on the user experience to the developers. But when the client is invoiced by the hour, it’s hard to justify just having the designer around to point to the developers that the buttons are supposed to be bigger until the business case can be validated with end-users. And that leads to Madsen’s point of the designers falling off the development process and thus not understanding the requirements of building the product at the level that they should.

I’m not advocating that all designers should be developers, and we certainly work in Figma a lot at Sakeus as we plan and iterate on the products we’re building. It certainly helps take off a lot of cognitive load from development when you have some sort of “target render” to work towards. But I think designers should have an understanding of how the web works the way Michelangelo had an understanding of the properties of marble. At bare minimum, I think they should know HTML, to understand what the basic elements of building the products they are designing are, and CSS, to be able to 1.) understand the constraints of what you can design and 2.) to be able to iterate on the designs during development (and fix the developers’ mistakes, because they often aren’t as detail oriented when it comes to the UI). This will not only lead to better products and workflows, but also makes the designers more valuable to the team.

With the new and fancy AI tools like Cursor and Github Copilot there’s even less reason not to get your hands dirty with the codebase, but I urge you that you should at least know the basics of what you’re asking the AI to do for you. If nothing else, they enable designers to work in the same environment as the developers and build proofs of concepts in actual code, which, I think, is a step forward from just having static UI designs.