Capture a complete design system from a live website for reuse
Learn how to capture reusable typography, colors, spacing, components, and layout rules from a live website without claiming its private design system.
capture complete design system from a live website for reuse
To capture a complete design system from a live website for reuse, compare several representative pages and record the visual decisions that repeat. Organize the result into typography, color, spacing, components, layout, and visible states. Treat the result as an observed reference for your own work, not proof that you have the site's private or official design system.
Start with repeated evidence
Capture at least two or three different page types, such as a product page, application screen, pricing page, or documentation page. Look for details that stay consistent:
- Font families, weights, sizes, and text hierarchy
- Repeated spacing between sections, cards, labels, and controls
- Backgrounds, surfaces, dividers, borders, shadows, and accents
- Shared treatments for buttons, inputs, navigation, cards, tables, and alerts
- Common content widths and alignment lines
- Visible hover, disabled, loading, focus, and selected states
Repeated details are stronger evidence than a single decorative element. The two captured Linear examples below show the same general typography, spacing, surfaces, and interaction treatment across separate pages. Their notes describe a near-black canvas, muted dividers, compact controls, and one cool accent.
Captured pages
Linear typography
- Inter
Weight 400
- Inter
Weight 500
Record the system in layers
- Canvas and surfaces: Record backgrounds, raised surfaces, borders, dividers, and accent roles. Note where each role appears instead of collecting unlabelled color values.
- Typography: List families, weights, sizes, line heights, casing, and tracking by role. Separate body copy, headings, controls, metadata, and technical labels.
- Spacing: Identify recurring gaps and padding. Group similar measurements into a small scale rather than preserving every one-off value.
- Shape and depth: Record radii, border widths, shadows, gradients, and focus treatments.
- Components: Capture structure and visible states, not just the default appearance.
- Page patterns: Describe how components combine into navigation, hero sections, forms, lists, tables, and feature rows.
Turn observations into a reusable reference
Use a table with columns for role, observed value, location, confidence, and notes. Separate confirmed observations from estimates and recommendations. For example, an observed muted divider is different from a proposed opacity value for your own CSS.
The captured typography identifies Inter at weights 400 and 500 for different interface roles. Use that as evidence about the captured pages, then verify whether the same pattern appears elsewhere. Do not assume the capture reveals every font, component, breakpoint, or internal rule.
A useful handoff includes a short overview, token tables, component examples, page patterns, open questions, and a test screen that was not part of the original capture. If the tokens work on a new dashboard, form, and content page without many exceptions, the reference is likely reusable. If every new screen needs a special case, it may be overfit to the source.
Before shipping, verify font and asset rights independently. Visual observation can guide implementation, but it does not establish ownership, permission, or licensing terms.
Use this in your AI agent
> Capture a reusable design reference from these website pages. Compare multiple pages and report only repeated observations for typography, color roles, spacing, borders, radii, shadows, gradients, components, layout patterns, and visible states. Separate observed details, inferred reusable rules, and open questions. Include a role-based typography table and a compact token proposal, but do not claim this is the site's official internal design system or invent missing values. > > Install Fudge for your AI agent
What should a complete website design system capture first?
Capture the decisions that affect nearly every screen first: background and surface roles, text colors, accent roles, content width, alignment, and the main spacing scale. Then document typography roles for headings, body copy, labels, controls, metadata, and technical text.
Next, review repeated components such as buttons, inputs, navigation, cards, alerts, tables, and badges. Record structure, padding, radius, border, shadow, text treatment, and any visible state changes. After that, document page patterns such as a hero with a product visual, a two-column feature row, or a compact proof grid.
Do not spend the first pass on one-off illustrations or isolated effects. Keep observations separate from recommendations so later users can tell what was seen and what was chosen for a new product. Include at least one page that was not part of the original capture as a validation screen, and record which rules required exceptions. That makes the reference more useful than a list of attractive measurements.
How can I reuse a captured design system without copying a website too closely?
Reuse the underlying decisions rather than reproducing the source page. Adapt hierarchy, spacing, component relationships, and interaction principles to your own content, brand, product states, and accessibility requirements.
Create your own page structure, copy, illustrations, imagery, and interaction details. Avoid distinctive logos, branded graphics, unique illustrations, and proprietary content unless you have permission. Test the adapted rules on unrelated screens such as a dashboard, onboarding flow, and marketing page. Keep a note of what came from observation and what you changed, and verify font and asset rights before shipping.
It also helps to change the visual combination, not just individual values. A similar type family may be reasonable on its own, while the same type, color palette, layout, illustrations, and copy could feel too close. Use the captured site as a reference for solving interface problems, then make deliberate choices for your product and document those choices in your own token file.