An AI photo editor can expose a deceptively small interface: upload, prompt, settings, generate. The implementation problem is larger because each control participates in a changing capability contract.
Disclosure: this article was drafted with AI assistance and then fact-checked and edited against the documented ArtDo workflow. The architecture below is a product-design pattern, not a claim that every image model behaves identically.
The useful engineering question is not “How do I add another model to a dropdown?” It is “How do I prevent the UI from offering a request that the selected workflow cannot fulfill, and how do I keep the output reviewable afterward?”
Model the request as state, not a form
A prompt-led image edit moves through distinct states:
- no source selected;
- source validation;
- capability loading;
- compatible settings selected;
- request ready;
- generation in progress;
- result ready for review;
- revision or download.
Those states should be explicit. If the interface treats everything as a loose collection of inputs, stale selections are easy to submit. A user can choose a resolution, switch modes, add another source image, and unknowingly keep a combination the current model no longer supports.
The ready state should therefore be derived, not toggled:
const requestReady =
sourcesAreValid &&
capabilitiesLoaded &&
inputCountIsSupported &&
selectedRatioIsSupported &&
selectedResolutionIsSupported &&
promptMeetsCurrentLimits &&
authRequirementIsSatisfied;
The exact fields can differ by provider. The design principle does not: the submit button represents a validated intersection of source, workflow, model, settings, account state, and current capability data.
Keep capability data out of permanent copy
Model availability, source-image counts, aspect ratios, resolutions, authentication requirements, and credit costs are unstable product data. Hard-coding them into descriptive copy creates two sources of truth: the application and the article or interface text that described an older version.
A safer boundary is:
- durable copy explains the workflow and its limits;
- live capability data determines the available controls;
- validation runs again when a dependency changes;
- the final request is checked server-side as well as in the browser.
That last check matters. Client validation improves the experience, but it cannot be the authority for billing, account access, provider availability, or accepted request combinations.
Reset dependent fields deliberately
Changing one selection can invalidate several others. A model change can alter input count, prompt limits, ratios, resolutions, or sign-in requirements. A generation-mode change can make an extra source image invalid.
There are two reasonable UI strategies:
- preserve a dependent value when it remains valid;
- reset it to a supported default when it does not.
Silent preservation of an invalid value is the dangerous third option. It creates requests that look complete but fail only after the user has invested time in the prompt.
The same rule applies while capability data is refreshing. A loading state should disable submission and avoid showing the previous model’s options as if they were current. A recoverable error state should explain that the compatible choices could not be loaded, not pretend that every choice is available.
The prompt is part of the validation surface
Prompt guidance often focuses on creative quality, but it also defines whether a result can be reviewed. A useful editing instruction contains a change, an invariant, and a likely failure area:
Replace the background with a neutral studio wall.
Keep the subject's face, clothing, pose, and camera angle unchanged.
Preserve natural edges around hair and transparent material.
This structure does not make generation deterministic. It makes the output easier to test. The result either preserves those invariants or it does not.
The product can support that behavior without turning the UI into a prompt course. Short examples, a visible prompt limit, and task-specific suggestions are often enough. The key is to avoid implying that elaborate wording guarantees exact compliance.
Treat the result as a review state
Many generation interfaces jump directly from “completed” to “download.” That collapses two different states.
Completed means a provider returned an image. Reviewed means a person checked that image against the requested change and intended destination.
The result surface should make comparison possible. At minimum, the user needs access to the source, the generated image, the prompt, and the settings that produced it. High-risk areas include identity, small text, edges, reflections, hands, repeated patterns, and reconstructed backgrounds.
If revision is needed, preserve enough context to change one variable rather than restart blindly. If the result is acceptable, download becomes a clear handoff instead of a false signal that the system approved its own work.
Failure states are part of the product
Validation, provider, safety, account, storage, and network failures should not collapse into one generic message. The user needs to know whether to change the input, sign in, wait and retry, choose another currently supported option, or stop.
At the same time, avoid inventing precision the system does not have. Do not promise a fixed processing time or suggest that another attempt will be artifact-free. A retry path is useful only when it is attached to an actionable failure class.
The narrow product contract
The most defensible contract for a browser AI photo editor is smaller than “edit anything perfectly.” It is:
- accept valid image sources;
- expose currently compatible choices;
- collect a specific editing instruction;
- show honest generation and failure states;
- return an image for human review;
- preserve a clear revision or download path.
ArtDo’s homepage is the concrete product surface that motivated this breakdown. The external reference is secondary to the implementation lesson, but the current upload-to-review flow can be inspected here:
Top comments (0)