Website design analyzer for component styles

Contents

• [Start with a component inventory](#start-with-a-component-inventory)
• [What to check in each component](#what-to-check-in-each-component)
• [Score consistency before rebuilding](#score-consistency-before-rebuilding)
• [Turn observations into reusable styles](#turn-observations-into-reusable-styles)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

A website design analyzer for component styles helps you inspect how a live page is built visually, from buttons and cards to spacing, type, borders, and color roles. The practical goal is to turn a reference website into a clear checklist you can compare against your own interface, not to copy a page without understanding its patterns.

Start with a component inventory

Review the page in this order:

1. Page structure: Note the header, hero, navigation, content sections, cards, forms, footer, and repeated patterns.
2. Surfaces: Record the main background, elevated panels, borders, dividers, overlays, and hover states.
3. Controls: Compare buttons, tabs, inputs, menus, badges, links, and icon containers.
4. Typography: Capture the font family, weight, size, line height, casing, and letter spacing used in each role.
5. Spacing: Look for repeated values between sections, inside cards, around controls, and along page edges.

This order separates large decisions from details. If the page structure and surface treatment are wrong, adjusting a button radius will not make the design feel consistent.

The supplied examples show two captured Linear pages with a near-black canvas, muted dividers, compact controls, and one cool accent used across related product pages. They are useful references for comparison, not proof that every Linear page uses exactly the same rules.

What to check in each component

For every repeated component, make a record with these fields:

• Purpose: What job does it perform?
• Size: Width, height, padding, and gap between label and icon.
• Type: Font family, weight, size, line height, and contrast against its surface.
• Shape: Border radius, border width, shadow, and whether corners change by size.
• States: Default, hover, focus, pressed, selected, disabled, loading, and error.
• Placement: What it sits beside, how it aligns, and whether it changes on smaller screens.

Compare at least three examples of each repeated component. For buttons, check whether primary, secondary, and quiet actions share a common height and radius. For cards, check internal padding, divider use, heading-to-body gaps, and hover treatment. For inputs, record label placement, placeholder contrast, border color, focus treatment, error spacing, and button alignment.

Score consistency before rebuilding

Score each area from 0 to 2:

• 0: No repeated rule is visible.
• 1: A pattern appears, but some components break it.
• 2: The rule is clear and repeated across the page.

Score structure, spacing, typography, color, surfaces, controls, and responsive behavior separately. A high score does not mean the design is better. It means the rules are easier to identify and reuse. A low score may indicate intentional variation, an unfinished page, or a system that needs closer inspection across more screens.

Prioritize the three lowest scores first. They usually create the largest mismatch when you rebuild the page. Keep exceptions visible instead of turning every difference into a new component variant.

Turn observations into reusable styles

Write decisions as rules rather than screenshots. Instead of saying that one card has 24 pixels of padding, record whether content cards use a large inset and compact controls use a smaller inset. Then verify the rule against several examples.

The captured typography evidence shows Inter used for body copy, labels, navigation, controls, headings, and emphasized interface text in the referenced Linear pages. Use that as a captured observation to test, not as proof that every Linear screen uses one identical font setup. Record family, weight, size, line height, casing, and tracking separately for each role.

If you need implementation output, keep source notes beside generated styles. Observed details describe a captured state and do not automatically become an official internal design system. Use purpose-based names such as surface-raised and text-muted instead of names tied to one appearance.

Use this in your AI agent

> Analyze the component styles of this website: [paste URL]. Create a practical design review covering page structure, repeated components, typography roles, spacing, colors, surfaces, borders, radii, shadows, responsive behavior, and visible interaction states. Separate direct observations from recommendations, then produce a concise checklist I can use to rebuild the system.

You can install Fudge for your AI agent when you want to inspect a captured reference while working through this checklist.

Compare them by rule, not by isolated appearance. Start with a table containing component name, purpose, width behavior, height, padding, radius, border, shadow, text style, icon treatment, and visible states.

For buttons, check whether primary, secondary, and quiet actions share a common height and corner treatment. Then compare label weight, icon spacing, and the difference between hover and pressed states. For cards, check outer spacing, internal padding, divider use, heading-to-body gaps, and whether the card changes on hover. For inputs, record label placement, placeholder contrast, border color, focus treatment, error message spacing, and button alignment.

Next, compare at least three examples of each component. Mark a rule as reliable only when it repeats. If one card has a different radius, decide whether it is a deliberate variant or an exception. This prevents you from turning every visual difference into a new component.

Finish by writing a short component contract: default style, allowed variants, states, and responsive changes. That contract is more useful than a screenshot because it tells you what should stay consistent as you add new screens.

Record the decisions in five groups. First, define layout values such as page width, column widths, section gaps, card padding, and alignment rules. Second, define type roles with family, size, weight, line height, tracking, and color. Third, list color roles such as page background, surface, border, primary text, muted text, accent, success, and danger.

Fourth, record component geometry: control heights, radii, border widths, icon sizes, and shadow levels. Fifth, describe states and responsive changes, including focus rings, selected styles, hover behavior, stacking, and hidden elements.

Use names that describe purpose rather than appearance. surface-raised is more useful than dark-gray, and text-muted is more flexible than gray-500. Keep an evidence note beside each value so you know whether it was seen once, repeated across the page, or inferred as a recommendation.

Before implementation, test the rules on one representative screen and one edge case. If the same tokens handle both without awkward overrides, your notes are probably capturing a real pattern rather than a one-off detail.

Related questions

• Website Design Analyzer for Gradients and Backgrounds
• Website design analyzer for color roles
• Website design analyzer for image and video use
• Website Design Analyzer for Border Radii and Shadows