From Design Mockups to Web Pages: Why Asset Slicing Is Harder Than Writing Components

1. The task is not inherently complex; the hard part is making it look right

Turning a product mockup into a runnable front-end page sounds like a clearly bounded job: identify structure, build components, apply styles, and complete interactions. The technology stack is also conventional: a component-based front-end framework, a layer of server-side rendering, and an atomic styling approach can cover most page needs.

The real difficulty appears when the mockup is no longer a neat admin table or form, but a product page with strong visual weight, many modules, complex backgrounds, and rich light and shadow layers. Such pages often carry a strong overall atmosphere: a unified light source, a continuous background illustration, layered glows and vignettes, and spatial relationships between characters or buildings and foreground cards.

In this situation, AI coding tools and code generation features can usually produce something that runs. They know that the top of the page should have a hero section, that an entry card should be placed in a certain position, that one area is a testing module and another contains statistics, and they can roughly tell whether the page should be dark or fantasy-style. But once the generated result is placed side by side with the original mockup, the problem becomes obvious: the page has structure, but it has lost the visual feel.

2. AI can generate structure, but it struggles with slicing decisions

To understand the problem, it helps to separate two different tasks: writing page code and deciding how the page should be split into assets and DOM.

The first task is one that AI is relatively good at today. Given a structural description, it can generate a semantically reasonable component tree, add appropriate tag levels, and write styles that run. The second task is a kind of visual decomposition judgment, and it is precisely the part most likely to be missing from current generation capabilities. In practice, AI often makes several types of mistakes:

• It knows there should be a card here, but it flattens an element that should belong to the background illustration, along with the background, into one large image;
• It knows there should be a button, but it loses all the glow, gradients, and border highlights behind the button, leaving only a solid-color block;
• It knows the page is dark-themed, but it flattens the light and dark relationships, failing to darken areas that should be darker or let through light effects that should be visible;
• It generates different modules independently, so each module may look acceptable alone, but when assembled together, the proportions are off, the hierarchy is confused, and the background looks fragmented.

In other words, what AI lacks is not the ability to write code, but the judgment of how an image should be sliced. Which areas should be kept as bitmap backgrounds, which must be implemented with real DOM, which light and shadow effects should be generated with CSS instead of being faked with an image — once these decisions are wrong, later code quality cannot save the visuals.

3. Why “slicing” is difficult

The term “slicing” can be broken down into four separate but related sub-problems.

1. Separating background layers from foreground layers

A visually heavy mockup is essentially composed from multiple layers. Characters, buildings, glows, particles, foreground cards, and text may sit at different Z-depths. The first key decision when recreating it is: which parts should be placed directly as a single background image, and which parts must be separated out and implemented with DOM.

The general principles are:

• Purely decorative, non-informative, non-interactive, and difficult to reproduce with code complex illustrations → background image;
• Content that carries real text, needs responsive line wrapping, requires interaction or accessibility support → real DOM;
• Elements with fixed positions but complex visuals, such as glowing icons or decorative borders → prefer slicing unless they can be reproduced with a small amount of CSS.

A typical consequence of slicing the boundary incorrectly is that text that should be selectable gets burned into a background image, making it impossible to localize, adapt to different resolutions, or be recognized by search engines or screen readers.

2. Proportions and composition of complex modules

Visually heavy pages are rarely uniform grids; they usually have a clear visual focal point. In the original mockup, a module may occupy 40% of the width and sit vertically centered and slightly above the middle, but the generated result often stretches it into an equal division or forces it into a rigid grid. Once the proportions are distorted, the overall sense of breathing room and immersion disappears.

These problems are almost impossible for a model to guess. They require going back to the design file and measuring: relative width, aspect ratio, spacing rhythm between modules, and whitespace ratios must be aligned item by item according to the design.

3. Light, shadow, masks, vignettes, and glows

This is the area where visual reproduction is most likely to fail and where differences between implementations are most obvious. In dark fantasy styles, glows, fades, vignettes, and volumetric light are essentially continuous lighting effects. Approximating them with a static image will almost certainly break when stretched, scaled, or viewed on different screen sizes.

The better approach is to reproduce light effects using native CSS capabilities so that the lighting adapts to the layout:

