Replacing a multi-iteration physical sample process with a real-time 3D editor used across Vans, Timberland, and The North Face.
Role
Lead product designer at DD.NYC, with one intern under my direction across the full project. Owned discovery, UX strategy, information architecture, and the design system from blank slate to production-ready specs. Cross-functional partners: project manager, creative director, our agency's CEO (final approval and active project involvement), and an embedded engineering team.
Problem
Custom apparel creation at VF Corporation required costly physical sample iterations, slow multi-party approval cycles, and manual sketch-to-production conversion. Every project lost time and budget to that process.
Solution
A real-time 3D apparel editor with high-fidelity material rendering, a shared annotation and approval tools, multi-garment collection view, and automatic production-layout export. Built to cover the full creation process digitally.
Outcome
Sample rounds per project: 4–6 to 1–2.
Design approval cycle cut by half or more.
Sketch-to-production conversion from manual time-consuming process to automated. Designer onboarding to working proficiency: under a day. Shipped for Vans, then Timberland and The North Face. Remaining VF brands handled by VF's internal team after rollout.
The Problem Worth Solving
VF Corporation (parent company of Vans, The North Face, Timberland, and JanSport) runs a custom apparel business serving both internal brand launches and large corporate buyers like ASOS and Yoox. The legacy creation process was expensive and slow by design. A buyer would submit requirements, VF would produce 2D Adobe Illustrator sketches, a physical sample would be manufactured and shipped, the buyer would respond, and the cycle would repeat. Typically across 4–6 rounds before production began.
There was no intermediate 3D step. The process jumped straight from 2D sketches to real-life samples, which is one of the core reasons the cycle dragged. 2D sketches don't convey real-life view well enough for a buyer to confidently approve, so confidence had to be bought with physical samples on every iteration. Logistics costs compounded across rounds, and misalignment between buyer expectations and 2D representations was the norm rather than the exception.
The strategic bet was straightforward. If VF could replace most physical sample rounds with high-fidelity digital mockups, they could cut cost and cycle time while improving buyer alignment. I owned the design of the tool that would deliver on that bet.
Discovery: Interviews
The interviews in discovery process were sequenced rather than parallel: executives first, then designers, then engineering. We kept active contact with all three groups throughout the project, but the formal interview phase moved from one to the next. Each step deepened the picture, going from overall goals (executives) to real use cases (designers) to implementation feasibility (engineering).
Executive Interviews
Executive interviews established the business goals and identified the two primary user groups: in-house VF designers across multiple sub-brands, and designers from corporate-buyer teams (ASOS, Yoox, and similar). One key tension came up early. The app needed to serve meaningfully different design environments per brand (Vans skews footwear, other brands skew apparel) on a single app. Scalability across environments became an explicit constraint from day one.
Success framing from executives: speed up apparel creation, digitize as much of the approval process as possible, reduce cost. They also flagged approval dynamics, which they often described by sharing the actual presentation decks they used internally for collection reviews.
Designer Interviews
I interviewed 20 designers across both user groups, roughly a 70/30 split between internal VF teams and client-side designers from corporate buyers. Batch of designers was picked by VF's hr who served as our main communication point throughout the whole process according to our requirements of selection being both randomized and representative of future users.
Three insights drove the rest of the design work, and each was learned through a different combination of methods.
First, designers live in Adobe Illustrator. This came primarily out of interviews, and we then asked designers to send recordings of their actual workflow to see how they used it day-to-day. Their muscle memory and shortcuts were very prominent and getting rid of them was not optimal. This became the foundation for the personalization model and the hotkey system replicating Illustrator's. The variance in how designers customized their Illustrator setups (panel layouts, navigation by visual vs. by code or name) showed up in both interviews and recordings, and it's what pushed personalization from a nice-to-have to a requirement.
Second, approval dynamics involve multiple stakeholder levels and mix async review with in-person collection presentations. We learned this from interviews with both executives and designers, and they shared their actual presentation decks with us so we could see how reviews were structured. This produced two features mapped to two distinct pains: notes for async feedback loss, and presentation mode for in-person collection reviews.
Third, designers compare items side-by-side during creation, not just at review. This came up in interviews and was reinforced in the workflow recordings, where designers would visibly switch between files or open multiple windows to compare pieces while editing. This drove multi-garment editing as an important feature. Designers compare pieces to keep a collection visually coherent as they work, which is a different problem from comparing pieces during a review which is another use case for this feature.
Competitor Analysis
I analyzed the major tools in the space at the time of the project (Browzwear, CLO 3D, VStitcher / Style3D), plus adjacent 3D editors like Spline as non-direct competitors with overlapping functionality. I looked specifically at layout patterns, tool coverage, and the workflows they assumed.
Three patterns came up across the field, each one a gap we could exploit:
None offered meaningful multi-garment collection editing. All were designed around the single garment as the unit of work. This doesn't match with use case reported by our future users.
Several were over-engineered for edge-case coverage rather than quick apparel design. They required a deep app understanding and long onboarding processes.
Layout and tool ergonomics varied widely. Our users are professionals, but the functionality required to fill the tasks they actually do isn't as wide as what the more complicated apps offer. A more complicated interface gives more freedom, but it makes the day-to-day slower and onboarding harder. Onboarding speed mattered a lot in this project, so this was a real trade-off, not a cosmetic one.
Screenshot of CLO3D - industry standart in clothing design, we took some elements from it as inspiration, but mostly it was not a right fit due to app complexity which we specifically wanted to avoid.
Technical Discovery
This is a real-time 3D editor with high-resolution assets running in browser, so it was crucial to involve engineering team in the design process from the start rather than handing off specs after finalisation. That decision prevented several expensive late-stage reworks.
Key technical constraints that shaped the design:
Drag-and-drop interactions (both for graphics placement on garments and for drag-to-anywhere panel placement in the personalization model) would have made the app significantly heavier to run in browser. Engineering raised this concern early. We considered drag-and-drop in both places, ruled it out for the same underlying reason, and worked through alternatives together.
How We Did Research
Research wasn't a discovery phase that ended once the design started. It ran across the entire project as an iterative rhythm of test, revise, and re-test. This section covers how we set it up, because the rigor of the research process is what made the design decisions defensible.
Interview Methodology
We recruited 20 designers through VF's project manager, who was our main communication point with the client and had a participant list ready before we asked, we just selected the most fitting candidates accordign to our criteria. Sessions were 1-on-1 between the participant and our team, which meant me, the intern, and our agency's CEO (sometimes other people were involved, but this is the main pool). Sessions ran 30–60 minutes each, conducted remotely via zoom or google meet. The CEO's involvement across the project was unusual but intentional: we were a small team, this was a strategically important project for the agency, and her presence made the cross-functional communication with VF cleaner from a business standpoint.
We used a structured discussion guide rather than open-ended conversations. Each session walked through the participant's current workflow, their tool stack, the pain points they hit most often, and the patterns they have worked with. We synthesized findings in Google Docs, coded by theme and severity.
Workflow Recordings
Interviews told us what designers said they did. Recordings told us what they actually did. We asked designers to record themselves working on real projects, uninterrupted, at their own pace. Recordings were shared via Google Drive. We requested specific flow recordings before designing each feature, then ran user testing on the prototype after the design was drafted. The combination of pre-design observation and post-design testing was the loop that drove most of the iteration.
User Testing Methodology
We used the Nielsen Norman Group usability testing protocol. Each session followed the same structure: a participant briefing (purpose of the test, encouragement to think aloud, recording disclosure), background questions to anchor context, a scenario that put the participant in a realistic role, a list of tasks they worked through on a Figma prototype, and post-task questions to capture qualitative reactions.
Concrete example from the layout-iteration test (Wave 1):
Scenario: "You're working on a custom shoe collection for a corporate buyer. You've received the brief and need to start building the design."
Tasks: create a new apparel piece from library, open the editor, navigate the parts list, apply a material, change a color, place a graphic, save the design.
Post-task questions: which parts of the layout felt natural vs. confusing, which actions took longer than expected, which version (across the three options) felt most like their existing tools and why.
Earlier-stage tests ran on Figma prototypes. We switched to testing on the built application once the initial design was confirmed and the app was deployed to a pre-production environment, which let us catch real performance and integration issues before the public launch.
Measurement and Severity
Every session was recorded. We rewatched recordings to manually track time-to-task-completion, mis-clicks, and error rate. We also logged self-reported confusion from think-aloud and post-task questions. Issues were scored on the NNG severity scale and aggregated in a google document, then turned into insights and applied to the next design iteration based on feasibility and severity.
We worked with two benchmarks per metric. The first was a rough best-case scenario, set against industry standards plus our own estimate of what a good outcome would look like. This was a quality floor: a way to check that whichever option won wasn't just the best of three weak options. The second was the average across the proposed options, which is what we used to pick a winner among the three (only used in wave one where multiple options were proposed). A design choice passed a milestone when the winner sat at or near the best-case benchmark. If it didn't, we reworked rather than shipped.
Testing Waves
We ran more than 30 testing sessions across the project, organized into six waves. Each wave informed the next.
Wave 1, layout direction. Three layout options tested against each other to pick a direction.
Wave 2, whole editing interface validation. The winning layout from Wave 1 fleshed out into a full editing interface and tested end-to-end.
Wave 3, compare mode, file system, and personalization. Tested together because the three features are tightly coupled in the workflow.
Wave 4, onboarding.
Wave 5, pre-production testing of all flows combined.
Wave 6, post-production pre-launch testing on the built application, before public release.
Cohorts were rotated and randomized across waves to keep the sample representative and avoid familiarity effects. Almost every design decision in the final product (layout, personalization model, the right-panel tools, multi-garment editing, file system structure) was shaped by what came back from these waves.
Screenshot of the Wave 1 user testing iteration where we were picking initial layout we'd iterate upon. As you can see A LOT was changed in the further process :)
Synthesis: What We Were Really Building
The largest single source of cost and time waste in VF's process was misalignment between parties. Buyers couldn't visualize designs from 2D sketches, feedback was lossy, and approval required physical artifacts. Solving alignment wouldn't solve the entire business problem on its own (efficiency wins on conversion and onboarding mattered too), but alignment was the lever most likely to compound across every success metric we're chasing.
Onboarding speed sat alongside alignment as a primary concern. A meaningful share of the user base would be designers or approving parties from outside VF, working at corporate buyers, who would not go through formal training on this app. If they couldn't pick it up quickly, they wouldn't use it, and the alignment thesis would collapse on the buyer side of the workflow. Fast onboarding wasn't a nice-to-have; it was a prerequisite for the whole product to work.
This led to four design principles that mapped directly to product features:
Minimize friction for designers: personalization model, quick interactions plus Illustrator-mapped hotkeys.
Make sharing, presenting, and reviewing first-class: notes plus presentation mode.
Support side-by-side design within collections: multi-garment editing.
Make the product picked up in a day, not a week: contextual onboarding designed for ongoing feature expansion.
Success metrics we will chase: time to complete key flows, physical sample rounds per project, onboarding time for new users, process coverage rate across VF sub-brands, and feature adoption rate as a proxy for actual workflow integration.
User Story: Before
ASOS places a custom shoe order with bespoke colorways. The brief moves to Timberland's design team, who produce an Illustrator sketch. ASOS sends it back with notes. Iterate, iterate and iterate, typically across four to six rounds. The buyer is reading a 2D sketch and trying to imagine a 3D shoe, and the designer is interpreting written feedback and trying to imagine what the buyer wants. Each round costs time. Once design locks, physical samples are produced and shipped, then more rounds of approval. Logistics charges accumulate. By the time production begins, much of the original budget and timeline has been consumed by the back-and-forth, not the work itself.
Visual Direction: Where I Pushed Back
In the beginning, the creative director and I aligned on visual direction. He proposed a minimalist style, mostly text-and-input based, beautiful and editorial. I disagreed and pushed for a more universal style with more flexibility and easier to work with. The reasoning was practical. A magazine-like interface looks great in screenshots, but a 3D editor needs visual hierarchy that supports active manipulation. Editorial layouts privilege reading, and this product privileges doing.
We both worked through several rounds of mockups before settling on a direction with cleaner interaction language and more visible controls. The minimalist version would have shipped well to executives and worse to designers actually using the product daily. Holding the position required showing the difference, not just arguing it.
Accepted vs declined visual direction options.
Design System
With direction set, we built a design system on top of MUI. We chose MUI because its component depth matched our coverage needs and we had no time to invent base primitives we wouldn't differentiate on. The differentiation lived in the canvas, not the chrome.
Personalization: Solving the Illustrator Transition Problem
Discovery showed strong Illustrator usage across designers, but we didn't understand how much variation in its usage there is. Some designers are panel-heavy, some live in keyboard shortcuts, and some navigate primarily by color code rather than visual swatch. A one-size-fits-all interface would have alienated experienced users.
Illustrator example one of designers shared with us.
Designer workflow variance was wider than the discovery interviews showed, so I spent additional time on observation (workflow recordings) and competitive review before committing to a personalization model. The goal was to find the smallest set of features with the easiest implementation that covered the largest part of the variance, without inviting the development cost of a fully open customization system.
The model came down to three targeted features:
Resize interface elements using the same stretch interactions designers already use in Illustrator.
Reposition interface elements using selection-based settings.
Hide unused panels via interface settings, keeping focus where it's needed.
Scale component layout between name-heavy and image-heavy views, because some designers identify materials by code, others by visual.
We considered drag-to-anywhere panel placement (free arrangement of panels into custom layouts) and ruled it out on the same engineering grounds as drag-and-drop graphics: too expensive to run smoothly in a web app at our target performance level. The three features above addressed the bulk of the variance I observed without that runtime cost.
Editing Interface: Parts and Layers
The default three-panel layout came out of layout testing in Wave 1. We tested three options. One was the original Adobe Illustrator default layout, which seemed like the obvious starting point given how heavily designers relied on Illustrator. Once we looked at the workflow recordings, though, none of the designers' actual setups matched the Illustrator default. They had all customized away from it, in different ways. So the second option we tested was an averaged version of designers' real customized layouts, mapped from the recordings to find common patterns. The third was our custom solution based on competitor research.
Each option was tested in a controlled session with 20 designers (mix of in-house and corporate-buyer teams) on a Figma prototypes, with each participant creating a shoe and making at least one edit per category: material, color, and graphic. We measured time-to-task-completion, mis-clicks, error rate, and self-reported confusion. The designers' Adobe Illustrator interfaces essence was the winner (second option).
Garments often have dozens of parts, some very small or visually similar. We added filtering by unconfigured parts (for self-review before submission) and quick-select by material, color, or graphic matching each part. That idea came directly from designer interviews and workflow recordings, where part properties came up as a faster identification method than part names.
Layers tab.
What We Cut: Large Property Previews
The first version of the layers list used large visual previews in each property category. Colors and materials displayed at sizes that emphasized visual identification, which matched the discovery insight about navigating by visual properties rather than part names.
Designers killed it in user testing. With 10+ parts per category, large previews pushed the list off-screen and made navigation slower, not faster. The right answer was a balance: smaller previews that still supported visual scanning but kept the list scannable at typical part counts. We added the personalization toggle for preview size, because the recordings showed that some designers were more comfortable with visuals and some with text. We held the visual-navigation principle from discovery and traded the specific implementation that didn't survive contact with real workloads.
Editing Interface: Tools
Export tool supports all formats VF and its buyers needed. The unlock was automatic conversion from sketch to production-ready layout, a process that previously took designers a meaningful amount of time per garment by hand. At collection scale, the time recovered is significant.
Notes is the backbone of the alignment thesis. Any designer or stakeholder can annotate a garment. Public notes are visible to anyone with file access, and private notes are scoped to the author. We shipped notes deliberately simple for the MVP: single-thread annotations with author metadata, no replies, no resolution states. We scoped threading post-MVP because we wanted to see how designers actually used notes in real workflows before committing to a more complex collaboration model. This is the feature most directly responsible for cutting the email-and-screenshot loop that dominated legacy feedback.
Hotkeys were mapped from Illustrator wherever technically possible, with a persistent reference panel and tooltips on hover. This reduces the learning curve without burdening the interface with onboarding artifacts.
Hotkeys tooltip shown on hover.
Presentation mode hides the interface entirely. Presentations are made for whole collections, not individual pieces, so the navigation is built around that.
Presentation mode allows to hide interface and quickly navigate apparel items inside collection.
Color, Materials, and Graphics
All three tools in the right panel share the same personalization logic: multiple view modes, quick-action shortcuts, and library access.
Color required extra care because screen color and real-world color diverge, and the divergence varies by material. We built multiple color-code format options (configurable per user). The format-options work came directly out of testing: different designers from different companies used different color-code systems, so a single hardcoded format would have made some users slower.
Materials apply to any part with rendering tuned to match real-world appearance. Preview can be set to either a 3D render or studio photography of physical samples. This was reworked during testing too: the original version used only one preview type, and testers wanted both, which gives designers a reference closer to what they're used to seeing.
Graphics placement was the most technically constrained part of the interface, and it went through three iterations before it shipped. The first instinct was drag-and-drop on the garment surface. Engineering ruled it out early on runtime grounds, the same constraint that killed drag-to-anywhere panel placement. We moved to an input-based control scheme next, where designers entered position, rotation, and scale as numeric values. User testing killed that one. It was too slow and clunky in practice. The third version was the one we shipped: physical-analogue controls with joystick-style placement and inputs for precision, which performed well in testing and was feasible to build. The decision is a real trade-off: less direct manipulation in exchange for runtime headroom that lets the rest of the editor stay performant. The path to it was iterative.
Multi-Garment Editing
Collections require coherence. Designers compare pieces as they work to keep a collection visually unified, which is what we observed both in interviews and in workflow recordings. We built a dedicated multi-garment editing mode that supports up to 15 items in a single view which is basically a technical limit.
The interface adapts automatically. Up to 3 items go side-by-side for active editing (the threshold designers identified as the useful maximum for simultaneous editing), with the primary garment taking most of the canvas when more items are loaded for comparison. All windows can be manually resized.
Switching active working area is a single click on the item's radiobutton. We tested automatic context-switching, but it created errors in user testing. Designers frequently look at one item while editing another, and auto-switch confused intent with attention. We cut it from scope.
Onboarding
Onboarding mattered because a meaningful share of the user base would be designers from outside VF, at corporate buyers, who would never go through formal training on the tool. If they couldn't pick it up quickly on their own, the platform's alignment value collapsed on the buyer side. The onboarding model had to be built to make external designers productive without a training session.
Onboarding is contextual. Tips appear when a user first enters each interface section, guiding them through features at the moment of first encounter. Users can click through and immediately test each feature, which builds both cognitive and muscle memory.
The system is extensible: adding a feature requires only a new onboarding sequence for that section, and existing users who haven't seen it will be shown it automatically. This lets the product expand without onboarding cost ballooning.
Pre-launch user testing measured time-to-working-proficiency at under a day with no additional guidance. Methodology: 20 designers in an uncontrolled test, selected for data truthfulness. (A controlled test had been run earlier in the design process specifically to surface design issues.) Task: create a test design with at least one edit per category (material, color, and graphic) and save it. Average time was self-reported and compared to session recordings.
Working with the Intern
I had one intern designer under me for the full project. We split the work intentionally. I owned the complex core flows, and he owned mobile optimization which was not the core use case, simple developer-handoff edits, and the secondary states (errors, empty, loading) that streamline a build but consume a senior designer's time disproportionately. We worked closely on the mobile version, where I handled the harder layout and interaction problems and he iterated under my guidance.
He attended every user-testing session. Watching real designers use the product was the fastest way for him to build the instincts that turn a junior designer into someone who can see why a layout fails before the user says something. He asked questions throughout, and I made time to answer them. By the end of the project he was producing handoff-ready secondary states without supervision.
User Story: After The Project
ASOS places the same custom shoe order. A senior Vans designer and a teammate split the collection in the editor, comparing pieces in multi-garment view as they work to keep the collection visually coherent. Notes flow inline, and the senior designer mentors the junior in-app rather than over email.
First iteration goes to ASOS as 3D files, no physical sample. ASOS reviews digitally and leaves annotated feedback in place. Designers apply changes within days. After a small number of digital iterations, the design locks. One physical sample is produced for tactile confirmation. It matches. Production begins with budget and timeline still intact.
Outcomes
The platform shipped, first for Vans, then for Timberland and The North Face. Remaining VF brands are being handled by VF's internal team using the foundation we built.
Measured outcomes
Estimated business impact
VF's analytics team measured cost-per-batch impact internally, and the detailed numbers weren't shared with us. Triangulating from the input metrics (fewer physical samples produced and shipped, design cycles cut by half or more, and recovered designer hours), the directional effect is a double-digit-percentage reduction in cost-per-custom-batch and a corresponding increase in throughput per design team. The combination of effects, not any single metric, is where the business case lives.
What I'd want to confirm before claiming more
Two honest caveats. First, I don't have access to VF's internal post-launch numbers, so the business framing above is directional. Second, the platform shipped to Vans first, then Timberland and The North Face, which is a phased rollout rather than a controlled experiment. The pre-launch testing numbers are clean (controlled methodology, documented sample), but post-launch business impact is correlated with our work and not exclusively caused by it. I prefer making that distinction explicit rather than claiming around it.
Qualitative signal
Pilot testing produced executive endorsement, designer feedback that fed directly into final UX adjustments, and the kind of internal pushback that's typical when a workflow shift this large meets long-tenured tooling. Both the feedback and the resistance were incorporated into the personalization model and onboarding before launch.
Learnings and What I'd Do Differently
Experienced designers aren't just used to Illustrator's features, they're organized around its conventions. Respecting that, rather than asking them to start over, was the difference between an approachable tool and one that sits unused. For high-level professionals, efficiency lives in personalization, not simplicity.
Embedding engineering in design from day one paid off most visibly in the graphics-placement decision, where what would normally have come up as a late-stage rebuild became a design problem we solved together. I'd carry that working model into every project that crosses a real-time rendering boundary.
Large enterprise clients have non-linear approval chains. Whole departments may review work before it moves forward. Next time I'd design milestone deliverables to convey decisions through internal chains without me in the room. Information loses fidelity in chains, and design artifacts that don't need a human escort lose less of it.
On research: I underestimated within-group variance. The personalization model held, but the right scoping wasn't by user type, it was by workflow archetype. A wider archetype sweep earlier would have caught the edge cases that became late-stage design constraints.
On craft: the large-property-previews cut was the most useful failure of the project. The discovery insight (designers navigate by visual properties) was correct, but the implementation (large previews) didn't survive real part counts. Holding the principle while killing the implementation is a discipline I'd want to install earlier in future projects, testing the implementation against real workloads, not just representative ones.