How to Brief an Art Outsourcer So You Get It Right the First Time

A good art brief states the target, the constraints, and the delivery format before it says anything about style. Reference images do the work that adjectives cannot. Technical requirements belong at the top, not in a follow-up message, because they change how the art is made rather than how it looks.

Why this matters

Revision rounds are the hidden cost of outsourced art. A brief that produces three rounds instead of one roughly doubles the calendar time and strains a relationship you probably want to keep.

For a solo developer or small team, that delay usually lands on the critical path. Art is often the last thing integrated and the first thing blamed.

The fix is unglamorous. Most revisions trace back to something the brief did not say.

What a bad brief costs you in revisions

Consider a request for "a set of fantasy-style icons, bright and colourful".

The artist has to guess the resolution, the aspect ratio, whether the icons need padding, whether they sit on a dark or light background, whether they need a consistent light direction, what file format you want, and how they will be named.

Every guess is a coin flip. Six guesses means the odds of a usable first delivery are poor, and none of that is the artist's fault.

Nearly every art revision is a question the brief did not answer. Write the brief as answers to questions.

Reference boards that actually help

References communicate more in ten seconds than a page of description.

The mistake is collecting images you like. Collect images that isolate a decision.

• One board for silhouette and shape language. Are forms round and soft, or angular and sharp.
• One board for colour and value. Include the background the art will sit on, because context changes everything.
• One board for line and rendering. Outlined or not, flat or shaded, textured or clean.
• One anti-reference board. Two or three images of things that are close but wrong, with a note on why.

The anti-reference board is the highest-value part and almost nobody includes it. "Not this, because the outlines are too heavy" removes an entire direction in one line.

Annotate every image with what you are pointing at. An unannotated reference is ambiguous: the artist cannot tell whether you liked the colours, the shapes, or the mood.

Technical constraints to state upfront

These change how the asset is built, so they belong at the top of the brief.

The most commonly missed line is the real display size. Art designed at large resolution and shown small loses its detail and reads as muddy, and the fix is a redraw rather than a resize.

State the device floor too, for the reasons in Shipping on Android.

Naming, formats, and delivery spec

Boring, and it saves hours on integration.

1. File format, including whether you need layered source files as well as exports.
2. Naming convention, written as an example: icon_shield_01.png, not "sensible names".
3. Export sizes, listed explicitly if you need several.
4. Transparency handling, including whether trimmed or padded edges are expected.
5. Folder structure for the delivery.
6. Colour profile, which quietly causes mismatches when unstated.

Provide a template file where possible. An empty document at the right size with the safe area marked removes an entire class of misunderstanding.

Revision rounds and how to scope them

Agree the number of rounds and what a round means before work starts.

A workable structure for a set of assets:

• Round 0: one test asset. Before the full set, commission a single piece. This is the single most effective thing you can do, and it costs one asset to validate the whole brief.
• Round 1: notes on the full set, consolidated into one message rather than sent as they occur.
• Round 2: final corrections only, no new directions.

Consolidating feedback matters. Drip-fed notes cause rework on pieces already revised, and it is the fastest way to exhaust an artist's goodwill.

Write feedback about the asset, not the taste. "The outline is heavier than the reference board" is actionable. "It feels off" is not, and the general principle is covered in How to Give Feedback on Game Builds.

What we would do

Always commission one test asset first, even for a small set and even with an artist you have worked with. It converts a brief argument into a concrete conversation about an actual image.

Put the technical section above the style section. It signals that you know what you need, and it gets read.

Then keep the brief as a living document. When a question comes up in chat, add the answer to the brief rather than only replying. The next brief starts better, and the next artist starts faster.

The short version

• Most revisions come from questions the brief did not answer.
• Use four reference boards: silhouette, colour, rendering, and anti-references.
• Annotate every reference with what you are pointing at.
• State canvas size, real display size, background, and pipeline before style.
• Give a naming example and a template file rather than a description.
• Commission one test asset before the full set, and consolidate feedback into rounds.

Write the technical half of your next brief before the style half, and commission one test asset. If you want a studio that works from briefs like this, tell us what you need.

Related reading: Game Art Style Budget Guide, How to Write a Game Brief, and Why Simple Art Outperforms Detailed Art in Paid UA.