AI Coding Design Capability Test: Comparing Two UI Versions of the Same Image Splitter

4 hr ago0 views

This article compares two versions of a browser-based image splitter generated by an AI coding tool: one focused only on functionality and one guided by frontend design capabilities. It covers workspace setup, design-skill checks, prompts, canvas-based slicing logic, evaluation criteria, local security, manual QA, and static deployment.

1. Why the Same Requirements Can Produce Very Different Results

Many developers can already use AI coding tools to generate pages quickly, but “it runs” and “it is suitable for long-term use” are not the same thing.

Take an image splitter as an example. A basic implementation usually needs to support the following tasks:

Upload a local image;
Split the image into multiple regions according to fixed rules;
Display the split results on the page;
Download a single image or download all images in a batch;
Complete all processing locally in the browser.

However, the parts that really affect user experience are often not in the feature list. They are in details such as:

Whether the page has a clear information hierarchy;
Whether the upload area makes the operation obvious at a glance;
Whether image previews and split results are easy to distinguish;
Whether processing provides clear status feedback;
Whether empty, error, and completion states are fully handled;
Whether the page remains usable across different screen sizes;
Whether colors, spacing, buttons, cards, and text remain consistent.

If an AI coding tool is only asked to “write the functionality,” it may generate a page that runs, but common visual problems include default fonts, stacked buttons, unreasonable content density, inconsistent spacing, insufficient color contrast, and primary actions that are not prominent enough.

Therefore, the value of frontend design skills is not simply “making the page look better.” It helps AI coding tools build a more complete approach to interface design.

2. Prepare a Clean Local Working Directory

It is recommended to create a separate directory for each experiment so that old files, configuration files, or historical code do not affect the generated result.

Run a command similar to the following in the system terminal:

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

If your terminal supports automatic directory creation, you can also use the corresponding directory creation command. After entering the directory, start the local AI coding tool.

When entering a new directory for the first time, the tool will usually ask whether to trust the current workspace. Only authorize access after confirming that the directory source is reliable. Workspace trust essentially allows the tool to read and modify files in the current directory, so access should not be granted directly to directories from unknown sources.

3. Check Whether Frontend Design Capabilities Are Available

Before generating the page, you can ask the AI coding tool to check whether the current environment has already loaded skill modules related to web design, interface layout, interaction standards, and visual standards.

You can enter a prompt such as:

Please check whether the current environment has already loaded any skill modules
related to web design, interface layout, interaction experience, and visual standards.
Please list the related capabilities you find.
If none are available, use a general frontend design skill module with a reliable
source and clear purpose, and tell me the installation or enabling result.
Do not modify the business code in the current project.

This step serves two purposes.

First, it confirms whether the tool has design-level assistance capabilities, rather than only code generation capabilities.

Second, it avoids discovering missing design constraints only after the project has generated a large amount of code, which would require significant rework later.

In practice, a design skill module usually helps the tool pay attention to the following:

Page structure and visual hierarchy;
Color matching and contrast;
White space and content density;
Interaction feedback and operation states;
Responsive layout;
Accessibility and usability;
Consistency of component styles.

It is important to note that a skill module is not a guarantee of a high-quality product. It is closer to a set of decision-support rules. The final result still depends on whether the requirements are clearly described and whether the result has gone through multiple rounds of validation.

4. Version 1: No Design Capabilities, Only Core Functionality

To observe the difference accurately, first ask the tool to generate a “functionality-first” version and explicitly prohibit it from using design-related capabilities.

Example prompt:

Please directly create a purely local image splitting web page and save it as index-v1.html.
Use case: a content operations user splits a large image into multiple smaller
images suitable for publishing in a desktop browser.
Functional requirements:
1. Support clicking to select an image and also support drag-and-drop upload;
2. All image processing must be completed locally in the browser, without uploading
   to any external service;
3. Support a nine-grid split, that is, 3×3;
4. Support a four-grid split, that is, 2×2;
5. Support a vertical three-segment split, that is, 3×1;
6. Display the split results on the page and label each result with a sequence number;
7. Each slice can be downloaded individually;
8. Support downloading all slices at once;
9. If the user has not uploaded an image, display a clear empty state;
10. If image reading fails, display an understandable error message;
11. Do not use any frontend design skill module;
12. Do not introduce unnecessary backend services.
Please prioritize complete functionality and directly runnable code.

