3 Different Approaches for Adding a Product Configurator to Your Ecommerce Store
If your brand offers customized products, then developing your ecommerce site to integrate this kind of customization is likely top of mind. Product configurators allow customers to design their own products on your site. They can be used to customize things as varied as a pair of sneakers to the latest Tesla vehicle. Configurators are the ultimate tool of ecommerce personalization, and shoppers love creating their own unique items.
But how financially viable is it to add a product configurator to your online store? What should you consider before implementation? In this episode of Recommerce, Sara and Tif break down all the aspects of product configurators. You’ll learn about:
- Three different approaches to product configurators and why they range in budget and timeline
- When to use photos versus rendered imagery in your configurator
- Why it’s important to know the characteristics your products share
- How to think about long-term maintenance needs for your configurator
Full Episode Transcript
Hello and welcome to another episode of Recommerce. I’m Sara, the founder of Command C, and I’m here with Tiffany, our tech lead. How’s it going, Tif?
Great, Sara. How are you?
I’m good. So today we’re going to talk about product configurators. There are lots of businesses out there that have the ability to offer custom or customized products, and the web offers this really unique space where you can very realistically simulate what this custom product will look and feel like.
Online product configurators are a unique space where you can simulate what a custom-designed product will look and feel like.
If you go into a furniture showroom, for example, typically there’s one version of the product that you’re interested in, and then you have lots of different swatches to pick from, and feel, and touch. You can get close to imagining what that final custom product will look like, but you don’t typically see all versions of that product in the store. So the web offers this really cool space where you get to do that. In fact, lots of showrooms are leveraging their web experiences now in-store to give customers a better sense of what they’re going to get visually.
So while we can really imagine these great user experiences for custom products on the web, the technical challenges behind building tools like this are significant, especially as the complexity of what you’re looking to showcase increases. So today we’re going to talk through the ins and outs of the technicalities of creating these tools.
Yeah. Not only are the challenges from a technical perspective pretty significant, they’re also really outside the realm of what most ecommerce platforms do right out of the box. I’m not talking about a t-shirt that comes in three sizes and five colors, this is accomplished with variance. And it’s easily something that your team can upload images of all of that inventory into the platform, and customers can see on the frontend. What we’re really talking about here are the ability to pick between hundreds, even possibly thousands, of combinations, and sometimes those combinations depend on one another. You can’t have the leather cushion with the ratan back or something like that. I’m just going to keep harping on this furniture example I think.
We’re talking the ability for your customers to pick between hundreds, possibly thousands, of combinations to create a product.
So you can start to see that layering and complexity that the platform may not support. Then there is kind of the secondary layer of this, which is that it would be next to impossible, and not even desirable in most cases, for your team to photograph or accurately render every possible customer configuration.
Yeah, I hear that. I think one of the things that comes up a lot when we talk to merchants about building these kind of tools is that often on the frontend the tools feel, from a web perspective, really simple. Obviously, depending on the user experience they can be a really easy feeling to use. I’m thinking about Nike ID, which is an example I use all the time, where you can build these incredibly custom shoes. I’m actually wearing a pair right now. I would show you if we had video, but we don’t.
You’re not going to show your shoes on the podcast?
That’s next-level web stuff right there. So anyways, that site is so easy to use, and I think that that leads to some assumptions about how easy the tools should be to build.
There’s definitely a disconnect there too between what this would feel like in real life. So why we can all use that furniture store example and understand that you’re not seeing everything, it’s also a process that you can visualize happening in real life that does not seem like a lot of complexity goes into it. As a human being, it’s very easy for you to say, “Okay, well I know that the red one only goes with the gray one, and I know that I can only put my name on this piece,” and all of those things. It’s a machine that has to make all of those decisions when we translate it to the web.
And so a person has to be able to really clearly articulate what all of those constraints and requirements are, and then ensure that there is a comfortable visual experience for the customer at the end of the day that is accurate, and, you know, as is the case with Nike ID, super fun to use.
Mm-hmm (affirmative), yeah. I think that that fun to use is a really crucial part of the user experience. I mean fun and easy I would even kind of extend that to. Can we talk a little bit about the different options for images with product configurators on the web? I’m thinking back to my Nike ID example. When I built my shoes there was a different color overlay I’m going to call it, for every panel that I was able to customize. How does that quote-un-quote color overlay get generated?
There are as many ways I think to accomplish that as there are configurations for some of these products, but I think they kind of fall into two buckets. The first one is that you’re using actual photographic imagery. We already decided that we have too many options to photograph every single possible combination. So what we look at doing is generating images that can be laid on top of one another that will correspond to the heel color, and the footbed color, and the shoelace color, and any other patterns that may lay on top of it, on top of the product.
There are as many ways to accomplish color overlays, but they basically fall into two buckets: photographic imagery and rendered imagery.
That’s a really common way to tackle this problem. There are plenty of tools within web development that allow us to lay these images on top of one another to combine together and create an overall image. Going even further, we can generate and save that image for distribution to your manufacturing team. There’s a lot that can be done with this idea of overlaying images. But it doesn’t really ease the need to have a whole lot of images as much as you might think, because now, even though we don’t need to take a photo of every combination with the red shoelaces, we do have to have a photo of all the different colors of shoelaces that we can overlay on top of the global image.
So that first bucket is really thinking about things from real-life imagery. Obviously, that’s going to be the most comfortable for the customer. It’s going to feel like real life. You’re not going to have any sort of weird disconnects regarding colors.
But the second version of this is utilizing rendered imagery, and that can be really nice for you as an administrator especially if you already have software that renders this imagery for you for manufacturing. You really can automate a lot of the generation. You’re not taking photos of every possible option, and you’re not needing to store all of those in a separate place, and you’re not really needing software to combine them together necessarily because you have been able to, within seconds potentially, automatically generate all of those renderings.
So if we think about it from one of those two perspectives, we’re talking about minimizing administrative overhead from creating the images, but also then what do we have on the frontend for the customer to experience. If your product is a very technical product, or something even anywhere in the technology space, a rendering is probably fine. If your product is shoes, or clothing, or something that’s going to require lifestyle imagery to go with it potentially, you may want to consider photos.
If your product is in the technology space, a rendering is probably fine. If your product is shoes, or clothing, or something that’s going to require lifestyle imagery to go with it, you may want to consider photos.
Mm-hmm (affirmative). Is there a load difference between the two options?
It really depends on how it’s built and how many things you need to layer together. This is a great non-answer: I would say that every single situation is going to call for a slightly different strategy for minimizing load time.
Welcome to my life.
Your mileage may vary.
Got it. One other thought that’s coming to mind, before we take a break, is what about the implications of long-term maintenance of a tool like this? Some, especially kind of the wearable brands that we tend to work with, oftentimes they’re releasing products in four different times throughout the year, seasonally. What is kind of the administrative load for keeping these products up to date but also transferring the information from an order through the various arms of the business who it’s relevant to?
Yeah. For that I would really encourage merchants to think about what aspects of their customizable products are the same. What do they all share? That’s where the code base for this or the solution that you choose. We’ll talk a little bit more about what options are available a bit later. But that’s where that really starts to matter. If your goal is that this is constantly variable, and you’re constantly adding new options, and you want the flexibility to change the shape completely, or add a completely new option that’s never existed before, we’re talking about a very different piece of software. We’re not just talking about software that you’re populating product data into. We’re talking about software that allows you to build product, and at that point what you’re building and what you need is significantly more complex, and the complexity comes up front in order to give you the flexibility you need as an administrator in the future.
Will you need software that you can populate data into or will you need software that allows you to build a product from scratch?
If on the other hand you can sort of say to yourself, “Yes, these are all the attributes that these products share. We’d like to build this under the assumption that any configurable product like this that we add in the future is going to share these attributes,” you can really have a smaller level of complexity up front that will still last you quite a long time by putting in that little extra leg work to identify what’s common and what’s unique between all of the products.
You’re listening to Recommerce, a podcast for ecommerce wearable brands navigating technical complexity and change, brought to you by Command C. We’re a development team that saves ecommerce retailers from outdated tech and ineffective operations with a strong focus on Magento and Shopify Plus. You can learn more about how we help at Commandc.com.
Okay, so coming back from the break I want to delve into some discussion around the three potential ways that we approach the challenge of building product configurators. I also want to talk about sort of the sense of cost, as well as administrative overhead and pros and cons of each of those approaches. So why don’t we start off with kind of the simplest approach and then work our way …
The simplest approach to this, at least from a getting set up and rolling perspective, is to use a service that already does it. So these are usually software as service (SaaS) providers. There’s typically an onboarding phase where their development team is helping you get your products set up within their system. There’s typically an ongoing subscription. Usually, we are embedding the module that they create for you within your ecommerce platform. There’s some development that’s typically required in order to hand off the data from the configurator module that you’ve dropped into the product page to the actual ecommerce platform so that it can be processed by your team.
The simplest approach to add a configurator to your site is to use a service that already does it.
But you don’t really have to reinvent the wheel in this scenario. You don’t have to build the software that controls the user experience. So if you find one of these services that has a user experience you like, or that is potentially already sort of really integrated with your vertical; for example, someone who has developed a configurator for specifically the product that you sell, you may find that this is the fastest way to get up and running. Then you have the benefit of that software being in constant development. So they are constantly improving it. You are getting the benefits of those improvements, that research. You likely are going to get future options down the road and you’re not responsible for maintaining the ongoing development of that piece of software.
So as with all these options we’re going to discuss there are some pros and cons for using it. The pro for using it is that you get the benefit of constant software development. Their team is going to be constantly iterating on it, making it better, giving you more options. You aren’t responsible for maintaining it. You don’t have to host it. You don’t have to ensure it’s security or scalability. You’re really kind of one and done–you push the button and you’re live. Right? (It’s not really like that, but let’s pretend for a second that it is.)
The con, though, is that now you have potentially a very significant part of your ecommerce business riding on the existence of a single service. So if that service discontinues in the future, or if they dramatically change the way that they’re offering things, or they increase their prices significantly, which we’ve definitely seen with other SaaS providers, you could be in a space where you have to make the decision whether to completely jettison this piece of your ecommerce platform, which could be very critical, or re-build something brand new or think about something brand new, and that could happen at any time. So that’s the big con with using one of these providers.
I think another con with this option are sort of the inherent constraints to using a pre-existing piece of software. It may or may not achieve your needs.
We see a lot of times that what could be the perfect solution sort of gets molded and shaped to fit into the offering of a service that already exists, and there is absolutely a call for that in some cases. Budgetary constraints. Timeline constraints. Maybe it’s an experiment. Maybe you’re just dabbling in customizable products and it doesn’t make sense to build out this very customized platform, so you do a few things manually in the backend. Your operations team handles a few things by hand that you would rather see automated. The user experience isn’t exactly what you want, but it’s pretty close, and now you can test the waters and determine if further investment is warranted. So that ones a little bit of a double-edged sword, but definitely you’re going to be constrained to whatever options that provider gives you.
If a retailer has no budget or time constraints, they should consider building their own completely customized solution.
I mentioned it a couple of times I think in passing, in kind of the perfect world solution, if budget and timeline were absolutely no concern to anybody, is to build your own completely customized solution that does exactly what you want. This could be as simple as what we described earlier: choose a few colors and an overlay, and pass the data all the way through to check out. Or it could be as complex as 3D modeling and 365-degree rotation, video, layers on lifestyle images. We could even step into AR (augmented reality) and VR (virtual reality) if we wanted. The possibilities are limitless with this option, though budget requirements are also accordingly limitless.
So it tends to be something that is really only a great idea when you have a very customized, unique need, and when you are planning that into your marketing budget, when you’re planning your entire business potentially around this customizability, then building the solution completely from scratch starts to make a lot of sense. You have full control over it. It does everything that you want. You can control its scalability and performance, which I sort of listed as a pro. I listed not having to worry about those things as a pro for the previous option, but of course, having to worry about them does mean that you have control over them.
There is a middle ground, and the middle ground … and this is another one that’s particularly good if you’re just getting started with configurators. The middle ground is to leverage existing tools and data structures that are provided by the platform, by the ecommerce platform, and sort of adjust some of your expectations and requirements for the user experience to take advantage of those existing tools.
The middle ground is to leverage existing tools and data structures that are provided by the ecommerce platform and then adjust these elements.
We see this happen a lot with hosted platforms. When there may be an app that does some of what you need and then the rest can be coded into the frontend by a capable developer. Or maybe you’re not using an app at all, maybe you’re just coding a really snazzy client-side experience into the front end and passing those values off, but you’re leveraging tools that you already have within the platform. You’re not necessarily writing a completely new piece of software.
This is a really nice middle ground. Like I said, budget-wise it’s going to fall in the middle. There is going to be some up front development but certainly not as much as building a completely bespoke solution. There is going to be some ongoing maintenance, but it may not be more than you’re already paying for with your ecommerce platform. This is the solution that we tend to land on the most when we’re just starting with a configurator, when we’re not attempting to adapt a solution that somebody has had in place for a really long time.
So just to recap, the three paths forward for building configurators are:
- Leveraging a software that does it out of the box
- Building your own completely bespoke solution
- Some combination therein of leveraging existing tools and data structures that the platform gives you, but being willing to adjust some of your expectations around how customized this thing will be.
We typically end up recommending #3, that last approach, the middle ground. Although sometimes it really depends on where the business is. Is this something that has been a proven concept you really know is going to work, and you’re willing to make a larger upfront investment in it? Or is this sort of a new idea that you want to validate with the market before making this kind of huge upfront investment?
We typically end up recommending #3, the middle ground. Although it really depends on where the business is.
As a general rule, if you’re thinking about building a solution completely from scratch, if there are start-ups and organizations and businesses out there who have made their entire business model with complete teams of people working on this 24/7 maybe, working on this very hard, it is not going to be the least expensive solution. You should plan accordingly … that this is to be done right, to be done well, this is a piece of software that requires a lot of development time and a lot of ongoing dedication. So like you said, that’s why we often land in that option three realm unless your entire business is based around the idea that people can customize the item, and you have these very, very unique needs, there is usually a creative way to bring your configurator to life and start gathering interest in it, and growing that portion of your business, within the constructs that your platform offers you out of the box.
Great. Well, thanks for the chat today. It was really interesting to dissect all of this.
It definitely was. Thank you.
You’re welcome. Have a good one.