Don't Be a Figma Mockup Slave

Designers in many tech companies hand down to the developer high fidelity UI mockups, built in Figma or some other design tool. In my experience, the best UI developers are the ones who treat their relationship with their designer as a two-way street. They offer feedback and suggest alternatives. Importantly, they reveal the API constraints of the design system and push back if what has been mocked up is not possible with whatever design system or component library they are using.

This push back needs to happen for there to be a healthy iteration loop that feeds back into improving the design system. The designer needs to be made aware of the decision and tradeoff of either evolving the design system or doing a custom job. An occasional custom job might be fine, but if there are too many, the developer needs to advocate for sticking to a system and improving it.

Unfortunately, I feel the perception of frontend code among many developers is that it is adhoc work with tons of arbitrary point decisions. I think this is why there has historically always been an undercurrent of thought that frontend is not 'real engineering' but moreso closer to a craft. I believe frontend engineers also fall victim to this thinking as it can be attractive to get stuck in some flow state pushing pixels around. But I would offer a different perspective and say to both the designer and developer that UI can be built in a systematic way with tunable plaform knobs akin to any well designed back end system.

I feel that sometimes the developer does not have the confidence or concern to have this kind of relationship with their designer. I often see devs throw up their hands with phrases like "I'm not a designer" or "I defer to design" when asked their opinion about UI design. This is understandable as sometimes it is easier to just implement what is given to you. But this kind of mentality - being a slave to the Figma mockup, can be harmful to the product in the long run. Doing too many custom jobs in the UI can result in layers of CSS rules and hardcoded constraints that implicitly depend on each other. Making your designer blissfully unaware of the cost of their proposed designs is a recipe for a UI codebase that is a house of cards. Over time, you end up spending more time doing archeology on layers of ad-hoc code than providing business value. The other devs on your team start to become scared to touch UI code as small changes start to have 2nd order effects. The UI starts to feel janky and inconsistent as devs don't realize the subtle damage they're doing to other pages as they are making changes in some part of the code base that was assumed to be isolated. You start to realize that you need UI integration tests to stop the regressions and this becomes another huge time sink.

Designers, by their nature, are inclined to think about the aesthetic side of design and can live too much in the Figma canvas. They can neglect how their mocks actually manifest in code. Developers can neglect to look at design as a generalizable systems problem and can fall into the comfort trap of being a Figma mock up slave. If both sides recognize that design systems are more than aesthetics and you have a relationship that pushes each other, I think this results in good, long-lasting design. When you have a designer and developer who recognize this dynamic, or a design-engineer or designer who can code, you have something special and rare that you should try to preserve.