3D Product Configurator: 8 Decisions Before You Build

A 3D product configurator lets clients choose options and see a visual representation of the product they are building. It can connect finishes, sizes, parts, and accessories with valid sets and a quote or order. The key challenge is keeping the displayed product, allowed choices, price, and supply record consistent.

This guide explains eight choices to make before commissioning product configurator software. It covers product rules, model assets, performance, pricing, accessibility, order handoffs, and upkeep. It also includes a pilot plan that tests a full set of choices through the sales flow.

A viewer and a configurator solve other problems

A 3D viewer lets a person inspect a model. A configurator also changes the chosen product options and applies rules to those choices. The viewer is one part of the flow, not the complete business system.

For instance, a client might rotate a desk model, choose a finish, change its width, and add a cable tray. The app must know which tray fits which width and which chosen parts the business can supply.

The model-viewer project provides a web component for displaying interactive 3D models. Its features illustrate the display layer. Meanwhile, your option rules, pricing, and order logic need their own design.

1. Start with the product choice the client faces

Define why a client needs the configurator. They may need to grasp appearance, check fit, check options, or obtain a correct quote. Those needs lead to other interfaces and levels of visual detail.

A furniture buyer may value finish and proportion. An industrial buyer may care more about matching parts and ongoing specs. Therefore, do not let a visually impressive demo decide the product scope.

Map the current sales flow first. List the questions clients ask and the fixes sales staff make. A configurator earns its place when it helps answer those questions or prevents avoidable option errors.

Next, choose one product range for the first release. A narrow pilot can prove the rule and order flow before the business invests in models for each product. Keep later ranges in the plan without pretending they already fit the same logic.

2. Define valid sets before building controls

Product rules determine which choices can coexist. A size may limit available parts. A finish may apply only to certain materials. Write those relationships in a form that the product team can check.

For the desk example, a wide top might need a different frame. Choosing the new width should either update the frame transparently or ask the client to choose a valid one. It should not leave an impossible set in the quote.

Also set the treatment of conflicting choices. Disabling an option, explaining a constraint, and replacing a prior choice create other flows. The client should see why the change occurred and what remains chosen.

Keep the final checks on the server. A browser screen can guide choices. But the backend must check the sent set of choices before pricing or accepting an order. Client-side controls alone do not establish a valid product.

3. Create model assets with business ownership

3D assets need to show the product correctly enough for the planned use. Define sizes, part boundaries, material names, and the level of detail. A production CAD file may need conversion or simplification for a browser flow.

Shopify’s product media documentation shows how 3D models can form part of an ecommerce product presentation. A store’s media support does not by itself provide option rules or a data link to factory records.

Ask who approves each model and how that sign-off links to the product version. For instance, a revised chair arm should not leave an older visual asset attached to the current orderable item. Keep asset identity separate from a filename that someone can overwrite.

Next, check finishes under the actual display conditions. Screens, lighting, and materials can affect appearance. Explain useful limits to clients and avoid presenting the shown color as a guaranteed physical match.

4. Keep the flow usable on ordinary devices

A configurator may work smoothly on a designer’s desktop and struggle on a client’s phone. Test sample devices and network conditions. Large assets, complex scenes, and extra effects can delay the first useful interaction.

Use a clear loading state and a useful fallback. The client should still be able to read specs and chosen options if the model cannot load. A blank canvas should not block the whole purchasing task.

The model-viewer loading examples show poster and loading approaches. Use those ideas when checking the waiting flow, then measure your own model and screen rather than assuming the demo’s performance transfers.

Also test repeat option changes. The app should avoid flicker, stale materials, and a price that belongs to an earlier set of choices. Show a pending state when the system still needs to check a result.

5. Make pricing and stock status in step

Decide which system owns prices, discounts, and stock status. A configurator can display a price rough figure, request a quote, or work out an orderable total. Those modes should have clear labels and other controls where suitable.

For instance, choosing a premium finish may affect price and lead time. The client should see both changes before sending. If stock status changes during the session, the backend needs to recheck the set of choices before accepting the order.

Our guide to CPQ software explains related configuration, pricing, and quoting workflows. A 3D screen can support that workflows without becoming the only place where their rules live.

