A week or two after I signed on with Rev Supply Co. as Digital Marketing Director, I flew out to the company’s headquarters in Santa Ana to meet with the team I inherited. Leading to that point, creative had been the responsibility of two junior-grade graphic designers working onsite. I met with these two first and asked them to walk me through their daily routines, most of which involved creating product assets like diagrams, banners, thumbnails, and more.

Right away, I could tell these designers were hard workers. But I could also plainly see that their methods were a bottleneck to the team’s output. Before I could demonstrate any real improvements to the marketing department under my leadership, this limitation had to be addressed.

Note: The goal of this project was to systemize production of these assets. The assets desperately needed a graphical redesign too, which came not long after with //Ulrich. But that could wait for the time being. First, we needed order.

Sighting The Problem

Since I wanted to get an accurate reading of their everyday productivity, I made sure not to put any undue pressure on my new subordinates. To begin, I simply asked them to demonstrate the creation of a common graphic while I watched, so that I could understand the process. As one designer went through the motions to build what he called a “Cars and trucks banner” (pictured above), he and his partner outlined the steps for me:

1. Open a shared Excel spreadsheet in OneDrive
2. Find the SKU they were asked to work on (by email, not project management software)
3. Find the column marked “Popular Vehicles”
4. Take note of the first five vehicles listed there
5. Search for each vehicle on Google Images
6. For each one, find photos with white backgrounds
7. Try to find photos taken from angles that complement the others
8. (If this is not possible, at least collect an assortment of three or four)
9. Isolate each image (remove white backgrounds) in Photoshop
10. Move all of the isolated images into a new Photoshop file together
11. Somewhat align the vehicles in a row
12. Add text boxes with the vehicles’ names
13. Add a text heading with a general description of the item
14. Save the PSD file inside a folder named by the item SKU
15. Name the file something like “Pickup trucks banner” (doesn’t matter what it’s called)
16. Export to PNG format

Keep in mind that these were the steps for just one graphic. One of thousands required for thousands of products.

With the “Cars and trucks banner” done, I continued to sit and converse with the designers while they made additional elements for SKU 70K648, a typical M14x1.5 lug nut kit. They didn’t know it, but I was keeping track with the stopwatch on my phone. The table below provides a breakdown.

By the time the assets were ready, 3 hours and 19 minutes had gone by. That kind of time is excessive, especially for such simple designs. And the waste doesn’t end there, because construction is supposed to be one stage of an asset’s lifecycle. How would this team have handled a sweeping revision, such as a color change or textual update for the whole catalog?

With their methods, incremental improvement was out of the question, since even small changes would cost a fortune.

Expanding and Utilizing the Product Data Model

My first step was to collect and audit every type of graphic in circulation, and then hold whiteboarding sessions with the creative team. The goal was to document their storytelling methodologies, the purposes behind those methods, and how well the current assets served those purposes.

In doing so, I discovered two root causes of inefficiency. On one side, the creative team’s narrow-minded practices left no path toward scale. On the other, the product data they were expected to work with was underdeveloped. SKUs existed only for sellable items like kits or bulk packs, meaning the company had no way to reference an individual nut. So, designers were left guessing which nut belonged in which diagram. That explained some of the head-scratching, not to mention why no one bothered to organize relevant resources.

To solve this, I introduced a new layer of structure:

