Macys

Consistency People Can Build On

Macy’s operates a vast digital portfolio — website, mobile apps, and tablets — where design and engineering teams had grown independently for years. Cross-functional designers routinely built unique UI elements for each project rather than reusing shared components, so developers ended up coding the same idea multiple ways. That redundancy drove up tech debt, development time and maintenance cost, and it surfaced as visible inconsistency for customers moving across the site.

As Principal UX Designer, I saw the gap between how design and engineering were shipping UI components and took the initiative to fix it — this wasn’t an assigned project. I assembled a small task force of two junior UX designers, identified and contracted an outside Object-Oriented UX (OOUX) consultant, and led the effort to audit Macy’s existing UI components, consolidate them into a governed component library, and get it adopted across the design and development organization.

Impact

~66%

Reduction in required UI components

(approximately 75 audited down to 25 needed)

0 ⇢ 1

1 UI Component Library

(built from zero to one)

50

Fewer components

(to design, build, and maintain)

picture showing examples of OOUX elements, wireframes, and prototypes for Macys.com
Examples of OOUX elements, wireframes, and prototypes for Macys.com.

Context

Macy’s, a leading American department store, operates a large digital portfolio aiming to provide a seamless shopping experience across platforms. As both the design and engineering organizations grew over time, individual teams stayed focused on shipping their own features — and the resulting UI inconsistency and component redundancy developed gradually, without anyone owning it at a cross-team level.

My Role

Principal UX Designer

A dedicated team comprising product managers, UI developers, and UX designers was established to identify tasks, discuss progress, and share achievements.

The Challenge

Cross-functional designers across Macy’s 12-person UX design team often built unique UI elements per project instead of reusing shared components. Developers then had to code each variation, increasing complexity and tech debt, development time, and maintenance cost. Customers experienced the resulting inconsistencies as friction.

The question: how could Macy’s simplify the user experience and reduce development inefficiencies by standardizing UX design elements — without a mandate, and without an assigned owner?

Research and Discovery

I brought in Sophia Prater to train the task force and broader team on Object-Oriented UX (OOUX), a framework grounded in users’ mental models rather than screens or features. Using OOUX, the task force identified Macy’s core user tasks — browsing, researching, and buying — and extracted the underlying objects from those tasks.

In parallel, the task force audited Macy’s existing UI components and found approximately 75 in active use, many redundant. Prioritizing by actual usage, we determined only approximately 25 unique components were genuinely required to cover the same functionality. The task force translated the prioritized objects into UI elements, built prototypes, and tested them — confirming the resulting component set aligned with both customer mental models and developer workflows.

picture showing the object-oriented mapping of Macys.com UX design elements
Object-oriented mapping of Macys.com UI components.

Key Design Decisions

Audit before scoping

Rather than building new components speculatively or applying OOUX purely theoretically, the task force first audited Macy’s existing UI components. That audit — roughly 75 components found, many redundant — became the evidence base for prioritizing which components the library actually needed to include, rather than guessing.

Govern the system, not just build it

The task force defined explicit rules for when to modify or extend an existing component versus create a new one. Without that governance, a consolidated library tends to re-fragment the same way the original component sprawl happened in the first place.

Lead with examples, not a mandate

Rather than mandating adoption top-down, the task force built a small number of example components in partnership with developers first, to demonstrate the system before socializing it to the broader design and developer organization.

Product Experience

This system doesn’t live in a single flow or screen — it shows up across Macy’s entire digital portfolio at once. Rather than walk through one product journey, a few finished components illustrate the library as it actually renders in production, across desktop, tablet, and mobile.

Outcomes

  • Interface audit found approximately 75 existing UI components; approximately 25 unique components were determined necessary — a ~66% reduction in required components, per the task force’s interface audit.
  • Enhanced cross-functional communication: a shared language of UX principles and components reduced assumptions and improved coordination between design, product, and engineering.
  • Easier-than-expected adoption: the component library reduced workload for both designers (fewer components to design from scratch) and developers (fewer components to build and maintain), making it a rare win-win that drove organic adoption.
  • A governance process — rules for when to modify, extend, or create components — gave the task force (and the broader org) a way to maintain the system going forward rather than letting it fragment again.

Design Organization Contribution

Beyond the component library itself, this project produced a governance process: explicit rules for when to modify an existing component versus create a new one, owned by the task force Karl assembled and led. That process gave Macy’s design and developer organization a durable way to maintain consistency going forward, rather than a one-time cleanup that would drift again as teams continued to grow.

Reflection

I’d have raised the oversight question earlier. A system that reduces the workload for designers and developers is a rare win-win. Adoption turned out to be easier than we expected, because it solved a real problem for both teams.

Karl Schultz (Principal UX Designer)

Summary

Seeing a gap nobody owned, I led the effort to audit Macy's fragmented Ul components, train the team on Object-Oriented UX, and build a governed component library - reducing required components by roughly two-thirds while making work easier for both designers and developers.

Related Projects