Most of what's written about design systems assumes you're building one. The pitch, the first components, the governance model, the launch plan. That's the content that gets written because that's the exciting part.
Almost nothing is written about walking into one that already exists, but that's the more common situation. The Zeroheight 2026 report shows dedicated design system teams growing again this year, and the same teams still under-resourced. What that looks like in practice is turnover – someone built the system, then they left, and someone else is running it now. Depending on the organisation, this has happened two or three times already.
I've walked into more inherited design systems than I've built from scratch, and the pattern is consistent enough that it deserves a name. Software archaeology is a term engineers have been using for decades to describe reading legacy code you didn't write, and the design systems version needs the same name. The first 90 days of it looks nothing like the first 90 days of building.
Excavation before audit
An audit asks what's broken. Archaeology asks what was meant.
Those are different questions, and mixing them up is the first mistake most inheritors make. You open Figma, see fourteen button variants, three of which look identical, and you conclude the previous team didn't know what they were doing. Six weeks later you find the Jira ticket where someone had a real reason you didn't have the context to see. The three identical buttons are three different behavioural contracts that happened to collapse into the same visual output. The naming was a compromise with the mobile team. The fourth variant that looks out of place is actually the one that's right, and the other thirteen are deprecated but not yet removed.
The audit mindset wants to fix this quickly. The archaeology mindset wants to understand it first.
I've written before that explicit mess beats implicit order. The inherited system is where you find out how hard that is to live by. You walked in, and you don't have the context yet. Your pattern recognition is calibrated to systems you've built, not this one. Anything that looks wrong might be wrong, or it might be load-bearing in a way you don't understand yet.
The rule I use is simple – before removing, changing, or rebuilding anything in the first 30 days, you have to be able to answer one question. Why is it like this? If you can't answer that, you're not ready to touch it. Sometimes the answer is truly lost and nobody remembers, in which case the rule bends rather than breaks. You document the gap, treat the component as potentially load-bearing until proven otherwise, and if you do change it, you make the change small and reversible. Software engineers have a version of this rule that goes back decades, which I'll come back to in the lore section. For now it's enough to know that the instinct to wait for context isn't new or soft. It's the discipline the good ones have built their careers on.
What to read first
You can read an inherited design system the way a senior engineer reads an unfamiliar codebase – there's a sequence, and doing it out of order burns time.
Start with the token layer, not the Figma library and not the components. Tokens are the part of the system that tells you what the previous team actually believed about structure. I've argued elsewhere that tokens have become infrastructure, and that framing is useful here. Infrastructure is readable. If tokens are well-organised with a clear semantic layer over primitives, the team that built it thought in systems. If tokens are a flat pile of color-blue-500 and spacing-24 with no semantic indirection, they were treating tokens as a spreadsheet. If tokens exist in multiple conflicting formats, probably there were two previous teams and they disagreed.
The token layer is also the fastest way to find the first contradictions. Compare the tokens in Figma against the tokens in code, and where they diverge you've found a decision point the system never resolved. That divergence tells you something about what the team prioritised – usually that the code moved while the design files stayed tidy, which tells you the canonical source was never actually declared. An undeclared source of truth is the single most common gap I see in inherited systems.
Read component architecture second. Look for the components that don't quite fit the pattern – a card in a library of flat components, or a button variant that takes eighteen props when every other component takes four. These are the places where the system bent to accommodate something. Treat them as scars rather than bugs, because each one has a story behind it.
Read the contribution history third. Git log for the code repo, Figma file history for the design library, the archive of any design system meetings or RFCs if they exist. You're looking for two things – when did major decisions happen, and who was in the room. Both will be gone from the team by now, but the artefacts remain, and the decisions you can date tell you what was reacting to what. A big token overhaul three weeks after an acquisition tells you something, and a component deprecation the week before a design lead left tells you something else. If the artefacts themselves are missing – because the repo was migrated, the Figma file was rebuilt, or nobody wrote decisions down – treat that absence as information too. A system without a contribution history is a system where decisions have always been informal, which tells you that the lore you need is entirely in people's heads.
Read documentation fourth, not first. Documentation of an inherited system is almost always out of date. Reading it first calibrates you to what the team said the system was. That's worse than being uncalibrated, because it gives you false confidence that you understand what's there.
The lore problem
Every design system that's been running for more than about two years has lore – decisions made for reasons nobody wrote down. A component that exists because one PM in 2023 had a strong opinion and the team capitulated. A token architecture that looks broken but was a deliberate workaround for a platform constraint that's since been fixed in the platform. A naming convention that seems inconsistent until you realise the inconsistency maps to the org chart of the team that existed at the time.
Lore is the part of the system that isn't documented and can't be inferred from the artefacts alone. It lives in the heads of whoever was there. When those people leave, the lore leaves with them.
You have to divide the lore into two categories in your first weeks. This is where Mitch Rosenberg's first law of software archaeology earns its place in the design systems conversation. Everything that's in the system is there for a reason, and Rosenberg identifies three possibilities. It used to need to be there and no longer does. It never needed to be there and whoever added it had no clue. It still needs to be there and you have no clue. Until you know which applies, don't modify it. This is the rule I referenced earlier, stated more precisely.
Here's what that looks like in practice. You find a button variant with a tight prop that reduces its vertical padding by 4px, with no documentation and no usage in the main product. Rosenberg's three possibilities are all live. Maybe the tight variant was for a legacy modal that no longer exists. Maybe the original developer added it speculatively and nobody used it. Maybe three internal admin tools depend on it and nobody on the current team owns those tools. The only way to know which reason applies is to find out – not to infer from the artefact, to actually find out. If you can find out, the variant stays until you know which category applies. If you really can't find out after trying, you mark it as unknown in your lore log and treat it as potentially load-bearing – the default is caution, not removal.
In design systems the first two collapse together in practice, because you remove them either way. It's the third category that has to earn its own name.
Load-bearing lore is the decisions that would have been documented if anyone had thought to, and that still matter – a component that looks redundant but exists because an accessibility audit flagged something, or a naming convention that looks arbitrary but was the compromise that ended a three-month cross-team dispute. Breaking load-bearing lore accidentally is how you lose credibility in your first quarter, because the team that's been here notices immediately and stops trusting you. If the load-bearing lore is itself the thing that needs to change – and sometimes it really is – you do that work later, with the people who care about it in the room, and with the understanding that you're re-litigating a resolved argument. That's a legitimate project. It just isn't first-90-days work.
Vestigial lore is the decisions that were made for reasons that no longer apply – the workaround for the Safari bug that was patched years ago, the prop shape that was designed around a CMS constraint the company no longer uses, the component variant that existed because one team was using a framework the rest of the company migrated off. Breaking vestigial lore is free, because nobody will defend it. The reason it existed is gone.
The hard part is distinguishing them. You can't do it from the artefacts alone, you have to ask. This is why the first 30 days should be weighted heavily toward conversations with whoever's still around – the engineer who's been on the team for four years, the designer who remembers the last refactor, the PM who ran the project where the weird variant got added. They carry the lore in their heads, and most of them will tell you if you ask directly, because nobody asks.
If there really is nobody left – a fully replaced team, an acquired product where the original team dispersed, a system that was handed down through three rounds of turnover before reaching you – the work gets harder but not impossible. You widen the search to adjacent people. The engineers who consumed the system but didn't build it. The product managers who reviewed work that used it. The designer in a neighbouring team who filed bugs against it. Their knowledge is partial, but partial knowledge of the system is still more than the artefact alone will tell you. The work takes longer, and your lore log has more gaps, but the method is the same.
The questions that surface real lore are rarely the obvious ones. "Why is the Button component like that?" gets you the official answer, the one people have rehearsed for stakeholders. The real lore comes from asking about regrets and what-ifs. What was the hardest decision you remember making on this, what's the thing you always have to explain to new people, what would you have done differently if you'd started over, what's the piece of the system you'd touch last if someone told you to clean it up. That last one surfaces load-bearing lore faster than anything else, because people are cautious about the parts of the system they know are holding something up. They'll tell you what to leave alone before they tell you what to fix.
Write the lore down as you hear it. Every piece that comes up in a conversation becomes a row in a document – not a beautiful doc, a messy running log. What the decision was, roughly when it was made, why, and whether the reason still applies. Dan Donald's Gotrino is building this into proper tooling, and until that's standard practice, you do it by hand. The log is your only defence against re-making decisions the team already made.
The first change you ship
The conventional advice for any new role is to spend 90 days listening before acting. For inherited design systems, that advice is almost right and slightly wrong.
The problem with pure listening is that the team stops believing you're going to do anything. Design systems teams are often seen by the rest of the org as the team that ships nothing, and you showing up and shipping nothing for a quarter confirms the suspicion. Your political capital for the next year gets set in the first two months.
The first change you ship matters, and what it should be is specific. It shouldn't be a rebuild or a major component. It should be something that demonstrates you understand the system as it exists and can improve it without breaking it. The best candidates are usually in one of three categories.
A documentation fix. Find the thing people are most often confused about and fix the doc, keeping the fix small and making it visible. This costs almost nothing and signals that you're reading what's there rather than reaching for the redesign.
A contract tightening. Find a component whose prop API has grown messy over time, pick the one where the mess is causing the most downstream pain – often a component that's being used in ways the original API didn't anticipate – and tighten the contract without changing the visual output. This is unglamorous work, but it's the kind the experienced engineers on your team will notice and respect.
An exception you make explicit. Find an undocumented exception, the kind every mature system accumulates, then document it, name it, and flag it as exception rather than rule. This does two things – it makes the system easier to read accurately, and it signals your disposition to the team. You're not here to pretend the system is clean, you're here to name what's actually going on.
Any of these three is better than trying to ship a visible new component in your first 90 days. New components are what the inheritor wants to do, and they're almost never what the system needs.
The political reason to ship one of these three early is that you're managing three different audiences at once. The team you inherited needs to see you respect what they built. Your manager needs to see evidence of momentum. The broader product org needs to see that this time, something is actually moving. A small, precise improvement satisfies all three. A rebuild satisfies none of them, because the team feels overruled, the manager sees no output for months, and the product org sees nothing shipped. Three stakeholders are making up their minds about you in the first two months, and the first ship is your shot to give them data.
What not to do
Most failure modes here come from the same mistake. You act from the mental model of the system you used to work on rather than the one you now own.
Don't rebuild. The urge is overwhelming, and I've felt it every time. You walk in, the system looks wrong, you can see what a better version would be, and you want to build that. The problem is that the inherited system has accumulated context you don't have yet, and rebuilding from a position of incomplete context is how you reintroduce the bugs the previous team already solved. Rebuilding is also the largest possible version of the move I wrote about in We're getting better at the workaround. You're choosing the comfortable path around the real work, which is reading what's there. Joel Spolsky wrote the definitive argument against rewriting working software back in 2000, using Netscape's three-year rewrite as his case study. His central point was that the crufty-looking parts of a codebase encode hard-earned knowledge about corner cases and weird bugs. The same is true of design system components. The one you think is badly designed might be badly designed. It might also be the fourth iteration of a component that the team tried three simpler versions of before arriving at this one.
There are systems that do need rebuilding – a system built on a framework the company no longer uses, a system that was built for a product that pivoted and now the tokens and components reflect a brand that doesn't exist anymore, a system so undocumented and so small that the cost of archaeology exceeds the cost of starting again. These cases exist, and what they have in common is that the decision to rebuild comes after the archaeological work, not before. You don't know the system is beyond saving until you've actually tried to read it. The practitioners I've seen make a clean rebuild decision always have a detailed audit behind them. Rebuilding as a first instinct is the failure mode. Rebuilding as an evidenced conclusion is a legitimate call.
Don't rename things in the first 90 days. Names have gravity in design systems. Every rename ripples through the codebase, the Figma library, the documentation, the mental models of every team that uses the system, and the muscle memory of everyone who types <PrimaryButton> without thinking. A rename you do in month two for good reasons will still cost you goodwill you needed for the harder work in month eight. Wait until you have the credibility and the context.
Don't deprecate components whose usage you haven't traced. I've seen people deprecate a component on the assumption it's unused, only to find out it was the component that three internal tools were built on, and those tools had been deprioritised to the point that nobody currently on the team remembered them. The component wasn't unused – its users were just invisible.
Don't publish your audit. The audit document you make in the first few weeks is for you, and it contains observations, assumptions, and rough judgments that you'll need to revise. If you publish it, you commit to positions you don't yet have the context to defend. Keep it private until month three at minimum.
The inheritance you're actually doing
The thing I keep coming back to with inherited systems is that you're not inheriting components. You're inheriting decisions. Each component is a frozen argument between whoever was in the room when it got built. Each token is a compromise. Each prop name is a vote that won. The practical consequence is that when you look at a component, the question isn't "is this good" but "what did this decide". Once you're asking that question, the piece of the system in front of you starts to read differently, because you're looking for the decision rather than judging the output.
The work of the first 90 days isn't fixing the system. It's reading the decisions accurately enough that when you do start changing things, you're adding to the argument rather than restarting it. The team that built the system isn't around to defend their choices, so you're the one reading what they meant. Read wrong and your mistakes get stacked on top of the original ones, and the next inheritor can't tell which layer is which.
A design system is built in layers. When the decisions stack cleanly, that's the benefit. When they don't, each layer makes the system harder to read. Archaeology is the work of reading back down through the layers before you add your own.
Start with the tokens. Ask why, as often as it takes. Write the lore down before you change anything.
The system you inherit is already telling you what it needs. It's just not using words.
Thanks for reading! If you enjoyed this article, subscribing is the best way to keep up with new posts. And if it was useful, passing it on to someone who'd find it relevant is always appreciated.
You can find me on LinkedIn, X, and Bluesky.
The Claude Code skill pack I've been building, Design System Ops, does some of this work with you.
Member discussion