A style guide is for the decisions that happen when you’re not in the room. Its job is to make the same call get made the same way, regardless of who’s making it.
Why a style guide exists
Clarity. That’s really it. Not as a buzzword - as the actual problem a style guide solves. Without it, every artist on the team is making judgment calls based on their own interpretation of the brief, their own mental image of what the art direction means. Multiply that across ten artists, add external vendors, and by the time you’re mid-production you have a visual language that’s drifted in ten slightly different directions.
Art direction and a style guide aren’t the same thing. Art direction is the ongoing conversation with reviews, feedback, context shared in the room. A style guide is the written artifact of that conversation. It’s what works when the art director isn’t available, when a vendor joins three months in, when someone needs to make a call at 11pm and can’t ask anyone. Getting it down in writing isn’t about bureaucracy; it’s about making the team functional without requiring a bottleneck.
What actually goes in it
The most valuable thing a style guide can do is remove ambiguity through imagery. Words like "stylized" or "hyperreal" or "gritty sci-fi" mean something different to every person who reads them. If I say H.R. Giger, you immediately have an image in your head, the tone, the shape language, the level of surface detail, the palette. That’s the level of specificity a style guide should aim for.
In practice, the sections worth having are:
Intent and pillars. Two or three sentences on what the overall look is trying to communicate. Not a mood board but a decision. "This world should feel utilitarian and improvised, not designed." That’s a rule an artist can apply.
Reference and counter-reference. The "do" is only half of it. Showing what the style is not, is equally strong imagery that sits in the wrong direction. This is often more useful than the positive reference alone. A counter-reference removes a whole class of wrong decisions in one image.
Do / Don’t examples from your own work. The moment you can show a correct asset next to an incorrect one from your own project, the guide becomes concrete. Developers understand this immediately in a way that external reference never quite achieves.
Material and lighting conventions. What’s the roughness range for hero props? Are metals warm or cool? Does foliage get a detail normal? These decisions get made during look-dev and forgotten six months later unless they’re written down.
Technical constraints. Texel density targets, polygon budgets per category, texture resolution rules. These belong in the style guide, not just in a separate tech doc nobody reads alongside it. More on this below.
The principle throughout: stick to the decisions, not decoration. A style guide stuffed with inspirational images and no rules is just a mood board. What teams need is a document that tells them what to do, again, clarity.
How I’d structure it
I’ll be upfront: I’m not an art director, so take this with that context in mind. But from the Tech-art and Material side, the structure that makes the most sense to me is macro to micro: start from the broadest strokes and get progressively more specific.
Start with intent (one page), move into overall shape language and silhouette, then materials and surface treatment, then lighting conventions, then the technical floor. That order mirrors how an artist actually approaches an asset: they establish the big read before honing in on the detail.
Visual-first throughout. Prose explains; images decide. For every rule you can state in words, find the image that makes it obvious. The "show the wrong version next to the right one" technique is underused, but it’s the fastest way to communicate where the line is.
The technical-art angle
This is where a TA can add something an art director often can’t: grounding the guide in what the engine actually enforces.
"Keep assets feeling grounded" is an art direction note. "All props target 5.12 px/cm texel density at the camera’s closest LOD distance" is a pipeline rule. Both matter, but only the second one is scriptable which means it’s the only one the validation pass can check automatically. The more of the style guide’s rules you can express as measurable constraints, the more of the guide you can enforce without relying on human review.
The goal is to make the style guide and the pipeline agree with each other. If the guide says one thing and the export validation flags something different, artists will learn to ignore one of them and it’s usually the guide. When they point in the same direction, consistency becomes structural rather than aspirational.
This connects directly to what I wrote about in Day 31 - 🛠️ Behind the process - How I Structure a Pipeline and Day 34 - 🛠️ Behind the process - Documenting Tools for Others: the pipeline and the documentation need to be a single coherent system, not two separate artifacts maintained independently.
Keeping it alive
The team owns it. Not one person, not the art director alone but the team. For that to work, everyone needs to see it as a shared resource rather than a top-down document handed to them. The practical way to get there is to build it collaboratively during look-dev, not write it after the fact and present it as law.
A style guide is a living document. When production reality diverges from it, and it will, the guide needs to catch up. Ignoring the gap is how you end up with a document that reflects the project as it was planned, not as it was built. That’s the version nobody trusts, and eventually nobody reads.
When the guide and production diverge significantly, the cost shows up as rework: assets that need to be redone because the rules shifted but weren’t communicated. Keeping the guide updated isn’t overhead - it’s how you prevent that cost from compounding.
Closing thought
A guide nobody reads is worth nothing. Write it to be used, not filed. That means keeping it short enough to actually reference, visual enough to be understood at a glance, and maintained well enough to still be accurate six months later. If it fails any of those three, it becomes wallpaper.
The best style guides I’ve seen are the ones that feel like they were written by people who had to use them.
© 2026 Stefan Groenewoud. All views are my own, not those of my employer.Day 34 - 🛠️ Behind the process - Documenting Tools for OthersDay 34 - 🛠️ Behind the process - Documenting Tools for Others: