Convert Website Design Details into Structured JSON
Organize observed website design details into structured JSON with clear roles for typography, color, layout, spacing, and reusable components.
convert website design details into structured json design details
To convert website design details into structured JSON, define a consistent document shape first, then place each observation under a role that explains how it is used. The result should preserve page context while remaining practical for design and development work.
Use a schema that mirrors the design
A useful structure separates shared values from layout and component observations:
This is easier to review than one flat list because related details remain together. For example, typography.body can contain family, weight, size, line height, letter spacing, and usage instead of scattering those properties across unrelated entries.
The captured Linear reference and typography summary show how evidence can be attached to a structured document. The supplied summary identifies Inter at weights 400 and 500 for different interface roles. Use that information as a reference for the captured example, not as a complete specification for every page.
Captured pages
Linear typography
- Inter
Weight 400
- Inter
Weight 500
Give every value a clear role
Use names such as pageBackground, cardRadius, bodyFont, and sectionGap when they describe a concrete job. Do not infer a role from a value alone. A dark gray could be text, a border, a surface, or an overlay, so record the observed use and add an uncertainty note when needed.
If the same value appears in several roles, keep one shared base value and list its uses. If similar values perform different jobs, keep them separate even when they look close.
Organize layout and components
Put page-level measurements in layout and spacing: content width, page padding, section gap, grid gap, card padding, control height, and alignment rules. Use borders for width, style, color, and radius. Use shadows for offset, blur, spread, color, and opacity when those properties can be observed.
Component entries should describe reusable patterns rather than every individual element. A button can include label typography, height, horizontal padding, radius, background, text color, border, and observed states. A card can include surface, padding, radius, border, shadow, and title spacing.
For missing evidence, be explicit:
This keeps an unreviewed state visible instead of filling it with a guess.
Check the JSON before sharing it
Confirm that the document parses, naming uses one convention, units are consistent, repeated values are defined once, and every reference resolves. Record source context, viewport, and page state in meta. Mark details as observed, inferred, recommended, or unverified, and review representative components before calling the document a shared system.
Structured JSON should preserve decisions as well as values. If a second page changes your conclusion, update the status and review notes rather than rewriting the original observation.
Use this in your AI agent
> Convert the supplied website design details into structured, valid JSON. Use sections for metadata, colors, typography, layout, spacing, borders, shadows, and reusable components. Give every value a role-based name, preserve units, include usage notes and source context, and label details as observed, inferred, recommended, or unverified. Use references for repeated values, check that references resolve, and return one clean JSON document.
Install Fudge for your AI agent to repeat this structured review workflow whenever you add another website reference.
What is the difference between structured JSON design details and design tokens?
Structured JSON design details are the broader record. They can include page sections, component observations, viewport context, usage notes, source references, and uncertainty. Design tokens are the reusable values inside that record, such as a color, font style, spacing step, radius, or shadow.
For example, this is a token:
This is a structured component detail that uses the token:
Keep both layers when possible. The token layer supports implementation and reuse. The broader detail layer preserves why a value exists, where it was observed, and whether it has been approved. This matters when you are studying one public page rather than documenting a confirmed internal system.
Can you give me a compact JSON template I can fill in after reviewing a website?
Use this compact template as a starting point:
Fill only what the page supports. Use an empty object for a category you have not reviewed, and add a note rather than guessing. After the first pass, validate the JSON, normalize naming, and replace repeated raw values with references to shared tokens.