Designing a Virtual Try-On Experience That Makes Online Shopping More Confident
Dopplr was a fashion technology startup building a browser-based virtual try-on experience for ecommerce brands. A shopper could open Dopplr directly from a product page, create a personalized avatar using their body measurements, and see how a garment fit before purchasing.
I joined as the company's only designer. There was no design system, no existing product, and no established user flows. The challenge was defining the experience from the ground up while working alongside the CEO and CTO to shape the product itself.
The Problem Space
Virtual try-on products already existed, but most fell into one of two categories. Some exposed too much technical complexity: body measurements, calibration settings, and avatar controls before users could see a garment. Others simplified so heavily that the output felt unreliable. A garment overlay might look visually appealing while providing little confidence about actual fit.
Dopplr was built around a different assumption: people make purchase decisions when they trust what they see. That meant creating an avatar detailed enough to feel personal while keeping the experience simple enough for someone casually shopping online.
Several constraints shaped the product from the start:
- The experience had to run inside a browser
- It needed to work across different ecommerce sites
- Performance had to remain acceptable on consumer devices
- The 3D garment view had to stay the focal point, not the interface around it
Defining the Product
Before designing screens, I worked with the CEO and CTO to define the core journey. The product centered around three connected experiences:
- Avatar Creation: users input measurements and the system generated a 3D body representation
- Virtual Try-On: garments were draped on the avatar for rotation, zoom, and inspection
- Fit Insights: a heat map overlay surfaced tension and pressure points across the garment
Each introduced a different design challenge.
Avatar Creation
Getting users to input body measurements accurately was harder than it sounds. People don't know their measurements off the top of their head, and asking for too many inputs upfront causes drop-off. Asking for too few produces an avatar that doesn't feel personal enough to trust.
The design had to find the minimum set of inputs that could generate a believable, useful avatar without making the process feel like a form. I explored several approaches, including guided measurement flows with illustrations, size-based shortcuts for users who didn't want to measure, and progressive input where the avatar updated in real time as values were entered. The goal was always to get the user to a point where they looked at the avatar and thought "that's roughly me" as quickly as possible. That moment of recognition was what made the rest of the experience worth engaging with.
The Try-On Interface
Once the avatar existed, the interface had to get out of its way.
Early explorations had persistent control panels, visible toolbars, and labelled buttons for every action. In practice these competed directly with the 3D canvas. Users were reading the interface instead of looking at the garment, which was the opposite of what the experience needed to do.
I landed on contextual controls. Nothing was permanently visible except the canvas and the garment. Controls surfaced when users interacted, hovered, or needed to take a specific action. Labels were reduced. Motion did the work that text had been doing.
This required close collaboration with the CTO and developers to understand what was technically feasible inside a browser plugin without hitting performance limits. Several concepts were abandoned because they added complexity without improving understanding. The final interface was substantially lighter than the earliest explorations.
Dopplr Product Prototype
Fit Visualization
The heat map was the most technically interesting surface to design and the one with the most ways to go wrong.
The data it needed to show was genuinely useful: where the garment was tight, where it had room, where it might cause discomfort over time. But a persistent color overlay on top of a 3D garment is visually aggressive. It competes with the fabric texture, flattens the depth of the render, and if the color scale isn't carefully considered, it reads as alarming rather than informative.
After several iterations, I designed the feature as an optional layer: off by default, one tap to activate, easy to dismiss. The color system was refined across different garment types and avatar combinations to maintain readability without dominating the experience. The final version worked as a secondary inspection tool rather than the primary view.
Motion as Feedback
3D assets take time to load. That's unavoidable in a browser environment, especially for a plugin that had to work across different ecommerce sites with varying performance conditions.
Rather than masking this with a generic spinner, I designed loading states that reflected the product's visual language and gave users a sense of what was coming. The motion wasn't decorative, it was communicative. It told users the system was working, what it was doing, and roughly how long it would take.
This thinking carried into micro-interactions across the product as well. State changes were animated. Transitions had direction and purpose. The goal was a product that felt responsive and alive without ever pulling attention away from the 3D canvas.
What I Learned
This project was my first experience owning product design from day one. There were no established patterns to inherit and very few comparable products to reference. Most decisions involved balancing user understanding against technical constraints, often in direct collaboration with the CTO.
Working on a browser-based 3D product changed how I think about interface design. Performance, rendering limitations, and implementation complexity influenced design decisions much earlier than in traditional SaaS work. Learning to speak in terms of feasibility, not just desirability, became a core part of how I collaborated.
The biggest thing I would change is the amount of user testing. Most feedback came from internal reviews with the CEO and CTO, which helped us move quickly but meant some usability issues in avatar creation surfaced later than they should have. If I were approaching the project today, I would prioritize lightweight user testing earlier, particularly around onboarding and measurement input.
