eCommerce Product Builders & Configurable Products – Considerations, UX Best Practices & Examples

Over the last few months, we’ve been working with a number of eCommerce clients on creating, simplifying and optimising product builders and product configuration processes – with this being a key part of their business and an opportunity to drive improvement in conversion rates and AOV, most notably. These types of products can also be very engaging and generally a really nice user experience vs purchasing items separately.

Product customisation, building or personalisation and generally more advanced configuration has become a big trend over the last few years – and getting the design and UX right is critically important, as it’s not simple and often requires a number of steps and aspects.

In this article, I’m going to provide recommendations on approaching the UX side (including on mobile, which is critically important), talk about different routes (e.g. custom vs standard product types vs third party solutions) and then also look at really good examples, in each of these areas.

Firstly, what is a product builder?

So, I would say a product builder is essentially an advanced configurable product (although not always structured that way from a back-end perspective) with a number is customisable aspects or components. These are notoriously hard to position online, as there are generally lots of options, several steps, variable compatibility and then often additional complexity around pricing and availability. 

Examples of product builders could include a personalised product (e.g. trainers on NIKE ID), a fully built / modular item (e.g. a car or a sofa) or even just configurable product sets or bundles.

How should a highly configurable product or customised product be structured?

Over the last year or two, it’s become very common to go beyond native product configuration and extend what the templating language of the core platform can do. By using a technology like Vue or React, data manipulation can be more dynamic, meaning you’re not limited by the catalog capabilities of your eCommerce platform (particularly useful if you’re working with a platform like Shopify). Two examples of that approach include:

The alternative approach would be to use bundling, a configurable product (in a platform like Magento) or variants (in a platform like Shopify), but you’re likely to be far more restricted from a technical perspective and, in the case of configurable products in Magento, you’ll be fighting against performance.

There are also then third parties (e.g. Smart Pixel, ThreeKit or Cylindo) that would handle the front-end side and require either individual products be created in the back-end or products are combined dynamically. I’ll talk more about these later on.

How should the front-end UX be approached?

From my perspective, I think multi-dimensional builders should be split out into steps, with a very clear journey and clear endpoint to the user. I think this makes things far clearer for the user and also helps to break up the process and keep things optimized for mobile etc.

This example from Interior Define is a great example of a multi-stepped approach that remains straightforward throughout. 

In this example, there are five very clear steps (as well as tooltips to help explain the steps) and then a clear add to cart that is activated once each option has been selected. This example is also well-optimised for mobile devices, which is a common weakness of builders in a lot of cases.

Splitting the configuration into steps also helps to handle compatibility, allowing for incompatible items to not be displayed within the next step. 

Pricing should be clearly updated as the item is configured and I prefer that, on mobile, the price is always visible – most likely within a sticky navigation bar at the top or bottom of the page, along with a CTA (likely greyed out until configuration is complete).

An alternative approach is to ensure that all options visible, if not sequential. The Nike example simply shows all options and allows the user to click the configurable aspect on the 3d image.

How should the back-end side of these configurable builders work?

The biggest complexity with these types of products, depending on your business and other systems, is often the product setup, as most merchants will want to stock manage items and ensure that orders are fully formed.

There are a number of ways to approach this side of things, which some of the common ones including:

  • Native product types – although often limiting, a lot of platforms will have native offerings for bundled and configurable products (such as Magento or Salesforce Commerce Cloud), which will allow for this core functionality out of the box. We’ve used both in the past with clients and this is typically a really good starting point for examples that aren’t hugely complex. There are also lower overheads and management benefits from sticking to native functionality – this would simply combine existing items and allow for configuration of the simple products.
  • Front-end manipulation – another route is to essentially show options on the front-end, but actually have logic that just adds different items to cart. The Outdoor Voices kit builder is a good example of this, with a script simply adding two separate items to cart here. Often this would be combined with discount scripts that would reduce pricing at a line-item level.
  • Back-end manipulation – another route is that you create logic on the back-end side that essentially splits out product, as would happen with a BOM (bill of materials) SKU. Sunspel is a good example of this, with these bundles having logic in place to simply split a simple product into three units when the order is passed down into the ERP.

It’s worth noting that this will get a lot more complex as you’re dealing with more advanced configuration / building – one of our clients applies this principle at a usage of material level, which means there’s a lot of logic going into the pricing in particular.

The next level of these product builders – in-line 3d building, augmented reality etc

