The term originates from a Unix utility that examined C language source code.” - Wikipedia
#Figma design system code#
“Lint, or a linter, is a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs. Using his plugin allows us to quickly relink to the appropriate missing attribute. He has helped make this process so much faster for myself and designers by creating a design linter that goes through and checks for unlinked typography and colors.
#Figma design system android#
Then I move on to relinking to LPL’s color attribute.Īt Lyft, I work with a talented Android engineer, Alex Lockwood, who dabbles in Figma plugin creation. I go through each text layer, and if needed, I relink them to LPL’s typography attribute. Typically I focus on relinking attributes within the design first when creating my redlines. The inspect panel helps communicate key information such as Typography and color details by a nickname. Important component information is displayed in the Inspect panel that supports the build process Engineering partners: you will be able to see the nicknames when you navigate to the Inspect panel in Figma where this information is displayed (see below image). By using these nicknames in both design and engineering, we successfully have created a way to communicate on the same page. We recommend that our designers use these attributes because there is a code equivalent labeled by a nickname. Spacing, typography, and colors are all attributes in the Lyft Product Language (LPL). But I also like to include extras that go above and beyond to help streamline the build phase. Most of the work is focused on the structure and foundation of the design like spacing, typography, and colors. I admit, redlines can be tedious, but I always put extra time and effort into them knowing this will help my engineering partners work more efficiently. Having all parts of the design process from concept to handoff saved in the file provides a single source of truth for the project and a great resource for future iterations. Since my current workflow is centered in Figma, I have evolved that part of my process by creating a new page within the design file labeled “? For Engineering”. In the past, I used Zeplin to deliver redlines to product engineering. Redlines are the final deliverable and signal to engineering partners that they can commence the build process. They transform into a communication resource between design and engineering, and through them, I want to ensure that everything the design needs to say is captured without question. But this behavior elevates engineering-ready mockups because redlines become more than just a design spec. I fuss over the details the curse (and superpower) of a production-minded designer. Pixel-perfection is something I care about a lot, especially when creating redlines. This blog post discusses how I provide pixel-perfect mockups to engineering partners that focus on presenting the necessary information, creating a seamless handoff experience. This allows me to think about the best way to handoff mockups from design to engineering. Over the years, I’ve internalized a quality checklist that I employ in these situations to help ensure mockups are build-ready. And as an added level of quality, I also assess any UI that can be swapped in for components that already exist in the Design System. Typically, my support role is focused on ensuring that mockups are cleaned up and pixel-perfect before being given to product engineering. A Product Designer, I’ve been able to collaborate and partner with many product teams.