Create a Design Report from a Website Reference

Contents

• [Use this report structure](#use-this-report-structure)
• [What to check before writing conclusions](#what-to-check-before-writing-conclusions)
• [Turn observations into an implementation plan](#turn-observations-into-an-implementation-plan)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

A useful website design report should turn one reference into a clear record of what to copy, what to adapt, and what still needs a designer's judgment. Start by documenting the page structure, typography, colors, spacing, surfaces, and recurring components, then finish with a short implementation checklist.

Use this report structure

### 1. Reference and scope Record the captured page, its visible state, viewport, and the parts you are reviewing. Note whether the report covers one landing page, a product flow, or a broader visual system. This prevents a report from presenting one page as the complete internal design system of a company.

### 2. Page structure List the major sections in order. For each section, capture its purpose, approximate height, alignment, content width, and relationship to nearby sections. Include recurring patterns such as a top navigation, hero, feature grid, logo row, testimonial area, pricing block, or footer.

### 3. Visual language Describe the overall direction in plain terms: compact or spacious, quiet or high contrast, rounded or sharp, restrained or expressive. Then record observable details such as background treatments, borders, radii, shadows, gradients, image crops, overlays, and repeated spacing values.

### 4. Type system List each observed family, where it appears, and the visible weight differences. Add heading sizes, body sizes, line heights, letter spacing, casing, and text colors when they can be checked. A practical report should explain the hierarchy, not just name a font.

### 5. Color roles Organize colors by use rather than by a loose list of hex values. Separate page backgrounds, elevated surfaces, primary text, muted text, borders, links, accents, status colors, and illustration colors. Include contrast checks for important text and controls, but label anything that has not been verified.

### 6. Components and behavior Describe buttons, inputs, cards, tabs, menus, badges, tables, and other repeated pieces. Note their states, density, padding, corner treatment, hover or open behavior, and responsive changes if the capture shows them. Keep these observations separate from recommendations.

A report can use a table like this immediately:

What to check before writing conclusions

Separate direct observations from interpretation. "The page uses a compact sans-serif with stronger contrast from size and weight" is an observation when supported by the reference. "This is the company's official type system" is a broader claim that requires additional evidence.

Check the first screen and at least one lower section. Compare repeated values instead of trusting a single element. Look for whether a color belongs to a role or appears only in an illustration. Check whether spacing changes between sections. Review mobile or alternate states when available, because a desktop capture alone cannot prove responsive behavior.

The examples below show how a captured reference can ground a report. The Linear example is represented by a saved page titled "The system for product development," and its typography notes describe Inter at regular and medium weights. Use it as a model for documenting evidence, not as proof that every Linear page uses only those choices.

Turn observations into an implementation plan

End the report with three lists:

1. Safe to reuse: repeated type roles, clear color roles, visible spacing patterns, and component shapes that appear consistently.
2. Needs adaptation: patterns tied to the reference's content, brand, illustration style, or unusual viewport.
3. Needs verification: hidden states, responsive behavior, licensing, unavailable font variants, and anything outside the captured page.

For implementation, choose one destination such as Tailwind v4, CSS variables, JSON, or DESIGN.md. Keep source observations beside the generated values so a developer can tell which values are measured, which are approximations, and which are recommendations. A strong report is short enough to use during a build and detailed enough to prevent repeated inspection.

Use this in your AI agent

> Inspect the captured website reference and create a design report for my project. Cover page structure, layout widths, spacing, typography families and weights, text hierarchy, color roles, borders, radii, shadows, gradients, images, and recurring components. Separate observed details from recommendations and unknowns. Finish with safe-to-reuse patterns, items that need adaptation, verification questions, and an implementation checklist for Tailwind v4, CSS, JSON, or DESIGN.md. Do not claim that the reference represents a complete official design system unless the evidence supports that conclusion.

Then install Fudge for your AI agent to run this review against your captured references.

Keep the scope explicit and focus on details that are visible more than once. Include the page sections in order, the main content width, alignment rules, spacing between sections, hero composition, image treatment, button and card patterns, typography hierarchy, color roles, borders, radii, shadows, and any visible responsive or interactive state.

Add an evidence column to every conclusion. Mark each item as observed, inferred, or unknown. For example, a font family visible in headings and body copy is a stronger reuse candidate than a color seen once inside an illustration. Do not call the result a complete design system. Call it a page reference report and list what would require more captures, such as forms, error states, mobile layouts, dark mode, and authenticated screens.

Use this prompt:

> Review this captured website reference and write a practical design report for a new implementation. First list the page sections and their purpose. Then document layout width, alignment, spacing, typography families, weights, sizes, line heights, casing, text colors, background and surface colors, borders, radii, shadows, gradients, image crops, and recurring components. For each detail, label it observed, inferred, or unknown. Separate reusable patterns from brand-specific details. Identify questions that cannot be answered from this capture alone. Finish with an implementation checklist and a small token table suitable for Tailwind v4, CSS variables, JSON, or DESIGN.md. Do not present the report as the reference site's official internal design system.

Related questions

• Create JSON Design Tokens from a Website Reference
• Create a reusable design reference file from a website
• Create CSS Variables from a Website Reference
• Create color and font tokens from a website reference