Designing a Reviewable Image Revision Flow: Correct, Then Restyle

AI image features often appear in a product as one friendly verb: improve. From a UX and QA perspective, that verb is too broad. Removing an unwanted object and changing a photograph into a watercolor-like illustration affect different acceptance criteria, different failure modes, and different reviewer questions.

This post is an interface-level design memo based on publicly visible controls. It does not infer private models, source code, or generation architecture. The goal is to make a browser image workflow easier to specify and test.

Define two jobs, not one

The first job is a controlled edit. The user wants to preserve a source image while changing a bounded detail: an unwanted object, a background, a damaged region, a color issue, or a frame edge. Success depends on preservation as much as change.

The second job is a style direction. The user wants a source image or prompt to adopt a different visual treatment while retaining enough of the main subject to work in its destination. Success depends on legibility, mood, and placement.

The public PictureMaker pages make this distinction visible. Image Edit exposes Inpaint, Transform, and Tag & Edit, with an upload area, prompt field, and result preview. The page describes tasks such as object cleanup, background changes, repair, color refinement, and frame extension. Style Transfer instead shows a source image, style/custom choice, optional style description, style strength, and preview, with preset directions including watercolor, oil painting, anime, 3D cartoon, cyberpunk, vintage sketch, and pixel art.

That difference should be visible in product states rather than hidden behind a generic “enhance” button.

Write acceptance criteria before the prompt

For a local edit, the brief should name the protected content and the requested change.

ts
type EditBrief = {
  protectedSubject: string;
  requestedChange: string;
  targetPlacement: 'listing' | 'social' | 'article';
};