Replace the general request with a use case
"Improve my visuals" can mean enlarging files, removing a background, harmonizing colors or creating a different mood. These tasks are not judged the same way. Start by asking where the outputs will be used and what their recipient needs to be able to do with them. The name of the software or GPU comes next.
Write a sentence that links a person, a result and a use: "The shop manager must be able to replace the twelve photos in this collection on her product pages." Add the known constraints, then the questions still open. The GOV.UK Service Manual suggests this separation between user need and the criteria that verify whether it is met; here, we adapt it to a small assignment.
Describe the expected package in five lines
You don't need a long specification to get started. Write down what makes the right delivery recognizable, then have this one-pager reviewed before you produce. If the recipient still doesn't know the required format, make a small export they can open in their tool. Uncertainty then turns into a precise check.
The table below is a working template to adapt, not a list of capabilities offered by a rental. For a personal assignment, replace the client's name with your own check. Someone still has to decide whether the output is suitable.
| Question | Answer to note |
|---|---|
| What must be delivered? | File type, quantity and match with the inputs. |
| What will it be used for? | Destination application or medium and how the result will be used there. |
| What would make the output be rejected? | Specific flaws, missing information or constraints not met. |
| Who validates and when? | A designated person and a planned review slot. |
| What stays out of this step? | Variants, formats or uses that will be handled separately. |
Separate blocking requirements from preferences
A blocking requirement makes the output unusable for its intended purpose: wrong product, text that has become unreadable, a missing document, or a format that cannot be opened. A preference helps you decide between several outputs that are already usable. State this difference before the test; otherwise, a late aesthetic opinion can be mistaken for a manufacturing defect.
Avoid criteria that shift with interpretation, such as "very beautiful," "intelligent," or "professional." Tie them to an accepted example and an observation: outline with no missing area, color matching the reference provided, answer based on the right passage. When a judgment remains subjective, name the person who decides and keep their reference example.
Don't pile up constraints unrelated to the assignment. A test meant to choose a method can end with a documented recommendation and a few commented outputs. It should not be presented as a complete production ready to publish.
Example: twelve visuals for a small collection
In this fictional example, a freelancer receives twelve images to replace the visuals of a collection. The initial request is "a cleaner rendering." After discussion, the scope becomes: twelve PNGs at 1,600 × 1,600 pixels, one product centered on a white background, with no changes to the logo or product details. These dimensions are a choice for the example, not a universal rule for e-commerce.
She selects three inputs for the first exchange: a light object, a dark object, and packaging with text. The client approves the framing and background of these examples before the batch is processed. The three tested images can be part of the twelve outputs; they are not automatically added to the ordered quantity.
| Criterion for this example | Planned check | Decision in case of a discrepancy |
|---|---|---|
| Twelve identifiable products | Compare the reference list with the file names. | Block delivery of the missing or mismatched product. |
| PNG at 1,600 × 1,600 pixels | Read the format and dimensions of each output. | Redo the export in question. |
| Product faithful to the source | Compare the contours, details, and inscriptions with the original. | Rework it or request a better input. |
| Framing and background as agreed | Compare with the approved sample at the usage size. | Correct the files in question, without changing all the settings at once. |
Give each result a status and each rework a reason
For the first pass in the example, let's assume nine images approved, two to correct, and one blocked by an unreadable source. The total remains twelve. A table showing the statuses "approved," "to redo," and "blocked" immediately shows the remaining work. Having twelve files in a folder would not lead to the same conclusion.
After correction, both reworks are approved. The tally becomes eleven approved results and one blocked input. The expected complete delivery is therefore not reached. The freelancer requests a usable source or an explicit agreement on a scope of eleven images. She keeps the decision along with the version in question, instead of making the twelfth reference disappear from the inventory.
For each piece of feedback, ask for the file identifier, the defect observed, and the expected change. "The text on image-007 is distorted; keep the inscription from the original" is enough to guide the rework. "It's not good" forces you to rebuild the request from scratch.
Put approval on the calendar, then handle changes
Set the time when the sample and the delivery can be reviewed. If approval is waiting on someone who is away, factor that delay into your organization. The budget guide distinguishes preparation on the rental, active work, waiting, reworks, and export. A wait during which you keep the rental occupies the window even if no computation is running.
When a new request comes up, describe its effect before starting it. Going from twelve images to twenty, adding a format, or asking for a different style changes the scope. Note the new quantity, the additional check, and the schedule to be revised. Fixing a known defect and extending the need should not remain mixed together in a single list.
Also agree on how many rounds you will run: for example, a review of the sample and then a planned revision. If the result is still rejected, take another look at the method and scope before adding endless attempts.
This sheet organizes your working decisions; it does not replace the commercial agreements specific to your assignment. It also does not let you infer a compute time. The first attempt is still necessary to check feasibility with the software and files you have chosen.
Make sure your scope allows a real decision
Reread the sheet without the context of your conversation. Can you name the files to be produced, recognize a rejected output and identify the person who validates? If an answer is missing, fill in that point before expanding the work. Also have the client confirm the elements they provided: source version, visual reference and usage authorization.
The common mistakes are starting with the whole batch, counting generated files as accepted results and changing the criteria after every attempt. Keep the initial sheet and note the revisions. If no sample meets the requirements, the right decision may be to rethink the method or drop this approach. A useful scope makes that conclusion possible.