Applied Filters
Checking what shipped against what was designed
Design debt rarely announces itself. It accumulates quietly: a pill background that's close but not quite right, a filter button using text where the spec calls for an icon, a mobile drawer behavior that was never implemented. Individually minor. Together, they erode the credibility of the design system.
This was a systematic check of the live search results experience against updated Figma specs, across desktop, tablet, and mobile, to document exactly where the shipped product diverged from what was designed.
When a feature ships, does what users experience match what the design specified? If not, what's different, and does it matter?
I authored the updated Figma specs for the applied filters component across all screen sizes, ran the comparison against the live product, severity-rated every gap, and triaged the findings with the product manager to separate deliberate decisions from implementation misses. The output is a structured issue list engineering can prioritize directly.
Exact values, not impressions
"That gray looks a little off" is not an actionable bug report. Instead of comparing by eye, I pulled the actual color, spacing, and sizing values the live product was rendering and set them beside the spec values. That turns a matter of opinion into a matter of fact: either the numbers match or they don't, and the conversation with engineering gets much shorter.
Coverage ran across four screen sizes: 1440px desktop (default and sidebar states), 768px and 600px tablet (layout row structure), and 375px mobile (filter panel behavior).
Eight gaps, severity-rated. The full set:
| Severity | Gap |
|---|---|
| Critical | Mobile filter panel opens as the desktop sidebar instead of the specced 300px drawer overlay |
| Critical | Sidebar doesn't auto-collapse at smaller viewports, covering pills, search bar, and results on load |
| Critical | Pills keep the full category label at 375px instead of the specced short form |
| Incorrect | Filter button is a text button instead of the specced funnel icon with counter badge. A different component, not a styling miss |
| Incorrect | Clear All missing from its inline position in the pills row; only reachable inside the sidebar |
| Minor | Pill background rgb(244,244,244) vs specced #e7e6e5, all screen sizes |
| Minor | Tablet rows stack separately instead of consolidating into one row per spec |
| Minor | Section headers (Company / Project Filters) omitted, pending confirmation whether intentional |
The one that matters most
The mobile drawer is the headline finding. The spec defines a right-edge drawer at 375px: 300px wide, with a header, close button, active filter count, Clear All, section headers, and a sticky Apply button. The live implementation opens the full desktop sidebar at every viewport width. Combined with the auto-collapse failure, applied filters are effectively invisible to a mobile user on load.
That's the distinction worth drawing. Three of these eight are cosmetic and can wait. Three change whether a mobile user can see what they've filtered by. Sorting the list that way is the actual work; finding the gaps is the easy part.
Not every gap is a bug. Some reflect deliberate decisions made during build that were never backported to the spec. Triage with the product manager sorts findings into three buckets: ship-blocking, backlog, and deliberate deviations where the spec is what needs updating.
That third bucket is the underrated one. A spec that silently drifts from the product stops being a source of truth, and every future audit inherits the noise. Triage is in progress; the ship-blocking mobile issues are the ones being argued for first.
Most portfolios show the work that goes into making something. This is the work that keeps it made. Checking the live build against the spec at every screen size, then driving the gaps to resolution with engineering and product, is what separates a designer who hands off Figma files from one who owns the outcome. The component isn't done when the spec is approved. It's done when what users see matches what was designed.
It also surfaced something true about design at scale: a spec is only as useful as the process for enforcing it. Finding these gaps was valuable. Having a repeatable method for finding them is more valuable.
What worked: Pulling exact values instead of comparing by eye took the subjectivity out of it. When you can put rgb(244,244,244) next to #e7e6e5, nobody has to debate whether it looks different.
What I'd do differently: Run the check before the feature ships, not after. Every gap here was cheaper to fix during the build than it is now, and the mobile drawer never being implemented is something a shared breakpoint checklist between design and engineering would have caught in the first sprint.
What this points at: The value isn't the eight issues. It's that the method is repeatable, and that a spec nobody checks against is just a picture.