/* Glow: use a radial gradient and blur to simulate volumetric light instead of using a glow image */
.hero-glow {
  position: absolute;
  width: 640px;
  height: 640px;
  border-radius: 50%;
  background: radial-gradient(circle, rgba(120, 80, 255, 0.55) 0%, transparent 70%);
  filter: blur(48px);
  pointer-events: none;
}
/* Vignette: darken the edges with an overlaid radial gradient while preserving center brightness */
.vignette::after {
  content: "";
  position: absolute;
  inset: 0;
  pointer-events: none;
  background: radial-gradient(ellipse at center, transparent 55%, rgba(0, 0, 0, 0.75) 100%);
}

For edge fading or top/bottom fade-outs, use masks instead of hard-cropping images:

.fade-bottom {
  -webkit-mask-image: linear-gradient(to bottom, #000 60%, transparent 100%);
  mask-image: linear-gradient(to bottom, #000 60%, transparent 100%);
}

Reproducing light effects with code rather than images has several benefits: it is inherently scalable, stays sharp at any resolution, and is easier to adjust later for intensity and hue.

4. Layering and stacking

The immersion in the original mockup comes from correct stacking between layers: the background sits at the bottom, light effects are stacked above the background, foreground content is on top, and vignettes or atmospheric overlays often cover some layers while remaining below the content. A common problem in AI-generated pages is “flattening”: everything is squeezed into one layer, so light that should show through is covered by content, areas that should be darkened are not darkened, and areas that should have depth look completely flat.

The correct structure should be explicitly layered, with each layer responsible for its own role:

function HeroSection() {
  return (
    <section className="hero">
      {/* Layer 1: atmospheric background illustration */}
      <div className="hero__bg" />
      {/* Layer 2: volumetric light / glow */}
      <div className="hero-glow" />
      {/* Layer 3: vignette and atmospheric overlay */}
      <div className="vignette" />
      {/* Layer 4: real DOM content, ensuring interactivity and accessibility */}
      <div className="hero__content">
        <h1>Title</h1>
        <button type="button">Start</button>
      </div>
    </section>
  );
}

4. Why more detailed prompts do not solve the problem

At first, many people attribute this kind of issue to prompts not being precise enough, so they keep adding requirements: “recreate it 1:1,” “do not improvise,” “strictly follow the mockup.” But they soon find that prompts can improve the direction of structure and style, yet they struggle to fix slicing decisions.

The reason is that the model receives a flattened image after composition. It does not inherently know which layers the image was originally composed from or in what order. When you ask it to recreate the image 1:1, it can only compromise between generating an image that looks similar and generating code with a reasonable structure. The result is often neither precise nor clean.

A more effective approach is to explicitly feed the layer information implicit in the mockup into the generation process: tell it which areas are background and which are content; slice complex illustrations into separate assets in advance and provide their dimensions; clarify the aspect ratio and layering relationship of each module. When the input changes from “a finished image” to “an image plus a layered description plus a set of prepared sliced assets,” generation quality improves substantially.

5. A practical mockup reproduction workflow

Summarizing the analysis above into a workflow gives five steps:

1. Layer decomposition: First break the mockup into layers along the Z-axis: background, light effects, overlays, and foreground content, clarifying the responsibility of each layer.
2. Asset classification: Determine block by block whether something should be a “background image / foreground decoration / interactive component / real text.” Export complex illustrations that must be sliced as separate assets, and leave the rest to DOM.
3. Codify light effects: For glows, gradients, vignettes, and fades, prioritize CSS gradients, blur, and masks instead of forcing a static image to do the job.
4. Establish proportion baselines: Use the design file as the source of truth. Quantify the relative dimensions, aspect ratios, and spacing rhythm of each module instead of placing a grid based on intuition.
5. Layered composition and comparison: Build the page layer by layer from bottom to top. After completing each layer, compare it side by side with the original mockup to catch problems such as fragmentation, excessive darkness, or lost hierarchy early.

As for the assets themselves, complex illustrations, character artwork, and large background images can be sizable. It is worth including them in a unified asset management and delivery system: host the assets in object storage, use an image processing service to generate different sizes and formats on demand, such as modern efficient compressed formats, and deliver them through a content delivery network to balance initial page load speed and visual clarity.

Conclusion

When using AI to help reproduce product mockups, the real dividing line is not whether it can write components, but whether the developer can slice the image correctly for the model. When developers shift their attention from repeatedly adjusting prompts to engineering actions such as layer decomposition, asset classification, codifying light effects, and aligning proportions, the generated result can move from “somewhat similar” to “exactly it.” This is both the current boundary of AI generation and the most worthwhile area for human-machine collaboration: the machine writes structure quickly, and the human provides accurate visual judgment.