How to Brief a 3D Product Configurator: The Buyer’s Checklist

A 3D product configurator brief should define ten things before a supplier estimates the work: the customer decision, commercial action, product rules, catalogue scope, asset pipeline, buying journey, integrations, performance, measurement and acceptance.

Without that detail, three suppliers can respond to the same request with three different products. Their prices may look comparable while covering different rules, assets, integrations and handover work.

Use this buyer checklist to turn product configurator requirements into a brief that exposes unknowns early, supports comparable proposals and helps the team decide whether the project should proceed at all.

What should a 3D product configurator brief include?

1. Customer decision: the difficult choice the experience must make clearer.
2. Commercial action: basket, quote, consultation, saved design or specification.
3. Product scope: products, options, dependencies, prices and availability.
4. Source assets: CAD, photography, materials, dimensions and ownership.
5. Buying journey: entry point, configuration steps, errors and completion.
6. Integrations: ecommerce, product data, inventory, pricing, CRM and analytics.
7. Performance: devices, networks, payload limits, loading states and fallback.
8. Accessibility: keyboard controls, labels, focus, zoom and a non-3D route.
9. Measurement: baseline, consent state, events, primary outcome and review period.
10. Acceptance and ownership: test evidence, handover and the team maintaining the system.

If several answers are unknown, mark them as discovery work rather than hiding them inside a fixed build estimate.

Start with the commercial job

Do not begin with software features. Begin with the customer decision the configurator must improve.

Write one primary job in a single sentence:

The configurator helps [customer] choose [product] by making [difficult decision] clearer, then moves them to [commercial action].

For example: “The configurator helps trade buyers specify a modular storage system by showing compatible dimensions and finishes, then sends the confirmed configuration into a quote request.”

That sentence is more useful than a list containing zoom, rotation and colour changes. It defines who the experience is for, what uncertainty it removes and where value is created.

Choose one primary commercial action:

• add the configured product to basket;
• request a quote with the configuration attached;
• book a consultation;
• save or share the design;
• generate a specification for a sales team.

Secondary actions are fine, but they should not compete with the main one.

Define the product rules before the interface

A configurator is a rules engine with a visual layer. Your brief should describe the decisions and dependencies behind the product.

Use real examples. “Finish affects price” is vague. “Brushed brass adds £X to sizes A and B but is unavailable for size C” is testable.

If the rules only exist in one employee’s head, treat documenting them as a project phase. Do not hide that work inside a development estimate.

Inventory the 3D asset pipeline

List the assets you already have, their formats, who owns them and whether they are suitable for real-time use.

Manufacturing CAD is rarely ready to place directly in a browser. Real-time assets usually need simplified geometry, efficient textures, consistent materials, sensible variants and quality checks across devices. The Khronos Group describes glTF as a royalty-free format designed for efficient transmission and loading of 3D scenes and models. That makes .glb or .gltf a useful delivery target to discuss, but the format alone does not guarantee a fast or accurate experience.

For each product family, include:

• source files and current formats;
• number of base models;
• number of option combinations;
• material and colour references;
• dimensional or engineering data;
• approved product photography for comparison;
• people responsible for visual sign-off;
• the expected process for adding a new product later.

Ask suppliers to separate one-off asset preparation from the repeatable cost of adding another product. A system that launches beautifully but requires a developer for every new finish is not scalable.

Set a performance budget

“Fast” is not an acceptance test. Put measurable constraints in the brief.

Google’s Core Web Vitals “good” thresholds are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, assessed at the 75th percentile. A configurator may not be the page’s largest element, but it must be designed within the page’s total budget.

Specify:

• target mobile devices and browsers;
• typical connection conditions;
• maximum initial 3D payload;
• whether the model loads immediately or on demand;
• what appears while assets load;
• the fallback when WebGL or device capability is insufficient;
• agreed Core Web Vitals targets for the complete product page.

The detailed guide to treating a 3D configurator as a performance budget explains why asset weight and interaction cost need to be agreed before visual polish.

Describe the buying journey, not just the viewer

The 3D scene is only one part of the experience. Your brief should show the route from arrival to commercial action.

