extract

Turn repeated UI patterns into shared components and styles.

On this page 3 sections

Use extract when the same UI has been implemented in several places and changes are getting hard to keep consistent. Impeccable brings those repeated patterns into your design system and updates their existing uses.

A design token is a named value, such as an action color or spacing step. A shared component is a reusable piece of interface, such as a button. Both let you change a pattern in one place.

Try it

/impeccable extract the primary buttons used in ordering, account settings, and supplier management. Keep their current behavior and follow our existing component conventions.

Name the area to consolidate and the library it should use, if that is not obvious from the project.

How it works

  • Find the conventions: locate the shared components, tokens, and naming patterns. If there is no design system, ask where the reusable code should live.
  • Identify real reuse: look for patterns used at least three times with the same intent. Similar appearance alone is not enough.
  • Build the shared version: define the variants, values, and states the current uses need. Include usage guidance.
  • Migrate and check: replace the duplicated implementations, remove unused code, and verify appearance and behavior at each use.
Three screens, the same kind of action
OrderingReview order
AccountSave changes
SuppliersAdd supplier
One shared button<Button variant="primary">

Style and states come from the same component. Each screen keeps its own label and action.

Illustrative extraction: the screens keep their behavior while sharing the button implementation. Future improvements to that component can reach all three uses.

Extraction can include components, color and spacing values, text styles, repeated layouts, and motion settings. Reuse what the product actually needs. A component should fit its current uses without accumulating options for imagined future ones.

Check the result

Try the affected screens, including keyboard use, loading, disabled, and error states where relevant. Make sure the old implementations were replaced, not left alongside the new component.

Look at the component’s interface too: can another developer understand which variant to use? Does it follow the project’s conventions? Similar-looking controls with different behavior may need to stay separate.

Use document to record the visual system for future design work, or polish to resolve remaining inconsistencies in a page.