Chris: Hey, today I'm here with Maya Hampton. She's the product manager for the Cedar Design System over at REI. Maya, I'm really glad to have you here. Thanks for agreeing to be on the show.
Maya Hampton: Yeah. Thanks, Chris. Thanks for having me.
Chris: So, tell me a little bit about what a product manager for a design system is all about.
Maya Hampton: Yeah, that's a great question. So I actually joined our design system team at REI right ahead of our release. So it was really to help drive adoption, help manage some communications, let stakeholders and potential users know what was coming and really start to build that awareness. And so adoption definitely took up a large part of the role, really building relationships with other teams. And then now, that's segued into more of our roadmap planning, planning for release cycles, keeping communications going out around new work that we're developing, trying to get some insights back from our other internal partners about where we can help add value, where there's potential gaps in the system or gaps in how we're delivering our brand expression. So it is a lot of working with those external teams within REI to look for those partnership opportunities.
Chris: That's awesome. So when you came in, Cedar was still this nascent thing that had either just recently launched or was about to launch, and a large part of your job as a product manager was to try to make sure that this was built in a way that would be adopted by the organization and really focus on making sure that it was the right system for the people that were ultimately consuming it.
Maya Hampton: Yeah, exactly. And we actually had a legacy systems with Cedar 1, our old school one, which was more of just a straight pattern library that had been integrated in the sites. And the team that had initially spun up to create that had fallen back to just one or two people trying to keep it going. So there were definitely some lessons learned about what hadn't worked when we envisioned this new system that would be more robust having those shared components with design and development, creating documentation to share that language. So, yeah, really stepping in to figure out, not only what have we learned from our previous experience with the pattern library, but then also, where are those other pain points that our product development process that the design system may be able to help integrate?
Chris: Got you. And have you guys always thought about your design system as a product or was that something that was new with your role? Because this was a big thing a couple of years ago, it was like, is a design system a product? And we've always taken the position very strongly, like yes, it absolutely is. But when you have somebody that has a product manager title associated with the design system, that's still a pretty new title. That hadn't existed for all that long. And so tell me a little bit about how the organization has thought about that design system.
Maya Hampton: Yeah, that's a great point. With the legacy system, I think one of those key learnings was that it was treated like a project. And then when the team went away and moved on to other projects, there was no one really left to maintain it, there was no really sustainable path forward to growing the system or making it better. So that was certainly a lesson that the org had learned into like, "Yes, let's treat this like a product with staff. Let's expect to continue funding this." Which now that I've been working on it for a couple of years, I really see that benefit. It's not just the tool, it's really the team and being that bridge to other teams and finding those connections across other teams that there's so much value that comes from the work that it does.
So there's definitely been a focus on, yes, let's treat this as a product. We want to have design and engineering equally represented, but we also want to keep the business in mind to what's coming up in our larger organizational roadmaps that we can tie our efforts into to make sure that we're helping to deliver seamless experiences and also help with some of those efficiency challenges.
Chris: When you talk that way about the design system and how it fits into the overall organizational strategy, a lot of that leads me to this thought about like, you're shaping the expression of the organization in its digital landscape, and then the organization is also shaping that design system. Talk to me about that interplay a little bit, because I think it's interesting to hear you say the direction for the design system is leading the product direction. And then likewise, you're incorporating a bunch of this feedback, I guess, into the design system, from those product teams.
Maya Hampton: Yeah. And one of the key benefits that I really see with this design system team is that opening up those avenues for feedback and collaboration, even across designers that maybe work on different teams, but also with designers and developers that work on the same team by having the shared language of UI components. It helps us to just really improve those ideas of collaboration, building things that are more maintainable and not a one-off. I also see it as, and this is feedback we've heard from some of our design system consumers, is that it empowers them to push back on maybe things that are coming through from product owners or business analysts, or like, "Oh, we want to try this one-off special thing."
We want to have design and engineering equally represented, but we also want to keep the business in mind to what's coming up in our larger organizational roadmaps that we can tie our efforts into to make sure that we're helping to deliver seamless experiences and also help with some of those efficiency challenges.
Maya Hampton: And it gives them some leverage to push back and be like, "Hey, well, if we do that, we're going to be starting to break some of our consistency. It's also going to become harder to maintain this over time as well." And so by creating the system around it and really advocating for that reusable ecosystem of parts and processes, it does help start to lead that change in the rest of the organization, especially when we talked to some of those other teams that are less digital first, like marketing or brand.
Chris: So how does that conversation get surfaced? That's really unique when you have somebody that is coming into this, is potentially hired, an outside contractor that is like, "This is the design pattern you should use for this particular control or this particular feature. Or what if we did something unique and interesting and different and went a totally different direction here?" And that ultimately gives that individual product team or product owner that pushback chance. What does that look like now? Because I am really curious about that interaction, where you have somebody saying, "I want to break a design pattern," and then you have the ability to say, "If I break this design pattern, it breaks all of this other work that went into constructing a consistent experience."
Maya Hampton: Yeah. There's a lot to unpack there. So REI, we're a retail store, so we have these in-person touch points, we have our digital channels, we have marketing, and we have all these different channels. And so really this last year has highlighted the importance of that consistency across all those different channels and creating that seamless journey for the customers who may come in from any of these different touch points but still expect that same experience. And if it doesn't feel that way, it's off. So we're able to really align with some of the design and customer research teams that are focused on that seamless user experience and customer journey and use that as one of our keys, I guess, to help promoting that this is why the consistency matters and by using the system, we can advocate for that.
Maya Hampton: But at the same time, we're also trying to figure out even now how we can better support that idea of teams being able to build some experimental components or patterns that we can test and learn into, knowing that the design system is intended to be a living system and intended to evolve. We want to learn what's working from those teams and build it back in the system. So that's the process we're trying to explore a little more deliberately now, how we can create that room for experimentation, not be overly prescriptive, but at the same time, deliver that consistency to their end users.
Chris: Yeah. And I'm sure that that's been no more prescient than with COVID. I'm sure, like most retailers, you guys had to shut down in-store operations for some time. And so having being thrust into the main channel, suddenly being digital, I'm sure that that was an adjustment you guys made over the past year as well.
Maya Hampton: Yeah. Definitely huge uptick in digital traffic. We started doing a curbside pickup program, which was something that REI hadn't been doing before. So the design system certainly helped spin up some of those pages and landing experiences easier so that felt consistent because that's a real challenge with some of these larger items we sell like a kayak or a paddleboard or a bike, you can't just get that shipped to your house, there needs to be some coming in-person. With bikes, we do a lot of that assembly. If you buy a roof rack, we'll help put it on the car. So how can we still provide those services and still provide that consistent expertise from our REI employees whilst keeping some distance? Or doing what we can online and making sure that messaging is really clear with some of these shipping restrictions.
Chris: So, for all those new digital experiences you guys had to create as a way to absorb this rapid change that COVID thrust upon you, was the design system a huge asset for you in the ability to do like things consistently and quickly as a part of that adaptation?
Maya Hampton: Yeah, I would say so. We've also been working on moving our backend infrastructure to more of a micro-site service that our design system has really aligned with that work going forward. So once you're on that micro-site, you get the design system, you get the front-end build system, it's all built in and really easy to get that up to launch. So by creating that architecture, that in itself made it easier to just spin up a couple of new pages, not have to worry about the design of all these things to that last detail, get it out there quickly and be able to get it in front of customers.
Chris: One of the thing that is interesting about, specifically the ecommerce side of things is, ecommerce is really notorious or maybe infamous for UX choices, having meaningful dollars added to, or subtracted from a shopping cart. You think about things like performance and how all the data about save your customers 100 microseconds and you're going to get them to spend like 10% more money, or the accessibility need about one in 10 people or one in eight people have an accessibility need for a website, if you cater to those people, those people will buy stuff from the sites that best represent accessibility. Has the design system helped you grapple with any of those UX choices that ultimately lead to really clear business ROI through a shopping cart?
Maya Hampton: Yeah. This has been a challenge, and I'm sure you've heard this with other design systems as well, is trying to track some conversion rate metrics with a consistent UI or UX. It's tricky to get that granular, but site performance and accessibility are actually two areas that we focused on largely with the design system last year as an opportunity to do what we can within that system and centralize it out with to other teams. So for example, with accessibility, we're very conscious about taking on a lot of that research upfront to make sure that our components meet those standards. We've build in what we can, but then we also provide documentation for what that implementing team needs to do. So our image component has a field for alt texts, but somebody still needs to go in and actually put the alt text in there. So really spelling out that relationship of, we're doing as much as we can, but we're also hopefully making it easier for the teams implementing to figure out what to do as well, and really make that easy choice. Similarly, with performance, we've been looking at a lot of ways that we can optimize our code, do some tree shaking to really only get those components and variants that need to be loaded to be loaded, and really partnering with our other front-end platform teams that work closely on performance so we can have something measurable that we can track there that's tied in back into the system and the larger libraries that are being loaded or not on every page.
With accessibility, we're very conscious about taking on a lot of that research upfront to make sure that our components meet those standards. We've build in what we can, but then we also provide documentation for what that implementing team needs to do.
Chris: One of the interesting things that you mentioned earlier was how you felt that like Cedar V1 and Cedar V2 went from being a pattern library to a design system. And that sparked something for me in that like, what we talk about very frequently in Knapsack is how, like your component library is not your design system, your design system is this collection of all these other things that are well beyond patterns or components. In that sort of transition, what in your mind really became the design system from that pattern library? If you had to talk about the anatomy of what you've built within Cedar, what would that really look like?
Maya Hampton: Well, I think one of the keys about design systems that's not always apparent as first when you're just building out those component libraries is really how they connect together and those inner connections, that's what really makes the system what it is. The Lego building blocks are the most famous example of components for a design system, but what's really so fascinating about the Lego system are the little, the tubes and the stubs that connect those pieces together. And so a part that was made in the 1950s still fits with a part that was produced today. And so really looking at those interconnections between how different sections of a page, how a different micro-site shares a component with another part of the site so it's consistent to that end user.
Chris: The awesome thing about that is, when you think about a block from the '50s fitting in with a block that's built today, this idea of these interconnected bits, when you think about something like your micro-site platform that you were talking about, that's starting to move beyond the idea of a component and more into the idea of a pattern in that that micro-site has layout, it has token sets, it has all these other things that ultimately represent a micro-site pattern for you. And sure, there's a lot of variations of that pattern, much like there's a lot of variations of a card component or something like that, but the important thing is that that's stitched together to represent some unit of value. Because we're not consuming components in isolation, no user is just viewing a card pattern. And so I love the idea of going from this pattern library to actually patterns and practice for implementation.
Maya Hampton: Yeah. And I will say that one of the other initiatives is that having a design system has spurred this desire for consistency in other things, for instance, in our front-end framework and tying that back to our micro-sites. With this rollout, we've been able to really advocate for view as the JavaScript framework. Previously, it was kind of the Wild West, pick whatever you want, and so there was a lot of inconsistency there, and that was a big pain point for developers that we worked with because it was really challenging to move from team to team, when new people onboarded, they may not have any documentation or clue what was going on. So driving for other standards like a shared JavaScript framework, a consistent website that people go to, tying it back to the designers, a shared library that they can pull from as well, it does start to promote this idea of what other parts of our process can we standardize a bit so we get that efficiency gain? Server-side rendering was a big challenge at one point and it was like, "Hey, similar to the design system, we have every team trying to solve this for themselves. Could we make one solution for that, tie it into our micro-site platform?" And then it starts to all just be bundled together and you get to really take advantage of the work and best practices that other teams are building.
Chris: Yeah. Coming from the world of PHP and service-side rendering, I totally empathize with that challenge. Yeah. It's interesting too, to see how, when you think about things as patterns instead of just as simple components or a pattern library, you start to incorporate lots of other disciplines into that as well. You start to think about like UI, content, design, and that becomes this collective intelligence about what represents something to a user instead of what is just that thing in isolation. And don't get me wrong, that thing in isolation is very important, but ultimately, what people are consuming and what you're constructing includes multiple disciplines and it includes multiple aspects of that pattern. I'm really curious how you think about that overall system and that systems-based approach to those different disciplines and those different patterns and how you think about the construction of that, specifically with something like the micro-site generator, because I think this is a really good microcosm for how systems like this actually get implemented. You're using your design system to construct an end experience for users. And that's consistent between different apps in different parts of the business, multiple micro-sites get launched on this sort of thing. And so when you look at those, that is a multidisciplinary, multifaceted implementation of a design system. And so when you look at that implementation of that design system, that goes far beyond like a component in isolation. So how do you go from a bunch of components that are like, sure, well-documented, have designs, have code, to actually the implementation of that thing as a pattern.
Maya Hampton: Yeah. I got you. And so a big key to this, and I think where the PM role especially comes in helpful is, it's a lot of those relationships and connections. And having those conversations with all the different disciplines that may affect a pattern. For example, we're diving more into patterns now as well, and one of the ones we're looking at is messaging. And messaging, once you start to unpack it, it becomes really complex. Then there's this larger category of communication and we want to be able to recommend when you're using a tool tip versus a modal window, but you can only go so far without starting to talk to the copywriters out there because they have an opinion about messaging. And then if you pull in somebody like marketing or these campaigns, well, they have a specific hierarchy of messaging that they want to see on the site too. So there's not decisions that we can, to your point, make alone in isolation. They really do need to start to bridge out to these other teams and figure out, what do they need? What's flexible? And what's not flexible? How can we work together to deliver something that still feels consistent and provides that best usability and readability and all that good stuff to our end users?
Chris: Yeah. Let's dive a little bit deeper there, because I think that this is an interesting concept. When you think about a pattern like messaging, how do you guys think about that? Because it feels really broad when you just say messaging, so what does an implementation of messaging really mean?
Maya Hampton: Well, like many design system conversations, that tends to get pretty philosophical on our team. We definitely go between the philosophy of exactly what our communication is, to that tactical, how do we get it out there? And when we look at patterns, even patterns is a word that we've been trying to unpack a lot because we have some history with a pattern library, we tried to separate ourselves from that, and now we want to re-introduce that. But largely, if we're thinking of patterns more as... So the component is like the specific thing that's built, But the pattern is more abstract and it's more guidance and could be potentially applicable in a variety of different contexts, so there's some flexibility inherent in that pattern.
Chris: I love the strict definition of a pattern for us, has been a solution to a commonly recurring problem. And that's as far as we go with that in terms of defining pattern inside of our app or inside of our company, because we want to basically think about patterns as this broadly applicable philosophical concept where you're solving a problem with a pattern and that pattern solves that problem repeatedly in all use cases across any parts of a context or whatever.
Maya Hampton: Yeah. I checked out Christopher Alexander's pattern language, tried to dive into that a little bit. Maybe some of the cliff notes helped me understand it a bit more.
Chris: Yeah, it's a heavy read.
Maya Hampton: It's pretty heavy, for sure. But at a high level, I think I understand enough about... He's talking about this patterns within the realm of architecture. So you're building a kitchen and depending on where you're building that kitchen, where there's light, where there's plumbing, it's going to look different, but it's going to have a lot of those same components, there is going to be a sink, there's going to be a fridge, some counter space, those basic components that would make up what we see as a kitchen, but with room for flexibility in terms of the specific context that that kitchen is being built. And then on top of that, there's even maybe it's a craftsman style house, and so it has a visual difference, but you still know it's a kitchen if it's different than another brick or Tudor-style house. I'm not so good on my architecture, but leading with that, the styles are different, but you know it's a kitchen. There's that shared pattern, that's again, solving a specific user task or something people are trying to do, cook food.
Chris: Yeah. And so your designed tokens become like what your color of cabinets are or what your countertops are made of, or those sorts of things. But overall, those patterns are about solving that need for the ability to cook food and a space. And I think the really good analog there in terms of the web is, a pattern solves a problem for a user like checkout or log in or product catalog or any of those other things. The wonderful thing about ecommerce is that these things are very distinct and well-represented and well understood, just largely because of the tie in to like dollars through shopping cart, but the patterns for them, I don't figure are particularly well-established in industry. It's rare to see a team organize around catalog pattern, for example, and have a product owner for a catalog and to have that catalog show up across or between multiple products. Is that what you guys are driving that with your pattern concept, or is it different than that?
Maya Hampton: I think eventually, there's levels to this, patterns can be in all sorts of shapes and sizes, but forms that you're speaking about has been the first pattern along with messaging that we've really been trying to dive into because that is the most common interaction on most websites. It's essential to things like log in and check out. So working with those teams, there's teams that work on checkout and customer accounts and login and all of that. So potentially working with them on those larger patterns, but we're starting with input patterns, really what are those best UX practices and implementation notes for putting together an address field and not auto-correcting the city credit card field, having some indication of the type of credit card like a little icon. So it shows some quick validation that this is a valid credit card number, and the expiration date, making sure that matches what's on your card, so people don't mess that up. There's little things like that that seem very granular, but we're starting on that level of really understanding these input types as they apply to specific user tasks or things that people are trying to do, really diving deep into the best practices, best accessibility practices around those as well. And then our hope is that if we can document that, then we can share that back out with more teams, and potentially we could get larger to that full checkout flow, but that may belong more with the checkout team since they're really owning that until we are looking across platforms.
Chris: No, it feels granular, like when you think about the number of places that people enter a credit card in the REI app ecosystem, I'm sure it's in the dozens. And so when you think about how that applies horizontally across an organization, now all of a sudden, that single piece of innovation having quick validation around a credit card provides user value at dozens of touch points for a customer across your ecosystem. And so I think that input fields are interesting because forms are hard, they're super complicated, almost every single major enterprise in the world has a difficult time managing them across their product ecosystem. And oftentimes, they're defined by third parties. And so how you think about input is an interesting idea of a pattern at a foundational level, where you start to think in the design systems parlance of like, what are my foundations? And then when I think about the implementation, like check out, maybe an implementation that combine stuff from input, combine stuff from product cards, combine stuff from all these other more foundational elements.
Maya Hampton: Yeah, exactly. And that's where, again, with the patterns, it can go so many different ways because at some point, it feels foundational, but then it's really taking that next level about how these more atomic components can start to be placed together and provide that best practice so you can tab through it and you can go to a checkout when you're signing up for a class or event with REI. And that feels the same too, and you still feel like you're with the same company and it's still listable.
Chris: And it's doing all the right stuff also, its performance, it's not making a bunch of like weird third-party calls in your input field. It's doing all the things that it need to do in terms of accessibility like you mentioned. And it's an interesting way of thinking about this because I think the industry is still trying to settle on what this pattern concept really is all about because there are these foundational things and there's the implementations of these foundational things, which then themselves are also patterns. And you end up with this like weird sense of meta associated with it all about like, where does the slippery slope of meta get to? And in this example of this, try being a company that provides design systems platforms that has their own design system.
Maya Hampton: That's really meta.
Chris: I think that the wonderful thing about these kinds of conversations is we get to start to think about, where do we draw some boundaries in this pattern concept around what we want to think about at the design system level versus what is it that more product implementation level. And for me, it's always been about what are the things that are commonly structured across all of my applications? So what are those recurring problems? And a recurring problem like messaging or input seems to be a lot more valuable across products than something like checkout, because checkout is only going to be specific to that particular checkout, maybe in multiple applications, but that feels like a lot more implementation specific. And I'm curious, in your mind, where do you think about those lines within Cedar? Do you think about it's the design system team's responsibility to define at a very specific implementation level like a product card looks like? Or do you try to keep it at that upper level, that more abstract concept of messaging?
Maya Hampton: Yeah. I would say that's just been ongoing balancing conversation to try to figure out, it's kind of that how flexible versus how prescriptive do we want to be. And generally, it seems like design systems add the most value when they're not overly prescriptive, they allow some flexibility. So if you have light coming in through your kitchen this way, you could position it this different way, leaving room for the teams to adapt to their context. But then there's also things that we are sticklers about, like the brand and typography and some of those really foundational styles that needs to come through. I think when we have research or accessibility requirements or even performance built in about what to use, when, then that starts to give us some of that credibility to go forward and really push back on those decisions, but not becoming the design police that you can't do this and that, making it feel more like a community and a collaboration, so we're not putting things out there that people aren't getting used. And at the same time, they're able to tell us like, "Hey it would save me a long time if I didn't have to figure out the spacing around all these different input fields in a form every time that I'm putting a new mock-up together." Or something like that. Like what are those problems that we can solve that can be reused across multiple teams? And then what's specific to just this team? And maybe that's where they have room to experiment with it, they have room to build their own compositions, which is what we think of as that next level up from components when you start composing different components together, you can create that composition. So another language normalization we're trying to get out there.
It seems like design systems add the most value when they're not overly prescriptive, they allow some flexibility...but then there's also things that we are sticklers about, like the brand and typography and some of those really foundational styles that needs to come through.
Chris: Yeah. I want to come back to the naming things here in a second, but one of the things that I've always really liked, my co-founder Evan, he was the first person, I think, to tell me the phrase, unopinionated tools with opinionated implementations. And I think that a big part of a design system is creating that unopinionated tool that can then have an opinionated implementation by somebody downstream. And I would maybe change the word tool for infrastructure, because I think that a lot of what we're doing with design systems is infrastructure, but what do you think? Do you think that that encapsulates what you're trying to build?
Maya Hampton: Yeah, I think so. And we don't put it so eloquently, but we talk about how our components are done. They don't know about the business logic about how many cards should show up on this page. It gives you the container that you can build a card in. So I think we've definitely skewed more towards that. Our components are really the simple, those UI elements, and especially those touch points, like primary action, call-to-action buttons where there's a real value and having that consistency. But then teams really owning that implementation, working with them though, so that we do have this feeling of community, and they can certainly reach out to us and consult with, "Hey, does this fit what you're thinking?" A lot of times that leads to conversations where we're like, "Actually, we just saw this other team over here trying to solve that in a similar way, so let's all get together and talk about this and come up with the way forward together."
Chris: Yeah. That's a really cool approach to democratization, and it's one of the things that I think I like most about implementations of design systems that are relatively mature, is you start to see this collaborative atmosphere percolate through an organization where people that are having innovation in one area are very eager to share that innovation with everybody in the group, because it's actually possible to take advantage of that via a systems-based approach to building products. And it's awesome to hear examples of that in a practice space where it's not like some giant handoff meeting or creative review that takes like two hours and everybody's miserable, and it's much more of individual contributor surfacing something that they did that was interesting. And then a design system team providing a lot of that, like interpersonal glue in the organization to bring those people together at the right moment.
Maya Hampton: Yeah. That's a great way to think about it. I know this run differently in a lot of the different design systems, so I think it also depends on the culture and the scale of how many teams you're trying to support. In some cases, you may need to be a little more heavy handed with like, "Hey, we're rolling out this new... We're in typography and we need everyone to make time to do that this quarter so it goes out consistently." So there's definitely some space for that, but not wanting to overburden teams with that as well so we can keep that good working relationship. And when we do collaborate or get a contribution from one of those teams, they're so much more likely to do it again and to help us learn from that and then to advocate to other teams as well when they see that. So it's really getting that knowledge out of just the design system team.
Chris: Yeah. And you build yourself your own like mini flywheel in product, the idea that once you get that spinning and people are eager to share, eager to show people what they've built, that leads to these flywheel effects of innovation inside a product.
Maya Hampton: Totally. And we were talking about those mature design systems and where do you go after building those core component libraries, and that's the vision that we're seeing now for Cedar is like, how can we make this more of a collaborative system that different people can use and contribute to, maybe we have some rotation onto working with the team, so people have that firsthand experience, maybe they're working on a contribution and we partner with them really closely on that, so that they get that value of the systematic thinking and approach. And also understand respect the whole process that we go through because it takes us longer to get things out of the door when we're trying to solve for every use case and really do our due diligence around best practices and accessibility versus just making a component like a date picker or something for one specific use case, for one specific product.
Chris: Right. And the idea is that if you build it right that one time, then the value is multiplied across every implementation of it. Like the design system math here is really funny, because if you think like taking really simple numbers, like, all right, it takes me 10 hours to implement something, and it would take me 100 hours to build an abstract implementation that is unopinionated, doesn't care about his context, is dumb as you say, that then can be implemented in one hour in any given place. So I have that 90% savings on my time, but I have to go through at least 10 or so implementations of it for it to actually pay off for me. And that's an interesting bit of a math that people aren't very specific about when they're designing design systems, but it's ultimately how that abstraction, that force multiplier works in this network effect within an organization. Do you guys do any of that math? I'm actually really curious about this because I've only ever seen the math done a handful of times, and I'd love to know if there's some sort of log of like hours saved somewhere in the REI database?
Maya Hampton: Well, I think a lot of other people are trying to do that. We've had some success and I think we're getting a bit better at it. We've had challenges around specifically tracking time, partially because we didn't get a great before, so we don't have a great baseline of how long it took. And then as people started to use the system, it becomes this perceived efficiency gains where now they're used to it so it's harder to break that apart from, "Okay, well, if you didn't have the system, how long would that take?" So we do have some sensible math about if it takes us 10 hours to build a button and that's used 100 times, then we're freeing up X amount of time and money that could be sent to create that button. So there's more of that theoretical. We've been tracking now on the measurement side, trying to figure out, get more visibility into where the components are being used, so which of those components are being used both in Figma, but then directly by querying our Bitbucket repos to see what's actually out there in code, seeing where those, especially where things like their answer being used so we can better understand that. The next thing I'm trying to do here is then to connect that to the traffic that comes into the REI website, because we have pretty good coverage across different micro-sites, but then that's not everything that's on Rei.com, but it's the majority of the traffic that comes through. So having that as another lens to get an idea of how many of our end users that go to Rei.com or mobile apps, how many of them are actually seen interacting with a component from Cedar, which may be able to get to some other extrapolation of user consistency equating to some dollars.
Chris: It's really interesting because I think of those two things is like audit. So I want to know where my components are being used and what are those variations of things. And then tying that into user behavior is like true analytics for a design system. What Figma built is great with understanding like, "Hey, here's how my design system usage is happening." but that's not user land, and that's the holy grail, is how do I tie how my design system functions to how actually user behavior has changed? And right now, doing that without creating a massive performance burden on your website is actually a really hard problem. There has to be this like dividing line where this integration work that I haven't seen yet, but I want to build that is there that understands user behavior and how that ties to design system variance. And I think that that'd be really powerful data to capture inside of an organization because then you could understand based on very fine grain UX choices, how that ultimately affects how users use your site.
Maya Hampton: Yeah. I think that would be amazing. I feel like that is a gap in the skills and what we've set up with the design system today is to be able to get to that information. And I think that's really important because the value of design systems goes so far beyond just those efficiency gains. So even if we do some numbers, even if we get some time tracking around that, it's not telling the full story about how having that consistency affects end user behavior, but also even our internal teams, how it affects their behavior and potential to collaborate by having this shared language and system and single source of truth for documentation about that.
Chris: Yeah. It's such an interesting topic. I think that on the analytics front, there's almost three things. There's this idea of how's my team functioning? What are the people downstream from the design system doing with my design system? What are the designers and the folks upstream doing? Which that is either in design app analytics or based on some input in the design system. And then there's like one more metal level down, which is, what are the users doing? And I think that the complete solution looks at all of those things. It looks at what's upstream, what's downstream, and what's way downstream, and tries to paint a really amazing picture of what's working from a UX standpoint. And do we end up then in this place where we have a much better understanding about how the design choices that we're making ultimately impact the use of the system? I hope so.
Maya Hampton: Yeah, I would hope so too. And that's where I think the designs, the fact that it's a system, it starts to provide some of that infrastructure to get things out there to test to see what works, but also when it does work to share that back out with everyone else. And that's both for the end users that actually interact with that, but also for how our designers and developers work together.
Chris: One thing on naming real quick because you brought this up a minute ago, when you think about naming, we talk about this all the time, how hard naming is, and especially how hard naming is in a system, when you guys think about the naming of your patterns specifically, and you look at words like messaging, and you look at words like input, where does that really drive from? Are you trying to derive like that most abstract level? Or is that just something that you've settled on collectively inside your organization? Where do those names come from?
Maya Hampton: We certainly haven't settled on them, so I think that's part of the challenge right now, honestly, is trying to figure out how we can find a word to really capture everything that we're talking about, but it is from that, what is a user trying to do, or what's the specific problem that a designer is trying to solve? So messaging may actually be more of this communications category, and then the patterns might actually be alerts and validation and notification that are actually part of how we want to communicate to that. But it's not something that we've really landed on. And I think that's one of the other benefits I've seen through the design system is putting in that thought, testing it out with different teams, seeing what sticks and what people will react to, but also trying to keep it abstract enough so it's not overly prescriptive as we were talking about before. So naming is really a challenge, especially trying to think of consistent naming across other potential patterns we may pick up in the future. So we're looking at, what are the different actionable elements? Should there be like interactions pattern, if you will, or how meta do we want to get with it versus high level? So this is where a lot of those philosophy conversations come back in and all that swirl around meaning. I don't know that we've really solved it, but talking through it honestly, does introduce a lot of those good questions and also potential gaps with the system too, and where we could go to help fill some of those in.
Chris: Yeah. I think it's impossible to solve the specific without getting into that more philosophical abstract piece. And I think it's honestly healthy. Well, there is a little bit of naval gazing that happens at that more philosophical level, I think it helps solidify a team's thinking around what the use or purpose of a system really is.
Maya Hampton: Yeah. And it's kind of that go slow to go fast. Ultimately, we want to improve speed to market, have these decisions out there so people can build on them without having to think through it all each time. So it's been intentional and deliberate upfront with how we're making those decisions, putting that time into really think about it, taking that time, and then outputting something that hopefully will continue to provide guidance at a higher scale.
Chris: We sometimes throw in a personal anecdote or something like that, is there anything that you want to talk about in your personal life and how patterns apply to that? You're obviously a nature lover, you work at REI, that could work.
Maya Hampton: Funny you should mention. Yeah, that was one I had been thinking about. Now that it's spring finally here, I've been spending a lot more time outside and spending a lot of time out in the garden, pruning, trimming things down to get ready for the growing season. And that's something that just continue to fascinate me, are those natural patterns. When you trim something down, you can go all the way down, practically to the foundation of it. And you know it's going to grow back and it's going to grow back and each branch is going to have two branches, and it's going to branch off two ways, and it's just these infinite patterns as well. And they're not exactly the same, but they're following that consistent, just growth pattern, I suppose. But once you start noticing those outside, you just see them everywhere, in trees and how things grow and bloom.
Chris: That's awesome. I also I'm a bit of a gardener, I love spending time in the yard. It has been funny taking this very systems-based tack in my professional life and how it definitely bleeds into the way I think about pruning and planting, and all those other things like that. I think maybe we should ditch the Lego analogy for a more plant-based one.
Maya Hampton: Yeah. Plants always work. And our design system is Cedar, named after a tree. So maybe my head is in that a little too much, but it's also the other analogy that I like to think about when we're talking about components, if we're only thinking about components, we're losing the forest for the trees, It's not just the trees out there, it's the whole forest and how they work together, and how trees communicate with each other with root systems and all these different things that go into that. So I always like to throw that one out there too.
Chris: That's great. Well, Maya, it's been a real pleasure chatting with you. Thank you so much for lending your voice and your expertise to this. Really appreciate you being on the show, and can't wait to have you back.
Maya Hampton: Thanks, Chris. This has been great conversation.
Chris: That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @thedspod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
