Same Requirements, Different Results: A Practical Test of Front-End Design Capabilities in AI Coding Tools

1. Why the Same Requirements Can Produce Very Different Results

When using AI coding tools to generate front-end pages, many people encounter a typical problem: the functionality basically works, but the page looks like a hastily assembled demo.

Common symptoms include:

• Unclear page hierarchy, with upload, action, and result areas mixed together;
• No consistent rules for color, spacing, or font size;
• Button states are not obvious, so users cannot tell whether an image has already been uploaded;
• Empty, loading, and error states are not designed;
• Image preview sizes are unreasonable, and users have to scroll repeatedly to find sliced results;
• Download entry points are scattered, making batch and single-item actions easy to confuse;
• Content overflows on mobile or in narrow windows;
• The page includes decorations, statistics, or marketing copy unrelated to the task.

These problems do not necessarily come from insufficient coding ability. Implementing functionality and designing a product are two different tasks. Ordinary code generation often prioritizes explicit requirements such as making buttons clickable, processing images, and downloading files, but it does not automatically establish a complete visual system and interaction specification.

The role of a front-end design capability module is essentially to provide AI coding tools with a decision framework for interface design, for example:

1. How to determine the page’s information hierarchy;
2. How to organize first-screen content;
3. How to establish rules for color, spacing, corner radius, and shadows;
4. How to design interaction feedback for different states;
5. How to avoid a generic template-like page style;
6. How to make visual presentation serve real usage scenarios.

Therefore, what is really worth comparing is not whether a certain tool is installed, but whether the AI coding tool has sufficiently clear design constraints and whether those constraints are correctly applied to requirements, layout, interaction, and code implementation.

2. Experiment Goal: Build a Local Image-Splitting Tool

This practice chooses a scenario with clear functional boundaries but still many interface details: an online image-splitting tool for content operations staff.

The tool should meet the following requirements:

• Import an image by drag-and-drop or file selection;
• Support three common split modes: 3×3, 2×2, and vertical three-segment;
• Display the original image and the sliced preview results;
• Give each slice a clear number;
• Support downloading an individual slice;
• Support packaging and downloading all slices;
• Complete all image processing locally in the browser;
• Do not upload user images or rely on backend APIs;
• Run by opening a single web page file;
• Enter the working state directly on the first screen instead of showing a long explanation first.

This requirement includes functional, interaction, visual, and security dimensions, making it suitable for observing the changes brought by a design capability module.

3. Step 1: Create a Clean and Reproducible Working Directory

It is recommended to create an independent working directory first to prevent historical files, old configurations, or other project code from interfering with the generation process.

In the terminal, you can run a command such as:

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

If you are using a graphical system, you can also manually create a folder with the same name and then open a terminal in that directory.

Next, start the local AI coding environment. When entering a new directory for the first time, confirm that the directory source is reliable and explicitly allow the tool to read and create files in the current project.

There is an important principle here: do not put a large amount of old code, unrelated assets, and complex configurations into the project directory at the beginning. For a page-generation experiment, the cleaner the directory, the easier it is to determine whether the result comes from the prompt, the design capability module, or the influence of existing files.

4. Step 2: Check Design Capabilities Before Deciding Whether to Load Them

Before formally generating the page, you can first ask the AI coding tool to check whether the current environment already contains capability modules related to interface design.

The prompt can be organized like this:

Please check the currently enabled capability modules related to web interface design, interaction design, and visual specifications in the current environment.
List the module names and their main purposes.
If there is no suitable design capability at present, install a reliable, general-purpose front-end design capability module.
After completion, explain whether the installation succeeded and how it will be used when generating pages later.

The purpose of this stage is not to make the tool write code immediately, but to confirm the working environment first.

Without a design capability module, the result is usually an implementation that prioritizes functionality. If a design capability module is loaded, the subsequent generation process is more likely to actively consider:

• Whether the primary action is prominent enough;
• Whether the page has a clear visual focus;
• Whether different areas have reasonable whitespace;
• Whether buttons and cards use a consistent style;
• Whether the empty state can guide users to start operating;
• Whether the result display is suitable for batch browsing;
• Whether failure scenarios have clear prompts.

It is important to note that installing a design capability module does not guarantee an excellent page. It only provides a better foundation for design decisions. The final result still depends on whether the requirement description is complete, whether constraints are clear, and whether verification is performed after generation.

5. Step 3: Generate a Baseline Version Without Loading Design Capabilities