The goal of this version is not to pursue the final visual effect, but to establish a verifiable functional baseline.

1. Image Processing Logic

Local image splitting in the browser can usually be implemented with canvas technology. The basic process is as follows:

Obtain the image file through a file selector or drag-and-drop event;
Read the file using the browser’s image object;
Calculate slice dimensions based on the original width and height;
Create a temporary canvas;
Draw the local region of the image according to row and column coordinates;
Export the local canvas as an image file;
Generate temporary download links.

For a nine-grid split, assuming the original image width is W and height is H, the theoretical size of each region is approximately:

slice width = W / 3
slice height = H / 3

If the original image dimensions are not divisible by three, the code needs to handle the remainder to avoid losing pixels in the last column or last row. A more reliable calculation method is to subtract boundary coordinates:

left boundary = floor(total width × current column / total columns)
right boundary = floor(total width × (current column + 1) / total columns)
actual width = right boundary - left boundary

This method ensures that all pixels are covered and avoids edge loss caused by floating-point numbers or rounding.

2. Common Problems in Version 1

After the functional version is complete, the following problems are usually visible:

The upload area looks like an ordinary input box and lacks visual guidance;
Controls and the result area are not clearly grouped;
Split-mode buttons are not prominent enough;
Download buttons are mixed with other operations;
Image preview sizes are inconsistent;
Result cards lack hierarchy;
The page has horizontal scrolling on narrow screens;
There is not enough obvious feedback after processing completes;
Error messages directly display technical text that ordinary users find difficult to understand.

These problems do not mean the functionality has failed. They show that “functional structure” and “product interface” are two different layers.

5. Version 2: Regenerate with Frontend Design Capabilities

After the functional baseline is confirmed, ask the tool to regenerate a second version based on the same requirements and explicitly require it to use design-related capabilities.

Example prompt:

Please redesign and implement the same local image splitting tool and save it as index-v2.html.
This time, please use the currently available frontend design skill module, but do not
sacrifice the existing functionality.
Design goals:
1. Aimed at content operations users; the page should be clean, clear, and professional;
2. Use a clear page title and supporting description;
3. Separate upload, split mode, preview, and download results into clear areas;
4. The upload area must support drag-and-drop and provide understandable operation hints;
5. The currently selected split mode must have an obvious state;
6. Primary action buttons should be prominent, while secondary actions should have lower visual weight;
7. Display split results in consistent cards and keep sequence numbers;
8. Design four states: empty, processing, completed, and error;
9. Ensure text contrast and button sizes are suitable for long-term use;
10. Adapt to common desktop window widths and remain compatible with narrower screens;
11. Do not add complex decorations unrelated to image splitting;
12. All processing must still be completed locally in the browser.
Please analyze the page information architecture first, then generate a complete single-file page.
After generation, check the interaction logic, style consistency, and edge cases yourself.

This time, the tool is not only writing event handlers. It also needs to consider the complete path a user follows to complete the task:

Enter the page
  ↓
Understand the purpose
  ↓
Upload an image
  ↓
Choose a split method
  ↓
View processing results
  ↓
Download a single file or all files

If any step on the page lacks feedback, users may wonder whether “the button did nothing,” “the image was processed successfully,” or “where the download went.”

6. Key Metrics for Comparing the Two Versions

1. Information Architecture

The functional version may place all content in the same area, while the design-optimized version usually establishes a clearer hierarchy:

Top: product name and purpose description;
Main action area: upload an image;
Parameter area: choose a split mode;
Result area: view slices;
Action area: single download and batch download.

Once the information architecture is clear, users do not need to read a large amount of text to understand what to do next.

2. Visual Hierarchy

Not all elements on a page should have the same visual weight.

For example:

The main page title should be more prominent than supporting text;
The primary action button should stand out more than ordinary buttons;
The currently selected split mode should have an obvious state;
Error messages should use sufficient color and icon cues;
Download actions should become easier to find after results are generated.

