How Design Skills Affect AI-Generated Frontend Quality: A Two-Version Image Splitter Test

When using AI coding tools to generate frontend pages, many developers encounter the same problem: the functionality mostly works, but the result still looks like a usable prototype rather than a tool suitable for everyday use.

Buttons may lack a clear hierarchy, the upload area may not stand out, status messages may be incomplete, image previews may have inconsistent proportions, and narrow screens may introduce horizontal scrolling. These issues are usually not caused by the model being unable to write code. More often, the requirements describe only what the page should do, without defining how the interface should be organized, how states should be communicated, or how errors should be handled.

This article uses an online image-splitting tool as a case study. Two versions are generated from the same functional requirements:

• Version 1: no dedicated frontend design guidance; only the core functionality is implemented.
• Version 2: the same functionality is combined with requirements for design rules, visual hierarchy, and interaction details.

The comparison makes one point clear: design capability is not simply about changing colors or making a page look more attractive. It helps transform a collection of functions into a product that real users can operate smoothly.

1. Case Study Goals and Functional Scope

The tool is intended for content operations, social media image creation, and routine image processing. It should run entirely in the browser and split an uploaded image locally.

The core requirements are:

1. Support image selection through a file picker.
2. Support dragging an image into the upload area.
3. Provide three splitting modes:
   • A 3 × 3 nine-grid layout;
   • A 2 × 2 four-grid layout;
   • A vertical three-section layout for long images.
4. Preview all generated slices on the page.
5. Display a clear number for each slice.
6. Allow individual slices to be downloaded.
7. Provide an option to download all results in one batch.
8. Process images locally whenever possible instead of uploading the original file to an external service.

There is also an important engineering boundary. If the page needs to generate an archive, the browser must use a general-purpose dependency capable of creating compressed files, or the application must fall back to downloading each slice separately. For a fully offline setup, the dependency should be stored in the local project directory so that the page does not request it from an external URL at runtime.

2. Create a Clean Project Directory

Create a separate directory for each experiment. This prevents old files, dependencies, and previous prompts from affecting the result.

Run commands similar to the following in a local terminal:

mkdir image-splitter-demo
cd image-splitter-demo

If the directory already exists, confirm that it does not contain important files before generating the pages. A simple project structure might look like this:

image-splitter-demo/
├── index-basic.html
├── index-designed.html
├── assets/
└── README.md

Save the basic and design-enhanced pages separately. This makes them easy to compare and provides a clean foundation for later iterations.

3. Start the AI Coding Environment and Check Its Capabilities

After entering the project directory, start the local AI coding environment. On first use, it may ask for workspace safety confirmation. Continue only after verifying that the directory is trustworthy and understanding which files the tool may read or modify.

Do not immediately ask the tool to generate the complete page. First, check whether the environment includes capabilities related to frontend design. You can use a prompt such as:

Please check whether the current environment has any capability modules related to web design, interface layout, interaction design, or visual guidelines.
List the relevant modules currently available and explain which problems each one is intended to solve.
If no design-oriented capability is available, recommend a general-purpose frontend design capability that can be managed offline, and explain which parts of the workflow it would affect.

This establishes a capability baseline. Without this step, it is difficult to determine whether differences in the generated pages come from the prompt, the tool configuration, or the model itself.

Design capability modules do not replace requirements analysis. They can help the model handle layout, color, spacing, component hierarchy, and interaction feedback, but the actual functionality still needs to be constrained by explicit product requirements.

4. Version 1: A Function-First Basic Page

To observe the effect of design guidance, the first version should intentionally minimize visual requirements and focus on functional completeness and local execution.

Use a prompt similar to the following:

Please create a single-file webpage and save it as index-basic.html in the current directory.
This is a local image-splitting tool for content operations teams. Requirements:
1. The page must run in a desktop browser.
2. Users can select or drag and drop one image.
3. Provide three modes: a 3 × 3 grid, a 2 × 2 grid, and a vertical three-section split.
4. Display the generated images on the page and label each result with a number.
5. Allow each image to be downloaded separately.
6. Provide an option to download all results at once.
7. Process the image locally in the browser without uploading the original file.
8. Keep the code largely in one HTML file so it can run by opening the file directly.
9. Provide basic messages for missing files, invalid image formats, and download failures.
Prioritize functionality. Do not introduce complex visual design or unrelated modules.
After generating the page, explain the file structure, the core processing flow, and known limitations.

This version can usually complete the basic workflow: upload, read, split, preview, and download.

However, it may have several weaknesses:

• The upload area may be no more than a standard button.
• The splitting modes may use a default dropdown or simple buttons.
• The preview and results may lack a clear visual hierarchy.
• The active mode may not be sufficiently visible.
• There may be no loading state during processing.
• Download completion may not produce any feedback.
• Empty, error, and completed states may be incomplete.
• Large images may cause the page to become unresponsive.
• Slices with different dimensions may not appear consistently in the grid.

These issues do not necessarily mean that the code is unusable. They show that functional correctness and product usability are different quality levels.

5. Version 2: Add Systematic Design Requirements

For the second version, avoid writing only “make the interface more beautiful.” That instruction is too subjective. A more effective approach is to divide visual, structural, and interaction expectations into requirements that can be verified.

An example prompt follows:

Based on the same image-splitting functionality, create a second page and save it as index-designed.html in the current directory.
Focus on the following areas:
1. Overall layout
   - Use a clear two-area structure: an upload and control panel on the left, and a preview and results area on the right.
   - Make the page suitable for full-screen desktop use while remaining compatible with narrower windows.
   - Keep the control area stable in width and allow the results area to expand responsively.
   - Establish a clear primary and secondary hierarchy instead of giving every element the same visual weight.
