Building in quality – why bother?

Part one – The hidden costs of missing information

I didn’t start my career in engineering or product design, I entered design through print. And doing work in print meant knowing what “CMYK” stood for, physical site visits for press checks, and—maybe most importantly—how to prepare a design file so that you didn’t piss off your printer. And by printer, I mean the actual person that would have to deal with your lack of knowledge on the other end of the process as they did their work to make screens or plates or whatever was needed to ready a particular job for the press. You wanted this person on your side. You wanted them to want to help you when you missed something small because there was no way to get things fixed if they came off the press incorrectly.

Depending on the size of your team and its velocity, mistakes can be fixed quickly, quietly, and sometimes without notice. But you still need your engineering partners on your side…

We take much of this for granted in product design today. Depending on the size of your team and its velocity, mistakes can be fixed quickly, quietly, and sometimes without notice. But you still need your engineering partners on your side—you still want them to want to help you out when you’ve mistakenly specced the wrong design system component or provided the wrong color. And, you still want to hand them the best possible starting point for their work—it’s a “help me help you” situation.

In print, we learned how to pre-flight a document—review typography, color assignments, artwork assets, and other bits that would trip up the print production process if they were missing. It was part of the job to learn some of these basics, just in the same way it’s part of a product designer’s job today to become proficient in some of the more technical aspects of their team’s design system and engineering handoff process (if there is one).

Dev Mode is amazing, but it only amplifies the information that’s already in the file—if a token is missing or a component is wrong, that information is not communicated.

Today, Figma makes so much of this easy—click on any layer in your file and you can see the color(s) applied, the typography styling, the spacing, the component it belongs to, etc. But when it comes time to hand something off to your engineering partners, it can still be a very manual process to audit everything in your shipping frames and ensure the correct tokens were used. Dev Mode is amazing, but it only amplifies the information that’s already in the file—if a token is missing or a component is wrong, that information is not communicated.

At LinkedIn, teams move fast and everyone is understandably pressed for time. In building out a Figma mockup, information is often lost without anyone realizing it in the design review process. The file then gets handed off and assumptions are made. For example, a detached component can mean that custom code gets written—causing a cascade of unnecessary bugs—when something from the design system would’ve worked in its place. Or new color tokens get requested because of a hex value in Figma when, ultimately, they weren’t necessary. Even in the best scenario, our design peers and managers are needing to click through individual layers trying to catch things that are off-system.

There’s a cost to all of this, even if it’s rarely directly attributed

There’s a cost to all of this, even if it’s rarely directly attributed—Dev Mode is amazing, but it only amplifies the information that’s already in the file—if a token is missing or a component is wrong, that information is not communicated.

In print design, that pre-flight process isn’t manual. There is software that would help me check through a file for errors, missing information, and then even assemble the supporting files (typefaces, images, etc.) that the press would need. The project wasn’t ready for the printer until I’d pre-flighted it.

In engineering—on most teams—you cannot commit your code into a main branch without running automated checks on it. Linting (a fancy word for style-checks), tests to ensure something didn’t break, and other requirements are automatically vetted when code is submitted. An engineer knows they’re not done until those checks pass. You wouldn’t ask a peer to review your work if the linting check failed, for example.

I’m not even sure that there’s agreement on whether or not these things are part of the job of a product designer. But if it’s not part of their job, whose job is it?

But on many design teams, there isn’t a set process or an automated way to ensure that a text layer is in fact color-text and not #000000. I’m not even sure that there’s agreement on whether or not these things are part of the job of a product designer. But if it’s not part of their job, whose job is it?

What if you could automate these checks—custom to the design system, or even the team? What if in design reviews nobody had to worry about color tokens or type styling, but could focus on the higher-level design work? Several of us within Design and Engineering at LinkedIn had been asking ourselves these questions. We knew a few 3rd-party Figma plugins could help, but they weren’t specific to our design libraries. We liked the idea of adding our own quality-check plugin to the suite of tools we had already built. But custom or not, asking designers to remember to open up yet another tool—training them on how to use it, and then hoping they would—felt daunting.

Figma’s Dev Mode feature provided us with a unique opportunity—not simply because engineers in the company were increasingly using it to view files, but because designers were starting to mark their shipping work “ready-for-dev”. Designers’ files contain many, many iterations of work, but if we knew what they were focused on shipping, could we use the Figma REST API to scan a file, find its dev-ready frames, and look for commonly-missed issues? Could we find things that pull a design off-system or create extra work for someone in the future? My teammate, Jui-Ting Sun , and I created an experiment to answer these questions. More on that later this week…

This article is the first in a two-part series. Read Part Two.