How can I set expectations for quality without asking for unnecessary perfection?

Agree on the purpose and the quality bar before anyone starts. The key is to distinguish requirements from preferences. If every suggestion sounds mandatory, people may spend time polishing details that do not help the work succeed.

Try three levels:

1. Must-have: required for the work to serve its purpose. State these as observable checks, not vague adjectives like “excellent.”
2. Useful improvement: worth doing if time allows or if it clearly helps the audience.
3. Optional polish: a preference that can be skipped without making the deliverable unsuccessful.

Then describe how the work will be used, who will use it, and what “done” looks like. A short agreement might say: “This is ready when the required information is present, checked, and understandable to [audience]. A consistent layout would help, but decorative refinements are optional.” That sets a real standard while leaving room for judgment.

For each level, name the condition that would let a person decide whether it is met. Tie that condition to the task’s purpose. “Make it clear” is hard to assess by itself; “a new team member can follow the steps without asking what each heading means” is more useful.

You can fill in this agreement:

Task: [deliverable] Purpose and audience: [what it will help someone do; who will use it] Must-haves: [required content, checks, or format] Useful improvements: [changes that help but are not required] Optional polish: [preferences to attempt only if time remains] Done means: [observable conditions for handing it over] Time or effort limit: [agreed boundary] Review: [who checks what, and when]

For example, assuming the task is a one-page internal process note: the must-haves might be the current steps, the responsible role at each step, and any known unresolved question clearly marked. A useful improvement might be an example of a common case. Optional polish might be custom illustrations. Adjust the requirements to the actual process and audience.

Ask what the deliverable needs to do now, and whether it is likely to be reused. A quick internal draft may need accurate core information and visible gaps, not finished styling. A document intended for repeated use may justify more careful organization and a clearer handoff. Reuse is a reason to consider extra work, not proof that every detail needs maximum polish.

Make the trade-off explicit. For example: “We have time to check the required facts and organize the sections. If we also add diagrams, that may delay delivery; please choose whether diagrams are necessary for this audience.” If different audiences have different needs, identify the primary audience first. Treat other audiences’ needs as improvements unless they are essential to the deliverable’s stated purpose.

Also agree on what happens when a requirement cannot be met. The person doing the work can flag the gap, explain its effect, and ask whether to adjust the scope or deadline rather than quietly hiding the issue or polishing around it.

Label the feedback and explain its priority. For instance: “Must fix before handoff: [specific issue], because [reason]. Suggestion if time allows: [specific improvement]. Optional preference: [polish idea]; skip it if it would delay the work.” Then confirm whether the change affects the agreed deadline or scope.

If the same “optional” change keeps appearing in review, decide whether it should become a requirement for future tasks. Update the agreement before the next assignment instead of relying on people to infer a changing standard. Keep the review focused on the agreed purpose and checks, not on whether the work matches one person’s unspoken ideal.

A useful closing question is: “Does this meet the must-haves for its intended use, and is any remaining improvement important enough to justify more time?” That gives the team a practical stopping point without confusing unfinished work with work that simply could be polished further.