2. Visual hierarchy
   - Use a simple and restrained color palette.
   - Establish hierarchy through headings, descriptions, section labels, and supporting information.
   - Make primary actions more prominent than secondary actions.
   - Apply consistent rules for border radius, borders, spacing, and shadows.
   - Avoid excessive decoration and do not add visual elements unrelated to image processing.
3. Interaction experience
   - The upload area must clearly communicate that it supports both clicking and dragging.
   - Highlight the area when a file is dragged over it.
   - After a successful upload, display the file name, dimensions, and file type.
   - Use a clear selected state for the three splitting modes.
   - Display progress or a loading message while processing.
   - When no image has been uploaded, show a helpful empty state in the results area.
   - When an error occurs, provide a specific, understandable reason and a suggested action.
   - Add hover, click, and completion feedback to download buttons.
4. Results presentation
   - Arrange slices in a consistent grid.
   - Display a number for every slice.
   - Make the individual download action easy to find without overpowering the image content.
   - Provide clear statistics for the results area, such as the number of slices and the current mode.
   - Do not force images into distorted proportions; use an appropriate scaling method for previews.
5. Engineering quality
   - Keep image processing, interface state, and download logic reasonably independent.
   - Add necessary null checks and exception handling.
   - Explain the potential memory pressure caused by large images.
   - Do not upload the original image.
   - After generation, provide a test checklist and list unresolved edge cases.

The value of this prompt is that it converts “make it look good” into standards that can be implemented, reviewed, and accepted.

6. Key Differences Between the Two Versions

6.1 Different Information Architecture

The basic version often arranges elements according to implementation order: upload button, mode selector, process button, and result images.

The design-enhanced version organizes the interface around the user’s task flow:

1. Select or drag in an image.
2. Confirm the image information.
3. Choose a splitting mode.
4. Start processing.
5. Review the results.
6. Download individual slices or all files.

This is task-oriented information architecture. It reduces the user’s cognitive load and helps prevent mistakes.

6.2 Different State Communication

The functional code may only need to know whether an image exists. A real interface should distinguish at least the following states:

• Initial state;
• Drag-over state;
• Image-reading state;
• Image-loaded state;
• Processing state;
• Processing-complete state;
• Download-in-progress state;
• Invalid file-format state;
• Unsupported-browser state.

If these states are not reflected in the interface, users may assume that the page is not responding.

6.3 Different Visual Hierarchy

In the basic version, upload, processing, and download buttons may use similar styles. The design-enhanced version distinguishes primary buttons, secondary buttons, disabled states, and result actions so users can understand what they should do next.

The core of visual hierarchy is not the number of colors used. It is whether the priority of each action is clear.

6.4 Different Responsive Behavior

The basic version may be tested only at the current browser window size during generation. The design-enhanced version should also account for:

• Layout changes when the browser window becomes narrower;
• Changes in the number of result-grid columns;
• Wrapping of long file names;
• Scrollable result areas when many images are generated;
• Sufficient button sizes for touch devices.

7. Perform Manual Acceptance Testing After Generation

Even when a page is generated by an AI tool, it should not be considered complete without testing. A practical sequence is outlined below.

Functional Tests

• Upload images in common formats.
• Drag an image into the designated area.
• Switch between the three modes.
• Verify the number of generated slices.
• Verify that numbering is continuous.
• Download an individual image.
• Download all results.
• Upload a new image repeatedly.
• Clear the results and process another image.

Error and Edge-Case Tests

• Click the process button without selecting a file.
• Upload a non-image file.
• Upload a corrupted file.
• Upload an unusually large image.
• Click repeatedly while a download is in progress.
• Test in a browser environment that does not support a required capability.

Visual Tests

• Is the primary action obvious?
• Is the upload area easy to find?
• Are the result images clear?
• Is all button text fully visible?
• Are different states sufficiently distinguishable by color?
• Does a narrow window introduce horizontal scrolling?
• Do long titles and file names break the layout?

8. Run Locally and Publish at Low Cost

For personal use, the HTML file can often be opened by double-clicking it. However, some browser environments impose restrictions on resources loaded from local files. A more reliable approach is to start a local static server:

python -m http.server 8000

Then open the local port in a browser.

If the tool needs to be shared with other people, it can be deployed as a static site. The application does not require a backend API or image storage because it does not need to save user images. A simple deployment structure can include:

• Page files;
• Stylesheets;
• Script files;
• Local dependencies;
• Usage documentation.

If the tool later adds user accounts, history, or online asset management, it may require general cloud services such as object storage, a database, authentication, and log monitoring.

9. Conclusion: Design Capability Is More Than Visual Polish

For the same functional requirements, the biggest difference between the basic version and the design-enhanced version is not the number of style declarations added. It is the shift in how the page is designed:

• From listing functions to designing a task flow;
• From a static page to a state-driven interface;
• From default controls to explicit action hierarchy;
• From “it opens” to “it is easy to understand, operate, and recover from errors”;
• From one-time generation to a process that supports testing, maintenance, and iteration.

For AI coding tools, design-oriented capabilities can therefore be viewed as a form of requirements interpretation. They help the model translate abstract product goals into layout rules, interaction states, visual guidelines, and acceptance criteria.

However, no design capability automatically guarantees quality. A strong result still depends on three factors: clear requirements, verifiable prompts, and complete testing after generation. The most effective approach is not to pursue a perfect page in one step. Start with a working basic version, then iteratively improve the layout, state communication, responsive behavior, and error handling.