A public library catalog's web and mobile apps have years of bespoke UI; how would you estimate and contain the cost of retrofitting them onto a new design system?
answer
- cost is distance, not count
- sample, spike, extrapolate
- drop-in, adapt, redesign
- foundations first, components on touch
- visible change needs sign-off
basics
~20 sEstimate retrofit cost by timing a spike on a representative sample of screens and classifying usages as drop-in, adapt or redesign. Contain it by adopting foundations first, retrofitting components when screens are touched anyway, and prioritising high-traffic surfaces.
solid answer
~50 sRetrofit cost depends less on how many screens exist than on how far each sits from the system: custom widgets coupled to data and layout, overridden styles, and accessibility gaps that surface once correct components go in. I would pick a representative sample of the catalog's screens on both platforms, retrofit them in a time-boxed spike, and classify every usage as **drop-in**, **adapt** or **redesign**, which turns counts into an estimate with a range. To contain it: adopt foundations first, because swapping raw values for tokens changes a lot of surface cheaply; build every new screen on the system; retrofit components when a feature touches a screen anyway; and prioritise high-traffic flows such as search and item detail. I would also budget design sign-off and product-team time, and avoid a stop-the-world rewrite that freezes feature work.
go deeper
Recall that moving an existing product onto a design system costs real effort, and that it is usually done gradually rather than in one rewrite.
Explain what drives the cost — coupling, visual deltas, one-offs, exposed accessibility gaps, test churn — and why foundations are usually adopted before components.
Show a concrete estimating method (sample, spike, drop-in/adapt/redesign bands, a range) and a containment plan: new-work boundary, retrofit on touch, prioritising high-traffic flows.
Frame the retrofit as a funding negotiation with product teams: whose roadmap absorbs it, how long old and new UI coexist, and when an estimate should be revisited.
## What a retrofit is A **retrofit** moves an existing product, built with its own bespoke UI, onto a new **design system** — the shared foundations (tokens for color, type and spacing), components and guidance. Unlike a new product that starts on the system, a retrofit must replace or reconcile UI that already works, already has users, and is already covered by tests and expectations. Moving consumers off an *older* version of the system, with deprecation paths and automated code changes, is a different problem. This is about the first move from bespoke UI. ## What actually drives the cost Screen count matters less than **distance** — how far each screen sits from what the system offers: - **Structural coupling** — custom widgets entangled with data fetching, state or layout, which cannot simply be swapped. - **Visual deltas** — spacing, type and color that differ from the system, so every swap changes how a screen looks and needs design review. - **Overrides and one-offs** — local customisations with no system equivalent, each forcing a decision: redesign, request a new variant, or keep a local component. - **Accessibility gaps** — correct components often expose problems the old layouts hid, such as missing labels or a broken focus order. - **Test churn** — snapshot and visual-regression baselines change on every retrofitted screen. ## Estimating it 1. **Pick a representative sample** of screens on each platform — simple forms, dense lists, complex flows — drawing on whatever usage data a UI inventory already gathered. 2. **Run a time-boxed spike**: retrofit the sample for real and record the effort. 3. **Classify every usage** into an effort band: | Band | Meaning | Typical effort | |---|---|---| | Drop-in | A system component replaces the old one with no layout change | Low | | Adapt | The replacement needs layout, content or variant adjustments | Medium | | Redesign | No system equivalent exists; the flow needs design work first | High | 4. **Extrapolate with a range**, not a single number, and state the assumptions so the estimate can be revised after the first few weeks of real work. ## Containing it - **Foundations first** — replacing hard-coded values with tokens changes styling rather than structure, so it spreads the new visual language widely at low risk and shrinks later component swaps. - **A new-work boundary** — every new screen is built on the system, so the bespoke surface stops growing. - **Retrofit on touch** — when a feature changes a screen, its components move to the system in the same piece of work instead of in a separate rewrite. - **Prioritise by traffic and pain** — once patterns are proven, high-traffic flows deliver the most visible consistency per unit of effort. - **Avoid stop-the-world rewrites** — freezing feature work for a full rewrite concentrates risk, and such rewrites tend to overrun. ## Costs that estimates forget - Design sign-off for visible changes, and product-owner acceptance of them. - A period of maintaining old and new UI side by side. - Team time spent learning the system and its documentation. - Accessibility fixes that were always owed but only now become visible. ## Example: a public library catalog A catalog whose web and mobile apps have years of bespoke UI might move colors and type onto tokens across both apps first, then make every new screen system-only. The spike samples search results, the item detail page and account settings: search results are mostly drop-in, item detail needs adapting, and the mobile app's custom date picker for choosing a hold pickup date is a redesign. The estimate goes to product teams as a range together with the retrofit-on-touch plan, so the work rides along with features rather than competing with them for the same weeks.
- Why adopt design tokens before swapping components when retrofitting an existing product?Replacing hard-coded values with tokens touches styling, not structure, so it is low-risk and spreads the new visual foundations across many screens at once. It also makes later component swaps smaller, because the surrounding UI already uses the same color, type and spacing values the system components expect.
- What hidden costs does a retrofit estimate usually miss?Updating visual-regression baselines, fixing accessibility defects that correct components expose, design review of every visible change, a period of maintaining old and new UI side by side, and the time product teams spend learning the system. Leaving these out is a common reason retrofit estimates run long.
saying these in an interview costs you the question
- Retrofit cost scales simply with the number of screens in the product.
- The safest retrofit freezes feature work and rewrites every screen at once.
- Swapping in system components will not change how the product looks.
- Retrofit effort cannot be estimated, so teams should just start and see.
- Once the tokens are adopted, the retrofit is complete.