Guide · glossary
what is a design system teardown?
A design system teardown is the practice of taking apart a finished interface, usually a live web page you did not build, to recover the decisions underneath it: the color and type tokens, the spacing and radius rhythm, the shadow and motion language, the section-by-section layout, and enough of a plan that you could rebuild the look in your own stack. It is reverse engineering aimed at design rather than code. You are not stealing markup; you are reading the page the way its designer would explain it, then writing that explanation down in a form you can build from.
The word is borrowed from hardware. iFixit pulls a phone apart on camera to see how it was assembled and where the corners were cut. A design system teardown does the same to an interface, except a screen has no screws, so most of the work is inference: you look at the rendered result and deduce the system that produced it.
why the term is confusing
Search for "teardown" and you land in two camps that rarely talk to each other, and the gap between them is where a real teardown lives.
The first is the product teardown, popular with PMs and UX writers. These walk an onboarding or checkout flow step by step and grade what works: qualitative, journey-focused. As Tal Raviv notes in his critique of the format, a good one starts from the problem the flow is trying to solve, not from a screenshot tour. The second camp is the design system extraction crowd, closer to engineering, who open DevTools and pull the raw CSS values off a page.
Both are useful, neither is complete. The product teardown tells you how a page feels but hands you nothing to build with. The extraction dump hands you 400 hex values with no idea which is the real primary button or why the hero is split. A proper design system teardown sits in the middle: it captures the objective tokens plus the structural and experiential logic that gives those tokens meaning.
what a good teardown contains
Strip away the jargon and a complete teardown has four layers.
| Layer | What it captures | Why it matters |
|---|---|---|
| Tokens | Colors, font families, type scale, radii, spacing steps, shadows, motion timings | The atomic values you rebuild from. See what is a design token. |
| Structure | Section-by-section layout: hero shape, nav pattern, grid, card system | Tokens alone cannot tell you a hero is centered vs split. |
| Motion and depth | Transitions, easing, hover states, elevation, blur | This is where premium interfaces separate from generic ones. |
| Rebuild path | A written plan, ideally a build prompt, that reassembles it all | Turns analysis into something you can actually ship. |
The first layer is the one every extractor tool gives you: colors as hex, fonts as families and weights, spacing as a 4px or 8px step, radii like 12px, and shadow strings. On their own these are trivia. The value appears when they are grouped into roles: this gray is the border, that gray is muted text, this blue is the one and only call to action.
The second layer is structure, and it is where most automated tools fall down. Knowing the accent is #635bff does not tell you the pricing section is a three-up card grid with a highlighted middle tier. Structure is the difference between a palette and a page.
The third layer, motion and depth, is the one people skip and then wonder why their rebuild feels flat. The Stripe teardown is a good study: the gradients, subtle elevation, and timing of hover states carry as much of the brand as the colors do. Miss the motion and you have a costume of the design, not the design.
The fourth layer is the rebuild path. This is the honest test of a teardown. If it does not leave you able to recreate the thing, it was an appreciation post, not a teardown.
manual vs automated
You can do this by hand: right-click, Inspect, read the Computed tab in DevTools for every element that matters, then transcribe it into a spreadsheet or Figma. It works, and doing it a few times will teach your eye more than any tool. The catch is time. Context.dev estimates a thorough manual extraction runs 8 to 20 hours per site, which makes benchmarking five competitors close to a full work week. For the mechanics of the hand method, see uiscanner vs browser devtools.
The automated path has caught up fast. Thoughtworks placed "reverse engineering for design system" on its Technology Radar in April 2026, describing how multimodal models now extract tokens and recurring component patterns from live pages, and calling it a practical starting point for enterprises buried in brownfield design debt. What needed a senior designer's trained eye now returns as structured data in seconds.
Automated tools split into two families. Pure code scrapers read only the DOM and CSS: fast, but blind to intent, so they will report a hidden fallback button as the primary CTA or miss that a hero is visually centered. Vision-only tools read a screenshot and guess at values, which flips the failure the other way: nice semantics, unreliable numbers. The reliable approach reads both.
how uiscanner does it
uiscanner is the automated version of this whole practice. You paste any public URL, or type it straight into the address bar as uiscanner.com/https://stripe.com, and it returns a teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a Claude-tailored build prompt to recreate the look.
It reads the rendered page with vision and the DOM together, so it catches what a code scraper misses: the real primary button rather than a hidden fallback, a centered versus split hero, and decorative imagery, which it flags with prompts to recreate as originals rather than copying. It is transformative by design. uiscanner describes and tokenizes a page; it never copies or re-hosts the original site's asset bytes. You rebuild in your own stack from the tokens and structure, which is also why you can do this cleanly. See clone a website design system legally.
The rebuild path is the part most teardowns lack and the part uiscanner leads with: a build prompt tailored to how you plan to use it. Every scan returns an id and a shareable uiscanner.com/t/<id> link, and you can browse teardowns of well-known sites on explore.
If you live in an editor, it also runs as an MCP server and a CLI, so an agent can pull the teardown into context before it writes a line. In Claude Code:
claude mcp add uiscanner -- npx -y uiscanner-mcp@latest
Or as a one-off from the terminal:
npx -y uiscanner-mcp@latest scan stripe.com --target landing
The MCP surface exposes five tools: ui_teardown runs a scan, ui_probe is a cheap preflight that spends no scan, get_teardown re-fetches a finished one, retarget_teardown re-tailors the build prompt to another archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without re-scanning, and whoami reports your plan. Full setup for Claude Code, Cursor, and Codex lives on the mcp page. Quota is unified across web, MCP, and CLI on a rolling 30-day window: Free 5, Indie ($12/mo) 100, Studio ($39/mo) 400.
why people run teardowns
Four honest reasons, all of which the four-layer output serves.
Learning comes first. Taking apart Linear or Stripe teaches you the spacing discipline and restraint that make them read as premium, faster than another theory thread. Rebuilding is second: you found a layout that works and want to ship your own version in your stack, legally, without pixel-copying. Audits are third. Run a teardown on your own site and the token roles expose the drift, the four grays that should have been one, the radius that changes between two components. Onboarding is fourth: a written teardown is the fastest way to hand a new engineer or an AI agent the shape of an unfamiliar system.
That last point is where this is heading. A teardown used to be a document a human read. Increasingly it is context an agent consumes so your generated UI stops looking generic. However you do it, by hand or with a tool, the goal is the same: turn a finished screen back into the decisions that made it, in a form you can build on.