Faulty Assumptions and Unwanted Features of Most Web Design Tools

The broken traditional web design process frustrates everyone involved. Web design software makers saw this pain and built features to help. Unfortunately, these features don’t help as much as the software makers hope.

At best, they are unwanted features to be ignored. At worst, they reinforce faulty assumptions that undermine design systems.

I recently wrote about the problems with the traditional design system process and how static mockups—what most design tools output by default—don’t capture the full breadth of design decisions. These issues are amplified when organizations adopt design systems.

Because a design system component will be adopted by many teams, a well-considered component will address:

• Multiple use cases
• What variations to support
• Interaction and behavior
• Animation
• Responsive design
• Different types of input
• Accessibility
• Performance

The bar is higher for design systems. As Nathan Curtis explained:

Design systems must be made to a level of quality to meet or exceed what every adopting team requires. Team(s) resist using features from somewhere else if they feel they do it better themselves.

Because so much effort goes into a design system component, you generally want the component to be used wherever possible. If the design system team spent long hours refining and testing a component, then you should leverage that hard work instead of starting from scratch

On the development side, reuse is common so long as the design system team provides components in a format others can adopt. Perhaps the design system uses framework-agnostic technology like web components or vanilla HTML, CSS, and JavaScript. Or if the organization has standardized on one framework, the design system can be built on top of it.Footnote 1

On the design side, things are more difficult. While most design tools provide shared library functionality, these shared libraries aren’t based on the design system code because most design tools don’t provide a way to import design system components.

Because of this, designers often maintain their own copies of the design system components in their chosen design tool. Unfortunately, a facsimile will not have all of the characteristics of the original design system.

To be useful, designers must maintain this design system copy, but it is unlikely that this effort is prioritized and funded by the organization. So even if the copy of components in design tools starts out with parity to the source design system, over time they tend to diverge.

What happens when a developer receives a mockup that deviates from the design system? How do they know which design deviations were intentional and which were merely mistakes made while trying to replicate a responsive web experience in a static mockup design tool?

A few years ago, Tyler Sticka described what happens when static mockups are tossed over the wall to well-meaning developers. While Tyler wasn’t writing specifically about design system component copies in web design software, the process and the outcome he describes resonates.

In his hypothetical scenario, a designers creates a new element which they hand off to a developer:

The developer implements the design in code, and the end result looks a bit off from the mockup:

Maybe, as Tyler suggests, the developer is “well-regarded for their HTML, CSS and JavaScript skills, but they are not a trained designer” and this accounts for the differences from the mockups. But it is easy to imagine deviations between the mockup and the design system components contributing to the lack of fidelity.

The designer then responds by “attaching a detailed spec which takes longer to prepare than the original mockup:”

What do the designer and developer take away from this interaction? They learn that handoffs are difficult. And the designer begins to believe they need to create detailed, prescriptive specifications.

To me, these detailed specifications are more evidence that the traditional web design process is broken. Design software makers reached a different conclusion. They look at the detailed specs and think, “Ah ha! We can create those!”

Web design tools like Marvel tout how they generate extensive documentation for developers. Marvel has a lovely animation that describes handoff as a key selling point for their app:

At first glance, this seems like an awesome feature. Instead of spending a bunch of time documenting your design, your web design tool provides all of the specifications to the developers. But when you dig a little deeper, the problems become apparent.

What does this image tell us? Not as much as I suspected the designer intended. The dotted lines and measurements document the margins around the avatar. But are those margins fixed? Or are they going to change based on the viewport size?

Do the measurements even matter? The margins are equal on both sides of the image. Could it be that the design intent is for the avatar to be centered and the pixel measurements provided happen to the center for this particular viewport?

Generating code is the newest web design tool hotness. But how useful is this code? We don’t know if these sizes need to change responsively. And the code generated is ignorant of any existing components, design tokens, or other use cases.

I chose Marvel app as example because I admire their animation, but I could have picked nearly any web design tool. Figma. Sketch. Adobe XD. Framer. UXPin. Zeplin. They all have handoff features. Many even use the same language about turning “handoffs into handshakes.”

Does it make sense for developers to adopt code from design tools? The code generated by design tools is unlikely to be a good fit for organizations—particularly for those using design systems. Design tool generated code will likely:

• Be fixed width and not responsive
• Fail to use design system conventions and tooling
• Lack design tokens or subcomponents
• Reflect one specific use case

And when it comes to a design system, is this code the best to standardize on and replicate across multiple teams? Does this code meet the higher quality bar that design systems must reach?

Even if the code generated by design tools is useful either as a guide or, less likely, as production code, I’m just as troubled by what these code generation and specification features say about the way these design tools view their role in relation to the design system.

Design tools often treat static mockups as the source of truth instead of the web-based design system. And frankly, anything that doesn’t exist in the medium, can’t be considered the source of truth for the web.

So far, we’ve been looking at broken processes and tools. Next time, we’ll look at a process that works, and unfortunately, why more organizations have difficult adopting it.

Permalink to This article is part 3 of a series on design tools in a design system world:

This article is part 3 of a series on design tools in a design system world:

1. Traditional Web Design Process is Fundamentally Broken
2. Design Happens Between Breakpoints
3. Currently Viewing:Faulty Assumptions and Unwanted Features of Most Web Design Tools
4. Responsive Design Process that Works
5. Web Design Tool Wish List
6. [Coming soon]