Less rework on design requests: write the brief and define done before AI
Design rework drops when you write down the request and what counts as done before AI makes anything.
Key points
- Brief on one page: reader, ask, decider
- Leave unknowns as TBD, not AI guesses
- Define done in one line: the takeaway
- Check with AI prototypes, not final work
Contents
Brief on one page to see which assumptions will shift
A&A perspective
Writing the request on one page shows, before anything is made, the assumptions that would otherwise change after it is made. Rework on a design request means the finished piece is sent back at the requester’s review and has to be made again.
Hypothetical example
Say a salesperson posts in the team chat: “Flyer for next month’s seminar, like last time.” The person making it builds a prototype (an early sample of the finished piece) with AI. Only then does it come out that this time the audience is first-time contacts rather than current customers, there is a fee, and the sign-up address is different. This is a hypothetical example.
A&A perspective
That fix looks like a design touch-up, but it is really a reset of the request’s assumptions. Automate & Augment (A&A), the company writing this article, recommends writing the request on one page before asking for more options. Paper or a shared document both work.
A&A perspective
On that page, write who it is for and what you want from them: who receives it, and how readers should act after reading it. Write who makes the final call. Add the conditions already settled, the materials that may be used and the deadline. For last time’s flyer, say separately whether only its look may be borrowed or its wording too.
Hypothetical example
The page is written by the person asking, not the person making. For the flyer, the salesperson writes it: the audience is first-time contacts, and the ask is to sign up for the seminar. The owner’s name goes in the final-call field.
A&A perspective
Filling every field is not the goal. If a piece of work fits on one page, it is easier to explain what you are asking for, even when AI is the first to take it on. If it does not fit, there are still decisions to make before you ask AI.
Leave unknowns as TBD instead of letting AI fill them
A&A perspective
Leave conditions that are not settled as “TBD” instead of letting AI fill them, and note who will decide. Leave a field blank for AI and a plausible-looking fee or date may end up in it.
A&A perspective
The person asking writes “TBD”. When the maker finds a condition missing from the page, they ask the requester instead of filling it in themselves or with AI. If the answer is settled, it goes in; if not, the requester writes “TBD” and who decides.
Hypothetical example
For the flyer: “Venue and date are set; the fee is being checked by the owner.” Even with the fee open, the layout can be worked out first. What it does not do is treat the public wording as final.
A&A perspective
Work can start while TBD fields remain. Plan the layout from what is settled and put the open parts in a form that is clearly provisional. But if the audience or the ask is still open, settle those before making anything, because they change what is being made at its base.
From the sources
Anthropic, a company that develops AI, explained how to build systems that hand work to AI in a December 2024 engineering article. According to that article, once the task is clear, AI plans and works on its own, and may return to a person for more information or a judgment.
A&A perspective
A&A sees a “TBD” field as the place where AI comes back to check with a person partway through the work. If the decider’s name is written there, AI does not get stuck on whom to ask when it comes back.
A&A perspective
When a field is settled, update the page right then. Once the fee is decided, remove the TBD mark and write in the amount. When the prototype is remade, give AI the updated page again.
| Item | Flyer example (hypothetical) | How to hand it to AI |
|---|---|---|
| Who it reaches | First-time contacts, not current customers | Pass it on as is |
| What they should do | Sign up for the seminar | Pass it on as is |
| Who makes the final call | The owner | Name them as the person to ask about TBD fields and publishing |
| Venue and date | Settled | Pass it on as is |
| Fee | TBD; the owner is checking | Do not let AI fill it; show it as provisional |
| Last time’s flyer | Borrow only the look, or the wording too | State what may be reused |
| Done condition | First-time attendees can tell what the event is and where to sign up | Hand it over with the prototype |
Define done in one line before anything is made
A&A perspective
Before anything is made, write in one sentence what a viewer must be able to read for it to be done. Without that condition, deciding whether to fix a prototype tends to become a matter of taste.
Hypothetical example
For the flyer: “Done when first-time attendees can tell what the event is and where to sign up.” Preferences about colour or photos come after this condition is met.
Hypothetical example
This sentence comes from two fields on the page: who it reaches and what they should do. “First-time attendees” is the audience and “sign up” is the ask. If the condition will not fit in one sentence, revisit those two fields.
A&A perspective
Add the done condition to the page and hand it over together with the prototype. The requester can then answer by whether the sentence is met, not by taste.
From the sources
The same Anthropic article describes splitting a task into a fixed sequence of steps and checking partway whether conditions are met. Its example is writing an outline of a document, checking that it meets certain criteria, then writing the document. It also lists clear success criteria among the features of tasks where AI adds the most value.
A&A perspective
A&A thinks the same breaks can be placed in a design request. The requester writes the page, the maker checks anything missing with that requester, makes a prototype, and finishes with settled information.
A&A perspective
Apart from the done condition, also write when it may be published: once the fee and photo use are settled and the decider has approved. Even if a prototype meets the done condition, it is not published until both are in place.
Check with AI prototypes; do not circulate them as final
A&A perspective
Do not circulate an AI prototype inside the company as the finished piece; use it as material for checking the done condition with the requester. A&A thinks the more polished a picture looks, the more easily it gets passed around as finished.
From the sources
Canva, which provides a service for creating designs and working on them together, has its employees use Anthropic’s AI. According to a customer story published by Anthropic itself, people who plan its products build prototypes of new features with AI. They use those prototypes to show engineers and designers their ideas in a visible form.
From the sources
One of them says AI made it possible to create prototypes they would not have attempted before, giving them a visual way to show ideas to the team. The story also describes giving AI product design styles and principles up front, so that it works from the same assumptions each time.
A&A perspective
From this case, A&A takes the idea that a prototype is a tool for communicating ideas. Canva, though, is a large company with many employees, and the case is not about a small company’s design requests. The case does not say that Canva uses a one-page brief or a review procedure.
Hypothetical example
If the requester looks at the flyer prototype and says “It looks aimed at current customers,” go back to the page’s audience field before changing colours. If the answer is “I can’t say while the fee is TBD,” do not make more options; record it as waiting for the owner’s decision.
A&A perspective
Put TBD fees and wording into the prototype in a form that is visibly provisional. Keep the prototype file separate from the file that will be published.
Summary
A&A perspective
Write the request on one page, lining up what you want the audience to do and who makes the final call.
A&A perspective
Leave unsettled conditions as “TBD” instead of letting AI fill them, and name who will decide.
A&A perspective
Before making anything, write in one sentence what a viewer must be able to read for it to be done.
A&A perspective
Treat AI prototypes not as finished pieces but as material for checking the done condition with the requester.
The key to less design rework is not how fast AI makes things but the one-page brief and the done condition written before anything is made. On your next request, see whether you can write both before asking; that also makes it easier to choose the first job to hand to AI.
FAQ
When does a tidy one-page brief still not reduce rework?
When the purpose and conditions are already settled and the sheer volume of work is the problem. Then what to revisit is not how requests are written but the people available to make things and the order in which you ask.
Can the same page be used with an outside designer?
Yes. Whether the maker is an in-house staff member, an outside vendor or AI, the information needed before making is the same. With outside work, a remake can affect cost and schedule, so there is good reason to hand the page over first.
How do I check whether it works?
Check what the work was waiting on, not the number of options. Pick one request that came back recently and write out the time spent making it separately from the time spent waiting for information or approval. Compare the same split after using the page, including review effort and AI usage fees.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Canva empowers employees across teams with Claude
Anthropic · Publication date not stated
Accessed 2026-10-23 - Building effective agents
Anthropic · 2024-12-19
Accessed 2026-10-23