The root causes for the dev-design mismatch

Designers use an unconstrained canvas tool to design for rule-based interactive systems, hoping the devs will perfect everything in production. This causes misalignment between designers and devs.

There are two persistent issues that keep plaguing the product design and development worlds. The first one is very much on the surface, and thus — no surprise — gets both a lot of attention and a plethora of sometimes reasonable solutions. The second one is much deeper, more subtle, and easier to miss.

Let’s start with the first one — the handoff problem.

There are, in fact, several reasons why the handoff process is a major problem:

1. Friction, and with it the potential for mistakes in a handoff, causes the actual coded products to differ from the designers’ intentions, as captured in their design tool. The only experience that matters is that of real users with the real-coded product. Not getting the designs perfectly reflected in the final product makes the process ineffective and demoralizing.




2. Handoff wastes a lot of time for designers and developers. It takes a lot of mental effort to encode and decode all the relevant info for building the screens correctly. A designer must over-communicate with specs, examples, comments, and documentation, while a developer must inspect the designs with paranoid, detective-level vigilance, sometimes squinting to avoid missing anything.




3. Handing designs to developers to build from scratch creates a redundant, atrophied artifact. Once the code is live, it diverges from the source of truth, creating a never-ending race to ensure the design file and the ‘reality’ match. When that pairing is inevitably broken, a chain of mistrust builds. Developers see outdated designs and feel justified in ignoring parts that seem out of touch with ‘reality.’ As a result, designers become hyper-vigilant, hunting for mismatches between the design and the implementation. This occurs frequently when developers choose a library as the optimal solution for a component and do not properly match the specified styling.




4. The need to hand designs over forces designers to waste time on things they usually don’t like or value that much. It’s not the peak of creativity to specify and document all the ways a text field should be able to render in the product. Especially knowing that this is not the actual thing being built, but only a disposable artifact. It forces front-end developers to focus on tasks of little joy or meaning as well. Recreating an already designed screen in code while chasing down designers to verify how things should reflow when the viewport gets smaller or larger is no fun either.

Since those problems are quite clear, the motivation for solving them was, and still is, high.

And so there were two general directions for solutions that the market allowed to evolve:

One was a path of helper apps to the most popular canvas design tools. It started with tools for easier inspection (Avocode, Zeplin, Simpli, Abstract). Then, design tools added inspection features (like Dev Mode in Figma, Sketch, XD, and InVision). After that, specific tools appeared. These included Zeroheight and InVision’s DSM for easier documentation. Many plugins also emerged in the Sketch and Figma marketplaces, like Anima, Locofy, and other ‘Figma-to-HTML’ tools.

As far as I’m aware, there have only been two design/development tools that successfully incorporated a different, unifying strategy.

Flash (created by Macromedia, succeeded by Adobe, killed by Steve Jobs)

Blend for Visual Studio using XAML and the WPF platform from Microsoft.

Flash had ActionScript that allowed the same object to be freely designed by the designer and logically manipulated using ActionScript commands by the developer. This setup let all the relevant pros do their jobs. The designers focused on what was important, both experientially and visually. They didn’t need to hand off anything to developers, since they could just target the existing assets created by the designers. No throwaway artifacts, no handoff, and no limit to the complexity. Flash didn’t try to code for you. It allowed developers to pick up where designers maxed out their comfort zone.

Blend for Visual Studio had a similar story, but with different files, structures, and logic. It was a twin-environment setup. The designers could design, and the Visual Studio developers could target the exact same assets. Again, no handoff, no throwaway artifacts, and no limits on complexity.

As we all know, Flash died because of security and performance incompatibility with the iPhone. Blend and Visual Studio are now niche, unpopular tools. In all the surveys of tool usage in the last 7 years, I haven’t seen a single mention of them. Meanwhile, Figma has taken almost all the product design market share).

This has to lead us to the conclusion that the tools with the best approach are still not immune to failing for all sorts of other reasons. Business is a fickle and unpredictable game, indeed.

Now, as I’ve stated at the beginning, there are two persistent issues that keep plaguing the product design and development worlds. Let’s explore the more hidden, but an even more important issue:

Naive canvas-based tools hide the vast spectrum of design properties from designers.

When you have no gravitation, the default mode of everything is to be absolutely positioned in gradual z-index order, one on top of the other. Nothing pushes anything else. Nothing interacts. Paddings and margins don’t mean anything. Text doesn’t make boxes get larger when more words are typed in. Since there’s no viewport, no viewport-related measurements can be used; even percentages are almost never used. So almost nothing is relative.

Slowly, UI-friendly tools started appearing. Sketch opened the door for both XD and Figma. It did this by using components, overrides, a generic mapping of frame = div, and more visual qualities that can be parameterized (colors, typography, effects, and layout grids in Figma). It was a breath of fresh air, but the challenges rose in tandem with the tools.

The most technical designers felt the pressure to start experimenting with code by themselves. This gave them superpowers because it informed their otherwise naive stance about how the real world of UI programming works. A push towards getting more robust tools was felt, and the leading tools (Sketch, Figma, and XD) introduced Auto Layout, which was a slightly capped but friendly version of Flexbox. It was like having a mini-universe with DOM-like gravity inside a capsuled ‘auto-layout-enabled frame,’ inside a universe of a do-whatever-you-like canvas.

This was revolutionary. Designers began to consider how content affects container sizes. Layout reflow became more robust, and finally, padding mattered.

Savvy designers started building almost everything they had in the UI using auto-layout.

Now, let that sink in for a second…

In a universe with no gravitation, we are creating almost everything as a bunch of microuniverses with gravitation! Wouldn’t it be so much easier if the base default reality was the one with the gravitation, sort of auto layout by default!? Oh wait, that’s exactly how the web, iOS, and Android already work.