One role of design skills is to help the tool move from a “collection of elements” to a “task-oriented interface.”

3. State Feedback

A complete tool should consider at least the following states:

No image uploaded;
Image being read;
Image read successfully;
Slices being generated;
Slice generation completed;
File format not supported;
Image reading failed;
User uploads a new image;
User switches split mode.

If only the success path is implemented, the page will appear unstable in real use. This is especially important for file-processing tools, where error messages and processing states matter greatly.

4. Responsive Layout

Although desktop tools mainly target large screens, window resizing should still be considered.

Common strategies include:

Use a maximum width limit for the main container;
Use adaptive column counts for the result grid;
Avoid making card widths excessively fixed;
Allow action buttons to wrap automatically on narrow screens;
Use a maximum width limit for image previews;
Prevent fixed-width elements from breaking the page.

For example, the result area can automatically adjust the number of columns based on container width instead of always using one fixed layout. This keeps the page readable across different monitors and browser windows.

7. Local Security and File Handling Considerations

The core advantage of this type of tool is that images do not need to leave the local browser, but several issues should still be considered during implementation.

1. Do Not Upload Original Images

The code should not call remote APIs by default, and it should not send converted images to unknown addresses. All reading, cropping, and export processes should be completed in the browser.

2. Release Temporary Resources Promptly

When displaying images through temporary URLs or generating download files, object URLs that are no longer used should be released after processing is complete to avoid memory usage during long-running sessions.

3. Limit Abnormal Inputs

The following cases should be considered:

The user selects a non-image file;
The image dimensions are extremely large;
Image orientation information causes the preview to differ from expectations;
File reading is interrupted;
Browser memory is insufficient;
There are many files during batch export.

4. Batch Download Implementation

Batch download can package multiple slices into a compressed file or trigger multiple downloads in sequence. The former is usually easier for users to manage, but it requires additional compression logic. Whichever method is used, the interface should indicate that files are being generated to prevent users from clicking repeatedly.

8. Manual Acceptance Testing Is Required After Generation

After an AI coding tool generates code, it should not be published directly. At minimum, complete the following checks:

Upload a landscape image and confirm that the slices are complete;
Upload a portrait image and confirm that the proportions are correct;
Upload an unrecognized file and confirm that the error message appears correctly;
Test all three split modes separately;
Check whether slice numbers are consecutive;
Download a single image and open it for verification;
Test whether batch download can be extracted normally;
Upload a new image repeatedly and confirm that old results do not remain;
Shrink the browser window and check for horizontal scrolling;
Refresh the page and confirm that the tool still starts correctly from its initial state.

Also open the browser developer tools and check for obvious errors. No matter how good the visual result looks, if the console continuously throws exceptions, future maintenance costs will increase.

9. How to Publish the Prototype as an Accessible Page for Free

If the tool consists entirely of static files and does not require a server to process images, it can be published using static web hosting.

A common process is:

Confirm that the page does not depend on local absolute paths;
Name the entry file as the default homepage file;
Check script, style, and image reference paths;
Create a site with a static hosting service;
Upload the page files;
Test through the assigned access URL;
Perform acceptance testing in different browsers and on different devices.

If user accounts, history, online collaboration, or cloud storage are added later, backend services, object storage, permission control, and logging and monitoring capabilities will be required. In that case, pure static page deployment will no longer be fully suitable.

10. Final Conclusion

With the same requirements, an AI coding tool is usually more likely to generate a page that “can complete the task” when there are no design constraints. After frontend design skills are added, the tool pays more attention to information architecture, visual hierarchy, state feedback, responsive layout, and interaction consistency.

The difference between the two is not just colors and rounded corners. It is a difference in product completeness:

The first version solves “whether the functionality works”;
The second version solves “whether users are willing to keep using it.”

A more efficient practice is not to pursue complex visuals from the beginning. Instead, establish a functional baseline first, then introduce design capabilities for structured optimization, and finally complete acceptance testing through real operations.

For lightweight tools such as image processing, text conversion, data organization, and content publishing, this process of “functional validation—design optimization—edge-case testing—static deployment” can significantly lower the development barrier and is also better suited for individual developers and small teams that want to validate ideas quickly.