At minimum, define:

1. how a customer discovers the configurable product;
2. the default state they see;
3. how options are grouped and explained;
4. how invalid combinations are prevented;
5. how price, availability or lead time updates;
6. how the final configuration reaches checkout or sales;
7. how the customer can return to or share it.

Include accessibility from the beginning. WCAG 2.2 says web content should be perceivable, operable, understandable and robust, with testable criteria including keyboard focus, labels and target size. The W3C WCAG 2.2 standard applies to the complete interaction, not only the HTML around the canvas.

The brief should require a non-3D route to the same core product choices wherever practical. Someone who cannot use the visual scene should not be blocked from buying.

Specify integrations and ownership

Name every system that sends or receives data:

• ecommerce platform;
• product information management system;
• inventory or ERP;
• pricing service;
• CRM or quote workflow;
• content management system;
• analytics and consent platform.

For each integration, document the source of truth, authentication method, test environment, owner and failure behaviour. What should the customer see if live pricing is unavailable? Can a quote still be captured? Who is alerted?

Also ask who owns the source code, 3D assets, deployment pipeline and analytics data. Record the handover materials you expect: repository access, build instructions, asset guidelines, rule documentation and staff training.

Plan measurement before build

Page views will not tell you whether the configurator works.

Define the decisions you want to measure, then map them to events. For ecommerce, Google recommends events such as view_item, add_to_cart, begin_checkout and purchase, with item data so product behaviour can be analysed. Use the official GA4 ecommerce measurement guidance as the base, then add carefully named events for meaningful configurator actions.

A useful measurement plan might include:

• configurator started;
• first option changed;
• invalid combination encountered;
• configuration completed;
• design saved or shared;
• quote requested;
• configured item added to basket;
• purchase completed;
• error or fallback shown.

Agree what success looks like before launch. That might be a higher product-page conversion rate, more qualified quotes, fewer pre-sale questions or better attachment rates. Do not promise an uplift without a baseline and a controlled comparison.

Turn requirements into acceptance tests

The final section of the brief should say how the work will be accepted.

Ask suppliers to identify assumptions and exclusions beside these tests. That makes a cheaper quote easier to interrogate: is it more efficient, or has it simply excluded asset work, integrations and support?

Copy-and-paste product configurator brief

Use this outline in your request for proposal:

1. Business objective: the decision and commercial action to improve.
2. Audience: customer types, devices, markets and accessibility needs.
3. Product scope: models, options, rules, prices and availability.
4. Asset inventory: source files, quality references and ongoing pipeline.
5. Journey: entry point, configuration steps, errors and final action.
6. Integrations: systems, data owners, environments and failure states.
7. Performance: devices, payload and Core Web Vitals budgets.
8. Measurement: baseline, consent state, events, primary outcome and review period.
9. Acceptance: functional, visual, accessibility and handover tests.
10. Delivery constraints: budget range, target date, stakeholders and approval process.

If several sections are unknown, commission a bounded discovery phase to resolve them before asking suppliers to price the full build.

Questions teams ask before sending the brief

Do we need final CAD files before asking for a proposal?

No. List the source files that exist, their owners and known quality issues. Ask the supplier to separate asset discovery, conversion and production from the software estimate so the missing work remains visible.

How detailed should the product rules be?

Detailed enough for another person to decide whether a combination is valid, how its price is calculated and what record reaches the basket or quote. Use representative examples and identify rules that still need discovery.

Who should approve the requirements?

Include the commercial owner, the person responsible for product rules and data, the visual or asset approver, the ecommerce or integration owner and the people responsible for accessibility, performance and analytics acceptance.

A good brief protects the outcome

The brief should not prescribe every technical decision. It should make the commercial job, constraints, unknowns and definition of done visible.

That gives capable suppliers room to propose a better solution while keeping their proposals comparable. It also gives your team a way to stop a polished demonstration becoming a slow, inaccessible system that sales and product teams cannot maintain.

If you are still testing whether the foundations exist, use the free 3D product configurator readiness scorecard. If the product, rules and buying journey are defined, review the product configurator service or send the brief for an initial risk review.