Vans Floor Set Design System

Rebuilding a manual merchandising workflow into a scalable design system.

RoleProject Lead, UX Designer
Timeline5 Months
TeamVisual Merchandising
FocusSystems · Training · Optimization
Vans wordmark over Figma artboards of the floor set system under a dark wash
[01]Overview

Vans' visual merchandising team was responsible for creating seasonal floor set documents that guided stores across the country on how to merchandise footwear. The process relied heavily on Adobe InDesign, requiring repetitive updates across multiple store formats, so that even small changes took hours.

As the company transitioned to Figma, the team needed more than a file conversion. They needed a system that mirrored the way they already worked while making updates faster, easier, and more scalable.

I led the design and implementation of an evergreen Figma system that transformed a repetitive production process into a flexible workflow built from reusable components.

[02]The Real Cost of Manual Work

Every seasonal update meant rebuilding layouts across multiple store concepts by hand. The team supported several unique store formats, each requiring its own floor set documentation and merchandising instructions. A single product change could result in hours of repetitive work and introduce opportunities for inconsistency across documents.

The challenge wasn't simply moving files from InDesign into Figma. The challenge was creating a system that could support the team's existing workflow while removing the friction that slowed them down.

Manual Workflow
Store FormatsSeparate docsSeparate documentation
Repetitive UpdatesCascading changesCascading changes
InconsistencyManual copyingManual duplication
[03]Learning the Floor

Before designing anything, I spent nearly two months embedded with the footwear and visual merchandising teams. I observed how floor sets were created, how information moved between teams, and where the process repeatedly broke down. This research phase revealed that the biggest pain points weren't visual. They were operational.

STEP 01

Embed with Teams

2 months observation

STEP 02

Map Current Workflow

Document pain points

STEP 03

Identify Patterns

Operational friction

STEP 04

Define Requirements

System specs

[04]The Process Behind the Process

A few patterns became clear:

·Updating one store format often meant manually updating several others.
·Merchandising decisions were slowed by production work.
·Existing documentation lacked flexibility and scalability.
·The team needed a system that felt familiar enough to adopt quickly.

Most importantly, this wasn't a design file problem. It was a systems problem.

Format Duplication
Production Bottleneck
Inflexible Documentation
Adoption Barrier
Systems Problem
[05]Built for Speed

Rather than recreate the old InDesign structure inside a new tool, I designed toward the patterns this research surfaced. I built an evergreen Figma system that replaced the team's InDesign workflow. Modular wall and fixture components allowed footwear to be added, swapped, or rearranged in minutes instead of rebuilt from scratch. It felt less like learning new software and more like arranging a shelf.

01 / 04

Interactive Merchandising

02 / 04

Footwear Library

Footwear Library
03 / 04

Component Variants

Component Variants
04 / 04

Dynamic Templates

[06]From Static to Scalable

The new system introduced modular wall and fixture components, a centralized footwear library, reusable templates across store formats, and greater consistency across seasonal floor sets. I also facilitated training sessions and led a Figma workshop to help the team transition from InDesign.

Store Format Coverage3→1One template system replacing a separate file for every format
Team Adoption100%Designers transitioned from InDesign to Figma
[07]What I Would Do Differently

Looking back, I would bring the system to the team earlier and in rougher form instead of refining it in isolation before the first workshop. That workshop revealed a few assumptions I had made about the team's workflow. Nothing major, but enough to create rework that could have been avoided through earlier collaboration.

I would also measure how long each task took from day one. I know the system improved efficiency because I watched the team adopt it and rely on it. But I never captured the numbers from before and after, so I can't prove it.

Finally, I would document the component library as it was being built rather than after the fact. The project reinforced something I continue to believe today: the best systems don't ask people to change the way they think. They remove friction and make good work easier to do.