Blog Post
You Lint Your Code. Why Don't You Lint Your UI?
UI linting applies automated quality gates to the visual layer of your product — catching spacing errors, color mismatches, and typography drift the same way ESLint catches code style violations. This article explains why every engineering team has seven quality layers for code and zero for design, and how design QA fills the gap.
Your team ships a feature. The code passes five quality gates. Linting, tests, type checks, CI, code review. The PR is clean. Merge. Deploy. Someone opens staging. The button is the wrong shade of blue. Spacing is off by 12px. The font weight is 400 instead of 500. Nobody catches it until a designer sees it in production a week later. This team has world-class code quality. Their UI quality process is "hope someone notices."
The Quality Stack You Already Have
Here's what runs on every commit at a modern engineering team: linting (ESLint, Prettier), type checking (TypeScript), unit tests, integration tests, CI pipelines, code review, and monitoring. Seven layers. Each catches a different class of problem. Some are automated, some are human. All are non-negotiable. Nobody questions whether you should lint your code. It's just how you ship software.
The Quality Stack You Don't
Here's what happens when a developer implements a design: designer hands off a design file, developer builds it, maybe the designer reviews on staging if they have time, ship. That's the whole process. No automated comparison against the design spec. No structured checklist. No fidelity score. No CI check that flags drift. Seven layers for logic. Zero layers for what users actually see.
This Isn't a Tooling Problem. It's a Process Problem.
Design drift doesn't happen because teams are sloppy. It happens because there's no defined step in the pipeline where someone checks whether the implementation matches the design. Code review checks logic, not visual fidelity. QA testing checks functionality, not design accuracy. Designers are already working on next sprint's features. The gap exists because nobody owns it. UI quality is where code quality was 15 years ago. The fix isn't a new tool. It's a new step.
What Design QA Actually Looks Like
Design QA is a step, like code review. Not a department. It happens pre-merge, takes 10-15 minutes, and answers one question: does the implementation match the design intent? Four things to check: does it match the design? Is the design system intact? Does it work in motion? Is it accessible? Attach it to PR review, give it an owner, start with a checklist, and timebox it to 10-15 minutes per PR with UI changes.
The Cost of Not Doing It
A design inconsistency caught pre-merge takes about 5 minutes to fix. The same inconsistency caught post-launch takes 45-60 minutes. That's a 10-12x cost multiplier. If a team ships 10 design inconsistencies per sprint, that's ~50 minutes total caught pre-merge versus ~8-10 hours total caught post-launch. The gap isn't just visual quality. It's engineering time that could go toward building features.
Frequently Asked Questions
What is UI linting?
UI linting is the practice of applying automated or semi-automated checks to the visual layer of a product. Just as ESLint catches code style violations and TypeScript catches type errors, UI linting catches visual discrepancies — wrong spacing, mismatched colors, incorrect typography — before they ship. It is the missing quality layer in most engineering pipelines.
How do you lint a UI?
Compare the live implementation against the design spec at the component level. Use a visual comparison tool to compare the design against the staging build, then capture any discrepancies with their computed CSS values. File each issue as a ticket with expected-versus-actual values. This is the visual equivalent of running a linter on your codebase.
Why do engineering teams lint code but not UI?
Because code linting is built into the development workflow — ESLint runs on save, TypeScript checks on build, tests run in CI. No equivalent automation exists for visual fidelity. Design QA requires comparing rendered pixels against a design spec, which until recently meant manual screenshot comparison. Modern visual QA tools make this fast enough to fit into the PR review cycle.