--
Chris:
Hi, and welcome to the Design Systems Podcast, the place where design and development overlap. Brought to you by Knapsack. Check us out at knapsack.cloud. Today, I'm talking with Rogin Farrer, the staff engineer at Wayfair, along with Neva Corbo-Hudak, the product design lead at Wayfair. They're both the team leads of the web design system. Welcome you all. Super glad to have you.
Neva Corbo-Hudak:
Thanks for having us.
Rogin Farrer:
Thanks. Excited to be here.
Chris:
The reason why we wanted to talk today is you guys have this really interesting story about the evolution of your guys' design system. It started one way, and it's now very much a different way. And in that evolution you guys had to make some really key decisions about what your system would support, the future of what design systems really look like at Wayfair. And if you could just give me a lay of the land of what it means when we talk about the web design system.
Rogin Farrer:
Sure. So today we have a single design system that supports all of our e-commerce sites. That's wayfair.com, as well as our other brands, like Perigold, Joss & Main, Birch Lane, as well as our B2B site. And then also our internal tools, our supplier platform, and our design system documentation site.
Chris:
Got you. So all of that stuff resides inside of what amounts to a single design system, is that right?
Rogin Farrer:
Yep. That is the home-based design system.
Chris:
Got you. And so it wasn't always that way. Tell me about what it looked like a couple of years ago when you guys first started working on design systems.
Rogin Farrer:
Yeah. Many years ago now we actually had three different design systems. One was that storefront customer facing design system that was supporting all of the brands I mentioned. But then we also had two separate other design systems for our supplier platform, and another one for our internal tools. And then for many years we didn't formally have a design system team. We had a team that was dedicated towards it, but it was just engineers.
We had one engineer that was supporting the customer facing design system, and another engineer, myself at the time, that was supporting the other two that were more similar than the e-commerce design system. Over time the team grew and actually we had separate growth trajectory. So the e-commerce part of our company was putting more effort and resources into the design system, hiring dedicated designers, dedicated content strategists, more engineers. And then separately, there was a different initiative to drive in improving the user experience of our internal tools, a recognition about the value of improving the UX and how that can drive value to the company for our internal tools and our supplier tools. And so there was a separate initiative to hire designers and engineers.
Chris:
So you have these two systems, and these two different systems are both getting investment from the organization. The organization's like, we need more people, more resources. We see the value in these things. And they're growing. They're growing in two different domains inside of the organization. A lot of it is about how do I support things, like how people make orders and stuff like that internal to the organization.
Rogin Farrer:
Yep.
Chris:
And then there are a lot more actual Wayfair customer-facing tools, which are things like your guys brand websites and that sort of thing, right?
Rogin Farrer:
Yes, that's right.
Neva Corbo-Hudak:
I come from the customer side. So where Rogin will probably talk about this, but our teams merged together so now we're all in one team. But Rogin came from more that enterprise internal tools space on the engineering side, and I came from the storefront design XD side of things. On the storefront side, when I joined Wayfair, we were already supporting a number of different themes, but not in a very consistent way. One of the things the storefront system had already started evolving to address the idea of a core foundational system that could scale out to serve all these different themes and different brands. There was some logic behind why we continued using that storefront space to expand and support suppliers and internal tools as well. Some of that foundation had been established already in that space.
Chris:
Got you. But there is still a consolidation here that happens. You guys have these two different systems that are going in two different directions. Ultimately, you guys decided that this was going to merge into a single system. And that merge is something that I can imagine was a little bit fraught. What was the decision process behind that? And what did that look like?
Rogin Farrer:
It was actually something that myself and the other engineers on the team had been talking about for a long time. It wasn't really even a design conversation for years. It was like, we're duplicating so many components. Yes, there are some unique ones, but we have two buttons, two text inputs, two toggles. And oftentimes it was mirroring one, but then they would just grow separately. So it was like, we just have this not ideal code base. We just always thought that the organizations we support would never want to deal with the friction, because someone has to move off of whatever they're currently using. Someone's going to get the shorter end of the stick if we consolidate to one design system.
But a couple years ago, I mentioned earlier that there was a recognition about the value that improving the UX for our supplier experience, our supplier portal, it's where they handle their part of the business, that that could drive a lot of value to Wayfair. And at first it was a discussion about how can we evolve the current platform? And I think at some point there was recognition, we actually need to rebuild. We need to set a new foundation.Our design system team was very involved in that conversation. And for much of the conversation we were still believing that preserving the specific design system for partner home was even going to be more value. That seemed like having a single system was actually going to make it more difficult.
Chris:
I think a lot of people face that exact same issue, where you see really complex architectures of design systems all over the place. There's this core system, there's a bunch of product group design systems that inherit from that core system. Because people have this dance that they're doing between the specific needs of a group or function inside of the business. Be that like, hey, I've got something customer facing where people need to be able to buy a piece of furniture to I have a supplier portal or I have an HR system that manages how people get scheduled in a warehouse. All those are vastly different needs, but you guys are essentially talking about how you unified those under a single system.
Rogin Farrer:
Right.
Neva Corbo-Hudak:
Yeah, absolutely. One thing that is challenging, while we realize that there's a lot of lift the supplier side to rebuild their experiences using a new core system, there also are some challenges for the customer facing side where, in order to make our system work best for all these different end user groups, we did have to shift from having customer focused products or patterns to more agnostic atomic pieces and components. That way we lean towards those end user feature teams to define their patterns with our components.
For instance, we had a product card component, which was great when we were a customer facing design system, but it's not appropriate for suppliers or internal tools. But all those little pieces that go into that product card are part of our system. So now we're leaning more into composability for our end user feature teams so that they can define the patterns using our molecules and atoms within the system.
But it also takes a little adjustment for our customer facing teams who were supported by these customer patterns who now have to take some more of that responsibility on their own. In the long run, I think it's in the best interest of the business across the board. The goal of our design system in general is scalability and efficiency. And so while there's some onboarding here for folks to get into this new mindset, I think in the long run it'll give us a lot more ability to differentiate experiences and still support everybody with one centralized team and system.
Chris:
So how does that look from a really practical standpoint? So you had a lot of modular patterns away from more integrated patterns, where you had a lot of opinionated implementations of things like product card. And now you pulled that into the realm of a lot of composable more atomic pieces of the system. Give me a viewpoint, and maybe the product card is a great example of this, of how that decision process went down. Is this everybody in a conference room basically looking at a whiteboard or a website and trying to figure out how I support ordering from a supplier and also selling to a customer at the same time? What does that meeting look like?
Rogin Farrer:
Yes, it's a good question. We tackled it in a more organic fashion. When we made that decision to consolidate our systems, we didn't go in and dive in making assumptions at that point about how the system needed to change, other than what we knew we needed to do to support that supplier portal.
For example, that was that moment where we had a recognition that the early designs that were coming out about what this new supplier experience was going to be, all the molecules, all the atomic components, were actually very similar to what we were providing to the eCommerce experience. When we were just starting from ground zero, it was actually very obvious. Of course we're not going to try to create a new system here. We have one that already is applicable and also fulfills all of our hopes and dreams of having a single design system home based team to get there.
Chris:
It's interesting even that you had people from both of those different teams in that same conversation, because think that that's one of the hard parts here. I love this part of the story. Because you had a system that was essentially siloed, right? You had this one group of people over here, this other group of people over here. By some intention or happenstance, they ended up to be in the same place at the same time. And they said, hey, these two things look a lot alike. And that seems to be a lot of how this decision got made.
Rogin Farrer:
Yeah. It was a funny organizational... I think part of that is the way that we were organized was very coincidentally led us to this. Because while we had two separate teams supporting these different design systems, we actually still figuratively and literally sat together in the company.
Chris:
Nice.
Rogin Farrer:
Our discussions about how to build components that are needed, many of them were happening together, but oftentimes the actual implementation at times were different people with different priorities that led to slightly different designs, different APIs. We were sitting together being like, wouldn't it be great if we could all work together on the same product? Wouldn't that be really nice? And it was always just the sense that the organizations that we support wouldn't be into it. They wouldn't want that friction. They wouldn't want to have their design system have other stakeholders, basically. And what we realize is actually there's a lot of value that we could give to the organizations by having a single one.
Chris:
So Neva, I want to come back to the specific implementation of this in a second, but this is really interesting. How do you ultimately talk to the supplier team and be like, yo, you guys are going to be a part of this design system now? What does that conversation look like? And how do you get there? Presumably this was not an overnight thing, right? What is that transition? How do you plan for that transition and then get there?
Rogin Farrer:
Yeah, it was tackled at many different angles. They were redesigning the atomic components for the supplier experience for this new improved UX. I was looking at the specs estimating that was going to take us a few months of dedicated work and there would be a lot of friction. How do we avoid breaking existing pages that are supplier facing while also building out this new experience? Because we didn't want to start from scratch because it was going to be a lot of friction there.
Chris:
No. And you guys actually were planning this as a retrofit of existing experiences as well.
Rogin Farrer:
Yes.
Chris:
This isn't like we're just going to build net new. We're going to actually address this as a technical debt project.
Rogin Farrer:
Yes. I think actually we just took advantage of an opportunity where other parts of the business were like, actually, if we're going to go into this new experience, we have to start from a deeper foundation, we have to start a new foundation. And so we were like, well, if these teams are going to be rebuilding many of their applications and reconsidering what pages are going to be on this experience, then we can capitalize on that and say, hey, use this new consolidated system.
Honestly, we were promising three to four months of dedicated engineering work with a lot of big question marks to retrofit this new design on the existing system. But we were able to provide an MVP in a couple hours by adding a new theme to our existing system.
Chris:
Oh, that's great.
Rogin Farrer:
And that was a very clear value add.
Chris:
One last question on this. Was there a day where you pushed the desks together in that office? Did people literally just be like, all right, we're one team now, and just move a cue ball or something like that?
Rogin Farrer:
I wish.
Chris:
What did that look like? Was it ever that simple?
Neva Corbo-Hudak:
Kind of. No. Well, it's funny because Rogin has been at Wayfair longer than I have. I joined a little over two years ago. I accepted the job, and I was on a team of say five people. And when I showed up two weeks later, the team was 20 people because the storefront and enterprise, or now we call them customer and supplier facing teams, had joined. I had all these teammates. We literally were at the same desks, so the desks were pushed together, but we were still functioning very independently, but having those conversations, like Rogin mentioned. It probably took another six months, at least if not longer, before we really started to mesh as a team.
Rogin Farrer:
And we were in the middle of the pandemic at that point, too.
Neva Corbo-Hudak:
Yeah.
Rogin Farrer:
Also, there was still a lot of question marks. So we made this decision, and we were able to provide an MVP for the component library. But at that time we were like, what are we doing with our internal tools? We didn't have an answer for that yet. So we knew that wasn't going away. And at that time there was still the existing supplier platform, and those teams had needs, and they hadn't really been looped into yet about what's expected of them. So we had this decision. It was a very long transition period about what are we doing with what's going to be deprecated system and looking forward.
So it was a period where things were a little bit stretched where people are asking for new features for the enterprise system, but we're like, this isn't going to be here. But we also didn't want to alarm them at this point about what's happening. We were still developing our messaging. So it was a very awkward period of figuring out what that process was for softly deprecating and messaging out the future of the enterprise system while also providing what teams would need to move over into a single home-based design system.
Chris:
Got you.
Neva Corbo-Hudak:
I will say we overthink perhaps everything. We were very cautious and made sure we really thought through all of these decisions and what we felt like was in the best interest of the team and the company and the organization and all of our users. There's always growing pains, and we continue to expand. We're talking about our web system here, but our app team was its own design system. We have again merged with them probably a year after the enterprise and storefront web systems came together. We're still going through of those transitions with app, and how we can work with them. We can't share code base because the platforms are all different, but how can we align on the design side so we have cohesive user experiences? So we're constantly working through those kinds of growth opportunities, challenges. And it makes it fun. But there's always ways of places for improvement and ways of working together.
Chris:
I think that's one of the most interesting parts about this story is that, while lots of people their way of supporting a huge diverse ecosystem is to chop that ecosystem up and to reduce fragmentation at the end points by moving that fragmentation up the chain maybe one level, you guys are going for the we don't want fragmentation at all scenario, where it is all one system. I think it's both ambitious, and also... I mean, I hesitate to say unique because I'm sure somebody will DM me on Twitter and be like, no, our system's that way, too. But I haven't heard of an enterprise system at quite this scale that is really all one cohesive unit.
And in that kind of macro to micro conversation, you have this big picture thing of, we have all these diverse needs across all these different parts of the organization. And we also have to all get them on board with using a single system. And at the very micro level, this actually changes the way that people think about patterns in the system, because now all of a sudden your patterns are much more modular, much more composable, much more structured on that lower level atomic side of things, because you want to give people more freedom to compose based upon all these different experiences that are out there.
Neva Corbo-Hudak:
Absolutely.
Rogin Farrer:
Yeah. And it's been a process. I don't think Neva or I would say that we're there yet at this modular place, because it has been organic. We didn't immediately start to move the product card, for example, outside of the design system. And there are certainly still patterns in our design system that are very storefront specific, but it's something that we're recognizing. Because in some cases they're built in a way that's technically incompatible with the supplier experience.
It has been a process of one, having these libraries being adopted by the new parts to the organization, and getting feedback over what is and is not working. Because one of the biggest things that we identified early on is we don't want to be over eager in assuming what any parts of these organizations need without evidence. In some ways the supplier experience does need some kind of card-like thing where there's media in it, but it might not be the kind of product card that we have for a customer. It might be something with a breakdown of an image for a product, but it's a whole grid of images for a product with metadata about that image.
Neva Corbo-Hudak:
Another thing I find exciting about the single them is that there are also a lot of wins that we might not have had otherwise. Our supplier tools are very table centric, and our B2B space was on the customer side of things where we had a table component, but it wasn't very robust. And by combining the systems, it gives the B2B space many more options and patterns and things to work with to build out their space even more than they had previously when we were siloed by user groups.
And then similarly, even within our end user groups, by thinking about those components and pieces as more modular, rather than a pattern that's in the design system, it allows our different brands to think about things differently. So a product card, again, keep going back to product card, but a product card for a Wayfair shopper is very different than a product card for a Perigold shopper. Perigold is our luxury brand. That's a totally different audience. What might Perigold want differently in their product card experience? Do they even want a product card? I mean, I think they do. What would it look like for that audience? They can now think a little bit more outside of the patterned box that we had set before within the component library, where they were adjusting a component. Now they can make their own product cards that better fit their users and their user needs.
Chris:
So I really love that you brought that particular thing up, Neva, because I think that one of the really cool parts about design systems, it's an underutilized value, is that ability to spread innovation. So you talk about that table component and having this really robust implementation of a table component within one business unit. And then having that actually implement, or rather influence, the table component in another business group and make it better. Likewise, the product card. I think that that is one of the major advantages to a single system is this ability to spread innovation from product to product to product, or team to team to team. Are there other examples where that's really been the case for you guys?
Neva Corbo-Hudak:
It's an interesting question. One thing that comes to mind, it's not quite answering your question, but I do also think when we shifted to this single system we also shifted our design tools. We moved to Figma, and we architected our Figma library in a way that better matches the way our code assets are set up. I feel like now our design teams in theory have a better understanding of how our code is built. So before we had built the styles into our old sketch library. So someone designing for, let's just go with Wayfair, has their button component looks like the Wayfair button. In reality, what is happening on the backend is there's this agnostic button that gets placed into a page in code, and then somewhere on the front end it says, oh, you're on Wayfair? It should be purple. Oh, you're on Perigold? It should be black and have squared off corners.
By rearchitecting our design assets to better match what we're doing in code really helps with cross-functional collaboration across our teams. So that's something I also think has really been a benefit. I think, again, we're trying to learn this new mindset. We're still trying to figure out how to better show and make those handoff docs and things even smoother or better. But it's another way that I feel like this new core system has helped us grow in a way that we hadn't necessarily been able to do before. So that design has a better understanding of engineering. We've named all of our variants to match our props so that when you're changing the variant on a component within the design assets it matches the same prop settings on the engineering asset.
Similarly, we're working right now, as we talked about moving to more composability, on building out more composable Figma components. Which is an interesting challenge for our XD folks to try to figure out how do we do that and still connect them to library components? So we're doing a lot of things with content slots, and then there's going to be a lot of learning for our feature teams on how to make those patterns that fit into those content slots. But it is an interesting new way that we're able to work better together across all of our pods and all of our disciplines.
Chris:
Yeah. I love that example as something that's really driving a new way of working. And when you think about that new way of working, I think that's a really great example, specifically from the design side, of changing the mindset about how you guys build software. From the engineering side, is there an analog to that?
Rogin Farrer:
Yeah, in a way. I'm glad Neva had a chance to share that. In the year leading up to that decision to merge systems, we'd actually been innovating a lot in the enterprise design system. We had spent many, many months adopting style components. We were previously using SaaS, because at that point we had had a separate internal tools and supplier experience. The components were the same, but they were code duplicates, because the way that our systems were architected historically. So we had to adopt these stylish components to solve that problem, but we were also adopting system props, which is a library that we created that provide some styling flexibility. It's similar to styled system, if our audience is familiar with that. And that was providing a lot of value to engineers. We were getting great feedback on that.
We were able to take those learnings and be able to start applying that to the single system that was also going to serve our eCommerce brands. So then we were able to take all that experience and learnings about refactoring the stylish components and already had a very clear path forward for adopting system props. We were able to bring the value that we were able to give one part of our business and very easily adapt that to the other part.
Chris:
Yeah. When you guys think about that value and representing that value to the people that are writing the checks, how do you basically justify the single system approach? Because I think that this is where a lot of teams get tripped up, is that budgets typically get handed out very differently across an organization. It's rare to see a single system out of a single funding pool that is basically continuing to get ongoing investment from the organization without an incredibly strong justification usually at a very high level inside the organization. How do you guys make that justification? And who does that justification ultimately go to inside of the org?
Rogin Farrer:
Yeah, that was definitely a big conversation that we had. In some ways we weren't sure how to answer that for the different parts of the business. For example, what we were seeing with the supplier experience was they were going from a more disparate, almost decentralized reporting structure and hierarchy to a more centralized having leadership that was going to spearhead this new platform. Because we were working with them very early on in defining the actual visuals and UX for what that platform could it be, our team was able to have influence, I think ultimately led to what was our storefront library catering well to what they were building. And being able to bring in our experience about research and user experience.
There's a lot of assumptions that are made about what an enterprise tool should look like and how atomic components should look like. Everyone normally thinks of an enterprise tool as being very sparse, very dense, small buttons, small fonts, tight data. And the designers on our team were able to demonstrate very clearly that, hey, if we actually think of this more about using just fundamental design principles about space and about appropriately sized tap targets, these systems are actually more compatible and this actually will end up being a better experience for the supplier. And ultimately if they can do their job more efficiently, that means more business for Wayfair.
Neva Corbo-Hudak:
Yeah. I'll add to that. I do think we work in a company that really does value design systems, and that helps tremendously. There's a lot of leadership buy-in. For instance, our head of XD, she is an advocate for design systems, as is the VP of our customer facing tools to the point where they launched maybe a year ago a definition of done for anything that's customer facing. And it includes having adoption, or what we call coverage of home based components at a certain percentage for all experiences. Because that leadership level, they understand the value that a design system unlocks as far as scalability and growth in particular.
So having that leadership buy-in really does genuinely help having that top down push to, frankly, require people to use the design system. I mean, it is an interesting path because a couple years ago, when we were separate and I was in the customer facing space, we had a employee who was hired whose job really was entirely to get buy-in for adoption of the home base our design system on those storefront products and tools-
Chris:
Like a hired evangelist?
Neva Corbo-Hudak:
Exactly. And her job was to go around and help teams measure how many components they were using, where they weren't, where they could transition things over and try to explain the benefit of using those components. One thing that Rogin can maybe speak to a little bit more because it's on the engineering side, our engineering team created an overlay plugin tool that helps teams identify on their layouts what is a home based component and what is not. So it really helped teams figure out where they were and were not using components, which ones are deprecated, and therefore need to be replaced. We did do a lot of work up front to get people on board.
Now we're actually at an interesting space where we have this buy-in, which is great. So where are we next in our evolution? If people are using our system already, how can we better support them? How can we grow our tools and our services to them? So it is an interesting change. We've moved from elementary school adoption to high school or college level.
Chris:
Yeah. No, that maturity journey is great, though. You're going from a place where you guys were in this heavy experimentation phase just trying to understand what's my baseline? How do I understand how my system's actually used and adopted? Now to a lot more forward thinking about, what do we need to think about next? What is the next stage of modularity, or the next stage in the component journey for this broader system? I love that.
Rogin Farrer:
The organizations we support have been interested in defining these relationships and what is next. Because part of this move to a single system was honestly changing our boundaries. Because our storefront system was more opinionated about actually what was part of the page, like these more complex components. We had carousels that were very specific about how the layout of the carousels would be, as well as our product cards is a great example. But when we're talking about, hey, that's not what our design system is for anymore.
Also, these other responsibilities that the design system team was taking that wasn't necessarily about the design system, but impacted global appearance and UI of the site. Those actually need to move into more of the domain specific expertise. So we saw that when we were working closely with the supplier experience teams that they put together a new team that was specifically for creating reusable composed patterns of the design system components that then were specific to other supplier experience. So that was tables that also had filters set up and things like that, where they wanted to have a standard for how tables appeared. Because there's a lot of tables in internal tools.
Chris:
That's super interesting, though, that idea of, okay, so we have this core design system, this broader composable set of things. And then we have the snowflakes squad that is making those things that is specifically focused on that composability. And the thing I love most about that is that they start with patterns. They don't start about what do we need to create that's original or new here? They start with the idea of, what can we compose? And I think that that's the powerful shift that design systems are broadly responsible for, is this idea that instead of our first instinct being able to crack open something and to start either drawing in Figma, or to start writing code in VS Code, is to actually look at what we've already built and see what we can make from that.
Neva Corbo-Hudak:
Yeah.
Rogin Farrer:
Right. It's been really important for our team to be involved in the conversations about what the role of these domain specific teams are, and their processes. So we were very involved in the governance model, for example, about these composed patterns. Because it is important to have evidence based solutions being put together other than assuming these are the patterns that an enterprise team might encounter.
Chris:
Yeah. So Neva, how does that look in design?
Neva Corbo-Hudak:
Yeah. It's a great question. It is interesting, because one of the things that we are thinking about now as next steps is how do we better support specific end user UI kits or pattern libraries? And from my standpoint, it actually makes a lot of sense to have those teams owning those patterns for themselves. What does the table look like? I don't know what the table looks like. I don't know that end user nearly as well as the folks who work on that specific team. So why should I be dictating how that pattern is shown to those folks? Leaning into that composition over configuration and letting the feature teams lead with their own patterns is really key.
Now, one of the challenges is, we're a pretty big org, so t's a lot of moving pieces. So how do we help folks establish their patterns that if we don't own them, somebody has to own it? And how do we establish those ways of working? How do we help stand people up so they can build patterns with home-based components?
Chris:
What are the workflows? What are the pathways for people?
Neva Corbo-Hudak:
Exactly. Yeah. And I think one of the things we're also working a lot on moving forward, one of our next steps in our growth maturity, as you mentioned earlier, is the idea of education or self-service for folks. So that's one thing that Overlay plugin does. While we used to have a person from our design systems team counting how many components are on somebody's page, we've now given them a tool, given our partners a tool that they can use. Where similarly in our move to Figma, we're able to see where people are detaching components, or we're able to see where people are implementing and placing them. If we keep seeing a certain input that's detached, for instance, that gives us some insights into-
Chris:
Hey, maybe there's something here.
Neva Corbo-Hudak:
Yeah. What do we need to support better? We keep talking about tables, but tables is a super challenging space, and it's not as easy to be build on the design side a table that as closely mimics what's happening on engineering, as it is to just stick a button on a page or draw a model.
Chris:
All those very data heavy experiences are always the ones that I point to as to where design tools and the web really diverge. For so long, we spent so much time relying on our design tool as this is the canonical representation of what should be. But it's so hard to do that with dynamic data, with all the different bits of things like charts and graphs and tables can change so rapidly. Really experimenting in code is almost a better medium for that.
Neva Corbo-Hudak:
Definitely. Some of the other things we've leaned into from the design side, like a lot of other design systems, is leaning into tokens to be able to provide those differentiation between experiences. If we have a table that needs to be data heavy and dense, can we use spacing tokens to adjust that spacing as opposed to having each team have to implement that separately or breaking the system into components? So how do we also represent that within our Figma assets?
We also have a cool plugin that one of our engineers made that does that theming for everyone. The styles are used for differentiation through our tokens, and it takes our agnostic design library assets and it themes them for whatever end user experience the design feature team is using. So that's one way they can see how it works and they can adjust... Those pieces will automatically adjust for them. We're building out some more support for that as we move forward. Right now we don't have spacing in there and we would like to. It really is an interesting challenge. But really trying to unlock a lot of that self-driven design choices for our end users. Our feature end users, I mean. There's too many end users here.
Chris:
We live in a world of meta, right?
Neva Corbo-Hudak:
Exactly.
Chris:
Yeah. I think that when you think about those consumers of your building blocks, those app teams, providing the service model for them that allows them to consume the design system more easily, I think that as a goal feels really canonical to this adoption story.
Neva Corbo-Hudak:
Yeah.
Chris:
If I'm getting this right, that's what you feel is the next evolution in the product, the design system itself?
Neva Corbo-Hudak:
Yeah. I think a lot. And helping work with our partners to help them define what their users need. Or help them build with home base, I should say.
Chris:
So that gets to a contribution question that I had, and this is something that is also core to design systems. We talked about those pathways and those workflows to consumption of the design system. What about the contribution pathways of workflows? Is that something that you guys have also really spent a lot of time thinking through? Or is that something that's still evolving?
Neva Corbo-Hudak:
Both. We have a number of different channels for contribution and engagement. I will say our documentation site is quite robust. It's unfortunately internal at this point, so we can't show everybody, but it is, I think, on our fifth version right now. So it's been around a long time. It originally was for engineers, and now it's been built out into a more content driven IA and approach that shows all the standard component pages, guidelines, patterns.
But we have within that site a section about contribution, and we really welcome contribution. But again, as we evolve the system and grow the system, that contribution process and the ways that different teams are contributing has changed. So there are some spaces that we're looking at. We had just a model where people put in a ticket, and sometimes we'd have people come into a study abroad where they sit on our team for two weeks a month and they build their own thing. We have Slack help channels and office hours where people come in with their questions or challenges. Rogin could speak a little more, we have an ambassadors program, where a number of our engineers come together to help us evangelize and build out and support the system with their teams.
But I think that some of the more recent things we're trying out are having some of our partner teams own... This is actually a better question for Rogin, because it's on more on the engineering side here, but have them own some of the changes they want to make. So with our brands, if they want to change a font, which happens a lot because our creative teams are always iterating on branding and marketing choices. Are there ways that our partner teams could own some of those choices and updates as opposed to us having to do it? Because it really is something that they own. Rogin, I don't know if you want to say a little more, because I just see the tickets on our springboard.
Rogin Farrer:
Sure. Yeah. Our contribution is really a giant spectrum of levels of engagement. We've always had, at the very foundational level, just tickets and letting us know. We have Slack channels let us know if a component... You're trying to do something and a component isn't fitting that. So that's just the kind of dialogue level of engagement. We also have office hours. We hold office hours twice a week where we encourage people to come. That's the next level above Slack channels and tickets. Have a conversation about it. Over the last couple of years we've really developed a more mature governance model, a whole flow chart that we put on our site to talk about, what does it mean to propose a new component? What are the requirements?
Chris:
I imagine that that is a long flow chart.
Rogin Farrer:
It is. We know the process is lengthy, but we also try to make it clear every step of the way who's accountable, who's responsible, who needs to be informed at every step. I should also mention, when we get proposals we do have a regular meeting where our entire home based team does review proposals. And that's an opportunity for us to ask questions about, hey, is this actually globally reusable? What are some feedback that we need to give back to the proposer before we make a decision about it?
And after that point, if we get to the point where with the proposal, if it's something as complex as a component or a feature of a component, or if someone reported a bug, we always, always, always are like, hey, we invite you to participate in this. You can fix this bug.
Chris:
Come join the conversation.
Rogin Farrer:
You can fix this bug. You can add this component in. And what Neva alluded to is, we've affectionately called our study abroad program-
Chris:
I love that, by the way. It's a great name.
Rogin Farrer:
Yeah. Yeah. It had an engineering origin many years ago that wasn't just the design system, but we really took ownership over it, where we basically will invite designers and engineers to join us, literally become part of our team for a sprint or two sprints. And usually it's very specifically to accomplish something. Very recently we had a proposal for a new component that came from our product page, and we had a number of other places in the e-commerce experience that was like, hey, we can actually also use this. It had global reusability. Once that proposal was accepted, an engineer from that team came and joined our team, attended all of our sprint rituals, all of our meetings, were invited to our Slack channels, and got to be part of the design system team for the period of time it took to implement that component in our system.
Chris:
And what a cool way to have that be your touchpoint to a design systems team.
Rogin Farrer:
Right. Sometimes people just come and say, "I don't really have anything that I specifically came to work on, no product reason to join the team. I'm just really interested." We have one coming up in January where an engineer is like, "I don't get to do this kind of thing on my team. And I'm really interested. Could I join you for a sprint? Whatever tickets you want to give me sounds good to me." And that's great, because that also plays into the culture of supporting a design system.
Neva also mentioned that we have an ambassadors program that was actually started by engineers outside of the home based team, the design system team, that were just really passionate about design systems and wanted to see it proliferate more and have better adoption. Also, be able to have input on what our roadmap looks like, talk about architecture for components to make sure that it was also what the storefront application needed.
Chris:
So what I love so much about this conversation is seeing what it looks like to have an organization that is so bought into the concept of design systems and how they change the way we think about building products. And so from the maturity model you guys think about to the adoption of a single system, to the way that you think about spreading this culturally around the organization, adoption is so core to the success of this. And it feels like you guys have really cracked the code for this. Just as a final thought, what are some of the other benefits that you've seen organizationally that this change has brought to your teams?
Neva Corbo-Hudak:
Yeah. There's two big ones that I would love to highlight and that we're working towards, is that this allows us to have experiences that can call to more than one theme in one space. So if you think about something like our B2B space, you could imagine a use case where there's a B2B header, but the content area is styled to match one of our brands, like All Modern or Joss & Main. Or on our supplier tools. A supplier might want to see what their product page will look like on site with the correct branding. So having that core system really will unlock that for us.
The other piece that I find really important is we really are prioritize accessibility, and it's incredibly important for all of our end users to have accessible experiences. So by building accessibility into our core foundational library components, that is on the engineering side of things so that the Aria, alt text, all that stuff, is correct. As well as on the visual design side where our contrast ratios are correct. If we build that into the core library, all of those pieces flow out to our end users. So we're sure that anybody building with our design system is building an accessible experience. So both of those are really, really important to us.
Chris:
Build it once the right way, and then everybody sees the benefit of it.
Neva Corbo-Hudak:
Yeah. And it scales out. Having that shared foundation allows us to do that in one place, and not have to make sure every single separate system and end user experience meets those criteria.
Chris:
Rogin, any final thoughts from you?
Rogin Farrer:
Yeah. To touch on a little bit what Neva said. We were getting requests for years about, "I'm a team that's building a internal tool that's supporting a part of the customer experience. And that means we have to have this internal page that's showing what the e-commerce page looks like." Or to integrate for a customer service agents, for example, who are actually... A lot of their work is on the customer site, but we need a part of that site to have the internal tools interface. We've always just had to say, I'm sorry, we can't support that. And then now it's very clear product value there that they can have it. They can have everything.
And the other thing I would mention about the value of consolidating our systems, and that was very clear to give, is that we more than doubled the number of people that were supporting a given space.
Chris:
Oh, wow.
Rogin Farrer:
We went from the enterprise design system has three dedicated engineers, and then five dedicated designers. And it's suddenly, actually our library design system engineering team is nine people, and we have a design team of 15 people. It was just very clear value there. We can dedicate more time to writing tests once really, really great. So we have an automated testing suite that we can put more of our effort into that benefits everybody. Developing APIs and architectures. That we have the ability to focus on specific parts because we have more people. It was a very clear value we could provide to the company.
Chris:
Awesome. Well, hey, Neva, Rogin, so great to talk with you all. This has been an awesome conversation. Loved learning about what your team has been able to accomplish. Can't wait to hear about what's next.
Neva Corbo-Hudak:
Thanks, Chris.
Rogin Farrer:
Thanks so much. This was great.
Speaker 4:
That's all for today. This has been another episode of the Design System Podcast. Thanks for listening. Our producers are Ryan Peterson and Shayna Hodkin. Our musical composer is West Willis. Our editor is Zach Marcus. 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.
