> Blog post by Lokesh Saini
> Canonical (HTML): https://www.lokeshsaini.com/blog/designing-the-thing-that-outlives-you

Every design system I have seen that decayed did so the same way: the founding designer left, and the next person found something too tangled to own. They did not deliberately break it. They just worked around the parts they did not understand, and the workarounds accumulated, and after six months the system was a legacy problem rather than a shared resource.

The system survived launch day. It did not survive the handover.

I spent two years as the first designer at a healthcare startup, building a design system from nothing. By the time I left, the system had absorbed a full rebrand and two designer transitions without disrupting delivery. About forty features shipped with no gaps traced back to the system. The replacement designer was productive from their first feature file.

That outcome was not luck. It was the result of a specific decision I made early: I was building for the designer who would come after me, not for myself.

## Simple Enough to Be Owned

There is a version of a design system that is impressive to look at and painful to work in. Clever abstraction layers. Components that inherit from components that inherit from components. Naming conventions that encode meaning only the founding designer holds in their head.

This system is built for the person who designed it. It is fast for them, because they know the implicit rules. For anyone else, it is a puzzle box.

I made a deliberate choice in the opposite direction. Every decision in the system had to pass one test: could a designer who had never seen this codebase look at it and understand the intent within a few minutes? If the answer was no, the decision was too clever.

This meant simpler token architecture than I might have chosen if I were optimizing for myself. It meant naming conventions based on plain descriptions rather than abstract category codes. It meant documenting not just what components did, but why specific design decisions were made.

Simple to own is a constraint, the same way WCAG AA is a constraint. It shapes what you build.

## Conventions Over Cleverness

The system used Atomic Design as its organizational layer. Not because Atomic Design is the best possible organization scheme, but because it is legible to designers who have never worked on this product. Any designer who has encountered component libraries before can orient themselves immediately. The familiarity reduces the onboarding cost before they even read the documentation.

I learned to prefer conventions over clever solutions everywhere they applied. When there was a choice between an elegant internal pattern and a pattern that matched how the ecosystem broadly worked, I chose the ecosystem pattern. The point was not to build the most sophisticated system. The point was to build a system the team could run without me.

This extends to file organization, naming hierarchies, and the way components are documented. The system standardized a consistent file structure: a README layer, a handoff layer, feature files, and a backbone.

Any new feature file started from the same template. No searching for the right place to put things. No judgment calls about structure. Just follow the convention.

## A Rebrand as a Stress Test

About halfway through my time there, the company rebranded. The visual identity changed substantially: different colors, different typography direction, different feel. For most design systems, a rebrand is a significant disruption. Designers rebuild foundations while trying to keep delivery running.

Because the system was built on a proper token architecture, the rebrand touched the Foundations layer. The higher-level components, the molecules and the organisms, did not need to change. The new palette and new type treatments flowed through to the components automatically via the tokens.

The transition happened without pausing feature delivery. That was the architectural decision validating itself.

## What Survived Two Transitions

The first designer who came in after me onboarded to the system and was contributing to feature files within their first sprint. The system had a Visitor Manual, a document explicitly for new designers joining the product, that explained what existed, how to navigate it, and what conventions governed contributions.

I wrote that manual for a specific, imagined person: someone with solid design skills, no context on this product, and a feature to ship in their first two weeks. Not a tutorial. Not a comprehensive reference. A document calibrated to that person's specific need.

The second transition happened during a period of significant regulatory pressure. The system absorbed it without resetting. Features kept shipping. The work I left behind kept working.

## Designing Your Own Obsolescence

The mark of senior design work is not how much you personally produced. It is what kept running after you left.

This is a strange thing to optimize for, because the incentive structures of most teams do not reward it directly. You are recognized for what you shipped, not for the quality of the handover. But if the handover is clean, the team's velocity after your departure is a direct measure of the leverage your work had.

I think of it as designing your own obsolescence. Build the system so thoroughly, so legibly, so documented, that the team barely notices when you are gone. Not because you were unimportant, but because you built something that absorbed your importance into the work itself.

That is what durability actually means. Not that the system never needs updating. All systems need updating. Durability means the next person can update it without tearing it down first.