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.
Though there was buy-in that a design system could help this objective, we needed to communicate our vision for the future and how that would come to life. I was responsible for interviewing & surveying design system consumers and aggregating the results into a prioritized list of pain points and needs.
Informed by this research, 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.
As a team, we built out this vision and roadshowed the deck to UX, engineering, and product leadership, as well as enterprise and customer-facing product squads.
Organizing our v0 roadmap around this system-of-systems vision, we 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”).
I worked with our lead engineer to implement this schema via StyleDictionary, making a few adjustments to ensure token names didn’t “skip” levels or have inconsistent lengths, accounting for the nested nature of the JSON output.
From this schema, I generated the token names for our initial set of ~200 tokens (aliases & primitives for color and typography). Over two 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. Consistent with our system-of-systems strategy, globally-shared primitives provide an underlying sense of cohesion regardless of brand, while the alias layer provides room for differentiation. This allows our enterprise design system, built on Material UI, 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.
We aligned the v1 delivery of tokens and theming with 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. I extensively referenced the MUI component API and open-source code on GitHub to ensure maximum parity between design and code. This ensured designers could trust their comps were more faithful to production code, and as we heard from consumers, leading to less guessing and 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.
Our initial pilot candidate looked great on paper, but after agreeing to pilot with the team, we experienced a lot of friction from their leadership, expecting extensive customizations and high-touch support just for their product.
We attempted to negotiate, but it became clear that we needed a more tangible demonstration of the value of a shared design system before their leadership would be convinced. We pivoted to pilot with two smaller teams that were excited to collaborate and use what we had created.
About a year later, having seen the successes of other adopters, that original team that was resistant to piloting came back to us looking to onboard to the design system and replace their homegrown solution.
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.
