Brand imagery & color swatches: lessons from building for e-comm, with Maya Hampton

Maya draws on her experience as a design systems PM at both REI and lululemon to explore what makes ecommerce design systems distinct. From the component library decisions to supporting editorial flexibility and brand storytelling, this episode digs into the real differences between ecommerce systems and other product contexts — and what's driving non-tech companies to invest in designs systems now.

Resources & Links

• Maya Hampton on LinkedIn
• Maya's writing on Medium
• Driving design system adoption
• REI Cedar system

Transcript

Maya 0:00

At Lululemon, we have a mandate to adopt the design system. I thought that would make my job a lot easier as a PM, right? Because that's what we're accountable for. But I think what was surprising is that in some ways it's actually made it harder. The scope is different, e-commerce exists in a larger ecosystem for brand. That includes store design, package design, hang tags, as well as other digital marketing channels that would benefit from the same brand layers. So there's coordination between the online experience, the in-store experience. We're working within a larger ecosystem. Digital is an organization. It is not the entire product. Like a SaaS company, everything is within that tech space. But in digital, we're also working with retail teams. We're working with those physical product design teams. The playbook looks different. We're building the product tile and the product color swatches, and we really need to partner with the PMs on those teams to understand, what needs to click through? Are we gonna totally break conversion rates if you suddenly can't click through on a color swatch? If you choose a color in a product and then you click through the product page, it should show the product with that color already selected, right? What needs to carry through? What's important? As the design system we can help elevate those patterns that are working, but then I think my principle is like, let the teams experiment with the stuff in their space that's really unique to their space'cause they know it best.

Elyse 1:20

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. Let's dive into the show. Today's guest is Maya Hampton. Maya is a Senior Product Manager specializing in design systems, and currently leading Lululemon's design system. She previously spent seven years scaling REI's Cedar system across the enterprise. She writes about the PM side of design systems at medium.com/@himaya. Maya, thanks for joining me on the podcast.

Maya 2:03

Yeah. Thanks so much having me, Elyse. Yeah!

Elyse 2:06

I'm really glad to have you on the show because we're gonna get into a topic that I feel like doesn't get a ton of airtime in design systems land, which is e-commerce. And you've now worked on design systems at two major retail brands, like really well-known names, REI and Lululemon. So I'm really looking forward to hearing what's the same and what's different at e-comm versus SaaS, because I feel like all the design system conversation is about how it works in SaaS companies. So really excited to hear what you've learned.

Maya 2:35

Yeah, agree. I feel like the e-commerce and even the PM side of things is often not heard as much, so glad to share a little more of that perspective.

Elyse 2:43

I briefly held a design systems PM title. Maybe we should talk about that too. I feel like it's a little bit rare.

Maya 2:51

It is, yeah. There's a level of maturity or maybe scale that I think necessitates having a PM. I'm obviously gonna advocate for it a lot of the time, but yeah, the more that you have to coordinate with other teams and have a roadmap to manage, the more value it can be, definitely, to have a PM spearheading that versus squeezing it into a designer engineering kind of part-time roles. The more we can support people to do what they do best, I think the, the PM can really come into play for sure.

Elyse 3:16

So I wanna start with your current experience. You just moved to Lululemon from REI recently, right? Like this past year? So you were at REI for a really long time, seven years. That means you've seen a ton of change just in design systems in general, how we do them, what the technology is like. What do you feel like has changed over the time that you were at REI?

Maya 3:43

I mean, it's a good question.'cause there's definitely tooling. I mean, when we started out like moving to Sketch and then moving to Figma, right? There's like some big transitions like that we always used Vue. So at least that was consistent from the engineering side. So definitely the tooling change. I think that goes with the territory. I think the bigger shift is just the— you know, seven, eight years ago design systems were relatively new, emerging. There was a lot of like, education— what are design systems, why should I use them? And a lot more that explaining. And, and now it's become a lot more standard. And so there's a lot more expectations even to have them. In that amount of time you go through the different maturity phases of a design system as well. And reorgs, and all the other things that affect the role of the design system and the broader product teams that we ultimately enable, yeah.

Elyse 4:28

What has surprised you most from the shift, from, you know, seeing REI's system over many, many years, to moving to Lululemon. What is Lulu doing with their system and what, like, what surprised you?

Maya 4:45

Yeah, so Lulu, it's kind of an exciting time because we're building a new global design system. So getting to start fresh, you know, there has been a few iterations of design systems before, but as design systems practitioners, it's always fun to be able to dive in and build from scratch. Especially to your point, like things have changed so much in the last 5, 7, 8 years that, you know, not having to just refactor and add things on, but really get a fresh start and be intentional with everything that we've learned to this point. So it's exciting time, you know, really looking at that global scale as well. That's a big part of a global redesign that Lululemon is undergoing right now to bring, not only the visual brand refresh, but also converging a lot of the platforms underlying those into to more of a shared global platform. So it's really exciting to be a piece of that and really help drive that work forward. One thing I will say that that kind of surprised me is, you know, at Lululemon, we have a mandate to adopt the design system. I thought that would make my job a lot easier as a PM, right? Because that's what we're accountable for. But I think what was surprising is that in some ways it's actually made it harder. At REI, we didn't have the mandate, and I think part of that, you know, goes back to the seven, eight years ago things were still emerging, it wasn't this expectation yet. So we did a lot of training and education, a lot of roadshows, talking to different stakeholders and teams, you know, really leaned on building an ambassador program, leveraging some of our early adopters to help advocate within their teams to adopt the system and promote the value. And all that to say that we spent a lot of time really building those relationships and earning that adoption, so teams like genuinely wanted to use it, and it was more, more grassroots. At Lulu just kind of jumping in with a mandate, we've missed some of that opportunity to get those relationships started. And it's more of just like, Hey, everybody's got timelines and now we're just a dependency showing up on different roadmaps. And so, we're certainly driving those conversations now. But it feels a little bit backwards in the sense of like, okay, now we're having to restate why we're building the design system, why it's a dependency, like how we're partnering, and shifting that mindset from, you know, we're not just a dependency out there for your teams, but we're really a partner and we wanna help enable you and help enable this global rollout.

