Think about the last site redesign your team shipped. The homepage probably held for a quarter or two before marketing wanted a campaign skin, product wanted a new onboarding flow, and the hero section everyone argued over got swapped without a goodbye. The buttons stayed, though. So did the form fields, the card layouts, the spacing scale, and the color tokens, which kept showing up in the mobile app, the customer portal, the sales microsite, and the admin tool nobody talks about.
That is the pattern worth planning around. The screens are the event. The library is the asset. If you scope, budget, and staff a redesign as if the mockups are the deliverable, you'll pay for the thing with the shortest shelf life and inherit the thing with the longest one by accident.
Before the Kickoff, Name the Real Deliverable
The first mistake happens before anyone opens a design tool. The statement of work describes screens, homepage, product detail, checkout, dashboard, and prices them like a finite set of artifacts. Nobody writes down that the components inside those screens will outlive the screens by years and ship into three other surfaces nobody has mentioned yet.
Fix this at the contract. Make the component library a named deliverable with its own scope, its own acceptance criteria, and its own budget line. Spell out which components are in scope, which states each one needs (default, hover, focus, disabled, error, loading), and who owns the code once it ships. See Designer Daily on why component libraries outlast redesigns for the plain version of the argument: the library is what the next team actually uses on Monday morning, and design shops increasingly partner with engineering to ship it as working code instead of mockups to be rebuilt.
During Design, Choose a Component Library Over a Pattern Library
The two terms sound similar and do different things. A pattern library documents how to solve a recurring problem ("this is how we do empty states") in prose, screenshots, and principles. A component library ships the empty state as code the next team imports and uses.
Patterns age fast because the examples look dated the moment the brand shifts. Components age well because the API stays stable while the look updates underneath.
Pick components as the primary artifact and keep patterns as supporting documentation. If you only have budget for one, the one that keeps shipping is the one engineers can import.
Go Deep Enough Into Atomic Design to Hit the Lasting Layer
Brad Frost's atomic design organizes a system in layers: atoms (a button, an input), molecules (an input plus its label and error), organisms (a full form), templates, pages. The counterintuitive part is that the lowest layers last the longest.
Pages get thrown out in the next redesign. Organisms get recomposed. Atoms and molecules keep going.
Spend accordingly. Over-invest at the bottom of the stack, where the work compounds, and resist the pull to perfect page-level comps that will be replaced. A good test: if the brand refresh landed next quarter, how much of what you're building survives? If the honest answer is only the atoms, you've scoped the project correctly.
Make the Tokens Portable So the Library Travels
A library that only works on the marketing site is half a library. Portability runs through design tokens: color, spacing, typography, radius, motion, and the rest, defined once in a platform-neutral format and compiled into whatever each surface needs.
Done well, the same token file produces CSS variables for the web, a Swift file for iOS, and an XML or Compose resource for Android. Done poorly, the web gets the real tokens while the mobile apps get a PDF of the brand guide and a prayer. Insist on token output for every platform the brand will ever appear on, including the ones that aren't in scope today. The second surface usually arrives sooner than the roadmap says.
After Launch, Give the Library an Owner
The failure mode in year two is orphaning. Marketing adds a one-off button for a campaign. Product forks a modal because the shared one didn't quite fit.
Nobody updates the docs. Six months later the "system" is three systems in a trench coat, and the next redesign gets pitched as the fix.
Name an owner before the final invoice clears. That can be a platform team, a design-engineering pair, or a single staff engineer with budgeted time; the title matters less than the calendar hours. Define a contribution path for people outside that team, a review bar for new components, and a deprecation process for the old ones.
The library is software. Software without maintenance rots.
Where This Lands for the Next Redesign
The redesigns that feel like money well spent two years later are the ones where the screens were the smaller line item. The team paid for a working component library, insisted on portable tokens, hired or contracted engineers who could ship the components as code, and funded someone to tend it after launch. The homepage changed again, as homepages tend to. The library kept shipping into every surface the business grew into.
If you're scoping a redesign now, flip the question. Ask what you want to still be using in three years, and put the budget there first.