How repeated design-review feedback inspired me to build a plugin that detects design-system drift, guides fixes, tracks improvement, and keeps designers in control.
It started with a comment I heard regularly from my manager and senior designers:
“Use the design system components in your designs.”
It was good advice and essential for maintaining consistency across a large product.
Our design system already contained reusable components, typography styles, color variables, spacing tokens, and interaction patterns. It gave designers a shared foundation and helped developers build consistent experiences.
But having a design system did not automatically mean every design remained connected to it.
As our team worked across different journeys, modules, files, and deadlines, design-system drift still happened.
A designer might detach a component to make a quick adjustment. A color could be entered manually instead of using a variable. Text might visually match the system but have no linked style. Spacing values could slowly move away from the approved scale.
Designers were moving quickly, solving product problems, responding to feedback, and trying to meet deadlines.
The real problem was that we did not have a fast and reliable way to check everything before a review.
That made me ask:
What if designers could audit their own work before sending it for review?
That question became DSLint.
The hidden cost of design-system drift
A design system is meant to create consistency, improve collaboration, and reduce repeated decisions.
But publishing a design system is only the beginning. The larger challenge is adoption.
In a production design file, inconsistencies can include:
- Detached component instances
- Local components replacing approved library components
- Hardcoded colors
- Missing text styles
- Unbound variables
- Off-scale spacing and padding
- Fixed layouts that should use auto layout
- Deeply nested structures
- Low-contrast text
- Small touch targets
- Generic image-layer names
- Finding these issues manually is slow.
A reviewer may need to open every page, inspect nested layers, compare values with variables, check component sources, and leave feedback.
The designer then fixes those findings and sends the file for another review.
The process can work for a small number of screens. It becomes difficult to scale across many designers, files, journeys, and product teams.
Moving from reminders to automation
The repeated feedback was useful:
“Use the design system.”
But reminders alone could not solve the problem.
Designers needed feedback while they were working not several days later during a review.
I wanted to create something that could:
- Scan a design automatically
- Detect design-system inconsistencies
- Explain what was wrong
- Navigate to the affected layer
- Recommend an appropriate fix
- Ask before making any change
- Track whether the file improved over time
That became the foundation for DSLint.
Introducing DSLint
DSLint — Design System Linter is a Figma plugin that scans designs for design-system drift.
Designers can scan:
- Selected layers
- The current page
- Every page in a file
- Results are organized into eight focused areas:
- Overview
- Components
- Typography
- Colors
- Variables
- Layout
- Accessibility
- History
The goal is not only to report issues.
DSLint helps designers understand where an issue exists, navigate to it, and safely resolve supported findings.
Components
The Components tab identifies:
- Detached component instances
- Local component usage
- Unavailable library sources
- Eligible components that can be re-linked
- For supported cases, DSLint can reconnect detached designs to their source component while attempting to preserve compatible:
- Text content
- Fills
- Visibility
- Opacity
- Dimensions
- Position
- Layer order
- This reduces repetitive reconstruction while keeping designers in control.
Typography
The Typography tab classifies text as:
- Library styled
- Locally styled
- Unstyled
- It compares font family, size, and weight with available text styles.
- When a suitable match exists, DSLint displays a confidence-scored recommendation that the designer can review before applying.
Colors
The Colors tab groups colors as:
- Hardcoded
- Variable-bound
- Style-bound
- Hardcoded colors are compared with available color variables.
- Instead of showing the same hex value repeatedly, DSLint groups matching colors, shows their usage count, and suggests relevant variables when a close match is found.
Variables
The Variables tab checks whether properties are connected to system variables.
It audits properties such as:
- Fills
- Strokes
- Spacing
- Padding
- Corner radius
- Stroke weight
- Layers are classified as:
- Fully bound
- Partially bound
- Unbound
- A hierarchical tree helps identify whether a warning belongs to a parent layer or a more specific nested child.
Layout and spacing
The Layout tab measures:
- Auto-layout adoption
- Fixed-layout usage
- Spacing values
- Padding combinations
- Sizing inconsistencies
- Nesting depth
- Spacing-token alignment
- When raw spacing values do not match the approved scale, DSLint can recommend the nearest token or numeric value.
Accessibility
DSLint also flags potential accessibility concerns involving:
- Text contrast
- Gradient contrast
- Small touch targets
- Small text
- Generic image-layer names
- Gradient contrast is evaluated across multiple points behind the text rather than relying on one assumed background color.
- If white text sits on a dark gradient and passes contrast, DSLint leaves it unchanged.
- If white text appears on a light gradient, DSLint can recommend an accessible darker color.
- If a gradient contains both very light and very dark areas and no single foreground color can pass everywhere, DSLint recommends reviewing the background or adding an overlay instead of applying an unsafe fix.
These findings are advisory and do not replace a complete accessibility evaluation.
From detection to guided remediation measuring design-system health
DSLint combines component usage, typography coverage, and color-variable adoption into a visual consistency score. Scan history and page-level breakdowns help teams measure whether system adoption improves over time.
Many linting tools stop after identifying a problem.
I wanted DSLint to reduce the gap between detection and action.
Supported fixes include:
- Re-linking components
- Applying text styles
- Binding colors to variables
- Snapping spacing to tokens
- Adjusting contrast
- Resizing touch targets
- Increasing small text
- Every supported design-changing action uses an Apply/Cancel confirmation.
Running an analysis does not modify the design.
This helps designers focus on high-impact issues rather than working through an unstructured list.
The History tab stores recent scan summaries and shows whether design-system health is improving.
For full-file scans, DSLint also provides a page-level breakdown so teams can identify which areas need attention first.
Human-controlled adaptive learning
DSLint includes an adaptive feedback system.
When designers accept or reject supported recommendations, that feedback can influence:
- Recommendation confidence
- Suggestion ranking
- Preferred color-variable mappings
- Preferred text-style mappings
- Spacing preferences
- Issue priority
- This does not mean DSLint changes files autonomously.
Learning improves supported recommendations. Designers still approve every design change.
Designing for large Figma files
Performance became an important part of the project.
Large files may contain thousands of layers, nested instances, text styles, variables, images, and pages.
A useful plugin will not be adopted if it freezes during analysis.
DSLint therefore includes:
- Layer counting
- Scan progress
- Elapsed time
- Estimated time remaining
- Page-level progress
- Cancellation
- Batched processing
- Cached lookups
- Indexed color matching
- Indexed typography matching
- Long operations pause regularly so Figma can remain responsive and the user can still cancel the scan.
What I learned
> Building DSLint taught me that design-system governance is not only a documentation problem.
It is a feedback problem.
Designers need feedback while they are working not only after completing a journey.
They also need more than a list of violations.
Good design tooling should:
- Explain the problem
- Locate the affected layer
- Show why it matters
- Recommend a safe response
- Ask before changing anything
- Measure improvement
- Learn from user decisions without removing control
- I also learned that automation must be careful.
- A technically valid change is not always the right product decision. That is why DSLint emphasizes confidence, transparency, confirmation, and human control.
Who DSLint is for
DSLint is designed for:
- Design-system maintainers tracking adoption
- Product designers checking work before review
- Design leads reviewing files before handoff
- Teams conducting recurring design-system audits
- Organizations trying to reduce repetitive compliance work
- What comes next
Future opportunities include:
- Custom team rules
- Baseline-versus-current comparisons
- “Only show new violations”
- Responsive-readiness checks
- Naming-convention audits
- Theme-mode coverage
- Shareable reports
- Design-system gap detection
- Stronger team-level governance
The longer-term vision is:
> Inspect → Remediate → Track → Predict
Final thoughts
DSLint began with a repeated reminder:
“Use the design system.”
It evolved into a broader question:
How can we make design-system compliance easier, faster, and more useful for every designer?
The answer was not another document or checklist.
It was a tool embedded directly into the design workflow.
Audit. Locate. Improve.
DSLint is coming to Figma Community.
Try the plugin: Figma Plugin DSLint - Design System Linter
Read the case study: [Coming Soon]
Thank you for reading & Share your valuable feedback in the comments section <3
Design Systems · Figma · Product Design
Top comments (1)
Sounds useful, but also sounds like a ton of work to develop this, not a simple thing!