Unity for interactive product demos and configurators

By Marco Lopes · April 11, 2022 · Design, 3D & XR

A product photograph shows one view. A video tells one story. An interactive demo lets people choose what they want to understand: how a mechanism works, how a finish catches the light, or whether a particular combination of components makes sense.

At Kordspace, we see these experiences as a meeting point between design and software engineering. As a remote studio working across software, AI, Web3, hardware, and design, we care about both the presentation and the systems behind it. Unity gives us a useful environment for bringing those pieces together, provided we choose the right scope and delivery format.

Here is how we approach Unity-based product demos and configurators, from the first interaction sketch to a maintainable release.

Start with the decision, not the model

Before importing geometry, we identify the decision the experience should support. Are we helping someone understand a complex product, compare options, configure an order, or explain a prototype to stakeholders?

Those goals produce different applications. An educational demo might emphasize exploded views and guided animation. A sales configurator needs clear choices, valid combinations, and a reliable handoff to an inquiry or checkout flow. An internal hardware review might prioritize dimensions and component visibility over polished lighting.

We write down one primary task and a few supporting tasks. For example: select a base product, choose compatible components, inspect the result, and save the configuration. This gives us a testable journey instead of an open-ended brief to “make it interactive.”

We also agree on what remains outside the experience. A configurator does not automatically need a complete commerce platform, multiplayer collaboration, or an immersive headset mode.

Decide whether Unity is the right fit

Unity is particularly useful when an experience combines rich 3D scenes, animation, custom interaction, and application logic. Its editor lets us work visually, while C# gives us room to build rules and integrations beyond a simple model viewer.

It can also support different delivery targets from a shared project. That matters when we expect related experiences for a website, a trade-show kiosk, and a native application. We still budget for platform-specific work; a shared project does not eliminate differences in input, performance, or packaging.

We do not default to Unity for every spinning product render. If the requirement is a lightweight viewer embedded in a content-heavy page, a browser-native approach may be simpler. We compare startup cost, accessibility, mobile requirements, and maintenance before committing.

The engine should serve the product journey, not become the reason the journey exists.

Prototype the interaction before polishing visuals

Our first prototype usually uses simplified geometry and placeholder materials. We want to learn whether people understand the controls before investing in detailed assets.

We establish a predictable camera, sensible rotation limits, and an obvious reset action. We separate inspecting the product from changing it: dragging should not accidentally select a component, and selecting a finish should not unexpectedly move the camera.

For touch interfaces, we test gestures on actual devices rather than assuming mouse interactions translate cleanly. For kiosk installations, we consider idle behavior, session reset, and how the next visitor starts fresh.

We also prototype the surrounding interface. A beautiful object is not enough if option labels are unclear or the next step is hidden. The product, controls, explanation, and call to action need to behave as one designed experience.

Prepare assets for real-time rendering

Engineering models and real-time assets solve different problems. A CAD assembly may contain internal fasteners, tiny bevels, or detailed surfaces that contribute little to a sales demo but add substantial rendering work.

We begin by auditing the source material: ownership, formats, units, orientation, component structure, and expected updates. We then establish a conversion and cleanup workflow appropriate to those files. We do not assume Unity will directly ingest every format an engineering team uses.

Our preparation typically includes removing invisible geometry, simplifying dense meshes, repairing normals, organizing pivots, and creating usable UVs. We preserve separate components where they need independent selection, animation, or replacement.

Materials need their own review. We standardize texture sizes and naming, reuse materials where practical, and check the result under the intended lighting. A texture that looks convincing in an offline render may need adjustment in real time.

Finally, we document the export conventions so a revised model does not force us to rebuild the application structure.

Treat configuration as data and rules

A configurator becomes fragile when every option is hard-coded into interface buttons. We prefer a data model that describes products, components, finishes, compatibility, and identifiers independently of their visual presentation.

The Unity scene then reflects the configuration state. Choosing an option updates that state; the application validates it and changes the visible components or materials accordingly. This separation makes it easier to test rules without manually clicking through every scene.

We pay particular attention to invalid combinations. If one component requires another, we decide whether to add the dependency automatically or explain the requirement. If two choices conflict, we make the resolution visible rather than silently discarding the user's work.

Where prices or availability are involved, the backend remains authoritative. A local preview can help the interface feel responsive, but a submitted quote or order should be validated server-side against current business rules.

Design for confidence, not just visual impact

The interface should make the current configuration understandable. We show selected options clearly and provide a concise summary that can survive beyond the 3D session.

That summary might include component names, finish identifiers, a preview image, and a configuration reference. We avoid relying on color alone to communicate selections, and we provide useful text alongside visual changes.

