Deprecation Telemetry: Data-Driven Component Removal
Deprecation telemetry turns removal from a guess into a plan. It's about tracking component usage in code and design files to see who's affected before you delete anything. The footgun is assuming a component is unused, only to break a silent consumer.
Why it exists
Design systems must evolve, which means old components must be retired. Doing this blindly is dangerous; you risk breaking applications that still depend on those components. Deprecation telemetry exists to replace guesswork with hard data, ensuring removals are safe, predictable, and don't introduce debt.
The mental model
Think of it like a census for your components. Before you decide to close a public service (deprecate a component), you need to know who relies on it. Telemetry—using tools to count usage—is that census. It tells you if a component is used by 100 teams or zero teams, fundamentally changing how you approach its retirement. Without it, you're just hoping you don't cause a problem.
How it works
The process involves two main activities. First, you identify a component to deprecate, often because it's being replaced or consolidated. Second, and most critically, you gather usage data. This is the telemetry part. You use tools like GitHub repository search or your IDE to find all instances of the component in code. Simultaneously, you use features like Figma Library Analytics to find all its instances in design files. This data informs the entire deprecation strategy, from who to notify to setting a final deletion timeline.
When to use it
Use it every time you consider removing or significantly changing a shared component, icon, or design token. It's essential when consolidating multiple similar components (e.g., several buttons into one), upgrading a component with breaking changes, or cleaning out old, seemingly unused parts of the system. The data you gather justifies the deprecation and helps you write targeted migration guides.
When not to use it
The only time to consider skipping it is if you have absolute, verifiable certainty that a component is unused, for example, a component that was merged but never adopted. Even then, a quick data check is a cheap insurance policy. Deleting without a deprecation process is a high-risk move reserved for cases where you can prove zero impact across all codebases and design files.
One canonical example
A design system team wants to replace three slightly different Button components with a single, more robust Button that takes a variant prop. Before deprecating the old ones, they use GitHub's search to find every repository that imports the old components. They also check Figma analytics to see which designers are still using them. With this list of affected teams, they can communicate directly, provide targeted migration guides, and set a realistic timeline for removing the old components completely.
Interview question
What is the main purpose of employing deprecation telemetry in a design system?
- a.To identify all consumers of a component before it is removed or significantly altered.Correct
- b.To determine which new components should be prioritized for development.
- c.To automatically delete components that are no longer in use.
- d.To track the performance and accessibility of existing components.
Why? this is the answer
Deprecation telemetry's core purpose is to gather data on component usage to understand who relies on it, enabling safe and data-driven planning for removal or significant changes. It does not automatically delete components, nor is it primarily concerned with performance, accessibility, or prioritizing new component development.
Just read this? Test yourself on what you have been reading.
Read the original → octopus.design
- #design systems
- #deprecation
- #telemetry
- #component lifecycle
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles