Maya Hampton — Product Manager, Digital Design Systems at REI
Hi, I’m Maya Hampton, I’m the product manager for the Cedar design system at REI. REI is an outdoor retailer, so we’re not a tech company, but we are really working to build out a solid digital foundation to help us scale more efficiently into some of our new business lines. So there’s really been a mindset shift to thinking more in systems and our design system has really helped lead the way. So it’s been really an exciting time to work on that. We launched the MVP of our system back in the summer of 2018, with a set of core components and then since then we’ve been continuing to build out that library. We have a dedicated team that supports it and a lot of great adoption throughout our digital properties.
Okay, well let’s get right into it. Maya, what is the most difficult thing that you’re facing right now in relation to design systems? Get it out of your system.
Yeah. Well, as you probably know, there’s any number of challenges with design systems, but now that we’ve kind of gotten through some of those initial challenges around what should we build, getting people onboarded and adopting the system. What we’re really facing now is how do we evolve the system over time and what is our governance and maintenance process? I think what makes it difficult is governance is kind of a scary word for people, but really the goal is to just have some more clarity about how we make decisions and having a better answer for our users about what to do when they can’t find something that they need in the system or we have a component that does most of what they need, but they’d have to break it or fork it in some way to really make it work for them. So how do we handle that from a systems perspective and there’s just endless complexity kind of working through that.
I bet you are not alone in that. Almost all of the questions that I get when I do workshops about design systems, I would say 50% of those at least, revolve around maintenance and governance and things like that. Can you talk a little bit through the governance process and the maintenance process? What does it look like? How do you do those things when somebody says, “Oh, I need to use this component, but it’s not quite what I need.” What do you do about those kinds of things?
Yeah, so we get, as I mentioned, we do get that question a lot and we try to keep our communication lines open with the teams that we support. So we have a good avenue for those, so we do office hours, we have a support Slack channel. So we really just try to keep a pulse on what teams are doing and what they need. In terms of the governance process, we’re trying to first establish some clear criteria about what goes into the system and then making sure that we kind of have a path for contributions as well. So when we talk about criteria, we’re looking at things, really at reusability, is this something that multiple teams can use as opposed to supporting something that’s really custom or really one off to that specific team. And then what we’re trying to work through now is how to work with teams to build sort of experimental components or new patterns that could potentially be contributions to the system in the future.
So the process we’re testing out now is working with those teams as we kind of hear about these requests, really encouraging them to build it in a way that’s compatible with the system but still feels cohesive to our end users. So use those foundational styles and design tokens, so it kind of is built on that same foundation, keep those components in a shared repo that other teams can access. And then what’s really cool from the design system perspective is we work across so many teams that we can start to suggest some of those components to other teams, when we hear that, “Oh, you’re looking for a search input, well, so was this team looking for a search input, we don’t have it in the system yet, but we have it here.” And we can start to look for those patterns to hopefully pull into the system over time.
You mentioned that you have a dedicated design system team that works with other teams. What’s kind of the team structure there? Do you have teams that are devoted to specific products or specific business units? How does the team structure work there at REI?
Yeah, so our team is cross functional. We’ve got four designers and four front end developers, we also have a dedicated technical writer and editor for our documentation in addition to project and program management. But then the product teams we support, yeah, they really do span a number of different areas across rei.com, sort of the eCommerce business, the whole product pages, search, checkout, that whole experience. REI also has a number of other businesses like adventure travel, we have retail stores that host classes and events as well. So there’s different teams that sort of work with in those different lines. And again, we’re kind of looking at what are those kind of consistent patterns across all of those different areas, when is it okay for them to kind of have their own look and feel and when do we really want to make sure that we’re providing consistent interactions.
So it sounds like nine people on the design system team, four designers, four front end, technical writer. You made a point of saying earlier that it’s not a tech company, right? REI is not a tech company. That’s a pretty mature design system team for not a tech company, that’s a mature tech practice. How does that fit in the context of a company that’s not a tech company, who doesn’t consider themselves a tech company? Is that an awkward fit? Do you have conflicting kind of business goals because of the adventure travel and things like that versus the tech goals that you’re supposed to support?
Yeah, that’s a great question. I think we’ve said that our biggest store at REI really is digital now. So there’s definitely recognition that digital is growing and it’s a strong area to focus. So we really are trying to build up those capabilities in general. And the design system team has really been one of those to kind of pave the way in some ways, which has been really a great position to be in. But yeah, there certainly are challenges. There’s some major initiatives that teams have to work on and where affects us is they don’t always have time to pull in updates from the design system because they have these other partnerships with retail or distribution, kind of that go beyond just the scope of maintaining digital.
So sometimes there’s that conflict. But I think in terms of our design system, we’ve always had this vision in the future that, hey, maybe we scale beyond just digital and we’re able to work on some of those employee tools that are used in store or even potentially some of that retail signage that’s printed out. Could we scale the system even farther outside of that. So on the flip side, I do think there’s some interesting opportunity to grow even larger with what we do.
Oh, that sounds exciting. Have you made any leaps into that territory already or is that kind of like far down in the roadmap?
It’s always kind of been out there on the roadmap, but I think we’re getting a little bit closer to it now.
Yeah, that’s awesome. Could you share some examples and stories about things about reusability? So you mentioned that you have some times where your team is kind of looking across to see how reusable a component might be, kind of figuring out what goes into the system. Maybe you can share some stories about how that’s gone really well, like in that pathway to contributing and then maybe some stories about how, ah, it just didn’t work as well as we thought it would.
Yeah. So I can think of a couple stories as they relate to a few components that seem pretty similar, but there’s been kind of really unique use cases. So the first one of those would be the modal component. That’s a pretty common design system component. It was on our backlog for a while, but we just hadn’t gotten to it. One of the product teams that we work with was building out a modal. So we decided to kind of collaborate with them and build it out in a way that we could, not make it too specific to what they need but kind of make it just a nice container and then so any team can take that and plug in what they need. So that kind of worked well as a contribution. It was something that we ended up doing a lot more work to kind of facilitate that then we may have initially expected, but that’s typically how things go.
But then kind of similarly we were looking at a pop over component that existed in shared repo and we’re like, “Oh pop over, we want to pop over, we’ll just pull this in.” And that one was a lot more complex. It had been really developed specifically for one specific use case in the header, so kind of normalizing that to be shared out with the rest of the teams became a bit more challenging to do. And then kind of this whole theory of build a component, we’ll pull it back in, but then what happens if we make some design changes to that or functionality changes to that? There’s certain accessibility considerations we want to bake in, but if we change something about how it looks or interacts, how do we then work back with that original team to update it on their side? Maybe they don’t want to update it because they built it specifically for that.
So kind of figuring out, is this actually something that can be reused or should we potentially just make another version of it that’s a little more stripped down and allow teams to kind of build on top of it that way. So that’s often where we start to have these debates about how rigid or flexible should this component be? Do we want to give teams a lot of leeway to build on it or do we kind of want to push back on some of those deviations where we feel like it’s going to affect the user experience?
Yeah, that makes sense. Well, I guess my last question for you is, you mentioned that one of the most difficult things is kind of figuring out how to evolve the design system over time. What is on your roadmap now? What’s sort of next for the design system team? What is the evolution of your design system?
Yeah, so we’ve knocked out a lot of those simple components and now we’re looking to some of the more complex components or compositions, things like cards that can have a number of different layouts inside of them. So that’s where we’re kind of looking into, instead of just building, here’s five different layouts of cards, maybe we make more of a container and sort of a cookbook style instructions for here’s how to kind of build what you need within that card. So we’re kind of diving into that world of what does that look like? How do we communicate that? How do we keep those consistent design principles but still give the teams flexibility to I?
And I think another area where it gets a bit difficult for us as a design systems team, is that we’re not actually pushing code live, we’re pushing it out to the product teams to consume and to publish. So we can’t really do any sort of AB testing on our own or really try out these new patterns. And so we’re really trying to partner more with the product teams that we support, to help them run tests, understand what sort of feedback we’re looking for. So ultimately we can have some confidence about the changes that we propose in the system and have a way to kind of evolve it and keep it fresh over time.
Yeah. Got it. For both of those things and building complex components and also kind of partnering more closely with the product teams, are those things that are being asked for? Are those things that the design system team is kind of looking out in the future and going, “We’re probably going to need this stuff.” So are you anticipating that or are you already being pulled to do some of that stuff?
It’s a bit of both. So we certainly keep in touch with our users and we know that they want cards, for example. So we want to find a way to solve that in a way that can scale to a lot of different teams. But then kind of also looking strategically at kind of our higher level roadmaps and where we’re looking to take the company and sort of what can we do now to help set us up for success in the future. Another challenge is that teams will often ask for something right when they need it. So how can we try to get ahead of that so we can actually build it in time for them to use it? So that’s where we’re trying to get ahead and keep an eye out to the future in that sense.
Well there you have it. The most difficult thing Maya is up against regarding design systems, is evolving it over time and the maintenance and governance aspects of it. Maya, thanks for getting it out of your system. I’m sure you’re not the only one facing this. I’m Dan Mall from SuperFriendly, thanks for listening to this episode of, Get it Out of Your System.
Great. Thank you, Dan.
Kim Williams — Head of Product Design at Minted