Generate a design report from a live website

Contents

• [Use this report structure](#use-this-report-structure)
• [Make the observations concrete](#make-the-observations-concrete)
• [Turn it into a reusable project artifact](#turn-it-into-a-reusable-project-artifact)
• [A practical review checklist](#a-practical-review-checklist)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

A useful design report from a live website should capture what is visibly used, explain how the parts work together, and separate observed details from your own recommendations. Start with the page itself, then document typography, colors, layout, components, and the decisions you want to reuse.

Use this report structure

Create the report in five sections:

1. Page overview: record the page purpose, main sections, navigation pattern, viewport or page state, and the strongest visual pattern.
2. Typography: list each observed font family, available weight, likely role, size range, line height, casing, and where it appears.
3. Color and surface styles: record background colors, text colors, muted colors, borders, accents, gradients, shadows, and contrast relationships.
4. Layout and components: describe container widths, spacing rhythm, grid or flex arrangements, cards, buttons, navigation, forms, media, and responsive changes.
5. Reusable recommendations: turn the observations into tokens, component rules, and a short implementation checklist.

This structure gives you a report that is more useful than a screenshot collection because each visual detail has a role and a place in the page.

Make the observations concrete

Avoid writing only "modern," "clean," or "minimal." Replace those labels with details someone can act on. For example, describe whether the page uses a narrow reading column, large heading contrast, quiet secondary text, rounded controls, or repeated spacing between sections. Note what changes between the first visible screen and lower sections.

For typography, check the family and weight separately. A page may use one family for body copy and a heavier variant for headings, or it may use size and color to create hierarchy. The examples below show a compact sans-serif pattern grounded in a captured Linear reference: Inter at weight 400 for body copy, labels, navigation, and controls, and Inter at weight 500 for headings and emphasized interface text. Treat that as an observed example to compare, not as a rule for every website.

For colors, document roles rather than producing a long list of hex values. A useful table might include page background, raised surface, primary text, secondary text, border, accent, success, and danger. Add a note about where each role appears and whether it is used for emphasis, separation, or interaction.

Turn it into a reusable project artifact

A report becomes reusable when it has stable names and decisions. Convert repeated values into tokens such as color.background, color.textMuted, space.section, radius.control, and font.heading. Then map each token to the observed value and include a short confidence note when a value needs verification.

Keep three categories separate:

• Observed: directly visible or identified from the captured page.
• Inferred: a likely rule based on repetition or visual context.
• Recommended: your proposed change for a new project.

That distinction prevents a report from pretending to be the website's official internal design system. It documents the page as it appears and gives you a sensible foundation for implementation.

A practical review checklist

Before you use the report, check that it answers these questions:

• Can another designer identify the page's main visual hierarchy?
• Are font family, weight, size, and line height recorded by role?
• Are colors grouped by purpose rather than dumped into a palette?
• Are spacing, borders, radii, shadows, and component patterns described?
• Does the report distinguish visible facts from recommendations?
• Can the details be exported into the format your project uses?

Open the captured examples below and compare the first screen before borrowing a pattern. The Linear reference is useful for checking how a restrained type system creates contrast without needing many font families.

Use this in your AI agent

> Inspect the captured website and generate a design report. Organize it into page structure, typography, colors, spacing, borders, radii, shadows, gradients, components, responsive behavior, and media. For every detail, label it observed, inferred, or recommended. Identify font families and weights by usage, group colors by role, and finish with reusable tokens plus an implementation checklist. Export the report as DESIGN.md and include a compact JSON token summary.

Install Fudge for your AI agent to run this workflow from your project.

For a SaaS landing page, prioritize the parts that affect hierarchy and conversion: navigation, hero, primary action, proof or feature sections, pricing or plan comparison, testimonials if present, footer, and responsive behavior.

For each section, record its purpose, container width, top and bottom spacing, heading size and weight, body width, button treatment, surface color, border or shadow, and the relationship to nearby sections. Note repeated patterns such as the same card radius, button height, muted text color, or heading rhythm.

Also document states that are easy to miss: hover or focus treatments, open menus, form validation, disabled controls, media overlays, and sticky navigation. If a section changes substantially on mobile, describe the change instead of assuming it simply stacks.

Finish with a short build-order checklist. A practical order is global tokens, typography, navigation, buttons, cards, section layout, responsive rules, then page-specific details. This keeps the report useful for implementation rather than turning it into a visual inventory.

Begin by grouping repeated observations into a small token set. Use names based on purpose, not appearance: --color-page, --color-surface, --color-text, --color-text-muted, --color-border, --radius-card, --radius-control, --space-section, and --font-body are easier to reuse than names such as --blue-1 or --gray-3.

Record the source value, where it appears, and whether it is observed or recommended. Then define typography by role, including family, weight, size, line height, and tracking. Do the same for controls and repeated surfaces.

For Tailwind, map the tokens into your theme and keep component classes focused on roles such as text-muted, bg-surface, or rounded-card. For plain CSS, place the tokens in :root and add a dark or alternate theme only when the page provides evidence for one. Test the tokens against the original page at the same viewport, then adjust inferred values rather than presenting them as official internal values.

Related questions

• Generate JSON design tokens from a live website
• Generate a Reusable Design Reference File from a Live Website
• Generate CSS Variables From a Live Website
• Generate color and font tokens from a live website