Augmented Product Configuration

I like watching videos about digital product configurators. Having worked on a lot of them for different industries (from automotive to construction to coffee machines), I still enjoy seeing how different people and teams have solved “the usual set of UX, UI and technical challenges”.

Here is a one that recently popped up in my LinkedIn timeline:

Augmented Reality car customiser using Unity & ARKit/ ARCore by Parth Anand

First of all: This is excellent work by Parth Anand, congratulations to him and the team. That said, it gets tricky when companies get inspired and want to have similar solutions without actually understanding the efforts involved.

So I thought I write an article to help businesses and organizations understand the terminology and challenges of digital product configurators.

Note: This article is really about digital transformation. To me digital transformation is not about innovation in itself, but rather about creating a digital infrastructure to be able to be innovative in the first place. So a lot of things I will talk about are venturing into internal processes and data warehousing / handling.

Visualizers vs. Configurators

A digital configurator usually shows the product with all currently selected options as well as all potential options that can be configured for said product. Each option is enriched with additional information (price, availability) and media (images, video). The overall product is visualized in real time, usually in 3D. All this is packaged in an engaging experience to hide the complexities as much as possible.

And there is a lot of complexity as the biggest challenge around digital product configurators is the data, not the visualization. Let’s dissect a car configurator to see what I mean.

Audi car configurator, audi.co.uk

The first aspect of a product configurator is to make sure that the user is presented with a complete model. In terms of a car that would mean it’s actually a complete car and there is some form of default configuration for every relevant configuration class: It has a trim, an engine, an exterior color, wheels, an interior and so on. So if bought, the car would be usable.

The second aspect is to make sure that the product can be built. The first step is to identify which options are actually available for the given model. So which trims, colors, wheels and other exterior / interior options are available? The second step is to make sure the selected options go together. Are certain wheels only available with specific exterior colors? Does the selected trim allow the current wheels to be selected? Almost every product I worked with had rules around how it could be configured and with every selection the system would check for the overall “buildability” of the product.

The third aspect of a product configurator is to make sure that all information is correct. Does the product option actually look exactly like that? Are the color and material properties correctly shown? Are there other media assets available for the relevant options like descriptions, images or videos? And maybe most importantly: Is the price correct and does it factor in other aspects like local offers?

Those three aspects are vital if the manufacturer wants to make sure a product can ordered exactly as configured. So in any kind of shop / sales context those aspects are key. Other times however completeness, buildability and correctness can be ignored, for example if only a small subset of options are presented that are available in all configurations or if they simply do not matter. Typical examples for this are marketing campaigns or trade show exhibitions. These types of experiences are usually called visualizers, where the product visualization is more important than configuration correctness.

If a digital visualizer is what you want, great. You can pretty much ignore the rest of this article. However if you actually want a configurator, here are a number of steps that will get you there.

Product Completeness

Product completeness is about making sure that the user can’t configure a product that wouldn’t work, for example a car without an engine or a coffee maker without the ability to draw water. To do that the system needs a concept of what components make a complete product and what options exist for each component.

So step one is to identify every product, including every available option, and add that to some form of product data management system. Ideally every product and option should have a unified and unique ID by which it can be identified throughout the entire system.

This can be tricky as different business units are responsible for different aspects of the product life cycle. For example product design, production, sales and service might have different systems to handle their business already, each with their own view on a specific product and its options.

Step two is to unify the view of all business units on products and options, binding their systems to the data management system. Ideally they use the central system directly, however realistically they might use some form of “bridge” that would connect their data view to the central system.

Step three: Every item in the system needs to be tagged by object type and category to distinguish between the purpose of the item. The data model needs to at least be able to hold product categories, individual products, groups of components, individual components, groups of options and individual ones. In other words: It needs to hold the different classes of coffee makers, the individual coffee makers, all components for them, all categories as well as all individual options.

This is especially relevant if the configuration process has to follow a specific order: Category A, then B, then C or D as this ventures into product buildability.

Product Buildability

Almost every product is based on rules, that describe some form of dependency. These might look like: “To be able to select option X, you need option Y and / or Z”. Simple examples might be “To select seat heating for this car, you need to have leather seats” or “To select the milk frothing option for this coffee maker, you have to select an option from the category milk supply.

A model is required that describes all dependencies within the system. Ideally this model is based on the defined components and categories and would understand different types of objects, for example “This is a model with a number of default options”, “This is an individual option”, “This is a group of options for a specific model” and so on. This also defines different views that business units might have on individual items and how they relate to each other.

So step four is to establish dependency systems for each individual item in the product data management system.

Depending on how deep you go with your system, this might become really complex. Companies can model their entire business within these systems, including every nut and bolt used to create components, their supply chain, up to assembly, fulfillment, marketing, service and support. At this point it becomes clear why this is about digital transformation:

This is your ERP system.

Every digitally transformed business and organization should already have (or at least work on) this. It’s digital 101 to have the data in order. Where most organizations struggle is the rigidity and endurance to roll out their ERP model into every aspect of their business.

The ERP system should be used as products are designed. Parts and components should be added and defined by different business units: How does construction / manufacturing think about this product / option / item? What dependencies do they have? What meta data do they need to work with the item? Again, they can still use their own systems and platforms in their workflow, however there should be a clear link to the ERP that binds all data sources together.

Product Correctness

This holistic view is important because of product correctness. Let’s look at the real time visualization part of digital configurators. They require an accurate and usable 3D model of every (visible) available option.

Accurate means that it matches the shape and dimensions of the real object as well as the material and physical properties. Like real components, virtual ones are created to spec and with low tolerances. Actually, the real components are most likely based on their digital counterparts as the design process is most likely based on CAD data. But it’s not only about the physical size and shape, but also about material properties: How reflective and shiny is the material? Is it coated or painted? Is it translucent or in any way transparent? Is the part made out of metal, plastic or cloth? To be able to accurately visualize the item, all of this is required. Depending on your design process, this could venture even deeper into material properties to be able to run computer simulations on individual items, for example for crash tests or other safety studies.

Usable means that the 3D data is such that it can be used for the desired endpoint. Models used in the design and manufacturing process are usually based on mathematical geometry. They also contain a lot of meta data used in the manufacturing process, making the files huge in size (think terabytes). CAD data used in design and production also require a lot of computing power and dedicated workstations to process. Models used in marketing, specifically product renderings in TVCs and images, might use the pure 3D geometry, optimize it for visual quality and strip a lot of the meta data. Models used in a sales context are usually based on polygon geometry with even less meta data, making the assets way smaller (think a couple hundred megabytes to low gigabytes) and thus easier to load and handle on normal hardware (like tablets and mobile phones). Each endpoint will have different requirements for models and meta data.

So to be able to utilize your 3D product data end-to-end from engineering and design to interactive marketing and sales to training, operations and support, you need to understand the respective needs of the business units and then build a 3D asset management system and pipeline around it. There also needs to be a group within your organization that owns and verifies the visual correctness of the data.

This is also true for all other types of data, not just 3D: All assets for a given product group, individual product or specific option should be available throughout your organization, bound to the respective ID in the ERP system. That also goes for localized information like marketing information, pricing and default product configurations.

At any given time you should be able to able to ask you system: “Give me the default configuration of this product in this market with all available options that I could add right now” and get not only the list, but also all associated assets like documents, images, movies and 3D data. To be fair, this might be a separate data layer / API, sitting on top of your internal infrastructure, aggregating data.

Summary

And with that you should be able to set up a product configurator. To summarize:

  • Identify every product, including every available option, and add that to some form of product data management system.
  • Unify the view of all business units on products and options, binding their systems to the data management system.
  • Every item in the system needs to be tagged by object type and category to distinguish between the purpose of the item.
  • Establish dependency systems for each individual item in the product data management system.
  • There needs to be a 3D asset management system and pipeline in place to utilize your 3D product data end-to-end throughout your organization.
  • All information and assets for a given item should be available throughout your organization, bound to the respective ID in the product data management system.
  • Then start the actual work on the configurator.

All the above is a lot of work and involves a lot of different business units within an organization. Here is the good news: If done well, you need to do all the above only once and every digital endpoint can utilize this system — internally and externally. Marketing will love getting access to complete and accurate product information right out of design. Service and support departments will also greatly benefit from having a centralized system to access things like user and service manuals, FAQs and training materials. It will support market and localization teams, allowing easy translation and easy sharing of asset and insights between markets. If done well the system will even allow you to go beyond your products into topics like digital service records, digital twins, predictive maintenance and so on.

The bottom line is:

A good product configurator starts with a good digital understanding what your products are and can be, ideally throughout your entire organization.

That also means: It’s not something that just one department can pull off. As said, biggest challenge around digital product configurators is the data, not the visualization. Real product configurators require your organization to be digitally transformed and indeed I have seen some companies start with a digital product configurator project that resulted in a complete overhaul of internal processes and data management. It became their need for digital transformation. And once they got there from a data point of view, they were able to do so much more.

Additional pointers & best practices:

Living in Berlin / Germany, working at Microsoft, loving technology, society, good food, well designed games and this world in general. Views are mine, k?