Sarah Clarity Studios

Chapter 4: Documentation & Naming that Downstream Teams Love

Created by Sarah Choi (prompt writer using ChatGPT)

Documentation & Naming That Downstream Teams Love for Mecha Concept Artists

In modular mecha projects, your drawings are only half the work. The other half is documentation and naming—the shared language that lets modeling, rigging, animation, VFX, UI/UX, gameplay design, tools, outsourcing, and production all move in the same direction. Modularity multiplies complexity: parts combine, variants stack, families branch, trims unify, and monetization adds another layer of content rules. Without clean documentation and a naming system that downstream teams trust, every new module becomes a meeting, every bug becomes a mystery, and every content drop becomes fragile.

For concept artists on the concepting side, documentation and naming are how you “ship” your intent. You turn a design vision into a buildable system that can scale. For production-side concept artists, documentation and naming are how you protect consistency during implementation: you reduce rework, prevent style drift, and make sure the modular ecosystem stays readable and ethically monetizable.

Why downstream teams care so much

Downstream teams don’t just need to know what something looks like. They need to know what it is, where it attaches, what it replaces, what it depends on, how it behaves, how it is categorized in UI, how it is balanced, and how it is monetized or unlocked. They also need the same answer every time, across hundreds of assets.

If naming is inconsistent, tools can’t auto-sort, scripts can’t batch-process, and outsourcing can’t follow standards. If documentation is vague, rigs break, collision fails, VFX overwhelms silhouettes, and UI labeling becomes confusing or misleading. The best documentation is not long; it is precise, consistent, and designed for reuse.

The mindset: treat parts like a library, not like illustrations

Modular customization is a content library. Your documentation should feel like a catalog with rules, not like a pile of pictures.

That means every module should have a clear identity: category, family, slot, tier, role, compatibility, and “why it exists.” The goal is that someone who wasn’t in the early concept meetings can open your package and understand how the system works.

A useful mental model is that each part is a “product.” It needs a name, a SKU-like code, a spec sheet, and an image. When you document like that, downstream teams can treat content as data—sortable, searchable, and verifiable.

The core artifacts: what to document for modular mecha

In modular systems, a concept package that downstream teams love typically includes a few repeatable artifacts.

A slot map shows every hardpoint on the chassis: head, core, shoulders, arms, legs, backpack, primary weapon, secondary weapon, utility, cosmetic slots. It also shows orientations and interface zones.

A family sheet defines visual DNA and trims: edge language, panel rhythm, material zones, signature motifs, and protected channels (team color, faction markings, emissives).

A compatibility matrix lists what fits with what, including known conflicts and dependencies.

A tier ladder sheet (starter/elite/legendary) defines what changes per tier.

A trim and material guide shows how trims unify parts, what trim sheets or material libraries are assumed, and how decals are tiered for mip friendliness.

A UX preview guide shows the recommended thumbnail angles, UI icons, and preview lighting notes.

You do not need to write a book. You need a repeatable template that can be filled quickly for each family and slot.

Naming systems: what good looks like

A good naming system is consistent, unambiguous, and tool-friendly. It should be readable by humans and safe for pipelines.

The best naming systems are structured. They include the minimum fields needed to uniquely identify an asset, and they use a consistent delimiter and ordering.

Downstream teams love names that answer the most common questions instantly: what slot is it, what family is it, what variant tier is it, what side is it (L/R), and what version is it.

The enemy of good naming is “creative naming” that changes per artist. Your lore name can be creative; your production name must be boring.

A practical naming convention for modular mecha

A simple convention that often works across art and tech is:

ProjectPrefix_Chassis_Family_Slot_Module_Tier_Side_VariantID_V##

ProjectPrefix keeps assets grouped.

Chassis identifies the base body.

Family identifies the style set.

Slot identifies where it attaches.

Module identifies the part type.

Tier identifies starter/elite/legendary (or S/E/L).

Side is L/R/Center where relevant.

VariantID is a short code for variations.

V## is the version.

In practice, you might shorten fields, but the structure stays.

This naming convention can be mirrored in file names, layer groups, and even in UI IDs. The point is not the exact string; it is the consistency.

Naming layers and callouts inside concept files

Downstream teams don’t just ingest your final PNG. They often need to reference your PSD, your callouts, and your notes.

Concept artists can help by naming layer groups and callout labels in the same structure as the asset naming convention. If your PSD has groups like “SHOULDER_L_ELITE” and “BACKPACK_LEGENDARY,” it becomes far easier for someone else to interpret.

For production-side concept artists, this is especially powerful when doing paintovers on in-engine screenshots. If you label the failing part with the exact slot and family code, the modeler can find it immediately.

Slot names: agree once, use forever

One of the biggest sources of downstream pain is inconsistent slot terminology. Is it “back” or “spine”? Is it “shoulder” or “upper-arm”? Is “utility” a slot or a category?

The fix is to agree on a slot taxonomy early and stick to it. Even if the taxonomy is imperfect, consistency beats perfection.

A slot taxonomy should include:

The slot name used in UI.

The slot name used in production.

The slot name used in tools.

