As 3D production expanded across configurators, digital twins, AR, and virtual try-on, what started as a technical and artistic challenge turned into a design problem, the moment quality started depending on who happened to be working on a given asset that week, not on any system behind it.

My approach followed the same method design work always does: identify the friction, treat the people affected by it as users with real needs, and build a response that actually speaks to them, not a fix that just closes a ticket. Applied to a pipeline instead of a product, that meant designing how the team worked before designing what they shipped.

Configurable 3D products from the SaaS platform

Who the Pipeline Serves

I started by reading the pipeline the way I would read a product: less a chain of tools than a system people work inside. The empathy is practical here: identifying who actually depends on it, and where it was failing them.

Three groups of users emerged, each with different operational needs and its own recurring frictions. Every design decision that followed was tested against these three perspectives, so the system stayed technically sound and operationally usable at the same time.

Technical Artists

Needed predictable hierarchy and naming to run validation and automation reliably.

Product Team

Needed planning visibility and production logic that repeats across product lines.

Brands & Clients

Needed coherent quality, behavior, and visual identity across every channel.

How the Work Repeats

The response to those frictions is not a standard written once and enforced. It is an iterative loop: the same four steps run every time a new friction surfaces, whether it comes from the team itself or from a supplier on the other side of a handoff, and the next time something feels harder than it should, the loop starts again at step one.

01

Problem Identification

Feedback from the team and from external suppliers surfaces the same issue more than once.

02

Build & Test

A workflow gets built and tested against real production, on that one recurring case.

03

Workshop & Documentation

What works is taught to the team in a shared workshop, then written down as documentation.

04

Extended to Suppliers

Documentation and handoff criteria travel outside the team, letting new suppliers work in parallel.

Scaling 3D meant designing how teams worked before scaling customer-facing experiences.

Real-time 3D product render from the SaaS pipeline

The Default Workflow

Every specific fix eventually traces back to the same five-stage pipeline. It is built around one recurring reality: the same model often carries a family of variant products, changing color, material, or shape. Each stage carries its own logic underneath, refined against a shared board where the team and its partners flag friction directly, project after project.

Each project starts with a mapping session on Miro, where all configurable options are laid out and each variant is tagged as either a geometry change or a color and material change.

From that session, a shared reference sheet is produced: a structured document capturing the variation logic for every option. That sheet also defines the master model: a single reference asset encoding naming, hierarchy, and structural slots from which all variants derive.

Geometry variation

When the product changes in shape, structure, or removable components, the asset follows a dedicated geometry flow built around a stable master model and controlled variant branching.

Material variation

When the product changes only in finish, color, or surface treatment, the variation is handled through material logic and mapping rules, avoiding unnecessary geometry duplication.

The master model is the single point every variant derives from. Its naming and hierarchy are functional, not just organizational: defined once at the source, they stay coherent across every variant that follows.

A coherent schema also automates part of the platform setup: variant mapping, material targeting, and component visibility are driven by predictable naming instead of manual assignment.

Master model with shared naming and hierarchy

Texture sets and their unwraps are assigned based on the presence of static or variant surface areas, not just mesh topology.

Assets are prepared with a neutral white base color, keeping the model decoupled from any specific finish. Color and materials are added in the final phase, or directly in the platform at configuration time.

Shading and texturing with neutral white base and variant areas

Geometry and textures are tuned to delivery constraints before anything reaches the platform. Textures are compressed in bulk, and assets are saved in web-compliant formats such as glb. When a model still weighs too much, Draco compression closes the gap.

The asset is loaded into the platform, where the final fine tuning and configuration operations take place: naming and configurations are validated at handoff. If the previous stages have been respected, this phase is very fast.

Where the Pipeline Branches

Some problems needed more than a rule inside the default workflow. They needed a pipeline of their own, built the same way everything else in this process gets built: as a fix for one recurring case, tested, then documented and taught like the rest.

Photogrammetry and AI-generated model cleanup process

Photogrammetry & AI-Gen Cleanup

Photogrammetry captures and AI-generated models arrive messy: colored, unstructured, not ready for variants.

Blender handles retopology and unwrapping. Photoshop converts the capture into a neutral grey base and masks the variable areas. Substance assembles those masks into the variant zones.

Real-time transparency and refraction handling

Transparency & Refraction

Real-time transparency and refraction break easily outside a controlled render.

The workflow keeps both effects inside the limits of the engine running the experience, so what looks right in preview still holds once shipped.

After each project, a short retrospective with the team surfaces what to keep and what to adjust before the next cycle runs, which is the actual reason this pipeline looks different today than it did two years ago.

Results

Once workflow states, standards, and naming logic became explicit, the platform team spent less time on repetitive configuration tasks and more time on product-level improvements.

Internal Workflow ~30%

Faster preparation and validation

Shared standards for topology, UVs, materials, and export logic reduced preparation and validation overhead across the catalog.

External Teams 3+

Parallel external teams

Supplier-facing guides and repeatable handoff criteria enabled concurrent external production without redefining quality expectations each cycle.

Delivery Capacity ×2

Projects handled in parallel

A structured operating model enabled parallel delivery while preserving consistency across configurators, AR, and virtual try-on experiences.

A less visible outcome was client confidence. More consistent delivery and clearer implementation made the work easier to trust, and that satisfaction translated into stronger relationships, repeat opportunities, and new leads. That kind of trust doesn't come from a single good delivery. It comes from a team and a network of partners who no longer need to ask the same question twice.