Elyse 6:55

That's so funny because you hear so much from design system practitioners just like, oh, I wish somebody high up would just say, you have to do this, and then we would never have any hard conversations and everybody would be happy and wanna use the system and it would just be so seamless. So it's really interesting to hear a first person experience about what actually you miss when you have that mandate. Because, if a team, the only thing they know about you and the system is, my boss that I had to, and I have a deadline, like, what, what's in it for me?

Maya 7:33

Yeah, exactly. And yeah, I've totally been on the other side of it. Like, oh, I wish this would just, you know, I didn't have to go, you know do those road shows, do all those one-on-ones. But like, you know, at the end of the day, the design system is serving all these product teams. And again, going to the role of the, the PM on the team is really helping to bridge those gaps across different functions, right, design, engineering, making sure product also understands why it's worth putting this on the roadmap. Like maybe you're refactoring to get something that look exactly the same, but it's gonna save you a lot of time in the future, right? Or it's gonna have a lot more accessibility, brand compliance, baked in. We're solving some of that. So there's a number of those conversations and different value prop that you can go after. So yeah, it's just kind of like, when do you have those conversations? And you know, it's kind of nice when you do get the chance to get ahead of it. Although, yeah, to that point, we certainly have the space for it now. It just feels a little more time crunched, right?'cause it's more about like, is it ready yet?

Elyse 8:25

Yeah. So, So what have you found that's the same between REI and Lulu? And we'll talk a little bit more about the difference between SaaS design systems and e-comm design systems, but just even within those two companies, your design system work, what has been the same?

Maya 8:43

Certainly the scope of e-commerce is pretty well defined right? We have the core shopping funnel. You have your upper funnel experiences. You have your lower funnel experiences. The way that teams are structured and set up is very familiar across these different organizations. At the design system level, and I think this is, you know, regardless of the scale of the design system and the teams we support, and probably, you know, even e-commerce versus SaaS products, there's always gonna be that tension between, how flexible are we going, how many guardrails are we building, how heavy do we push on governance, versus how much do we just enable teams and see what emerges from that. I think it's healthy to have that tension and, but you know, it's certainly something that comes up again and again. And, you know, trying to prioritize, right, which decision feels right, what's applicable there? That's definitely the same across both of these orgs. I think in e-commerce, what else is the same as we have that dual pressure where we're working to enable our product teams that are working on those core experiences, making sure they have really durable, stable, accessible UI elements so that they can, you know, not have to reinvent buttons for every new screen or experience. But in addition to that, we're also working to support the brand storytelling aspect and campaigns that are more expressive and have very different needs than a functional button or quantity counter, or more of those standard UI elements. So, we're trying to be in a position where we can support both of those. And I don't know that, like in SaaS companies, there's as much of a focus on those kind of ephemeral campaign moments, somehow built from those like same durable design system parts as well.

Elyse 10:17

I really wanna dive into this because I think this is a thing that SaaS systems just really haven't had to think about or deal with. In my predictions and predictions recap episode earlier this year with Noelle, she was talking about how design systems are really going to enable brand moments in product. When you're coming from the SaaS side, that's actually a place that the design system really hasn't supported very much. You know, if you're building straightforward UIs— I mean, every company's got their own things that make them a special snowflake— but if you're building, you know, forms, sign in, dashboard, like all these things. On the SaaS side, there's all kinds of places where you might need a brand moment, hero moment, tie-ins. We see this a lot like going from the customer landing page of a campaign into the product. But mostly we've just sort of left that out of the system and we've been like, okay, just do a one-off design or like, that's the marketing team. But I know this has been a growing thing. Chris at Knapsack has been talking about this a lot, that the design system is a way to support brand design all the way through the product. And e-commerce, I think is actually really ahead of SaaS design systems in this way, because e-commerce really has to carry a lot of editorial. You do product storytelling like on the actual product page, or you have to tie a campaign all the way through. You have a discount code that's on the homepage that has to also like carry through to the cart. How do you think about supporting that flexibility in the design system? I mean, how do you, how do you think about that from the lens of the system, but also at a code or Figma kind of way, like literally what's in the system and what's not?

Maya 12:08