Next, test a price update and a discontinued part. Record which version the client viewed and what the final entry used. If the amount changes, ask the customer to confirm it rather than silently substituting a new price.

6. Offer controls beyond the 3D canvas

Clients should be able to choose options through clear labels and standard controls. Avoid requiring a precise click on a small part of a rotating model. A parallel option list helps users grasp the current choices.

Test keyboard navigation, zoom, readable labels, and error messages. Also provide a text summary of chosen options. A visual change from one similar finish to a new may not be obvious to each user.

Oxen’s guide to accessibility testing offers useful checks for the full screen. Include the quote form and check screen, not only the model controls.

Next, test touch interaction. Rotating the model should not make page scrolling unusable. Give users a clear way to reset the view and return to the purchasing controls after inspecting the product.

7. Pass a structured set of choices into the order

A screenshot can help sales grasp appearance. But it should not be the only supply record. Send stable product and option IDs, quantities, rule versions, and the useful quote details to the receiving system.

For the desk, the order should name the chosen top, frame, finish, and accessory. The receiving team should not have to infer those choices from the shown picture. A clear summary helps both the client and daily work check the same product.

Oxen’s API documentation guide explains how to define that system handoff. Include how the backend rejects an invalid or outdated set of choices and what the client should do next.

Also test retries. A lost response after order creation should not produce a second order when the client clicks again. Use stable operation references and a clear route to check if the first entry done.

8. Plan changes and support before launch

Products evolve after the first release. New finishes, sizes, and part rules can need changes to both business data and visual assets. Set the owner and check flow for each type of update.

Test a change that affects saved choices. A client may return to an old link after a part is no longer in stock. The system should explain the issue and offer an approved next step rather than displaying an orderable-looking product it cannot supply.

Keep old quote records understandable. Store enough context to reconstruct what the client chose at the time, even if the current product list has changed. But do not assume each saved set of choices remains eligible for its first price.

Next, define support diagnostics. Staff may need the product range, chosen option IDs, asset version, and failure code. Avoid collecting extra personal details simply to investigate a display issue.

A worked set of choices flow

Imagine a maker selling configurable desks. This is an illustrative workflow, not a reported client project. The client begins with a standard top and frame, then chooses a width and finish from the valid options.

When the client selects a wider top, the app checks matching frames. It explains any needed change before applying it. Next, the client adds a cable tray. The backend checks its fit against the chosen top.

The screen updates the visual and requests the current price. If the pricing service fails, it retains the chosen options and clearly marks the price as unavailable. It does not keep showing an old amount as if the latest set of choices had a checked total.

Finally, the client checks a text summary and sends a quote request. The backend checks the complete set of choices and sends stable references to the sales system. Sales can then check the same choices without recreating them from an image.

What to include in a supplier brief

Describe the product range, user choice, visual needs, and final sales outcome. Include a rule list and examples of both valid and invalid sets. Ask suppliers to name assumptions about asset preparation and data quality.

• Product and part IDs with approved sizes.
• Option dependencies and conflicting sets.
• Price, stock status, and quote ownership.
• Needed device and network conditions.
• Accessible controls and a fallback flow.
• Order payload, retry handling, and saved-link behavior.
• Product list upkeep, asset updates, and handover needs.

Also specify who provides the models and who pays for later revisions. Asset preparation can be a substantial part of the project. A low development quote may assume that the business already owns web-ready, approved assets.

Run a pilot through supply

Build one product range with a limited set of useful options. Include a set that needs a dependent change and one that the system must reject. Test both desktop and mobile use with real users.

Next, send a quote and inspect the receiving record. Sales or operations staff should check that the structured options match the screen. Then test a stale saved link, an unavailable part, and a failed pricing response.

Measure task completion, option errors, loading behavior, and manual fixes needed by sales. If you assess conversion, set the experiment and review carefully. A visual configurator does not guarantee higher sales or fewer returns.

Expand when the rules, assets, and handoffs work as one flow. Extra models should follow a tested product-data and upkeep approach, rather than becoming separate one-off flows.

Build the product flow behind the visual

A useful 3D product configurator keeps appearance, valid options, pricing, and supply aligned. Start with one product range, test ordinary devices and failure paths, and prove the complete quote or order flow before expanding the product list.