A delivery matrix lists what must be supplied for each use before export begins. It prevents small variants, transparency requirements, and editable source needs from being remembered only at the deadline. Build it from confirmed destinations and specifications, then use it to track both creation and inspection of every final file.
Describe each output as a distinct requirement
Create a row for each actual deliverable, such as website header, social card, print poster, and layered source. Record dimensions, aspect ratio, format, background or transparency, color requirements, and intended use. Keep pixel dimensions and physical print dimensions clearly distinguished. A row labeled web version is too vague if the project needs several different web placements with different crops.
Add language, wording, or content variants where they change the artwork. A second language may require a different text layout, while a product color variant may affect contrast and reflections. Do not hide these under a generic export count. Identify which changes require composition work, which share a source, and which are simple encoding differences from the same approved image.
Confirm specifications with the receiving person or production supplier. Ask about bleed, profiles, accepted formats, or file size limits where relevant. Mark unknowns explicitly rather than filling cells with habitual defaults. A matrix can look complete while containing unsupported assumptions, so distinguish confirmed requirements from provisional values that still need a decision before delivery.
Track review as well as file creation
Include a clear filename or naming pattern for each row. The name should make the intended use recognizable without opening the file. Link the output to its approved source revision so a later correction can identify which variants need regeneration. A matrix is especially useful when several apparently similar files differ in crop, text, or background treatment.
Use separate status fields for exported and checked. Creating a file does not establish that its dimensions, transparency, visible content, or compression are correct. Open each output and inspect the properties relevant to that row. A print PDF requires different checks from a transparent PNG, while a layered source requires navigation and dependency checks beyond a flattened appearance preview.
When feedback changes the illustration, trace the affected rows and update them deliberately. A corrected date may affect every language version, while a background color change may apply only to screen outputs. Avoid assuming all exports regenerated automatically. Mark the old variants superseded so a stale file cannot remain in the final package simply because its filename still looks appropriate.
At packaging, compare the actual folder with the matrix and remove unrelated drafts. Include a concise delivery note explaining file roles and any agreed exceptions. Archive the completed matrix with the exact delivered files. The matrix is successful when every promised use has a verified artifact and the recipient can identify that artifact's purpose, reducing the risk of a technically valid file that belongs to the wrong destination.