Accessibility also affects our delivery architecture. A canvas-based experience should not be the only route to essential product information or the only way to submit an inquiry. We can place accessible HTML controls, descriptions, and alternative flows around an embedded Unity application where appropriate.

We are careful about visual promises. Screen settings, lighting, and material approximations affect perceived color and texture. Where finish accuracy matters, we explain those limitations and support a physical sample or other verification step.

Set a performance budget early

We define target devices and acceptable loading behavior before the scene becomes elaborate. “Runs on our development workstation” is not a meaningful release criterion for a public-facing demo.

For a browser build, we pay attention to download size, memory use, texture compression, shader complexity, and the cost of the surrounding page. For a kiosk, we can optimize around known hardware, but we still test long sessions and recovery from interruptions.

Unity's Universal Render Pipeline can be a useful starting point for scalable rendering, although we choose the pipeline after checking the actual visual and platform requirements. We favor restrained lighting, reusable materials, and measured effects over unnecessary complexity.

We profile on representative hardware throughout development. We also test first-time loading, not only repeat visits with cached files. A clear loading indicator helps, but it does not replace reducing what must load before the first useful interaction.

Choose browser, native, or kiosk delivery deliberately

WebGL can make a Unity experience accessible through a link without a separate installation on supported desktop browsers. That convenience comes with constraints around memory, browser behavior, networking, and integration with the host page.

As of April 2022, we would not promise Unity WebGL as a generally supported mobile-browser solution. We would validate the precise requirements and consider a native application or a browser-native 3D implementation when mobile web access is central.

For desktop web delivery, we test compression headers, caching, HTTPS, and cross-origin requests as part of deployment. An exported build that works locally can still fail when its files are served incorrectly.

For native and kiosk applications, we plan installation, updates, offline behavior, and operational support. A sales-floor application needs a dependable restart path just as much as it needs attractive rendering.

Connect cloud services without complicating the client

We prefer Google Cloud when it fits the project's operational needs, while also working with AWS or Azure where an existing environment makes those the better choice.

A practical architecture might serve build assets from object storage through an appropriately configured HTTPS delivery layer, with APIs running on Cloud Run. Product metadata, saved configurations, and inquiries can live behind those APIs rather than being bundled permanently into the application.

We keep secrets out of the Unity client. Anything shipped to a browser or installed application should be treated as inspectable. Authentication, authorization, validation, and rate limits belong in the service design, not in assumptions about hidden client code.

We also distinguish what must be live from what can be cached. Product descriptions may tolerate caching; pricing approval or order submission may require fresh validation. For offline demos, we make the limits explicit and define what happens when connectivity returns.

Make remote collaboration part of the workflow

Interactive 3D work crosses several disciplines, so clear handoffs matter. We establish ownership for geometry, materials, interface design, configuration rules, and infrastructure early.

In Unity projects, we use version control with an approach suited to large binary assets, preserve asset metadata, and agree on scene-editing conventions. Prefabs and smaller, well-defined components help reduce conflicting changes. We pin the editor and package versions rather than letting each collaborator update independently.

Our reviews use playable builds whenever possible. Screenshots are useful for composition, but they cannot reveal confusing controls or a broken configuration path. We pair review builds with a short list of questions so feedback stays focused.

We also define who will maintain the experience after launch. Updating a finish name should not require the same workflow as replacing an animated mechanical assembly.

Keep XR and other extensions purposeful

Unity gives us room to explore augmented or virtual reality when spatial understanding genuinely benefits the task. We might use XR to communicate scale, placement, or operation, but we treat it as a separate interaction and testing requirement, not a checkbox added at the end.

The same discipline applies to AI and Web3. We do not add them simply because they are available. Recommendations need useful product data and understandable behavior; wallet interactions need a concrete user benefit. The core configurator should remain coherent without fashionable additions.

A short pre-launch checklist

Before release, we confirm that:

• The primary journey works on the agreed devices and browsers.
• Configuration rules reject invalid combinations and preserve valid choices.
• Loading, performance, and visual quality have been tested outside our development machines.
• Essential information and inquiry paths have accessible alternatives.
• Backend validation, permissions, and error states are in place.
• Asset updates, deployment, monitoring, and ongoing ownership are documented.

A successful interactive product experience helps people understand an offering and take the next step with confidence. Unity can provide a strong foundation when we pair it with thoughtful design, disciplined asset preparation, and reliable software architecture. If we can help bring your product into an interactive demo or configurator, start a project with us, or explore our services to see how we work across design and development.