A 3D viewer lets someone inspect an existing product state. A product customizer lets them choose from bounded, predefined attributes and usually resolves those choices to a sellable catalog state. A product configurator evaluates a product model, rules and dependencies to produce a valid specification; it may also calculate price or feed a quote, order or manufacturing handoff.
Those are working scope definitions, not protected industry labels. Real products blur them. Google's <model-viewer> can enable orbit, zoom and pan through camera controls, which is classic viewer behavior.[1] The same component can expose material variants stored in one GLB.[2] A finish switch therefore does not, by itself, turn a viewer into a commercial customizer.
Use this page to decide which category fits. The 3D product configurator pillar covers the full system anatomy, including product models, option graphs, rules, pricing and integrations. Here, the narrower question is which responsibility your product actually needs.
Start with responsibilities, not the name on the button
The cleanest distinction is what the experience promises to return after a user acts.
The table below compares the working responsibilities and typical results for each category.
| Category | Primary responsibility | Typical result |
|---|---|---|
| 3D viewer | Present one approved product state for visual inspection | A changed camera view, hotspot state or AR handoff; the product itself may remain unchanged |
| Product customizer | Let a buyer select bounded appearance, personalization or catalog options | A chosen variant or personalization payload that can continue into a purchase path |
| Product configurator | Resolve choices against product, commercial or engineering rules | A valid configuration plus one or more downstream outputs such as price, SKU set, quote input or order data |
A viewer is enough when seeing the product from useful angles is the job. A customizer fits when all offered choices are already known and each valid combination can map to a catalog or personalization state. A configurator is warranted when the system must decide whether a combination is allowed, derive required components, recalculate commercial data or produce an output that another team or system relies on.
"3D" describes the presentation layer. It does not settle the category. A customizer can use still images, layered 2D artwork or real-time 3D. A configurator can use a form and no product render at all. Classify the responsibility first, then decide whether 3D helps the user make the choice.
Apply five tests before choosing a category
1. Product complexity
Count meaningful decisions, then inspect how they interact. Ten independent finish choices may be easier to implement than four dimensions with minimums, maximums and dependencies. Complexity appears when one answer changes what is possible next, not merely when the option list is long.
For a viewer, the product state already exists. For a customizer, the team can usually enumerate the offered states or treat personalization as a bounded payload. For a configurator, the valid product has to be resolved from a model of components, attributes and relationships.
2. Rule depth
Ask what happens when someone makes an invalid choice. A customizer may disable a sold-out color or hide a variant that does not exist. A configurator may need to explain that one mounting system requires a different frame, automatically add a power component, enforce a dimensional range or route an exception for review.
Salesforce CPQ documents alert, validation, selection and filter product rules. Its validation rules can block an illegal configuration, while selection rules can add, remove or hide products during bundle configuration.[5] That is a concrete example of configurator responsibility: business logic changes or rejects the result, rather than merely changing how it looks.
3. Price and availability
A customizer often reads commercial truth from an existing variant. Shopify's current Storefront API describes a ProductOption as a customer-selected attribute such as size, color or material, and says combinations of option values create distinct ProductVariant objects.[3] The corresponding variant object exposes selected options, price, availability, SKU and an associated image, among other fields.[4]
That model works when the catalog has already done the hard validity work. If price must be calculated from dimensions, quantities, regional policies, component choices or negotiated terms, the pricing contract belongs in configurator or CPQ scope. Do not let a visually updated price label hide where the number came from or who owns it.
4. Required outputs
A changed render is an interface state, not necessarily a business output. Name what must leave the experience: variant ID, personalization text, selected materials, calculated dimensions, component SKUs, price breakdown, saved configuration, cart line attributes, quote request or production specification.
The more downstream systems depend on the result, the less useful a loose "customizer" label becomes. A valid on-screen combination can still fail if the order payload omits an attribute that fulfillment needs.
5. Purchase path
A viewer may sit beside a normal add-to-cart flow without altering it. A customizer usually needs to bind selections to a product or line item before purchase. A configurator may end in a direct cart addition, a saved project, an assisted-sales review or a formal quote. The endpoint changes identity, permissions, persistence, pricing and integration scope.
Oracle describes its CPQ product as covering product selection, configuration, pricing, quoting, ordering and approval workflows across an opportunity-to-order process.[6] That is broader than a universal definition of "configurator." It is useful evidence of how far the responsibility can extend when configuration feeds enterprise selling.
Use the three-category decision matrix
This is an original Double Edged scoping framework. Read down the columns. If most rows land in one category, that is the working brief. If the rows split, define a layered system instead of forcing one label onto everything.
The table below is the three-category decision matrix.
| Decision axis | 3D viewer | Product customizer | Product configurator |
|---|---|---|---|
| Starting state | One approved model or product state | A finite set of known options or personalization fields | A product family, component model or parameter set |
| User action | Inspect, orbit, zoom, pan, open hotspots or launch AR | Choose finish, color, text, accessory or catalog option | Choose requirements, dimensions, components or performance parameters |
| Validity | The loaded state is already valid | Valid choices are enumerated or bounded with shallow availability logic | Rules evaluate compatibility, requirements, ranges and dependencies |
| Visual response | Camera or annotation state changes | Appearance or known variant state changes | Visual state follows the rule-resolved product specification |
| Price | Usually outside the viewer | Read from a variant or simple option adjustment | Calculated or retrieved from configuration, pricing and account context |
| Primary output | Viewed state or interaction event | Variant or personalization payload | Valid configuration plus specified commerce, quote or production outputs |
| Purchase path | Existing product page | Direct cart or order with selected options | Cart, save/share, review, quote, approval or assisted sale |
| Main source of truth | Approved 3D asset and product content | Commerce catalog and option data | Product model, rules, pricing authority and downstream master data |
| Stop signal | Users need to change the product | Choices affect validity or derived outputs | No rule engine or downstream dependency is actually required |
The stop signal matters. Buying a configurator for a viewing problem creates unnecessary product data, rule and testing work. Treating a configuration problem as a cosmetic customizer pushes rule handling into spreadsheets, support conversations or fulfillment exceptions.
Test the edge cases with one product
Consider a brand-neutral modular task lamp.
In a viewer scope, the shopper loads one approved lamp and inspects the pivot joints, base, arm reach and head from useful angles. Camera interaction is the product experience. There is no promise that the lamp changes.
In a customizer scope, the shopper chooses among three stocked finishes and two shades. Each allowed combination already has a variant identity, price and availability record. The visual updates to match, and the chosen variant goes to the cart.
In a configurator scope, the shopper selects a base, arm sections, voltage, head, shade and mounting accessory. Some combinations require a heavier base, some voltage and head combinations are incompatible, and arm reach affects which mounts are allowed. The system resolves those rules and produces the agreed order or quote payload. Real-time 3D may explain the result, but the rule-resolved specification is the product.
This example is a framework, not a claim about a shipped lamp or a measured project. A real brief still needs its own catalog, rules, price authority and acceptance tests.
Keep viewer scope honest
A useful viewer owns more than loading a model. It needs deliberate camera behavior, loading and error states, an approved starting view, useful controls, fallback content and a defined relationship to the rest of the product page. The official <model-viewer> camera examples show that pan, zoom, orbit target and recentering behavior all need decisions.[1]
Accessibility also belongs in viewer acceptance. Shopify's product-media guidance recommends inactive-by-default 3D content, keyboard panning, labeled controls, visible focus, text descriptions, live status and assistive-technology testing; it also calls for viewer controls and a progress bar.[7] Those recommendations do not prove a particular implementation is accessible. They define checks the team still has to run.
Do not define a viewer by what it cannot do. A viewer may expose hotspots, animation, material variants or AR. Keep it in the viewer category while those interactions help inspect an existing product state and do not create a commercial or rule-resolved product selection.
Keep customizer scope tied to a sellable state
A product customizer is most useful when buyers recognize the choices and the business can say what each completed selection means. The result might be a catalog variant, a base SKU plus bounded personalization fields, or a line-item payload with an approved rendering state.
Shopify's option and variant model illustrates the catalog route: option values create distinct variants, and each variant can carry its selected options, price, availability and SKU.[3][4] A customizer can present that data more visually, but it should not invent a combination the commerce source cannot sell.
The boundary moves when availability logic becomes a product model. Hiding a nonexistent blue-small SKU is still compatible with a bounded catalog customizer. Resolving component dependencies, calculated dimensions or conditional requirements is configurator work, even if the interface still looks like a row of swatches.
Treat a configurator as a system of decisions and outputs
A configurator has at least four separable responsibilities: capture user requirements, resolve valid options, present the resulting state and emit accepted outputs. Pricing, quoting, ordering and approvals may join that system, but they are not mandatory in every consumer configurator.
This is why a rule inventory comes before interface polish. Salesforce's documented rule types can warn, block, filter or change a bundle.[5] The UI needs to explain those consequences, but the rule source and its owner matter more than the visual treatment of an error message.
Keep CPQ as a named integration or broader operating layer when it owns pricing, quote generation, approvals or opportunity data. Oracle's documented opportunity-to-order coverage is one vendor example, not evidence that every product configurator includes that whole process.[6]
Define the output contract before estimating scope
Write one row for every output and assign its authority, required fields, consumer and failure behavior.
The table below maps configuration outputs to their authorities and acceptance questions.
| Output | Authority to confirm | Minimum acceptance question |
|---|---|---|
| Visual state | Approved product data and 3D asset mapping | Does every allowed selection show the intended geometry and material state? |
| Sellable selection | Commerce catalog or product master | Does the result resolve to a valid variant, SKU or approved personalization payload? |
| Price | Named pricing service, catalog or commercial owner | Is the displayed amount calculated from the right context and reproduced downstream? |
| Saved configuration | Configurator data model and identity policy | Can the exact revision be reopened with clear ownership and expiry behavior? |
| Cart or order line | Commerce integration contract | Are all fulfillment-critical selections present and unambiguous? |
| Quote or review request | CPQ, CRM or assisted-sales workflow | Does the receiving team get the product state, evidence and customer context it needs? |
| Production handoff | ERP, PLM or manufacturing owner | Is the output a governed specification rather than a screenshot or display-only state? |
Scope grows with rule interactions, product-data cleanup, price and inventory integration, visual-state coverage, save/share behavior, account permissions, quote or approval flow, downstream mappings and regression testing. Those are discovery variables, not universal budget multipliers. A responsible estimate counts the actual product families, rules, outputs and integrations before attaching a figure.
Use the estimator after the matrix, with the current product family and required outputs in hand. Its result is a scoping input, not a substitute for product and integration discovery.
Separate reusable architecture from project discovery
Reusable guidance can separate the product model, rule evaluation, presentation layer, commerce adapter and output schemas. It can also define versioning, validation and test seams. Those are architecture patterns.
Project discovery supplies the content those patterns cannot guess: exact option data, exceptions, source systems, pricing authority, role permissions, migration quality, output consumers and acceptance thresholds. A case study can show relevant delivery capability, but it cannot prove that a new rescue or migration will work, how long it will take or what it will cost. Keep those claims out until the specific system has been inspected.
Once the category is settled, use the interactive product configurator UX patterns to plan progressive disclosure, defaults, recovery, price presentation, save/share and mobile behavior. UX cannot repair a missing rule or output contract, but it can make a sound one understandable.
Choose the smallest system that owns the required result
Use a viewer when the approved product state only needs to be seen and understood. Use a customizer when buyers choose among bounded options that resolve cleanly to a sellable state. Use a configurator when the experience must evaluate dependencies or derive a valid specification. Add CPQ and operational integrations only when pricing, quote, approval, order or production responsibilities require them.
That sequence protects both sides of the decision. It avoids building a rule platform for a camera-control problem, and it avoids calling a rule-dependent product a customizer because the first mockup contains attractive swatches.
If the matrix already points to a bespoke, rule-driven build, the custom 3D product configurator service is the direct commercial route. Bring the option model, known rules, price authority, purchase endpoint and required outputs. Those five inputs are more useful than a preferred label.
