Building in quality – why bother?
An industrial printing press with rows of red and gray machinery, and a worker operating controls at a console in the background

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.



A large red and white industrial printing press in a factory floor setting. The press is the length of a room, with an operator overseeing it on one end. There is a walkway between the press and a large console to operate it. The press is moving with a continuous roll of paper moving between a tower and the front of the machine.

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.

I love your analogy here Grant. I'll never forget when early in my freelance design career I tried to get fancy with Pantone metallic spot colors for a New Year's Eve poster and ended up wrecking a print job that ultimately cost 4x my fee. I was lucky the printer set aside his frustration and took the time to show me my mistake and walk me through the correct set-up. I didn't get paid for that job, but I learned valuable lessons that improved my craft and my approach to working with technical partners: Talk to each other early and often, especially if we aspire to do something new! In digital production, often these moments get absorbed into timelines without healthy conflict and resolution, ultimately costing businesses more than it should to ship quality products. The work you and Jui-Ting Sun are doing on top of Figma's already powerful tools is so thoughtful and considerate of the real pressures digital product teams face. Our tooling can aspire to bring us together and be better creative collaborators. Not by automating craft out of the process, but by making it easier to see and improve across our functions.

要查看或添加评论,请登录

Grant Blakeman的更多文章

  • Building in quality – get comfortable with details

    Building in quality – get comfortable with details

    Part two – Automating peace of mind So much of our work is really about communication. What is in a Figma file is…

    9 条评论
  • The Messy Overlap

    The Messy Overlap

    I stumbled into Design Engineering. I didn’t set out to become one, but in a way I suppose I have always been one… I…

社区洞察

其他会员也浏览了