How to Brief a Character Artist for Pr…

Key points

Define what the character must survive in production before visual approval.
Lock scope, references, constraints, ownership, and handoff evidence early.
Use the brief to prevent hidden assumptions from becoming late review churn.

Sections 8 parts

01 Start With the Production Outcome
02 Package Visual Direction So It Can Be Executed
03 Define Deliverables Before Production Starts
04 Make Technical Constraints Explicit
05 Use Milestone Gates Instead of Open Feedback
06 Separate Preferences From Blockers
07 Minimum Briefing Package
08 Common Briefing Failures

TL;DRToo long, didn't readExpand summary

A strong character brief defines what the asset must survive in production before visual work begins. It locks scope, references, technical constraints, approval ownership, and handoff evidence so creative decisions happen with fewer hidden assumptions and less late review churn.

Briefing job
Name the use case, target platform, camera distance, deliverables, technical constraints, and final decision owner before production starts.
Main risk
If the brief only describes mood or style, the artist may be forced to discover scope, pipeline, and approval rules while building the asset.
Better outcome
A production-ready brief gives producers, art directors, and outsourcing managers a clearer way to judge fit, progress, and handoff readiness.

A strong character brief is not a moodboard with a deadline attached. It is the first risk-control document in external character production: it tells the artist what the asset must survive, who can approve it, and which handoff evidence will be judged at the end.

The goal is not to remove creative judgement. The goal is to make the commercial and technical boundaries explicit enough that creative judgement can happen in the right place: shape language, anatomy, materials, personality, and readability, not late-stage guesswork about file formats or who owns final approval.

For a producer, art director, or outsourcing manager, the brief should make one decision easier: whether the character can move from visual intent into production without hidden scope, technical assumptions, or review ownership gaps.

Illustrated character production scene where a brief shields the team from unclear notes, deadline pressure, and scope confusion.

Briefing outcome

What the brief must make obvious

What the character needs to do in production, not only what it should look like.

Which constraints are locked, which are still unknown, and who can approve a milestone.

What the receiving team needs at handoff so the final asset does not become cleanup work.

01. Start With the Production Outcome

Open the brief with the job the character must perform in the project. A character for a real-time combat camera, a cinematic close-up, a toy render, and a UGC marketplace item can all share the same concept art but require different asset decisions.

Define:

Usage context: gameplay, cinematic, marketing render, pitch visual, marketplace asset, AR/VR, mobile, or stylized social content.
Target platform: Unreal, Unity, Roblox, proprietary engine, offline renderer, or DCC-only delivery.
Camera distance: hero close-up, over-the-shoulder, mid-distance NPC, crowd/background, or icon-scale asset.
Performance expectations: whether the asset must support LODs, mobile budgets, real-time lighting, cloth, hair cards, facial targets, or animation retargeting.
Final decision owner: the person who can approve or reject the milestone without creating contradictory review loops.

If the brief cannot answer these points, the artist is being asked to design the production target while also building the asset. That often creates avoidable rework.

Filled brief example

A production outcome written clearly

Use case

Stylized real-time hero character for a third-person game prototype. This tells the artist that silhouette, deformation, material count, and engine import matter more than offline render detail.

Target

Unreal Engine delivery with a client-provided skeleton and one clean import proof. The skeleton and validation target are named before modeling and skinning decisions are locked.

Approval owner

Character lead approves visual gates; technical art lead approves handoff readiness. Two owners are acceptable when each gate has a clear decision boundary.

Illustrated character briefing checkpoint where game, mobile, cinematic, and marketing uses point to different production targets.

02. Package Visual Direction So It Can Be Executed

References should explain decisions, not just taste. A useful visual package separates locked requirements from inspiration.

Include:

Approved concept art: front, side, and back views when available.
Turnaround or model sheet: orthographic views, proportion notes, callouts, and any asymmetry that must survive production.
Reference board: anatomy, material, costume, surface wear, hair, props, and lighting references grouped by purpose.
Silhouette priorities: which shapes must read clearly at gameplay distance or thumbnail size.
Material intent: skin, fabric, metal, leather, hair, dirt, decals, emissives, and finish level.
Do-not-use references: styles, shapes, materials, or character traits that are outside the target.

Avoid “make it like this” as the only direction. Better language is: “Use this reference for fabric weave, this one for silhouette, and this one only for surface aging.”

Illustrated reference board split into silhouette, fabric, wear, hair, and style groups instead of one vague taste pile.

03. Define Deliverables Before Production Starts

“Character model” is not specific enough for procurement. Spell out exactly what needs to arrive at handoff.

Data table

Character brief deliverables

Each deliverable should be defined before kickoff so production and handoff expectations are explicit.

Each deliverable should be defined before kickoff so production and handoff expectations are explicit.
Deliverable	Define before kickoff
High-poly sculpt	Whether it is required, whether it will be delivered, and whether it is a final source asset or a bake source only.
Low-poly mesh	Target topology expectations, deformation zones, naming, scale, pivot, and file format.
UVs	UDIM vs 0-1 layout, mirrored islands, texel density, padding, material IDs, and whether UV2/lightmap data is required.
Textures	Map list, resolution, color space, channel packing, source files, and target renderer or engine.
Rig support	Skeleton standard, skinning scope, facial blendshapes or morph targets, and whether the artist or internal team owns rigging.
LODs	Number of LODs, reduction rules, material consolidation, and whether cards, hair, or cloth need separate LOD behavior.
Documentation	Export preset, dependency list, known limitations, and technical notes for integration.