Beyond standard configuration and in-line previewing, the natural progression is looking at 3d modelling and in-line previewing of the customisation or progressive building of the item. Nike and Helmade (featured later on) are really good examples of this, both starting with a base product and then allowing in-line customisation, viewable as a 3d model. This is getting more and more common with businesses seeing product customisation / building as an important part of their business – be it custom-built or powered by a third party.

The next level is then to use the 3d model as part of an augmented reality (AR) experience, allowing the user to see the item in lifesize in-context via their mobile device. Again, this is getting more common and Interior Define is a good example who have gradually progressed into this (they use Cylindo).

If you end up wanting to progress an existing configurable product and go down this route, it’s usually worth looking at an existing third party, who have already built the viewer, have an existing integration with your platform (ideally) and who will take away a lot of the heavy lifting around the build. These platforms are generally billed based on creation of assets and then a license cost for the software, but over a longer period of time will end up being more cost-effective and also more progressive in terms of features and improvements.

Technology considerations and approach

One thing that does need to be considered when you’re approaching this stuff is the restrictions around your technologies – for example some ERP systems won’t allow for BOM SKUs and platforms like Shopify aren’t as flexible around building the products via their APIs (often leaving line items as the only option for highly configured items). The first thing you should do really when looking at how advanced you can go is really do due-diligence on the most scalable route with building these, if even if you’re doing multiple phases.

We’ve seen a number of businesses build solutions within a platform and regret it or via something like React and end up moving to a third party (to benefit from other features etc), so it’s worth really thinking about the different approaches and what’s going to best fit your business, application and also back-office requirements (e.g. stock managing each aspect or handling availability).

Third-party solutions for product builders 

As I’ve already mentioned, there are lots of third parties that support both the building side of this and also the customisation / visualisation side, allowing for the in-line preview and the 3d modelling and AR. Here are some examples of technologies that we’ve come across with clients:

  • ThreeKit – had a number of clients look at ThreeKit and it looks very good. JPress is a good example of a simple implementation and # is a good example of a more complex one.
  • Cylindo – used by a couple of our clients. Very strong product and offering, specific to home and furniture industry.
  • Smart Pixels – currently being used by one of our clients. Fairly flexible around UI and approach and used by a number of premium brands.
  • Threedium
  • Productimize

Examples of well-design product builders and customisable / configurable products

Tylko (3d builder)

Tylko is the best builder UI I’ve ever seen – allowing for a huge amount of configuration whilst viewing the product in-line. This implementation appears to be bespoke and is very well optimised for all device types.

This is a good example of an item that’s likely to be set up around materials, with a price per unit type approach, with add-ons with other features etc.

Helmade (3d builder)

Until I found Tylko, Helmade was my go-to example for a highly complex personalised product – with excellent front-end visualisation (via CGI) and really nice configuration UX. 

Interior Define (configuration)

We’ve done a lot of work in the furniture industry and Interior Define is always the one I come back to. They’re using Cylindo to handle the assets and the visualisation piece, but the UX around the configuration journey is really strong.

Nike By You (Formerly Nike ID) (3d builder)

Nike is probably the best-known example of product personalisation and it’s been seen as the leader in this space for a number of years. Nike have create a highly usable editor and end-to-end it’s very impressive. The range of products they’ve applied the customisation option to is also very impressive.

Wristband.com (3d builder)

Really nice example of an in-line visual editor on Shopify, allowing for really advanced customisation with previewing. This is powered by Productimize.

Parachute Home (configuration)

This is a fairly simple configuration, however it’s a good example for standard product configuration or how bundling should be handled on PDP.

ByHumanKind (configuration)

This example is fairly simple, but it is nicely positioned within the off-canvas configuration area. I like how the different steps work and how simple they make the process. I also like how they’ve factored in the multi-buy discounts for one-time purchases.

Deranged Vehicles (3d builder)

Really nice, multi-dimensional product builder for a automotive business. Allows for highly advanced interior and exterior customisation, with up-sells and a really nice UI. This is powered by Threedium.

Roam Luggage (3d builder)

This is another Shopify example that uses Threekit. This is a really nice implementation and again just provides a more engaging experience for the end user.

Paul Rogers

Paul Rogers is an experienced eCommerce Consultant, specialising in all aspects of replatforming and eCommerce optimisation / customer experience.

Paul has worked with most mainstream eCommerce platforms and has supported complex replatforming projects with retailers from all over the world. From a solutions perspective, Paul specialises in working with Magento and Shopify Plus.

Paul is also the Managing Director of Vervaunt, an eCommerce consultancy and paid media agency based in London.

Leave a Reply

Your email address will not be published. Required fields are marked *