If those three differ, document the mapping.

Families and trims: document the rules, not just the look

Families and trims are where modularity either feels curated or becomes kitbash chaos. Documentation should include the rules that keep combinations coherent.

For families, document the signature motif and the “do not break” constraints: edge family, panel rhythm, typical material breakup, emblem placement, and silhouette anchors.

For trims, document where trims must appear and what they imply. Trims can define interface zones, frame lines, and safe areas for decals. If trims are tied to trim sheets, document which trim sheet is used and how it maps to the design.

Downstream teams love trim rules because they reduce subjective debates. Instead of “this feels off,” you can say, “This violates the family trim thickness and corner radius.”

Dependency documentation: what changes when a part changes

Modular systems are full of dependencies: equipping a shoulder cannon may require a reinforced torso collar, a different backpack counterweight, a stance animation change, and a different VFX mount.

A dependency map can be documented as simple text rules:

“If Shoulder_Cannon_HEAVY is equipped, then Core_Collar_REINFORCED is required.”

“If Backpack_Long is equipped, then HipSkirt_Large is disallowed.”

“If WeaponType_Sniper is equipped, then ADS animation set changes.”

For concept artists, the key is to document these dependencies in plain language. You do not need to implement logic. You need to communicate intent so design and engineering can decide how to enforce it.

Readability documentation: protect what must remain readable

Downstream teams often need explicit guidance on what must remain readable under distance, motion blur, VFX, and UI overlays. This is especially important in multiplayer or dense combat.

Document protected channels:

Team-color zones that must remain visible.

Faction marking zones that must not be fully overwritten.

Primary silhouette anchors that must remain present.

Weak-point placement that must remain visible.

Document “do not destroy” areas:

Do not add noisy geometry to silhouette edges.

Do not cover the mount interface zone.

Do not place emissives that obscure the outline.

This guidance supports ethical monetization too, because it prevents cosmetics from becoming deceptive.

UX documentation: thumbnails, icons, and naming in menus

Loadout screens depend on consistent thumbnails and labels. If each part is shown from a random angle, players can’t compare.

Concept artists can help by documenting recommended preview angles per slot and per family, plus a consistent lighting approach that reveals silhouette and material zones.

Also document iconography alignment. If a part is “stealth,” specify the icon motif (sensor/ghost/low-signal) and ensure the visual design supports it. When UI icons and art language match, players learn faster.

For production-side concept artists, it can be helpful to provide a small “UI label dictionary” that maps production names to player-facing names. Player-facing names can be flavorful; production names should remain structured.

Outsourcing readiness: documentation that scales beyond your team

Outsourcing is where naming and documentation either saves you or breaks you. External partners need clear, minimal ambiguity instructions.

Downstream teams love concept packages that include:

A one-page family bible.

A slot map and hardpoint standards.

A trim and material guide.

A naming convention sheet.

A few do/don’t examples.

If you include those, outsourcing can produce parts that match your system. If you do not, you will spend weeks fixing mismatches.

Monetization ethics: document content rules clearly

If the project includes monetization, document the ethical constraints as part of the art system, not as an afterthought.

Document what cosmetics are allowed to change and what they are not allowed to change. In many games, ethical constraints include:

No cosmetics that change gameplay stats.

No cosmetics that reduce enemy readability.

No cosmetics that remove team-color channels.

No cosmetics that hide weak points.

No cosmetics that mimic another class silhouette.

Also document how rarity tiers map to visuals. If “legendary” cosmetics are mostly ornamental, say so. If a premium item includes a unique emissive pattern, document the intensity limits so it doesn’t become visual pay-to-win.

This documentation protects player trust and protects the studio from avoidable controversy.

Production-side habits: how to keep documentation alive

Documentation dies when it is treated as a one-time deliverable. In live modular systems, it must be maintained.

Production-side concept artists can keep documentation alive by using templates, updating a single source of truth, and tying documentation updates to content drops. When a new family launches, update the family bible. When a new slot is added, update slot taxonomy.

A simple practice is to include documentation fields in your review checklist: is the name correct, is the slot mapping correct, are dependencies documented, are trims compliant, are protected channels respected.

Common failure patterns and fixes

If downstream teams constantly ask what something is, naming is too vague. Fix by adding structured fields and consistent slot codes.

If modular parts look incoherent, family rules and trim rules are not explicit. Fix by documenting trim thickness, corner rules, and emblem placement.

If players are confused in the loadout screen, preview angles and labeling are inconsistent. Fix by providing thumbnail angle standards and a UI label dictionary.

If monetization causes trust issues, content rules were not documented. Fix by explicitly documenting protected channels and fairness constraints.

Closing: documentation is how you make modularity sustainable

Modularity is a promise of freedom, but it only works when the system is coherent. Documentation and naming are the scaffolding that holds the ecosystem together.

For concepting-side artists, strong documentation turns your vision into a scalable library that downstream teams can build confidently. For production-side artists, consistent naming and living docs protect the game from drift, confusion, and costly rework. When you document families, trims, dependencies, and ethical constraints clearly, you create a customization system that players understand, teams love working on, and studios can support long-term without burning out.