Yeah, it's really tricky. I won't claim that we've totally nailed it or anything. It, it goes back to that same tension, right? Like, how much are we flexible with these patterns? Where are we consistent, right? Like, what we hear from brand teams, marketing teams, they wanna try something new and different, like that's the goal of the campaign. And so they're justifying having that bespoke solution. So how do we work within some defined constraints to enable that? I think within the design system, you know, from that PM lens, the first thing is really recognizing that they're, they're a different user type, right? I see design systems really as products, platforms for designers and engineers primarily to be using. Once we introduce a different user type, like a business user, somebody that's maybe adding content through the CMS, maybe somebody that's working through marketing channel, they're gonna have different needs. They're not confident to be building, you know, new components from tokens. They don't want to make design decisions about corner radius and shadows. Like they're worried they're gonna break something there. So part of it is really understanding that different user type and what they need that's different than, you know, a designer or engineer that's gonna be a lot closer and more comfortable with making some of those more detailed design decisions. At REI, what we did in this vein is really recognizing that leverage point of the content management system to help create almost a additional component library. What I think we were trying to get towards that system of systems concept as well, like, are there a set of these more heavy imagery focused big brand storytelling moments, text heavy components that we can put into a separate library where a lot of, again, those design decisions are constrained. If we can tie them into the content management system, have some content modeling set up so it's really giving those editors a chance to focus more on the content. And that was the initial principles. Like, okay, we'll make these kind of containers, right? And really, you know, standard brand textiles and then focus on them to like bring in the big imagery. We have really great photography at Lululemon as well. They spend a lot of time getting these really, really beautiful campaign photography, right? So we wanna let the content shine. We don't wanna have all these design inconsistencies or this and that, that gets in the way of that. So the first approach is like, what can we get away with? If we're saying we really wanna let you focus on the content, we're gonna make some very simple containers. Maybe there's a CTA box, maybe there's a couple different layout options, if you want it side by side, or if you want a two up, or a three up, or one up. Like just some basic layouts. And then under the hood, in the design system, at REI, we built a very fluid container system. So it could adapt into real time and support more of the drag and drop UI for the, for the CMS user. Again, that different user type. It really depends on what tech you're using on the content side to get to that. All that to say, try to build in some of those guardrails to a set of components. See where they push from there. But I think the other heart of it is, some things are just bespoke, and they really, you know, justify that additional time it takes to build things as a one-off and live outside the system. Especially if we know it's just like an ephemeral moment. It's a once a year campaign. Is there a need to store this anywhere for reuse? The team at REI, I will say also did a great job building basic templates for like big campaign moments and those more storytelling pages where, hey, we have, your basic template here where you can plug in these different components and content, you know, and then a couple times a year maybe we can do these bespoke campaigns. Those brand marketing teams, they don't have engineering resources, they don't have product design resources so, they wanna really be intentional about where things are bespoke and are justified in spending a little of that extra time, which is super crucial for brand storytelling.

Elyse 15:45

I am realizing as you're talking through all of this, that in e-comm, your CMS and your product are probably together. Which maybe sounds like a really obvious thing, but in the world of SaaS, your marketing site is usually entirely different. It's entirely different repo, entirely different CMS, it's completely disconnected from the product. And you don't have engineering resources, maybe you had an agency build it. You know, maybe you even have the agency do updates on it. And so there's been this longstanding wisdom, I guess, on the SaaS side of the design system world that you actually don't want your marketing site to use your same design system. And in a lot of cases, I think that that makes sense because if you are building, say, a really data heavy dashboard product, components that you need and the things that you need to support are very different than what you need to support on the marketing site. You know, I've got tables and I've got all these like filtering components, but just the, the typography stack is different, in an editorial or marketing environment than it is in a data dashboard. Maybe I'm just like having a obvious moment here, but like in e-comm, that's just not the case.

Maya 16:59

Especially for like the campaign side of things, right? And even if we are creating a new pages, you know, that's generated from the CMS a lot of times. There's certainly a lot of other integrations, you know, for just like product data and all the other information that comes through into to the e-commerce realm. But yeah, I think that is a key difference. And I don't work on the SaaS side of things, so I don't see it that way. But certainly in the e-commerce space, they do start to converge more.

Elyse 17:24

Yeah, and I'm wondering if we will see actually more of that convergence in the future for SaaS. Just because there are often many cases, not all, but many cases where you actually do have more of a through line from your marketing site to your actual product. And often those can feel very disconnected and I think they're disconnected because often they are technologically disconnected. It's actually very challenging sometimes to put those together. You've got two totally different tech stacks and very little overlap in needs. So I'm wondering if there are some things that we can learn from e-comm around how to put those together. I think it would be really cool to get into the weeds of how those actually work sometime. This needs to be a video podcast and show me behind the scenes of your stuff. But that's super interesting.

Maya 18:15

It is really interesting. And I remember at REI, when we were trying to crack it, we're like looking for examples. And I think the other thing about e-commerce, and maybe why we don't hear about as much, is they're not as public, right? And especially if you start to build in like specific business logic, or specific like, here's how our CMS works, maybe you're not comfortable sharing that as publicly. And so it's harder to find those reference points of yeah, like how, how does this work? How are their team solving this? We know they're doing it, but it's not on a public doc site somewhere. So like, yeah, how do we get that insider scoop and, and try to understand. And so, you know, back to that point about what's the same across orgs, it's been interesting to see how both, you know, Lululemon and REI are tackling this in the same way, but also in different ways. Like at REI, we were very conscious of like, does it make sense to add this scope to the design system. At Lululemon, it's like, of course we're adding the scope to the design system. So sometimes those decisions are already maybe established or part of like a bigger expectation around things.

Elyse 19:10

So actually let's get into it a little bit. What kinds of UI problems are you actually solving? And what does that mean for your component library? Like what are some things that e-commerce needs that a SaaS system doesn't? We talked about brand moments, but what are some actual components or elements or needs that you have to think about and build into your system.

Maya 19:33

Yeah. There's definitely some overlap, right? And I think back to upper funnel and lower funnel a lot, because that's where I see a lot of distinction within e-commerce, right? Like upper funnel, that's typically, your homepage maybe campaign pages, searching, maybe product details. Users are shopping, they're trying to learn about something, they're looking to filter down their options by categories, compare products. And so, we have a lot of those, you know, big hero moments, but also a lot of cards and tiles that really help you navigate further into those categories or promote and recommend specific products. You see that a lot, upper funnel, big images, definitely focus on the products themselves. At REI, support a lot of different brands, so you're featuring different brands and campaigns as well. You start to go into search, it's more of that grid view, a lot of filtering options as well. Radio, checkbox, product tiles are probably the workhorse of a design system within the e-commerce space, because there's different points throughout the flow that you wanna be able to click through to a product page. Or in the post-purchase space, to click back through and see what you actually did purchase. So definitely a lot of focus on product tiles, product cards, imagery, functionality that goes with them, right? Like color swatches—

Elyse 20:41

Yeah, I'm thinking about the like pick the color. Yeah. That's something I've never had to build.

Maya 20:47

Yeah, so, but it's like one of our first components in the new Lulu system, is like, the color swatches, how are we gonna do this? What is the hover state for those images? So you kind of see somebody from the front, from the back, different images. And I think there's a lot of customer feedback that goes in, right? Like when you're shopping online, you wanna see as much as you can about the product. We wanna see more video as well, I think that's definitely a trend where a lot of video of those product details and what it looks like.

Elyse 21:11

Maybe this is not so true with leggings, but as somebody who does not fit into a lot of standard clothes, give me actual measurements! Sorry. Totally personal rant. That drives me crazy.

Maya 21:22

No, yeah, I'm a short person too, so I'm always looking for the inseam length, like I, that's crucial information.

Elyse 21:27

Tell me, I know you know it. You made the clothes. I know you've got a pattern somewhere where it literally says.

Maya 21:32

I will say, I think that's easier for somewhere like Lululemon, that we're building all the products in-house. At REI, w e're curating products from a lot of different brands. So the information that you get is super inconsistent, which is a whole other kind of challenge—

Elyse 21:44

Yes, I know.—how

Maya 21:45

to, how to square all that away. So upper funnel, right? It's a lot of product discovery, help me make a decision, help me understand what's in this category, maybe compare different products, features, specs, and all of that. Lower funnel is maybe more like SaaS, right? It's a lot more like checkout forms and flows. We wanna make sure you know what you've selected, wanna make sure you are able to easily get all your information in there, and so that's where I think we see a lot of those more functional form elements, text fields, validation, all those types of

Elyse 22:11

Account settings, update my address.

Maya 22:13

Yeah, exactly. Manage your history, manage your profile, see what you've purchased in the past as well. Um, Lululemon has like great support for things that you've purchased, and so there's you know, a lot of things that you can layer into that. The other thing that I do think in the e-commerce space, there's more of the animation and motion, right? So more of these like micro animations, you know, how imagery behaves. As part of this redesign for Lululemon, that's actually a very big focus of it, is how can we bring motion in? How can we make certain things stand out in a different way? It's core to the Lululemon brand and the values around movement itself. So it's neat to see how they've worked that in. My assumption is, yeah, like on the SaaS tools, you don't want all those extra bells and whistles, like you're just trying to get your job done, you're trying to work through a flow. It's less impactful to have like a really robust animation system around some things.

Elyse 23:03

I'm sure that some companies do, but, the micro interaction animations are very micro. Maybe you'll have a little animation in a dropdown or maybe in an interstitial page, but certainly not as deeply baked in. The other thing that you're making me think about is just how heavily page layout is important, on e-comm, in a way that a lot of times in SaaS we provide these smaller components. And when we talk about patterns in design systems, we're often thinking, not even about page layout, but about here's how a form goes together, here's the spacing of the form. For e-comm, for like the product details page, the ability to show there's some images here and you're scrolling through them, and then we're gonna also show these larger images down here, and we're mixing in, you know, like an editorial shot, like farther down the page. I mean, there's just all kinds of actual page layout things that tie much more closely into content. Is that coming from the system or is that coming from the CMS or some combination? Like the page layout.

Maya 24:10

Yeah, to some degree from the system. In fact, we were just talking about like, oh, we need to remove some padding from these components, like what's the kind of spacing between these elements on a page, right? I think a lot of that's handled at the page level, you know, in e-commerce, or at least in, in the two places that I've worked, you know, teams are very much siloed by like, we have a team that owns the product details page, and this team owns the search experience, and other teams owns the homepage. So they, they really understand what users are looking for when they come to those pages, and like do a lot of testing and experimentation. Like if we put some, you know, recommendations here, is that gonna help people compare products? Are they looking for the more detailed information when they're at the top of the page? Those types of things. So from the design system, certainly trying to build in the flexibility for them to arrange those page layouts and compose. Especially thinking about some of like the homepage and campaign page templates, I think that also drives a lot of the variance that we see in components. You know, I talked about cards and tiles, but there's the layouts of those, right? Like, do you have a, a four up row with some padding around it, and then a six up row that's a carousel? And like, at some point you don't wanna just have like rows of tiles, so there needs to be some visual difference. And so on the design system, we wanna make sure that we're building those flexible layout options so that as you're scrolling through a page there's some reason and rhythm to it, right? It's not just like a grid of tiles. So I think that definitely drives some of those design system level decisions for that scrolling down the page experience. We're bringing some parallax in and trying to be very delicate about it.'cause I feel like that had its moment a while ago. But, you know, there's ways we can bring it back in, in a way that adds that movement back to the page.

Elyse 25:45

Yeah.

Maya 25:46

and kind of supports that more like browse discovery experience

Elyse 25:49

Yeah, well you were talking about the teams, you know, this team owns the product page and obviously in e-comm, I mean, definitely in SaaS you instrument clicks, behavior, you wanna understand how your users and customers are using your software. But that is so critical in e-comm. Like, the team that owns the product details page knows a ton about how people are using the product details page. Given that you're in a PM role, how is that information coming back to you, to the design system? What information is relevant? Like what user behavior information is relevant, and how does that affect what components you provide? Like, it's a six up carousel, oh, we hate the carousel, nobody scrolls the carousel, let's not have the carousel. Anything like that.

Maya 26:37

I mean, I think it's a great pipeline for us to keep the system fresh and know like what those needs are within like a product tile for example. So at Lululemon we're building the product tile and the product carousels, we're building a lot of different variants. And then, you know, I mentioned some of the color swatches and hover states. And so we really need to partner with the PMs and product folks on those teams to understand like, what needs to click through? Are we gonna totally break conversion rates if you suddenly can't click through on a color swatch? If you choose a color in a product and then you click through the product page, it should show the product with that color already selected, right? What needs to carry through? What's important? What's the level of metadata? So we made like a lot of different variants of the metadata, depending where it shows up. If it's the recommendation on a page, here's some products that you looked at, it'll show you the specific product, the SKU, the color maybe that you looked at. If it's somewhere on the homepage and it's more of a catchall, you're gonna have more options within it. So it just goes back to the flexibility and variability. Like, what can we build in as an option? And then as teams work through it, see what works, what do we then provide as like, hey, here's the recommendation for this, or here's the best practice that we've seen from this other team. There's been tests about like, should the product name be bolded, or should the brand name be bolded, or should it be the price be bolded. And like we did an audit at REI and it was like across the entire flow, it was inconsistent in every product card, right? But each team also did their own testing. So there's a balance again, I'm starting to feel like a broken record, but like there's a balance, like what's gonna work for this use case? What's worth promoting as a pattern. As the design system we can help elevate those patterns that are working, or even like, hey, we just saw this other team testing something very similar, maybe you haven't talked to them. Maybe we can connect some of that there as well. So I think we can help be the bridge. But then I think my principle is like, let the teams, experiment with the stuff in their space that's really unique to their space and their domain,'cause they know it best.

Elyse 28:29

Yeah. Yeah, that's so interesting because I think the common wisdom is like, okay, you provide a couple variants, but you want it to be the same everywhere. And I think what I'm hearing you say is that across e-comm, you actually have some information perhaps about, yeah, we need the brand name to be bolded, or the price to be bold, because that actually drives conversion right here. In a way that, in SaaS we're just sort of like, use the same component so that it's consistent. Like you just have a whole nother layer of information that we just don't ever really get.

Maya 29:04

I don't know who to credit this to, but I think of it more as like cohesiveness over consistency, like as long as we're using the same type styles, the same weight, the same shadows, the same colors, we can enable some of those variations within that space without them having to be like exact copy paste, right? We can carry that brand consistency forward, but still feel cohesive and give teams enough room to differentiate where it makes sense.

Elyse 29:28

Yeah, so I wanna actually talk about— we said we would— I wanna talk about what it's like to be a design system PM. Taking in that kind of information from teams— not just, hey, this component doesn't work for me as an engineer, or, as a designer, I wish that I had more variations on this— but actually taking in usage data, conversion data you know, priorities that different teams have. What kinds of things do you take on as a product manager and how do you work with your product teams, your design and engineering teams to communicate to them, to do that, stakeholder management, the road shows, things like that, and what, information do you take in and take back to your design system team?

Maya 30:11

Yeah, great question. So design systems, we work across a lot of different teams and orgs. So I think just even the stakeholder expectation requirement aspect of it is pretty huge. There's a lot of coordination. You're launching a redesign, you wanna make sure that like, we're not totally like breaking the experience, because you know, the homepage team is rolling out the changes at a different time for the PDP. So there's definitely moments where there's like very high level of coordination needed. There's also adoption, right? Like we have initial adoption, but we always have new releases, there's always updates. So there's always this ongoing adoption track as well. I think having a PM on the team can certainly help, you know, put together roadmaps and priorities. I think where I've been able hopefully to add value is by being exposed more to other product roadmaps and what's on their radars. And so if we see, six months this team is wanting to test a new feature it gives us a chance to, to try to get ahead of that. I think a trap, a lot of design systems get stuck in is we're always reacting. Somebody wants something right now, and like, it's gonna take us longer than right now to get that out to you. And so the more we can get ahead and be proactive and try to build those relationships with teams, like, oh, you wanna test this, that's great. You should use our components. Or you could build from tokens and building blocks to do that. We can work with you to socialize that back to other team if it works well. But building those partnerships at a product level, I think can help to make sure the design system is used. And also the education layer, you know, maybe we're assuming by now that designers and engineers understand the inherent value of the design system, and not repeating things over and over. But often there'll be stakeholders that want something bespoke and they may not really understand the cost, right, the long-term cost of like, okay, great, you can build this, but you're not gonna take additional time to build it. You're gonna be on the hook to maintain it. You're gonna have to do testing for accessibility, like you're accountable for a lot more things. I think there's an opportunity to speak some of that language, zooming out like, why this matters, how our roadmaps are aligning with your roadmaps. You know, you mentioned some of the reporting and usage data as well. And I think there's a lot of opportunity to track what's being used, what components are being used the most frequently. At REI, we used Vue for our platform and we did a whole big upgrade to Vue3, right? Which took a good chunk of time to migrate all of our components to the latest version of Vue. And, looking at the usage data helped us prioritize the order to go after those. Like, okay, modals gonna be a pretty big lift, also, we have like two teams using modal, so doesn't need to go first. But something like links and buttons right, obviously are gonna be used more often. So it's good to have a chance to, to look at the data, help make priority decisions, et cetera, for the team. I've worked with really strong design and engineering leads. And sometimes you just need a tiebreaker, right? Like we could go on and on all day. The PM in the room can help like, okay, but we need to make a decision, which is the best one to move forward with, what's easier to walk back or not. But bringing that lens as well, because passionate design system people will just debate things endlessly. And at some point you kind of need to call the stop or be the tie breaker as well. So I think there's an opportunity to help guide the team. And then yeah, connect it back to the larger business goals as well, so we're constantly staying relevant and we're something that teams want to use, and like, know that we're having updates and like are looking forward to changes. Rather than, that state we mentioned earlier of just being a dependency on a roadmap.

Elyse 33:30

Yeah, I feel like the imagined value from every design system practitioner who's never had a design system PM is like, I wish I had a PM so that they could talk to other teams in the business about how important and special we are and how great it is to use the design system. But that was my experience as well, that as a design system PM, I was really going out to teams and understanding what teams were doing, and doing education and stakeholder management. But that is a whole job. It is very challenging. And as you get to a certain scale, the differences between those teams are so great, that you're managing a lot of very, very different stakeholder needs. I'm thinking about at Indeed where we had the consumer facing indeed.com, but then we also had an entire other product that was for small to medium businesses, and we had a whole nother product that was for giant enterprises. And it wasn't just indeed.com, it was like five different things, and they all had their different focus areas and different technical requirements. And so actually, it was doing more selling almost than it was, being like, hey execs, the design system is so cool and valuable and important.

Maya 34:40

Yeah. And I think the bigger scale you're at, there's gonna be more PM roles at like a bigger enterprise, than a smaller system, just naturally. But yeah, it is a lot of that stakeholder management, communication, really clear roadmaps as well. You know, I love to be able to let the team focus on doing the work and making the decisions at like that, what's the best way to, architect this component, you know, and not having to be worried about like, when did we tell this team this thing was gonna be delivered by? You know, why is somebody asking for this reporting data? So it's a lot of just that, you know, typical PM stuff. And then I think what's really neat about being a PM for design system is again, our users are like—

Elyse 35:15

Right there!

Maya 35:16

Right? Designers and engineers, it's easy to go talk to them. It's super gratifying to be like, see, does something get unlocked right away? And get that instant feedback. And so we're super close to our users and can pull insights from them back to the team as well and even bridge across functions.

Elyse 35:31

Nice. So you mentioned earlier that you are working at Lululemon on a new system, a new global redesign. But REI, you, I think, had a longstanding system, a mature system. Can you talk a little bit about some of the things that you've learned or the things that are different between your experiences at REI and Lululemon, purely from the fact that you were in a different phase of the design system lifecycle, if you will, than you are at Lulu now. What are some different pressures, different focus areas, given those different phases?

Maya 36:11

I mean, I will say, we didn't start with a mature system at REI, right? I joined at a time when we had like trying to get ready for an MVP. So we did a lot of that work to get to adoption. I think being there for so long, we saw those different phases, right? Like we're in build, build, build phase. We're in driving adoption phase. We're in enabling big redesign phase. And then it kinda gets to the point of like, okay, well now, now what do we do? Do we build bigger components? Like do we go do some other work stream as well? I think with REI, you know, when we hit maturity, it also coincided with that 2020, 2021 timeframe, where we also started to get hit with reorgs, our team size got smaller, a lot of the product teams we supported, their teams got smaller. So there was the larger economic changes around our work that changed what we did. And, you know, at the role level, as a PM I was wearing a lot more hats. I was doing all the stuff we talked about, but then also like sprint planning, and leading backlog grooming, and all those daily standup ceremonies, right? And continuing to sell the value. I think that's another thing with mature systems is, you know, even after 5, 6, 7 years, you go through reorgs, you get new leaderships. One challenge we saw was like, now we have new leaders that weren't here for the before time, so they don't understand like how far we've come.

Elyse 37:24

It's done, right?

Maya 37:25

right? It's like, oh, this is how it is, and I came from, you know, X tech company where that was the standard as well. And so they start to bring in new expectations. So it becomes a different challenge of like, okay, we're retelling the story, we're reshaping the narrative. Maybe we need to be reporting on things differently to better show that story. So you're constantly learning your new stakeholders and trying to understand that. There was, I think, a lot of evolutions within that timeframe to get to that more mature system. At Lululemon, it's definitely a larger scale, right? So I mentioned it's a global org and we're really working to make the design system support globally, whereas previously it was focused on the North American markets. So there's a lot more teams to manage. We're working on things like localization, different type style, like all the fun that comes with global as well. Different regional needs. But there's also, the organization's a little bit bigger, right? There's a more robust PMO structure, more formal dependency management. So you know, more support from scrum masters and program managers in addition to product managers. So there's a lot more system set up around it. We're working on this redesign, so the pressures are around helping to enable teams to deliver this new redesign, right? And like, as timelines gets accelerated and we're just like, half a step ahead of these teams, how can we keep everything moving forward and make sure that we're prioritizing the right work? That's been more of the focus, whereas at REI, it was a lot about establishing it, getting that widespread adoption and then really optimizing it from there, seeing where we could stretch into new areas.

Elyse 38:50

Love that. Thank you. So on a little bit of a different topic. I touched on this in the beginning, but one of the trends that I was picking up on in the last year or two is this idea that non-SaaS companies would create or embrace design systems. And this, for me, really came out of seeing the Gartner Hype Cycle for design and engineering, I guess, I don't know if this was in 2024 or early 2025, but they had design systems like on the cusp of mainstream adoption. It was like early adopters, trough of disillusionment, and then it was like, oh, you know, we're actually gonna see this come up and become like way more mainstream. And it's really, really fascinating to see— I'm gonna say the word AI one time on this podcast episode— but it's been really interesting to see the story of like, oh, design systems are now so critical when LLMs are gonna be building all of this code. But I also think that it's non, you know, traditional tech companies, starting to adopt the idea of building and designing with systems. I know of a handful— Aritzia, GymShark, your two, I'm sure there's many more. I'm even thinking about like, you know, like Abercrombie or even, like Dominoes, Chick-fil-A. They have apps. Like Chick-fil-A has a design system. There's such an important technical element for e-Comm, you know, and that's just like how we build UI, you have some kind of reusable system. So there's this idea maybe that e-comm is, catching up on design systems. Having worked at two quite large ones, I'm curious, like, does that framing even feel right? Do you think that this is a growing trend, or is that just sort of our SaaS tunnel vision of like, oh, like, wow, look, there's other things out besides us! Does e-comm have its own mature design system playbook that we are just not hearing about?

Maya 40:37

I mean, I think it's a little of both. I would reframe it that e-commerce design systems are maybe not immature, but they're solving a different problem, right? Like, we talked about The scope is different, and other differences between SaaS companies, where e-commerce exists in a larger ecosystem for brand. At least for the ones that have physical retail presence or create their own products, brand for that includes store design, package design, hang tags, as well as other digital marketing channels that would benefit from the same brand layers. So there's a lot more coordination between the online experience, the in-store experience. There's certainly a lot of these larger enterprises that have been doing this for a while. I've talked with teams at Starbucks and Target for example, which I think are another great examples of having a really good, strong, multichannel, omniplatform, omnichannel presence, right? That's been the buzzword, but, more true than ever. We're working within a larger ecosystem, right? Digital is an organization. It is not the entire product. Like a SaaS company, everything is within that tech space. But in digital, we're also working with retail teams. We're working with those physical product design teams. There's a lot of different other touch points. So I think the playbook looks different. And you know, like we said before, maybe we just don't hear as much from e-commerce?

Elyse 41:51

Yeah.

Maya 41:52

Part of it, maybe it's just, keeping things more internal. I think there are a lot of systems that have had mature ones. That said, I know there are also some that are still catching up. And I think that kind of reflects organizations that maybe didn't invest as much in digital, a few years ago, within that 78 timeframes, there was a lot of digital transformations happening, right?

Elyse 42:09

I remember that, remember that phrase?

Maya 42:11

Right? Yeah. But that's where design systems started to creep into some of these larger retailers, e-commerce companies, places that weren't investing in that, now they're the ones that are doing a little bit more of the catch up. And, you know, like we talked about, what's changed so much in the past eight years, like the landscape has changed, but also the expectations have changed. It's becoming a lot more table stakes to have them. I think especially at that a global or multi-brand, multi-platform level, you start to get that ROI pretty quickly with the design system, having that at the central point.

Elyse 42:42

Yeah. In our predictions recap, Noelle suggested that— it was digital transformation, you know, seven years ago, and, and now it's like modernization. Can we utilize the design system to, you know, modernize our tech stack. At REI, so seven, eight years ago, and at Lulu now, what, what is driving the design system effort? Is it a, a technical modernization thing? Is it digital transformation? Is it a rebrand? You also mentioned the idea of like, you know, omnichannel or like multi-brand or multi-platform. Is it coming from that? Just curious what you have seen personally and how that ties to the design system, like, oh, can we use the design system to do, you know, insert big effort here.

Maya 43:25

Yeah, I mean, at at Cedar, at REI, you know, eight years ago, it was definitely more grassroots, right? Like it was more emerging. We had designers and engineers who were like, hey, we can share components and not rebuild them over and over, right? So we were able to build on that. At the same time, you know, REI was investing in a lot of platforms, so it did fit under that larger strategy. Definitely some of those modernization efforts, like moving to a microsite architecture were, I think, really key to getting that widespread adoption, because we were able to say, hey, we're gonna build the design system into this new architecture. So once you migrate to that, you get the design system for free, right? And we started to really build those strategic partnerships. So I do think there's something where aligning the design system with other modernization efforts or digital transformation efforts is how we get to that wider adoption. At Lululemon, we're converging not only the global designs, but the different platforms that the different markets are using, to have something more shared. And so again, it becomes this point where like, we need to modernize. It makes sense to do the design system as part of that. At REI we were working with the brand team, because digital is one touchpoint. And so how can we take these core brand guidelines and really adapt them to digital specifically? What do we need to add, and layer that on, and then we can distribute that through all the touchpoints? So we earned a seat at the table with this broader brand rollout that went beyond digital. And I think that was a really big step to showing like, here's the impact of the design system. I think the other trend that I've seen, as new leaders come in, it's becoming more the norm at other places, and so they're starting to build in this expectation, of course we have a design system. And that can have two parts to it, right? Because hopefully their expectation lines up with your expectations. But I think designers and engineers now also expect to have a design system when they're coming in. And if they know, there's a robust design system, I think that's a big value of having public design systems. It's kind of a signal that like, hey, this is somewhere that knows what they're doing, somewhere that I would be supported somewhere I wanna work.

Elyse 45:20

Or it's not total spaghetti code and just like figure it out for yourself.

Maya 45:24

Yeah, exactly. And, you know, I think that means a lot. So I think there's a lot of different directions it comes from. I will say, in the retail space, I don't know that it's, as early adopters of some AI. But definitely as we're building, the new design system now, it's like how can we future proof this as well? Like we know there will get to a point where the more structured and well documented the design system is, the more that other types of users, right, beyond designers and engineers or even content management system right, could start to leverage those same components and guidelines and everything. I think even if it's not a goal this year there's some acknowledgement, at the leadership level of like, this is how we get to that next step. And here's how we're gonna not fall behind, because we're already building this infrastructure in.

Elyse 46:08

I guess we will say AI more than one time on this episode. I think one of the places that design systems can theoretically support in the future is generative UI. What's gonna happen when the application can actually create, you know, the page for you based on what it is that you want, or you're doing, or what you've done in the past. But I feel like in e-comm, that's actually a really interesting and possibly earlier place than SaaS, to take advantage of something like that. Like, if you know something about me, what I've bought in the past, the kinds of things that I'm looking for, you know my size, you know what colors I buy, you know how much money I spend, like, all these things already. And so if you can have, not just like the product page, or the homepage, but, Elyse's homepage. These are your products, this is your campaign, how we're marketing to you. I mean, I think that's like a marketer's dream, right? And so how does the system support something like that? You know, how does the CMS support something like that? How do you say, here's what we know about you and here's how we can take all these product tiles and information and images, and just create a whole new thing for you. LLMs unlock something interesting there. Because to do that programmatically, the number of templates you have to have, and the number of connection points to information are just so massive, that to be able to feed that into a system and generate something I think is gonna be a really, really interesting unlock. But it's also, I just like, the design system challenge is extraordinary. And I have no idea what that looks like.

Maya 47:45

Yeah, no, I think how that gen-UI concept emerges will be really interesting. And you're totally right, like personalization is huge in e-commerce. It's leaning a lot on segmentation, right? It's like, okay, we know you shopped for this before, so we can start to generate recommendations. I think location is another factor. Like at REI, we're in Florida, you're pitching more of the water products, right? And kayaks.

Elyse 48:06

No, no. Like ski gear. Not in August in Florida.

Maya 48:10

Exactly. And in, Lululemon we have these campaigns in Australia, and like they don't want puffy coats right now in Australia. And so there's some degree of coordinating that based on location as well as your activity and preference. I think it will be really interesting when it gets to that UI level and what we can infer, maybe, versus maybe what people can explicitly state, in like an account settings, what they wanna see. It does create a you know, challenge at the design system level, but I think the more that we have, really flexible, fluid, foundational parts to build from, that will help to compose more on the fly, right? And so we're not having to build extra different variants of these layout components for cards, but we can, just derive that based on usage that we see, and probably get better input on the fly. So I think there's a lot of potential there. I will say as a PM for AI and design systems, I'm probably more excited about how our teams can work more efficiently, versus the gen-UI angle. Just being able to get through things in the backlog faster, or even things that I can do now using Claude, whereas before it would just languish, wait for an engineer to pick it up, was never the top priorities. You know, how can we automate between tools? I think there's a lot more, before we even get to that gen-UI place, that I'm excited to see how we can integrate within just our workflows and how we also distribute those updates to teams as well.

Elyse 49:30

Yeah. What kinds of things are y'all doing now and where have you been experimenting with ai?

Maya 49:35

Candidly, we've been pretty focused on building the design system and trying to make it futureproof. We are looking at building agents to help facilitate guidance around when to use components. We use Zeroheight, so how can we tap into some of their tooling too. I think they're building a teams agent as well to be the chat bot that references your documentation. So there's that aspect of it. There's potential that I'm excited about within the accessibility space as well, because we def facto own a lot of that within Lululemon and have a lot of the accessibility experts within our team. But it creates a bottleneck. And so I think there's potential too like, how can we further build that into, you know, help me understand these WCAG guidelines or help me, like how do I need to test this experience? I think there's a lot of potential there as well. At REI, I was able to build like a visual coverage tracker, just like a Chrome plugin, which, you know, I never would've been able to do just on my own. So little things like that make me feel super powerful, even though it's like, you know, a basic AI usage at this point. Just being able to do it myself. I think as PM sometimes we're like, I wanna do it, but I don't know how to make a Figma plugin, or I don't have the right permissions. So it's little things like that, where it can just enable the work that we're doing. I think in the future it'll get more probably towards that personalization, especially, global scale. How do we tailor it for different markets? So I'm excited to see where that could take us.

Elyse 50:54

Yeah. It's very exciting to be like, oh, I can get this data, I can make this thing that helps me do my job, or do my stakeholder management. Especially as a PM there's so much information that you can glean about your product, that you can grab yourself now, which is really cool. Now we are at the best question of the whole podcast, which is the spicy take question. Maya, what as a design system PM, what is your spicy take on design systems?

Maya 51:21

Love it. So my spicy take is that we should be encouraging teams to build outside of the design system. And that is probably blasphemy as a PM, my role is to be driving adoption! But I think we do start to get to an inflection point where, you know, we shouldn't be aiming for a hundred percent usage of the design system. Like that is where we get to the point where we're putting too many constraints, right? Ultimately, we want a healthy relationship with the system. We don't want to be fully limited by the system. So, I think as long as deviation is intentional. There's guardrails around it, right? You're using tokens. I think it's really healthy to be building outside of the system. I also read, recently PJ Onori wrote a really great post about this from the craft and design perspective, that, I've heard a bit anecdotally as well, like the more designers, engineers are dependent on using the design systems, they're losing the skills to develop it in the first place. Because they're just plugging in from the design system. We almost get too dependent on it, and so, as the PM for a design system, I wanna make sure that our system stays fresh. We're getting those contributions. We have teams that know how to build at the quality that something could be contributed back into the design system. And if we're just saying, use our parts, don't, you know, we're gonna be the design police and tell you not to, I feel like we're missing on a lot of opportunity. So, yeah, I think it's really smart not to aim for too high of adoption. Again, feels a little spicy from the PM role. But I think it's, again, it's really healthy to have that relationship with the system.

Elyse 52:49

Yeah, I love that. I like aiming for somewhere in the 40 to 60% mark, in terms of percentage of lines of front end code. You touched on this earlier, the teams themselves understand their part of the product. They understand their user needs, they understand what's working and not working, and they need to be able to adjust, to respond to those things. And if you only say, you could only use, you know, this filter component exactly as it comes, and they're like, it's not working for us. You aren't building a relationship with your teams, you're, you're just, you're being the police and you're like, I don't care. I don't care about your users. I don't care that it's not working for you.

Maya 53:28

Yeah, a hundred percent. And I think the premise of the design system, right? We're solving the solved problems. But the goal of that too is to free these other teams up for more time to work on what's really unique and challenging for their space. I don't think that's a failure of the design system. I think that's the system working well. If we're enabling teams to do that and create those really bespoke and custom moments, or experiment and try something different to see what is gonna move the needle that could then potentially be shared out to other teams as well.

Elyse 53:55

Yeah, well with AI— oh, that's the third time— we're going to see, I think an, an explosion of one-offs, customizations, things that I can just do myself. So putting those guardrails in place is a really interesting exercise for design system teams right now to allow for that within those strong, intentional guardrails. So completely agree. Maya, thank you so much for taking us through all of that. Really interesting to hear and, and even like some light bulb moments for me. So, super fun conversation. Thank you so much for coming on the podcast.

Maya 54:29

Yeah. Thank you.

Elyse 54:31

Thanks for listening to On Theme. If you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!