Wayfair: Operational Mapping System
Building a multi-surface design system for a 150,000 sq. ft. flagship launch under real operational constraints
Quick Summary
The Problem: Existing store maps were created ad hoc by an ops employee in Google Slides with no design system, no consistent visual language, and no spatial context — no doors, elevators, entrances, or surrounding department references. Associates had no reliable way to orient themselves or verify placements across a 150,000 sq. ft. space during a time-critical flagship launch.
The Fix: I built a professional mapping system from scratch in Adobe InDesign — character styles, department color mapping, templated layouts, and spatial context landmarks — designed to work across print, web, and Zebra handheld devices. When leadership later required broad accessibility, I migrated the system back to Google Slides while preserving as much of the design system as possible. I also prototyped a mobile app vision at my manager's request as a future pitch to leadership.
The Result: A standardized mapping system covering 28 maps and 26 departments, adopted as the primary navigation and execution tool by hundreds of employees before and after the grand opening of Wayfair's first retail flagship in Chicago.
Role: Senior UX & Systems Designer
Tools: Adobe InDesign, Google Slides, Figma
Timeline: 6 months
Context: Physical retail, live store environment
Research: Learning How the Store Actually Worked
Before designing anything, I spent time on the floor observing how associates actually moved through the space during real operational tasks. What I found wasn't a map problem — it was a mental model problem.
Every existing map faced a different direction. Associates would pick one up, scan it, then spend several seconds physically rotating it to match their position in the store. During a high-pressure launch with hundreds of placements to execute, those seconds added up to real errors and real delays.
That single observation became the design foundation for everything that followed: every map in the new system would be locked to the perspective of someone walking in from the main entrance — the way associates actually entered and moved through the space.
Phase 1: Shipping what works (Google Slides)
With no engineering bandwidth before launch, I needed a system that could be deployed immediately and updated by non‑technical teams. Instead of waiting, I built a scalable mapping system using Google Slides.
I overhauled the maps to include landmark context like surrounding departments. To make the maps scalable, I established three core system rules:
Department Locator Keys: A mini-map on every slide to show exactly where the associate was standing in relation to the rest of the store.
Predefined Color Styles: A consistent, accessible color language designed to work for both screen and print, ensuring sufficient contrast while supporting rapid, error‑safe updates as the layout changed.
Standardized Labeling: Clear, uniform naming conventions across the entire store to ensure every team was speaking the same language.
Together, these rules made the system fast to update, easy to understand, and reliable under constant change.
Most importantly, I locked the visual orientation of every map to match the exact perspective an associate has when walking in from the main entrance. Observing teams in the physical store revealed how often they lost time reorienting themselves because each map faced a different direction. By grounding the digital tool in their real‑world point of view, we eliminated that friction and dramatically improved wayfinding accuracy under pressure.
Prototype demonstrating live inventory integration and scalable layout behavior
Phase 2: Building the Future Vision
Once the immediate system was stable, my manager asked me to draft a mobile app concept to pitch to leadership — a vision for what a native tool could unlock beyond static maps.
The design decisions came directly from what I'd observed on the floor. Associates were constantly cross-referencing between the map and a separate inventory document to verify what belonged in each zone. That two-document workflow was the friction point. So the prototype collapsed it into one: tapping a zone surfaces live inventory for that exact location, with color-coded status badges showing stock levels at a glance.
The goal wasn't to build something polished. It was to make the operational case concrete enough for leadership to understand what a connected tool would actually change about how the team works. The prototype did that — it shifted the conversation from "how do we maintain better maps" to "how do we build a connected operational system."
Designing for Real-World Data & Handoff
To make this system scalable beyond static maps, I designed the interface to behave predictably under real data conditions and support clean engineering handoff.
To make this system scale to 150,000 square feet, the UI had to be modular. I built the interface using structured layout rules so that variable data like product names, quantities, and statuses could scale without breaking the UI. This made it easier for engineering to map real inventory data into the system without introducing inconsistencies.
Outcome & Impact
By the end of the project, the standardized mapping system supported a massive and complex retail environment. By focusing on how the store team actually worked rather than just making a pretty map, we established a primary navigation and execution system for the grand opening.
28 maps
Each representing a unique layout with operational dependencies.26 departments
managed through a consistent visual language.1,200+ individual placements
verified and executed.Scaled adoption
Established as the primary tool used by hundreds of employees pre and post-launch.
What started as a stopgap solution became the foundation for how the team navigates and executes in-store. By designing for the real environment, not just the interface, the system scaled beyond launch and into ongoing operations. Most importantly, associates no longer had to stop and orient themselves. The tool matched how they moved through the store, allowing them to focus on execution instead of navigation.
What I'd Do Differently
The biggest constraint on this project wasn't design — it was tool access and time. Building the system in InDesign first, then migrating it back to Google Slides under launch pressure, meant some of the design system's fidelity got lost in translation. If I were starting today, I'd push earlier for alignment on the final delivery format before investing in a tool that leadership would later require us to move away from.
I'd also formalize the research phase earlier. The on-site observations I made were valuable, but they happened organically rather than as a structured process. A brief structured research sprint at the start — even just a few hours of shadowing associates — would have surfaced the spatial context gaps faster and given me a clearer brief to design against from day one.
That said, shipping a system that held up under real operational pressure, across multiple surfaces, during a live flagship launch, is something I'm proud of. The maps worked when it mattered.
Next Project
The Sales Success Map
How a light design task became a self-directed information architecture overhaul that changed how a global sales team works.