For legal and commercial terms, keep the creative brief separate from the contract. Usage rights, buyout language, work-made-for-hire terms, portfolio permissions, NDA scope, and source-file ownership should be reviewed in the actual agreement.

Illustrated model package with low-poly mesh, UVs, textures, rig, and documentation laid out as required deliverables.

04. Make Technical Constraints Explicit

Technical constraints are not secondary details. They determine how the asset is built.

Define:

Units and scale: centimeters, meters, or project-specific world scale.
Origin and pivots: world origin, character root placement, prop pivots, sockets, and attachment expectations.
File formats: FBX, USD, GLB, BLEND, MA/MB, ZTL, SBSAR, EXR, PNG, TGA, or studio-specific package format.
Engine version: target engine and version when relevant. Do not rely on generic terms like “game-ready.”
Skeleton and rig rules: Humanoid, Generic, Epic-style skeleton, proprietary rig, facial rig, blendshapes, morph targets, cloth, or physics proxies.
Texture protocol: PBR workflow, map list, max resolution, bit depth, sRGB/linear requirements, and packing rules.
Naming and folder rules: prefixes, asset IDs, version naming, folder hierarchy, and export preset names.

The brief should also state what is unknown. “Final engine version pending” is safer than pretending the pipeline is locked.

Illustrated constraint checkpoint where scale, pivot, format, and engine version rules are checked before production readiness.

05. Use Milestone Gates Instead of Open Feedback

Character production becomes expensive when every review tries to evaluate every aspect of the asset. Each milestone should answer one kind of question.

Data table

Character review gates

Each gate should resolve one production decision and keep feedback inside that boundary.

Each gate should resolve one production decision and keep feedback inside that boundary.
Gate	Primary decision	Feedback that belongs here
Brief lock	Is the scope clear enough to start?	Missing references, platform constraints, deliverables, approval owner.
Blockout	Does the form solve proportion, silhouette, scale, and major design intent?	Big shapes, pose neutrality, readable proportions, missing design features.
Primary sculpt/model	Is the high-level anatomy, costume, and construction direction approved?	Anatomy, surfaces, hard-surface logic, material zones, production risks.
Retopo/UV lock	Can the asset move into baking and texturing?	Edge flow, deformation zones, UV layout, material IDs, naming.
Texture/material review	Does the surface language match the approved target and engine constraints?	PBR response, map packing, color space, wear, material separation.
Handoff	Can the internal team import and use the asset without cleanup?	File structure, scale, skeleton, textures, export notes, missing dependencies.

Late redesign after retopology or UVs is not a normal note. It is a change request, because it can invalidate downstream work.

Illustrated milestone gate scene where open feedback is separated into blockout, UV lock, and handoff decisions.

06. Separate Preferences From Blockers

Use a priority ladder for feedback. It keeps the artist focused and gives producers a clear way to protect the schedule.

P0 - Production blocker: wrong scale, missing maps, broken skeleton, invalid topology, unusable export, missing source files.
P1 - Scope or concept mismatch: major silhouette drift, missing approved design element, incorrect costume structure, wrong material family.
P2 - Quality issue: anatomy refinement, surface polish, texture response, roughness tuning, readability at target distance.
P3 - Preference or exploration: alternatives that may improve the asset but do not block the agreed milestone.

Good feedback includes the location, the expected change, the reason, and the decision owner. “Make the jacket better” is not actionable. “Reduce the shoulder-pad width by roughly 15% so the silhouette matches the approved front view” is actionable.

Illustrated feedback ranking checkpoint where a broken export is treated as a blocker and a color jacket note is treated as preference.

07. Minimum Briefing Package

Before kickoff, a production-ready package should include:

Kickoff checklist

Minimum briefing package

Production target Project goal, asset use case, target platform, engine, renderer, or destination DCC.
Visual direction Approved concept art, reference groups, turnaround, callouts, and do-not-use examples when available.
Delivery contract Deliverable list, file formats, source-file expectations, known technical limits, and export requirements.
Review ownership Milestone gates, final approver, feedback severity, schedule assumptions, and hard dates.
Commercial boundaries NDA, usage rights, portfolio permissions, and source ownership handled in the contract, not hidden in art notes.

This package does not need to be long. It needs to be unambiguous.

Illustrated import checkpoint where a nice-looking character image fails engine import because scale and maps were not proven.

08. Common Briefing Failures

Using “game-ready” as a requirement: the phrase means different things across engines, studios, platforms, and character types.
Approving a concept without production callouts: the artist has to guess hidden construction, back views, material transitions, and asymmetry.
Changing the design after technical lock: late changes can invalidate retopo, UVs, bakes, and rigging assumptions.
No single approver: conflicting stakeholder notes slow the work and make accountability unclear.
Missing rights language: commercial use, source ownership, portfolio permissions, and NDA restrictions must be contractually clear.
No import test: visual approval is incomplete if the asset has not been checked in the target environment or equivalent validation scene.

If your team is about to brief a hero character, start by naming the use case, technical target, and approval owner. Those three fields expose most of the risk before production begins.