A product configurator can clarify a complex purchase, but an interactive 3D view cannot repair unclear product rules, missing data or an undefined buying process.
Use this free scorecard to check eight foundations before choosing a platform or commissioning a full build. It takes about five minutes. Your answers stay in your browser and are not submitted or stored.
Check whether your product is ready for a 3D configurator
Score eight delivery areas. The result highlights the foundations to resolve before a pilot, not a promised commercial outcome.
Private by design: your answers stay in this browser and are not submitted or stored.
0/24
Complete all eight areas
Your result will appear here as you answer each area.
Resolve these foundations first
How the score is interpreted
- 0–7 — Discovery first: define the customer problem and delivery constraints before choosing technology.
- 8–14 — Foundations needed: the opportunity may be useful, but rules, assets, integration or ownership still need work.
- 15–19 — Pilot-ready: a bounded product range can be tested with explicit success and stop criteria.
- 20–24 — Scale planning: the core foundations appear strong enough for deeper technical and commercial due diligence.
A zero in customer evidence, product rules, commerce integration, accessibility or operational ownership overrides the total and returns a foundations-first result. This prevents a polished 3D demo from masking a critical delivery gap.
What the score covers
The scorecard reviews eight areas that repeatedly affect whether a configurator can move beyond a demonstration:
- Customer decision problem: evidence that buyers struggle with a choice the configurator could make clearer.
- Product rules and data: valid options, dependencies, prices and identifiers that can be expressed consistently.
- 3D asset pipeline: suitable models, materials, optimisation rules and repeatable ownership.
- Commerce integration: a dependable hand-off to price, basket, quote, order and fulfilment.
- Performance and device fit: explicit device, network and loading requirements rather than a desktop-only demonstration.
- Accessibility and fallback: semantic controls and an equivalent route that does not rely on the 3D view alone.
- Measurement and evaluation: a baseline and business outcome that can support a continue, change or stop decision.
- Operational ownership: named people and budget for data, assets, engineering, content, QA and support after launch.
Each area scores from 0 to 3. The maximum total is 24. The areas are deliberately weighted equally because a severe weakness in any one of them can make an otherwise impressive build unreliable.
Why critical gaps override the total
A total score can conceal a serious dependency. For that reason, a zero in customer evidence, product rules, commerce integration, accessibility or operational ownership returns a Foundations first result regardless of the total.
This is a planning safeguard. A product with excellent 3D assets is not pilot-ready when valid combinations are still known only by one salesperson. A fast renderer is not production-ready when a customer cannot complete the same task using keyboard controls or an equivalent non-3D route.
The current WCAG 2.2 Recommendation covers requirements including keyboard access, focus, target size, labels and status messages. These requirements apply to the complete buying task, not only the surrounding page.
How to interpret the result
0–7: Discovery first
Do not start by selecting a 3D engine. Define the customer problem, pilot product range, valid option rules, commerce outcome and owner first.
A useful discovery output should include:
- the buying decision that needs to become easier;
- evidence for the current problem;
- a representative product and option set;
- the next commercial action after configuration;
- the technical and operational owners;
- the decision that will be made after a pilot.
8–14: Foundations needed
The opportunity may be sensible, but one or more delivery areas need structured work. Resolve the weakest dependencies before committing to a production budget.
A short technical spike may be appropriate when the uncertainty concerns model quality, material rendering, browser support or integration feasibility. It should answer a named risk rather than produce an open-ended visual prototype.
15–19: Pilot-ready
A bounded pilot is reasonable when it uses a representative product range and has explicit success and stop criteria.
Define the pilot before building it:
- included products, options and exclusions;
- target devices and networks;
- asset and loading budgets;
- accessible controls and non-3D fallback;
- data contract with the commerce platform;
- baseline, events, guardrails and review date;
- who fixes product-data and asset problems during the pilot.
Core Web Vitals can support loading, responsiveness and stability checks, but a configurator also needs task measures such as load success, option latency, invalid-selection handling and completion.
For the implementation detail behind those constraints, use the 3D product configurator performance-budget guide before asset production and interface polish begin.
20–24: Scale planning
A high score means the foundations appear strong enough for deeper due diligence. It does not guarantee conversion, revenue or delivery success.
Before scaling, test the difficult product cases, slow devices, interrupted requests, invalid combinations, asset updates and alternative buying route. Document ownership and recovery rather than assuming the initial implementation will remain correct.
Where an open exchange format fits the asset pipeline, Khronos describes glTF as a runtime 3D asset delivery format. Format choice alone does not solve material consistency, optimisation, product rules or asset governance.
What this scorecard does not do
This is an original practitioner planning framework, not an industry benchmark, certification or substitute for technical discovery. It has not been validated against a published cohort of configurator projects.
The result does not estimate:
- build cost or delivery time;
- conversion or revenue improvement;
- the number of products that should be included;
- whether Three.js, PlayCanvas or another platform is the right choice;
- accessibility conformance;
- whether your source product data is contractually or technically usable.
Those decisions require evidence from the actual products, users, commerce stack and operating team.
Reuse the methodology
The project-created scorecard methodology, including its eight areas, four score levels, score bands and critical-gap rule, is licensed under Creative Commons Attribution 4.0 International.
Suggested attribution: 3D Product Configurator Readiness Scorecard and Checklist by Niall Arnfield, licensed under CC BY 4.0. Source: https://niallarnfield.com/product-configurator-readiness-scorecard/ If you adapt the method, state that changes were made. The licence does not cover the Niall Arnfield brand, website theme, client or partner material, case studies, private evidence, linked research or third-party items.
Turn the result into a useful brief
Start with the lowest-scoring area, not the most exciting visual feature. Record the missing decision, evidence needed, owner and review date.
If you want an independent view, send me your score, product URL and the choice customers struggle with. I will tell you which dependency I would test first and whether a configurator looks like the right intervention.
You can also read the product configurator service guide or use the 3D product configurator briefing checklist to prepare a more detailed project brief.