Create a reusable design reference file from a website

To create a reusable design reference file from a website, capture the page, inspect the visible design decisions, and organize those observations into a format your team can use. The file should explain what was observed, where it appears, and how it can guide new screens. It should not claim to be the site's complete internal design system.

Start with a useful structure

Create the file with five parts:

1. Reference and scope: page URL or project name, capture date, viewport if known, and the areas reviewed.
2. Typography: family names, roles, visible weights, sizes, line heights, letter spacing, and examples.
3. Color: background, surface, text, muted text, border, accent, status, and gradient colors, with their visible uses.
4. Layout and components: content width, spacing rhythm, radii, borders, shadows, navigation, buttons, cards, forms, and repeated patterns.
5. Usage notes: what to copy, what to adapt, and what still needs checking.

This structure works as a DESIGN.md, JSON file, CSS file, or Tailwind v4 theme. Keep source observations beside proposed tokens so readers can distinguish a checked detail from an interpretation.

The Linear capture below illustrates how to document a reference. It records Inter for body copy and labels, plus a heavier Inter treatment for headings and emphasized interface text.

Turn observations into decisions

Record the choices a designer or developer will need to make:

• Which typeface handles most interface text?
• Which weights separate labels, body copy, headings, and emphasis?
• Is the page based on a light surface, dark surface, or several layers?
• Which color is reserved for actions and links?
• Are cards separated by borders, shadows, contrast, or spacing?
• Do controls use sharp, modest, or rounded corners?
• Does the layout depend on a narrow reading column, wide product canvas, or responsive grid?

Attach evidence to each answer. Inter, regular, body copy and controls is more useful than simply listing Inter. A note such as muted gray appears in secondary navigation and supporting descriptions gives a future designer a usable direction without pretending that the original site exposed its semantic token name.

Choose the file format

Use DESIGN.md when people need to review reasoning and uncertainty. Use JSON when another tool needs fields such as family, weight, role, hex, or component. Use CSS or Tailwind when implementation is the immediate goal.

A practical project can keep a readable reference, machine-readable tokens, and an implementation file together. Link each token to a reference section. If a font variant, line height, radius, or interaction state was not visible, mark it as unknown rather than filling the gap with a guess.

Review before sharing

Check that:

• The page and reviewed areas are identified.
• Every font has a role, not just a family name.
• Colors are grouped by use rather than listed without context.
• Spacing, borders, radii, and shadows are tied to visible components.
• Responsive behavior and hidden states are marked unverified when necessary.
• Observed details are separate from recommendations.
• A developer can use the file without reopening the original page for every decision.

A captured reference can guide a new interface, but it does not prove ownership of an official design system. Describe it as a record of observed design details from the reference.

Use this in your AI agent

> Inspect the captured website reference and create a reusable design reference file. Record the page scope, typography families and roles, weights, sizes, line heights, colors by role, spacing, borders, radii, shadows, gradients, and repeated components. Separate observed details from recommendations and mark anything that was not visible as unverified. Return a concise DESIGN.md-style guide plus implementation-ready color and font tokens.

Install Fudge for your AI agent

Start with the page scope: identify the reference, visible sections reviewed, viewport if known, and limits of the capture. Then document typography, color roles, layout, components, visual details, and reuse guidance.

For typography, include family, role, weight, size range, line height, and usage. For color, include background, surfaces, primary and muted text, borders, actions, status colors, and gradients. For layout, record content width, columns, spacing, alignment, and responsive behavior only when visible. For components, cover navigation, buttons, links, cards, inputs, tables, badges, and repeated states.

Include image crops, overlays, shadows, radii, and clipping when they affect the design. End with patterns worth reusing, patterns to adapt, and details that still need verification. Keep recommendations separate from observations so the file remains useful and honest.

Translate repeated observations into semantic names such as color.background, color.surface, color.foreground, color.muted, color.border, color.accent, font.body, font.heading, and font.mono. Create a role only when the reference supports it.

For every token, keep the proposed value, role, and observed location. If the reference shows regular Inter in body copy and a heavier Inter treatment for headings, record those as separate usage decisions even though the family is shared. Keep a supporting monospace or display face scoped to its observed use.

Use JSON when a build tool needs structured data, CSS custom properties for direct browser use, or Tailwind v4 theme tokens when the project already uses Tailwind. Test the tokens on one representative screen, checking hierarchy, contrast, spacing, controls, and card separation together. Label adaptations separately from facts about the source.

Related questions

• Create structured JSON design details from a website reference
• Create a Tailwind CSS Theme from a Website Reference
• Export a website design system as color and font tokens
• Export a Website Design System as CSS Custom Properties