Decomposed 100+ self-contained Lens Studio templates into a modular asset library, so creators across every skill level could compose new work instead of inheriting old patterns.
Context
Lens Studio's creators span the full skill range — and they all enter the platform through LS4 Templates: complete, self-contained AR experiences you open, study, and learn the platform from.
The user — three creator groups intersect
Three creator groups intersect at this migration moment, each with a different relationship to the change:
- Existing LS4 creators with deep template-first muscle memory — the group most disrupted by an architecture change.
- New creators with no LS4 history — who would arrive directly into the new architecture.
- The cross-functional internal team — Graphics, AR engineering, creator-experience — who own different parts of the system.
The hardest user research problem: how do you change the architecture without breaking the trust of the LS4 creators who built the platform's reputation?
The problem
Templates are great for learning. They're broken for building.
Hair Color
Portrait RelightingEach template is an all-in-one, opaque bundle.
The moment a creator graduated from learning to making their own project — pulling the physics from one template into a Lens that used voice UI from another — the complex, interlinked setup of each template became the wall. Creators without an engineering background — which is most creators — hit this wall first and hardest.
Why decomposed assets, not better templates?
The instinct was to simply migrate the templates. Existing LS4 creators would find what they knew, in the same shape. Comfort.
| Templatesseed similar work | Assetscompose new work |
|---|---|
| Each template is a finished destination | Each asset is a building block |
| Customize within the template's bounds | Compose freely across the library |
| Comfort, but locked-in outcomes | Initial unfamiliarity, but unlocked outcomes |
I argued for the harder path: break the template-first mental model. Templates step back from the building surface — modular assets step forward.
Templates teach a platform. Components build on it.
The brave part wasn't the architecture — it was telling LS4 creators to leave years of muscle memory behind. To soften that shift, the new asset architecture borrowed the two design cues creators already used to recognize and scan templates: the screenshot-icon and the technical name.
Marker template
Marker Image assetFor new creators — people without LS4 history — the mix-and-match-able building blocks are simply the starting point. They never have to unlearn anything.
Design decisions
The principles translate into specific choices. Each has a defensible alternative I didn't take.
1. Rank the Asset Library by popularity — carry LS4 usage data across the cutover
The Asset Library inherits one signal from LS4 — which patterns creators actually reached for. Highest-popularity assets surface first, so creators see what their peers were already using even though the architecture underneath is new. LS4 usage history became gravity for the new system instead of being thrown out with it.
Trade-off: a clean-slate ranking would have been free of legacy bias. The carryover means LS4 patterns shape what LS5 creators see first — that bias is intentional. It's what gives recurring creators their bearings on day one of the cutover.
2. Preserve LS4 recognition signals — screenshot icons and technical names
The Asset Library uses the same two recognition cues creators relied on in the LS4 era: each asset's icon is a screenshot of what it produces, and asset names keep the technical vocabulary creators already searched for — Voice UI, Cloth Sim, Hair Color, Physics. The architecture changed underneath, but the search-and-recognition surface stayed identical.
Trade-off: abstract icons would have scaled cleaner at small sizes, and newer naming would have read more elegantly — both costs paid to keep LS4 muscle memory intact.
3. Asset Library imports auto-configure the setup
When a creator picks an asset, the Asset Library handles both the import and the configuration — instantiates it, sets sensible defaults, links dependencies. The creator gets a working asset, not a kit of parts to assemble. The primary path has to work for non-coders, who are most of the creator base.
Trade-off: manual setup would teach more about how the system works underneath. Auto-configuration trades that learning moment for time-to-first-result — the creator sees the asset working before they understand how. The curiosity catches up later.
4. Standalone assets, built on named primitives
Each asset works on its own — no required ecosystem to drop in. The library composes from a small set of named primitives — Behavior Script (trigger/response), Tween Manager (animation), Visual Script (node-based logic) — that creators recombine across the platform. The engineering team's new package management and versioning is the foundation: each asset is individually versioned and dependency-aware in a way the LS4 template format never had to be. Templates can still live on this infrastructure. The Asset Library is what leverages it.
Trade-off: deeply interconnected assets could be more powerful but create dependency anxiety — standalone-by-default removes that. Primitives need careful API design because they compose everywhere, so early mistakes compound.
5. Keep templates with complex setup or eye-catching use cases as sample projects
Not every template made it through the decomposition. Two cases stayed whole as sample projects on the LS5 Home Page rail:
- Complex internal setup — templates whose value lives in the interlock. Decomposing loses the lesson.
- Eye-catching showpieces — templates where the use case is the point. Asset-by-asset doesn't carry the hook.
Trade-off: a fully decomposed library would have been cleaner architecturally. The hybrid model keeps showpieces whole because that's where their value lives.
The migration
I led the cross-team Lens Studio 4→5 platform migration across graphics, AR engineering, and feature teams. We decomposed 100+ legacy templates into reusable components and assets — building blocks that snap together cleanly across every kind of creator.
The cross-functional execution
This wasn't a unilateral design move. The migration spanned three teams with different ownership and different cadences:
- Graphics team — owned the underlying engine components the new asset architecture composed.
- AR engineering team — owned the runtime behavior the assets produced.
- Creator-experience team — owned the surface creators actually touched.
As cross-team project lead for the migration, I aligned the three on a shared decomposition plan, navigated the trade-offs where their interests differed, and kept the creator-facing experience coherent across what was effectively three engineering programs running in parallel.
The migration shipped on a single timeline despite spanning three teams. That coordination — not any single design decision — was the harder half of the work.
Outcome
A platform-wide content architecture shift shipped to the Lens Studio creator ecosystem. The 100+ asset Asset Library grew out of this work, including primitives like Behavior Script (trigger/response without code), Tween Manager (animation without code), and Visual Script (node-based logic without code) — adopted as core building blocks used by the majority of Lens Studio creators.
One tracking capability, three themed variants. Creators picked the art direction without forking the underlying template.
Marker exposed as two composable variants — Image and Cube — instead of two separate template forks.
3D Body decomposed into four ready-to-use variants. Each one a starting point creators could remix.
Behavior Script and Tween logic lived duplicated inside every legacy template — every fix had to be re-applied across 100+ places.
Measurement
Two signals told us the migration succeeded.
- Asset Library adoption spike post-migration. Creators reached for the new assets at a rate that exceeded the rate at which they'd reached for templates pre-migration. The decomposition didn't just preserve velocity — it accelerated it.
- Lens publish rate held steady through the cutover. The fragile moment was the version cutover itself — creators with deep LS4 muscle memory who might have churned. Publish rate held, which means the recognition signal decisions worked: creators trusted the new system enough to keep shipping through the transition.
The numbers are internal. The directional signal is the case study.
The throughline
Four design instincts run through every decision in this migration:
-
The brave move is rarely the comfortable one. Migrating templates one-to-one would have been comfortable. Decomposing them into a matrix-organized library was right.
-
Familiarity bridges complexity. Recognition signals — icon-as-screenshot, preserved vocabulary, capability-matrix organization — let creators walk into a new architecture without flinching.
-
Preserve the muscle memory; restructure underneath. Existing creators' search-and-recognition behavior is sacred. Architecture changes have to flow underneath that behavior, not against it.
-
Cross-team coordination is the harder half. The design decisions matter; the cross-team alignment that delivers them coherently matters more.