Illustration Style Guide for Product Teams

An illustration style guide should help two different people produce artwork that belongs in the same product. A mood board is useful inspiration, but it cannot answer practical questions about perspective, stroke weight, detail, or export settings. The guide needs reproducible decisions, visible examples, and a process for handling exceptions.

Define the system's purpose and boundaries

Begin with the situations the illustrations serve: empty states, onboarding steps, educational panels, or feature announcements. Specify where they should not appear. A product may allow illustrations in first-use screens but avoid them in urgent error messages or dense operational tables. Those boundaries protect attention as much as they protect consistency.

Use the color converter to record approved illustration colors in the formats your team actually needs. Convert source values consistently and label their intended color space. Conversion is a handoff aid, not a substitute for reviewing the palette on the product's real surfaces.

Write three visual principles that affect drawing decisions. For example: objects before characters, simple spatial depth, and restrained accents. Replace vague adjectives such as friendly with observable instructions: rounded exterior corners, no exaggerated facial expressions, and one focal object per spot illustration.

Create a scope statement distinguishing illustration from icons, logos, and screenshots. An illustration may use expressive proportions that would be inappropriate in a 16-pixel action icon. Keeping the systems related does not mean forcing them onto identical geometry or asking one asset to serve every purpose.

Specify geometry and construction

Choose a reference canvas and explain how it scales. A 240-by-160 working frame is a reasonable example for small spots, but the important rule is consistency within a placement family. Record safe areas, typical object size, and whether artwork is allowed to extend beyond the frame.

Define construction rules for perspective, corners, strokes, and depth. For instance, use front-facing objects with occasional simple side planes, rounded corners based on two approved radii, and strokes that remain proportional when the entire scene scales. If strokes should instead remain visually constant, document that exception and test the resulting SVG behavior.

Show the same object built correctly and incorrectly. A folder with dramatic perspective, a tiny handle, and three shadow layers might violate the system even if it looks polished. Annotate the differences so a contributor can recognize the pattern rather than copy one reference drawing mechanically.

Set a detail budget appropriate to display size. For a compact spot, try one focal object, two supporting shapes, and one grounding device. Treat those counts as starting constraints, not a mathematical definition of quality. Review at final size and remove lines that merge or create accidental texture.

Include guidance for characters only if the system actually uses them. Describe proportions, expression range, gestures, clothing detail, and representation review. Avoid making contributors infer those choices from a single mascot illustration or from marketing artwork designed for a much larger canvas.

Define color, lighting and composition

Give each approved color a role: focal accent, secondary object, outline, shadow, and surface. A palette of named roles is more useful than an unlabeled row of swatches. Identify which combinations work on light and dark product backgrounds and which need separate approved variants.

Use color hierarchy to direct attention. The strongest accent should usually belong to the main object or meaningful action, not to scattered decorative confetti. If every object receives an equally saturated color, the scene loses a clear starting point. Review monochrome versions to see whether composition supports the hierarchy independently.

Specify one lighting convention and a limited shadow treatment. For example, use a soft grounding shape beneath objects and avoid cast shadows inside small interface panels. If gradients are permitted, document their purpose and endpoints rather than allowing arbitrary effects that vary between contributors.

The MDN SVG documentation provides implementation references for vector features. Keep the style guide focused on which features your system permits. A technically valid blur or clipping construction may still be unsuitable because it is difficult to edit, inconsistent with existing work, or unreliable in the intended delivery context.

Provide composition examples for wide, square, and compact placements. State whether each is a new composition or a crop of a master asset. The aspect ratio calculator helps contributors prepare matching frames, while actual previews reveal whether the focal object survives each placement.

Make examples and accessibility part of the guide

Create a small reference set that covers different tasks: a first-use empty state, a no-results state, an onboarding step, and a neutral informational message. Include the associated heading and action so contributors see the relationship between art and interface content.

Document how to decide whether an illustration is decorative or informative. If it repeats adjacent text, avoid redundant announcements. If it adds essential information, provide a suitable alternative. Link to the WAI images tutorial rather than inventing a rule that all illustrations receive the same alternative text.

Include negative examples: artwork that overpowers the action, imagery that implies data loss when only a filter is active, or a metaphor that depends on local cultural knowledge. Explain the problem in terms of user interpretation, not personal taste. The Nielsen Norman Group empty-state guidance provides additional context for judging whether the interface communicates a useful next step.

Connect illustration rules with existing design token documentation where shared colors or spacing apply. Do not make illustration-specific geometry a global component requirement merely because both systems use numbers and named values.

Document delivery and review responsibilities

Define asset handoff requirements: editable source, export format, canvas dimensions, naming, approved background variants, and any license or attribution record. Specify whether text must remain outside artwork and how referenced fonts or linked raster elements are handled. A visually correct file that depends on a missing external resource is not ready for delivery.

Use the existing SVG cleanup guide when preparing vector exports. Compare the optimized result with the approved artwork, including gradients and clipping. Preserve an editable source even when the delivered asset is simplified.

Create a short review checklist covering meaning, construction, palette, display-size legibility, responsive composition, and export integrity. Name the person responsible for approving visual exceptions. Record exceptions with their reason and affected assets so a temporary workaround does not silently become the next contributor's reference.

Finally, test the guide with a new assignment. Ask someone who did not create the initial artwork to draw a simple approved concept using only the documentation. Their questions reveal missing rules. Update the guide when repeated ambiguity appears, and keep the reference set small enough that teams can actually consult it before starting work.

Key takeaways

• Turn visual principles into observable construction and composition rules.
• Define color roles, reference sizes, detail limits, and placement variants.
• Show approved and rejected examples with explanations tied to meaning.
• Require editable sources, verified exports, and a clear exception-review process.