Friction Inversion

On a large DoD training contract, we had dozens of artists working across simultaneous deliverables under strict contract style requirements. People read the style guide. That wasn't the problem. The problem was that nobody could commit every layout treatment to memory, and the ones that took judgment, like spacing relationships, hierarchy decisions, and compositional rules, came out inconsistently from artist to artist, and weren't repeatable even by the same artist across sessions. The style guide described correct behavior accurately. It just couldn't enforce it at the moment the decision was being made.

The standard response would have been a more detailed style guide. A mandatory review gate. A layout audit that flagged violations after the fact.

Instead, I encoded the style guide into an Adobe Creative Cloud shared library, but not as a static reference. Smart graphics for every callout label variant. Character and paragraph styles for every typographic treatment. Interactive and non-interactive highlight colors as named swatches. PSDTs (Photoshop template files) for every approved layout, ready to open and populate. The library wasn't a collection of assets. It was a working design system that lived inside the tools the artists already had open.

Artists made consistent layout decisions, not because they memorized more rules, but because the correct treatment was already in the panel, one click away. Need a callout label? The smart graphic is there, built to spec, ready to place. Need the interactive highlight color? It's a named swatch, not a hex value (the raw #RRGGBB color code) to look up. Need a layout? Open the PSDT, not a blank canvas. Reaching for the wrong treatment meant going somewhere else to find it. Reaching for the right one meant clicking what was already there.

Correct behavior became the path of least resistance. The friction moved.

The style guide didn't change. The rules didn't change. What changed was where the rules lived. They moved out of a document that required recall and into a tool that only required recognition.

Section 508 (the U.S. accessibility law) compliance in digital courseware is notoriously tedious. Every image needs alt text. Every video needs captions. Every interactive element needs keyboard navigation and screen-reader labels. The remediation list for a single module could run to hundreds of items.

The standard approach: audit after production, generate a violation report, send it back to the team, wait for fixes, re-audit. A cycle that could add weeks to delivery and required specialized knowledge to interpret.

I built a tool that runs the audit and hands back remediation code, not a violation report. Instead of telling you an image is missing alt text, it gives you the corrected HTML with the alt attribute already filled in from the surrounding context, ready to paste.

The cognitive load of knowing what 508 compliance requires moved out of the artist's head and into the tool's output. Compliance wasn't a goal the team had to achieve. It was what the publish button produced.

My current project sources 3D assets built for a real-time game engine. The rendering and material handling live in the engine. The engine does things with UV channels (how textures map onto a 3D surface), material layers, and lighting that Arnold, our offline renderer for instructor-led training materials, doesn't know anything about.

For years, adapting assets from engine output to Arnold renders was a manual per-asset process. Every artist had their own approach. Results were inconsistent. Lighting matched in some renders and not others. The right way to do it lived in the head of whoever had figured it out last.

I used AI to iteratively build a custom shader tool that reads the same UV channels the engine uses and processes them through Arnold's material system. The bridge is the tool. Artists don't need to know how the engine handles materials. They don't need to know anything about UV channel logic. They run the shader and get a consistent render.

The knowledge that used to live in individual heads, and had to be re-learned every time someone new touched the assets, now lives in the tool. It works the same way every time. It produces the same output regardless of who runs it.

SCORM is the standard format for e-learning content that needs to run inside a learning management system. It is also, by any reasonable measure, a nightmare to produce correctly. The specification is dense. The tooling is either prohibitively expensive or severely limited. Most instructional designers either pay for a commercial authoring tool that abstracts the complexity or hand-code SCORM packages and accept the inconsistency.

I'm building CourseForge because neither of those options is right.

CourseForge is an LCMS, a learning content management system, built from the ground up with one constraint: the publish button produces compliant SCORM output. It doesn't hand you the SCORM settings and ask you to configure them correctly, and it isn't a validator that tells you what you got wrong after the fact. The output is compliant by construction.

The instructional designer shouldn't need to know what SCORM is. They write the content. They structure the module. They click publish. CourseForge handles the rest.

Twenty-one years of building defense training content taught me exactly where the friction lives in this workflow. CourseForge moves it.

A brand's social-video lower-third, the colored box that holds the on-screen headline, is exactly the kind of thing a style guide describes in a sentence and then watches drift for months. I audited one such feed. The brand color was perfectly consistent, but everything structural around it wandered clip to clip. Placement floated. The box width tracked the copy instead of a rule. Inner padding was eyeballed. The mark sat in one corner on some clips, a different corner on others, and nowhere at all on the rest. Every individual editor was competent. The format still came out different every time, because the correct version took a dozen small judgment calls and nobody makes the same dozen calls twice.

The standard response is the one everyone reaches for: write the brand bible. Document the exact placement, the padding, the safe zones, the type scale. Hand it to the editors and ask them to comply.

I wrote the bible, but the bible isn't the deliverable. The deliverable is an After Effects rig that is the bible, executable. A script builds the lower-third in every aspect ratio with the geometry baked into the structure: the 45° chamfer, the registration mark, one padding token, an auto-fitting headline that can't overrun the box or break the platform safe zone. It animates itself. And it promotes its own controls into Premiere's Essential Graphics panel, so the comp ships as a template an editor opens and types a sentence into. They don't set the placement. They can't. The placement is the one thing the tool won't let them touch.

The bible documents the rule. The rig makes the rule the only path. An editor producing a brand-perfect lower-third now does less work than producing a wrong one. There's no blank canvas to get wrong, just a headline to type.