• Piece Index: A unique identifier for the single nut or piece (e.g., 08##48BLK). This gave creatives and engineers a common language for the smallest unit of product representation.
• Kit Index: A parallel identifier for kits. While a SKU refers to a specific sellable item (e.g., 08K648BLK), the Kit Index (08K#48BLK) denotes the general kit type, regardless of the quantity contained.
• Natural Parent: A logical grouping based on product lineage. This connects a nut back to its natural grouping as presented in the catalog. For instance, color variants are parented to the standard chrome-colored SKU.
• Mechanical Parent: A functional grouping based on vehicle fitment. This ensures that when a product appears in a diagram, it’s contextualized correctly within its practical use case.

These attributes did not exist in the product database, which, at the time, was managed in a spreadsheet. I worked with the product team to formally institute them as part of the company’s data model. I also modified the schema for existing attributes, including Category and Series, to better support creative workflows.

That effort laid the groundwork for our later adoption of a full Product Information Management (PIM) software (project //Roller), but even in the interim, it gave us a controlled vocabulary with zero ambiguity.

Below, you can see a small batch of SKUs with their attribute assignments. Next, I’ll explain how I employed these attributes to set up a true Creative Operations Framework (COF).

Establishing a Naming Convention

Now, product data was structured in such a way that lines between different products, as well as between products and their constituents, were clearly drawn. And since I had met with both my team and executive leadership to nail down existing concepts as well as storyboard new ones, I knew how to turn those clearly drawn connections into concrete expectations within a smarter creative workflow.

But concrete expectations would only go so far if I let my people keep naming their files “Truck banner thing final.psd.” I needed them to follow a formula, starting with an actual naming convention. The convention I selected was the one set forth in the Atlas Method, a file management philosophy I developed personally in 2021. Feel free to read up on //Atlas. I won’t go into detail about the entire method here, but it’s worth noting that the naming convention is only a part of it. This project borrowed other ideas from it as well.

Mapping Assets to Products

At this juncture, //Roller, our PIM implementation project, had begun and was running concurrently. I knew it would be some time before Roller was fully deployed, but I also knew Opheim depended on it. The controlled vocabulary I had just defined needed to live in the PIM’s schema, where it could be enforced against every SKU. For that reason, one of the very first structures I implemented in Roller was a system of asset mappings.

These mappings defined how each product should connect to its required creative deliverables. For every SKU in the database, I established a set of asset types, each paired with two directives — Layout and Scope.

• Layout identified which layout variant should be used within a master file.
• Scope defined the level of product hierarchy the asset should represent.

From just those two attributes, a procedural filename could be generated. Each filename carried a dual role:

• As instructions for the designer, it told them exactly which layout and which scope to build against.
• As expectations for the system, it functioned as a contract—if the prescribed file didn’t exist under that name, the asset didn’t exist.

This approach eliminated ambiguity and guesswork, replacing “Truck banner thing final.psd” with deterministic, machine-readable identifiers. In the table below, you can see the generated filenames for the same SKUs listed in the earlier table. Every file became both a directive and a data point, making the creative workflow inseparable from the product database.

Corraling Assets in InDesign

With mappings defined and filenames procedurally generated, the next challenge was where to anchor the work. It wasn’t enough to define assets in the PIM; those assets needed a production environment that could hold them together, enforce consistency, and make large-scale updates effortless. For Opheim, that environment was Adobe InDesign.

InDesign excelled here because so much could be centralized inside the file itself. A single .INDD file wasn’t just a canvas—it was a container of rules.

• Master Pages established repeatable structures for layouts, grids, headers, and callouts. Editing a master updated every linked page automatically.
• Object Styles standardized the look of recurring elements—annotation arrows, product callouts, or technical frames—so a tweak to one definition cascaded everywhere it was used.
• Paragraph and Character Styles locked down typography across captions, labels, and SKU numbers, eliminating drift and guaranteeing uniformity.
• Linked Ingredients like illustrations, icons, swatches, or copy blocks were referenced directly, giving designers a single source of truth that updated predictably across every dependent layout.

This meant assets were no longer maintained one by one; they were managed as systems. Change a type hierarchy, and thousands of product diagrams updated. Adjust a swatch or object style, and entire series of assets shifted instantly.

Just as important was the day-to-day speed this unlocked for designers. In stark contrast to the old clunky Photoshop-based workflow, InDesign templates turned repetitive work into a seamless flow. A designer could keep a file manager open on one screen and InDesign on the other, dragging new images directly into predefined frames. Instantly, those images became linked files and had all required styles applied. Aside from a little refitting here and there, the template did the rest.

Scripting File Output

The final step was to bridge production with delivery. With assets corralled inside InDesign, consistent naming enforced by the Atlas Method, and mappings established in the PIM, the last piece was to automate output. For this, I turned to Adobe ExtendScript.

ExtendScript gave me direct programmatic control over InDesign’s export functions. Instead of designers manually exporting things one by one, guessing at filenames, and saving to arbitrary folders, a single script could do all of this in a deterministic, repeatable, sensible way.

The script pulled data directly from the PIM mappings, ensuring that every exported rendition carried the correct filename, complete with Scope, Layout, etc. Output destinations were also automated. This meant designers didn’t even need to think about filenames or folder hierarchies; the system handled it. All of it.

The impact was twofold:

• Error elimination: no more misnamed files, misplaced assets, or skipped variants. Scripts enforced the naming convention without exception.
• Mass scalability: hundreds of assets could be exported in minutes, freeing designers from rote tasks and keeping production aligned with schedules.

By combining InDesign’s centralization with scripted output, Opheim delivered a workflow that was faster, cleaner, and virtually immune to human error.

Result: Output Skyrockets by 276%

By the time Opheim reached steady state, the combined effect of Atlas naming, PIM-driven mappings, InDesign centralization, and scripted output was clear: production speed had transformed. What once required tedious manual setup in Photoshop was now reduced to a streamlined sequence in InDesign, backed by automation and enforced consistency.

The table below shows a sample set of assets produced under the new framework. Each figure represents the average time it took to prepare and export a finished rendition, compared with the prior process.

These numbers tell the story: output time was cut by nearly three-quarters across a representative workload. Assets that previously consumed half an hour or more could be completed in minutes, while simpler graphics dropped to almost negligible times.

The improvement wasn’t just speed. Accuracy rose in parallel, since filenames were generated systematically and assets flowed into the right destinations automatically. Designers spent their energy on creative choices, not repetitive prep, and the organization gained confidence that production would scale predictably with demand.

Opheim’s 73% improvement was not an incremental gain but a step change — proof that a disciplined operations framework, when coupled with the right technical implementation, can redefine what’s possible for a creative team.