# Export a website design system as a DESIGN.md file [Open the live Fudge conversation](https://design.withfudge.com/share/export-a-website-design-system-as-design-md-file) Last updated: 2026-08-25 You can export a website design system as a `DESIGN.md` file by first collecting its observed fonts, colors, spacing, layout patterns, and component styles, then organizing those details into a project-ready reference. The result should explain what the page uses and how to apply it, while clearly separating observed details from any official internal design system. ## Decide what belongs in the file Start with the details that affect day-to-day implementation. Record the main font families and variants, common weights, heading and body sizes, line heights, text colors, background colors, border colors, radii, shadows, spacing steps, and repeated component treatments. Include the page sections and layout patterns that explain where those choices appear, such as navigation, hero content, cards, forms, buttons, and footers. Use a simple test for every entry: could another designer or developer use this detail without reopening the reference? A useful entry gives a name, a value, a role, and an example. For instance, do not write only `Inter 500`; write that Inter at weight 500 is used for headings or emphasized interface text. Do not call a color “brand blue” unless its role is clear, such as primary action, link, background, or muted border. ## Captured pages [![The system for product development](https://pin.fontofweb.com/6434?format=jpg)](https://design.withfudge.com/share/pin-6434) [The system for product development](https://design.withfudge.com/share/pin-6434) ## Linear typography - **Inter** — weight 400 · Body copy, labels, navigation, and controls. - **Inter** — weight 500 · Headings and emphasized interface text. ## Use a repeatable export method Inspect the captured page in passes instead of trying to describe everything at once. First map the page structure and viewport state. Next check typography, including families, files, variants, sizes, weights, and line heights. Then inspect colors and contrast, followed by spacing, borders, radii, shadows, gradients, and component styles. This order moves from the page's overall system to the details that repeat across sections. After collecting the evidence, group the results into a short `DESIGN.md` structure. A practical outline is: `# Design system`, `## Overview`, `## Typography`, `## Colors`, `## Spacing and layout`, `## Components`, `## Motion and interaction`, and `## Notes and limits`. Under each heading, use tables where comparison helps. Include the source page, capture state, viewport, and date of inspection so readers know what the file represents. Do not turn one page into unsupported product rules. If a captured page shows a 24px gap between two sections, describe it as an observed spacing value or recurring pattern unless you checked enough pages to support a broader rule. Likewise, a font or color found on a public page is evidence of what was delivered there, not proof that you own the typeface, have permission to redistribute it, or have access to the site's private design tokens. ## Check the file before sharing it Review the document against the page in a final pass. Confirm that every important claim points to an observed detail, that units are consistent, and that names are understandable outside the original site. Check whether a color is a solid value or a gradient, whether a font weight is actually available, and whether a component changes between desktop and mobile. If the page contains animation, overlays, video, or clipped content, describe those behaviors separately from static styles. A useful quality checklist is: does the file identify the page and capture state; list the main fonts and their roles; distinguish text, background, border, and action colors; describe spacing and layout patterns; document repeated components; note responsive or interactive states; and flag anything that still needs verification? If an answer is unknown, write “verify” rather than filling the gap with a guess. Open the examples below and compare the first screen before borrowing a pattern. The Linear reference shows a compact sans-serif approach with contrast coming from size, weight, and muted color. Its recorded typography uses Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 for headings and emphasized interface text. Treat that as a concrete example of how to write roles in the file, not as a universal rule for every website. ## Use this in your AI agent > Inspect the captured website and export its observed design details into a `DESIGN.md` file. Include page structure, viewport and state, typography families and variants, sizes, weights and line heights, color roles and contrast, spacing, borders, radii, shadows, gradients, repeated components, and notable motion or interaction. Organize the file with practical headings and tables where useful. For every detail, describe its role and where it appears. Clearly label observations, assumptions, and items that need verification; do not claim the file is an official internal design system or invent licensing facts. Save the result as a concise, implementation-ready reference. [Install Fudge for your AI agent](/mcp) --- A good `DESIGN.md` starts with context, then moves from broad page decisions to reusable details. Include the reference URL or page name, capture state, viewport, and a short note about what was inspected. This prevents readers from treating a single page or responsive state as the complete product system. Use sections such as: - **Overview:** page purpose, major sections, and layout character. - **Typography:** family, source or file when known, variants, weights, sizes, line heights, casing, and roles. - **Colors:** foreground, muted text, backgrounds, borders, actions, status colors, gradients, and contrast notes. - **Spacing and layout:** container width, grid or flex patterns, gaps, padding, alignment, and responsive changes. - **Components:** buttons, navigation, cards, forms, badges, tables, and repeated states. - **Motion and interaction:** transitions, hover states, overlays, video, clipping, or scroll behavior. - **Verification notes:** facts that need another page, a smaller viewport, or an owner-provided source. For repeated values, use tables with columns for name, value, role, and evidence. Keep the wording practical: “muted text used beside primary copy” is more useful than a bare hex value. End with a short list of limits so the file remains honest about what the captured page can prove. To have an agent build the outline from a captured reference, copy this prompt: “Create a practical DESIGN.md from the captured website. Separate observations from assumptions and list anything that needs verification. Use Fudge through [the /mcp server](/mcp).” --- Make each entry actionable without forcing developers to interpret a screenshot. Give values consistent units, use stable names, and explain where each choice belongs. A typography row should include family, weight, size, line height, and role. A color row should include the value, role, and whether it appears as text, a fill, a border, or part of a gradient. Separate design observations from implementation decisions. For example, record that a card uses a particular radius and shadow, then describe a suggested token name such as `card-radius` only if that naming choice is your proposed mapping. This keeps the exported reference faithful while still making it easy to turn into CSS or another project format later. Include responsive behavior when it is visible. Note whether navigation collapses, columns stack, spacing changes, or type scales down. Also record states developers often miss: hover, focus, disabled, loading, selected, open, and error. If a state was not captured, say so. Finally, test the document by handing it to someone who did not inspect the original page. Ask them to build one small section using only the file. Wherever they must guess a value, role, or behavior, either add the missing observation or mark it for verification. That simple exercise turns a descriptive export into a dependable working reference. To run that check with an agent, copy this prompt: “Review my DESIGN.md against the captured website, identify missing implementation details and unsupported assumptions, then revise the file. Use Fudge through [the /mcp server](/mcp).” ## Related questions - [Export a Website Design System as a Design Report](/share/export-a-website-design-system-as-design-report) - [Export Website Design Details as Structured JSON](/share/export-a-website-design-system-as-structured-json-design-details) - [Create a Tailwind v4 Theme from a Website Reference](/share/create-tailwind-v4-theme-from-a-website-reference) - [Export a website design system as CSS variables](/share/export-a-website-design-system-as-css-variables)