For a fair comparison, you can first explicitly require the tool not to call any design capability and generate a baseline version.

An example prompt is as follows:

Please create a single-file local image-splitting tool and save it as index-basic.html.
Functional requirements:
1. Users can drag and drop or click to select an image;
2. Support three split modes: 3×3, 2×2, and vertical three-segment;
3. Display the original image and split results on the page;
4. Each slice displays a number and supports individual download;
5. Support packaging and downloading all slices;
6. All image processing is completed locally in the browser, and no files are uploaded;
7. Do not use illustrations, fake data, or redundant marketing copy unrelated to image splitting;
8. Users can start operating directly after the page opens.
Please prioritize functional availability and use native front-end technologies.

The baseline version can usually accomplish the following:

• Read local image files;
• Obtain image width and height;
• Calculate slice regions based on the number of rows and columns;
• Use canvas to draw each image block;
• Generate downloadable image files;
• Complete batch packaging through browser-side compression logic.

However, its visual result is often direct: a title at the top, an upload box in the middle, and several buttons and image cards below. Such a page can run, but it is not necessarily suitable for long-term use.

6. Step 4: Regenerate After Loading Design Capabilities

Next, under the same functional requirements, enable the front-end design capability module and ask the tool to complete interface design while implementing functionality.

A more complete prompt is recommended:

Please redesign and implement a local image-splitting tool and save it as index-designed.html.
The target users are content operations staff who process social media images every day. They want to quickly split images, check the order, and export results.
Core functions:
1. Support drag-and-drop or click-to-upload images;
2. Support three split modes: 3×3, 2×2, and vertical three-segment;
3. Display the original image, current split mode, and slice results in real time;
4. Each slice displays a clear number;
5. Support individual slice download;
6. Support batch download of all slices;
7. Complete all processing locally in the browser;
8. Do not upload images or retain user files;
9. Run as a single web page file.
Design requirements:
1. Enter the working interface directly on the first screen;
2. Use a clear three-part layout: upload and settings, original image preview, and result preview;
3. Give primary actions obvious visual priority;
4. Design states for not uploaded, processing, completed, and failed;
5. Use consistent rules for color, spacing, corner radius, borders, and buttons;
6. The result area should be suitable for viewing multiple slices;
7. Adapt to common desktop browser windows and also support narrow-screen display;
8. Avoid unrelated illustrations, fake statistics, and decorative content;
9. After generation, self-check the interaction flow and visual consistency.

Compared with the baseline version, the design requirements are no longer just “make the page look good.” They turn visual goals into executable constraints. Pages generated this way are usually closer to a real tool rather than a simple functional demo.

7. Core Differences Between the Two Versions

1. Different Information Architecture

The baseline version often arranges elements in the order of code implementation: first the upload control, then buttons, and finally images.

After loading design capabilities, the page is more likely to be organized around user tasks:

1. Import an image first;
2. Choose a split method;
3. View the original image and split results;
4. Execute downloads.

This is task-flow design, not just control arrangement. Users can understand what to do next without reading instructions.

2. Different Visual Hierarchy

On the baseline page, titles, buttons, and explanatory text may use similar font sizes and colors, resulting in unclear priority.

After design constraints are applied, a clearer hierarchy is usually established:

• The page title explains the tool’s purpose;
• The upload area serves as the first action entry point;
• Split modes serve as secondary settings;
• Batch download is the primary action in the result area;
• Individual download is a local action for each slice.

The clearer the visual hierarchy, the lower the cognitive cost for users to complete the task.

3. Different State Handling

A usable tool should not consider only the “success path.” At minimum, it needs to handle the following situations:

• The user has not yet uploaded an image;
• The file format is unsupported;
• Image reading fails;
• The image size is too large;
• The user switches split modes;
• Users need to wait while results are generated;
• Batch packaging fails;
• The user uploads a new image repeatedly.

The baseline version may only output error information to the console, while a well-designed version provides understandable feedback on the page, such as explaining the specific reason, giving next-step suggestions, and preventing buttons from being clicked repeatedly during processing.

4. Different Result Presentation

The core of an image-splitting tool is not just “splitting” but letting users confirm whether the slice order and content are correct.

Therefore, the result area should focus on:

• Whether numbers are prominent;
• Whether there is enough spacing between images;
• Whether preview proportions are consistent;
• Whether slices of long images are not compressed beyond recognition;
• Whether download buttons are easy to locate;
• Whether the grid layout can adapt to different numbers of results.

