The Nordstrom Design Language System (NDLS) is made up of design tokens, components, Figma & code libraries, and documentation. The NDLS is multi-platform (supporting web/React and native iOS & Android) and multi-brand (supporting Nordstrom, Nordstrom Rack, and enterprise applications).
My primary roles and responsibilities have included:
When I joined Nordstrom in 2021, the design systems team had just formed and the company was focused on being ‘omnichannel’ — creating a cohesive experience for customers and employees regardless of where or how they engage with the brand.
There was enough buy-in that a design system could help this objective, but design systems were still a novel concept within the company and the team lacked a tangible vision. We needed to communicate how the system would come to life.
I proposed a system-of-systems approach where all ‘omnichannel’ products would share a common set of visual styles and components, but still have the flexibility to optimize for the unique needs of their specific audiences and platforms.
Aligned to this vision, our v0 roadmap prioritized standing up strong foundations that could be used by all teams regardless of brand, platform, or product: new color & typography systems, design tokens to support theming, and new Sketch component libraries.
I was the design lead responsible for standing up design tokens and defining our approach to brand theming.
Prior to design tokens, there was a hodgepodge of color and typography variables with no consistent owner or naming convention. Other foundations like spacing and shadows had no defined styles at all. Web, iOS, and Android followed separate naming conventions, and they were all different from what designers were using in Sketch/Figma.
I defined a standard naming schema, determining the relevant data and sequencing of a token name. From this schema, we could generate any new token name based on its purpose and intended usage. In partnership with our content designer, I formalized the taxonomy for each part of the token name (e.g., a token “Role” can have a value of “success”, “critical”, “warning”, or “info”).
From this schema, I generated the token names for our initial set of ~200 tokens (aliases & primitives for color and typography). Over three years later, this schema is still in use and has supported the addition of multiple new token types, including shadows/elevation, composite typography tokens, and size/space.
I mapped out a two-tier system of semantic alias tokens which reference a single set of global primitives. Globally-shared primitives provide an underlying sense of cohesion regardless of brand, while the alias layer provides room for differentiation. Our enterprise design system, built on Material UI, is able to import and apply primitives directly to the core theme file.
For a theming MVP, we focused on color, font-family, and border-radius (everything else is the same for both brands). From just this small set applied across components, we’re able to reflect the unique identities of each brand — with room to scale to more drastic differences, sub-brands, or dark/light modes.
The delivery of tokens and theming were aligned to the rebranding of Nordstrom Rack, as a way to drive adoption and immediately demonstrate impact. I provided documentation and support to help in mapping legacy styles to new tokens. In about 4 months, 11+ product teams across web, iOS, and Android adopted tokens with the old branding. When the new brand went live, we pushed an update changing the token values to the new colors & typography, smoothly rebranding the site with next to no additional effort from product squads.
I was the only designer responsible for building, maintaining, and supporting design systems for enterprise tools. This was a small portion of my capacity, and design systems engineering was almost entirely allocated to customer-facing systems, so we leveraged the Material UI (MUI) framework.
Prior to our involvement, enterprise front-ends were a wild west. MUI was the most common framework, but there was no shared theme in the codebase or design tools. Designers mostly relied on copy/pasting to reuse elements from others’ files, often introducing custom styles and components without knowing it. Everything had to be rebuilt from the ground up.
I built all 40+ Figma components from scratch in about 4 weeks. To create maximum parity between design and code, I directly referenced the MUI codebase & component APIs. This ensured designers could trust their comps were more faithful to production code. After shipping the library, we heard from consumers that this regularly led to less guessing or miscommunication between designers and engineers.
Having immersed myself in the MUI codebase when creating the Figma library, I was able to help designers consider the technical feasibility of design options, serve as “translator” between designers and their engineering partners, and occasionally helping engineers with how a design could be built using the MUI components.
Consuming teams included the point-of-sale system, pricing & purchase order tools, and stylist CRM. With my limited capacity, and such a wide range of product use-cases, it was not feasible to create custom guidelines/documentation. Instead, I directly supported teams in documenting their own “local systems” to codify how they utilize and fit MUI to their respective needs.
To support teams, I set up a bug tracking Confluence and Slack channel, supported MUI questions in Office Hours, had 1-on-1s with adopters, and hosted a monthly community meeting for consuming teams to share patterns, learnings, and best practices.
I led the UX organization’s migration from Sketch to Figma, planning the workspace/component library architecture, migrating design system Sketch libraries, and leading general education & training.
I migrated 9 visual style, component, and iconography libraries in 2 months, optimizing for native Figma functionality like autolayout and component properties. To support theming, since this predated Figma Variables, I created separate libraries for each brand theme that were exact mirrors of each other. It meant a bit of duplicated work for the design system team to maintain, but allowed system consumers to easily Library Swap to “theme” their files.
I wrote ‘Figma Usage Standards’ for the design system team, documenting our approach to library architecture and naming, guidelines for component and property definition, and a process for deprecating legacy components.
Very few people on the UX team had any familiarity with Figma. I created a Figma Best Practice hub in Confluence, where I wrote out best practices for file organization & naming and recommendations for importing from Sketch.
Right before the switch-over, I presented in a UX all-hands, covering migrating files, workspace setup, and an overview of design system libraries. For the following few months, I hosted a bi-weekly Figma Office Hours where I walk through a preprepared demo and answered walk-on questions. Topics included auto-layout, plugins, ‘slot’ components, and best practices for content designers.
While I don’t write production code, I often make a quick mockup in Codepen or dig through the codebase to understand how something was implemented. Using code as a design and communication tool has been a huge help in tackling highly technical problems like design tokens.
“I think it’s great that Jeremy has fostered an awareness into engineering concerns - he’s mentioned a few times how API set up, component props, etc. on the engineering side can inform UX library decisions, and this kind of wide-angle view will be helpful as we expand our resources for engineers and designers alike.”
— anonymous 360 peer feedback
“I was very, very impressed by his explorations with Material Grid. Not only did he understand the design of the component, but he also went all-in on reworking it in a code sandbox to match our custom breakpoints. Syncing up with him on the topic showed that he wasn’t afraid of going outside of his comfort zone and learn about + apply concepts that aren’t part of his day to day.”
— anonymous 360 peer feedback
See full case study on Modal Dialog component design.