This is also where design capabilities most easily demonstrate value: they further transform “output files” into a “result panel that can be checked and operated.”

8. Key Technical Points at the Implementation Level

1. Read Images Locally

The browser can obtain the file selected by the user through a file selection control and then use a local reading API to create a preview object. The entire process does not require uploading the file to a server.

Pay attention to:

• Limit acceptable file types;
• Prompt when reading fails;
• Release old preview resources when replacing images;
• Do not write image content into unnecessary persistent storage.

2. Calculate Slice Regions

Assume the original image width is W, height is H, and it is split into columns columns and rows rows. The theoretical size of each slice is:

sliceWidth  = W / columns
sliceHeight = H / rows

Actual drawing needs to consider integer pixels and edge errors. A more reliable approach is to calculate the starting point based on the current slice index and let the last column or last row absorb the remainder, avoiding missing edges.

3. Export Images Using Canvas

Each slice can be drawn onto an independent canvas and then converted into a downloadable data object. The original ratio should be maintained during export, and an appropriate image format should be selected according to requirements.

If the tool is mainly used for social media images, common format options can be provided. If additional complexity is not needed, the default can use a format with good browser compatibility.

4. Considerations for Batch Download

Batch download usually requires generating multiple files first and then compressing them into an archive. Pay attention to:

• File names should include numbers;
• Numbers should preferably be zero-padded consistently, such as 01, 02;
• The compression process should show a processing state;
• Enable the download entry point only after generation is complete;
• Avoid blocking page interaction when there are many files;
• Release temporary objects on failure to avoid continuous memory growth.

9. How to Perform Post-Generation Acceptance

You should not consider the task complete just because the page opens. It is recommended to verify against the following checklist.

Functional Acceptance

• Does it support drag-and-drop upload?
• Can it handle transparent images or images of different sizes?
• Are the results correct for all three split modes?
• Are numbers consistent from left to right and top to bottom?
• Can individual downloaded files open normally?
• Is the batch download content complete?
• Are old results cleared after replacing the image?

Interaction Acceptance

• When no image has been uploaded, do users know what to do?
• Does the page update promptly after selecting a split mode?
• Can repeated clicks be avoided during processing?
• Are error messages specific?
• Is there feedback after download completes?
• Are keyboard operation and focus states basically usable?

Visual Acceptance

• Are primary buttons prominent enough?
• Is text contrast clear?
• Are cards and buttons consistent?
• Is the page crowded when many slices are displayed?
• Does horizontal scrolling appear in narrow windows?
• Are there visual elements unrelated to the task?

10. Zero-Backend Publishing and Security Boundaries

This type of tool can be published as a purely static page or opened directly locally. If it needs to be shared with others, it can be deployed to any environment that supports static file hosting. Usually only the web page file and related assets need to be uploaded.

However, the boundaries of “local processing” must be clear:

• Page code does not automatically guarantee that all dependencies are local;
• If external scripts, fonts, or images are referenced, network requests may still occur during access;
• If online analytics components are introduced, user behavior may be sent to external services;
• If a server-side API is added, the image processing chain is no longer purely local.

Therefore, when privacy truly matters, inspect the page source for network requests, external resources, and third-party dependencies, package necessary resources locally as much as possible, and observe in browser developer tools whether there are unexpected requests.

11. Conclusion: Design Capability Is a Constraint System, Not Decoration

For the same functional requirement, AI coding tools can often quickly generate a page that “can run” when there are no design capability constraints. After design capabilities are added and clear goals are provided, the result is more likely to reach a level that is “suitable for long-term use.”

The fundamental differences between the two are mainly reflected in:

• Whether the page is organized around user tasks;
• Whether it has complete state design;
• Whether it establishes unified visual rules;
• Whether it considers result checking and batch operations;
• Whether it actively performs self-checking after generation;
• Whether usability, accessibility, and privacy boundaries are included in the requirements.

Therefore, a front-end design capability module is not a simple beautification plugin. It is a constraint system that helps AI coding tools make interface decisions. For developers, the most effective practice is not simply saying “make it look better,” but specifying users, task flows, information hierarchy, state changes, responsive requirements, and security boundaries.

When these conditions are written into prompts, combined with multiple rounds of acceptance and small-step iteration, it is possible to generate front-end tools with professional quality, complete functionality, and practical usability more reliably, even without manually writing a large amount of code.