The following is the transcript of our most recent podcast recording featuring Corey Greeneltch, Head of Design Systems at Compass. Listen below:
Chris Strahl:
Hi, and welcome to The Design Systems Podcast, a place where design and development overlap, brought to you by Knapsack. Check us out at knapsack.cloud. Hey, everybody, Chris Strahl here with The Design System Podcast. Today I'm talking to Corey Greeneltch. He's the director of design for Design Systems at Compass. Welcome to the program.
Corey Greeneltch:
Hey. Thank you, Chris. I am super excited to be here to talk to you.
Chris Strahl:
Yeah. We actually ... It's great to chat with you again. We had a prior podcast that we were recording that we never actually got to release for various reasons. It's really good to have you back on the program. Super excited to talk.
Corey Greeneltch:
Yeah. I was really, really sad to have that one not hit the air. I really enjoyed that conversation, so yeah, excited to get some more time with you.
Chris Strahl:
Awesome. Well, one of the things we wanted to talk about today was starting off with teams. You have a design team that works with you on the design system at Compass. I think that you had some really interesting thoughts about the composition and the makeup of that team, and how that's really kind of influenced the contribution model within the design system space.
Corey Greeneltch:
Yeah. Been super excited about working with Compass. One of the things that really brought me over to that opportunity was during my interview processes, you always ask the question of: How much is this company investing in a design system team? Are you saying, "Hey, we need to have a design system and you're going to need to figure this all out"? Or are there people waiting to help with this? And I've been super fortunate at Compass to step into a situation that's incredibly well invested. I've got an engineering partner with a full squad of web engineers. And we have a few iOS engineers and Android engineers. I've got a really well staffed design team. I've got a product partner. It's such a rarity, and I know everybody listening who's on design systems [inaudible 00:01:47], I'm sorry. I feel bad for you.
Corey Greeneltch:
And I've been on both sides, so let me just tell you, it does get better. But one of the things that I had the opportunity to do when I started working with Compass is hiring and adding more folks to the team from a design side of things. And I happened across, and this was total coincidence, a recruiter reached out to me and said, "Hey, there's this person, Carrie Martin, and she's been working in Figma for three years." And we're like, "Wait, nobody's been working in Figma for three years. That's crazy."
Chris Strahl:
Right, one of the early adopters.
Corey Greeneltch:
Yeah. And we were like, "Okay, let's talk." And we ended up bringing her on board to really just focus on Figma. Like I said, it all kind of just fell into my lap. It wasn't really a whole lot of strategy, but it just became apparent that this was such an important thing.
Chris Strahl:
Got you. So you've got this situation where you came in, and you have this very fortunate setup where you have an engineering partner. There's an understanding that design systems are multidisciplinary, multi team. And then you were able to find this person that was really fantastic at just understanding how to use Figma very effectively. Kind of give us a sense, I'm sure that there's people that are listening to this that are salivating with envy right now over your setup. But I think that this is kind of like a good framework for thinking about modern design systems team. What has this enabled that you didn't have in previous roles or in other opportunities you were looking at?
Corey Greeneltch:
Yeah. As we dip more and more into Figma as an enterprise tool, it just becomes more and more complicated. And having someone who is dedicated to managing your Figma libraries, managing the Figma experience, which is something that we spend a lot of time thinking about, our builder experience, Figma is not an easy tool to use. It's got a steep learning curve and we tend to forget really quickly that designers and even developers need help using it. You can't just send it out there and have it grow on its own. We used Photoshop and Illustrator for 20 years and there were still people figuring that out.
Corey Greeneltch:
So this has really enabled us, like I said, to focus on that singular entry point of experience, and to really be on the ground where the designers are. And the designers are in Figma right now.
Chris Strahl:
Yeah. So when you talk about managing those Figma libraries, what does the practical application of that look like? Is this about structuring things around components? Is this about using the more enterprise features around management of variants? Or is this about something more, about how you actually present those files to the broader audiences?
Corey Greeneltch:
It's all of the above, but how it culminates in the presentation of those things is key. The design systems need to be where the people are. I mean, any product that you build needs to be where your audience is. And half of our audience of our builders, the designers, are in Figma. So crafting that experience, getting into the nitty gritty of the components and the variants, and making sure that everything is accurate and makes sense, but also adding some light documentation into those, really designing your sticker sheets and combining those with your libraries, having an effective team strategy for how you're going to roll your design system out and include all of your designers and developers and teams, so it automatically shows up in their software. There's so much to it. I don't understand how we did it before.
Chris Strahl:
And that does bring me to kind of an interesting question. Right? So when you think about the engineering side of things, and in particular how developers are consuming the structure and the components associated with Figma, what does that look like for you guys? How are you able to take a design intent and express it in a way that an engineer is going to be able to understand?
Corey Greeneltch:
We just recently cut loose our Zeppelin contract because we really believed in this strength of Figma in the handoff process. So it does require a lot of education on both sides. And we have active developer onboarding for, hey, here's how to use Figma. When a designer hands you the file, here's exactly how you go through what is there. Here's how you tell what is a component. Here's how you inspect different items and how you can kind of relate these designs back to the design system components, which then we go through all the work on the back end to make sure nomenclature is synchronized across everything, so that obviously the Figma component matches the naming component, matches the tokens, everything is there.
Corey Greeneltch:
So if you've done all your homework and you've set up all the foundations in Figma appropriately, and hopefully the ... And you've educated your design staff on how to use that, and then you've educated your engineering staff on how to receive it, that is the process. That's how you create much more seamless, much more efficient handoffs.
Chris Strahl:
Got you. And so when it comes to the structure of those teams, you have this person that is dedicated to the management of essentially this tool. And then you have an engineering counterpart on, I guess air quotes here, the other side of the kind of systems application development side of things. Is there a counterpart inside of engineering that is working, and I believe you said that her name was Carrie, is there an engineering counterpart that's working with Carrie on a daily basis?
Corey Greeneltch:
Not necessarily. I think that all of our ... We have really fantastic engineers. There's some of those unique people that it's not service based. They have a broad interest. And so they are in and using those sticker sheets and those libraries as well to make sure that the names are there. But there's not necessarily ... What we're doing is leaning more on the design resources to help educate the usage of this design tool for both parties.
Chris Strahl:
Got you. And so when it comes to the engineering side, you mentioned naming a couple of times. And so the intersection point is really for you guys around nomenclature. I mean, naming is one of those traditionally difficult problems. And I also agree that there's a lot of power in the ability to connect things, just via a name. Would you say that's the number one way that you're able to kind of bridge that gap between design and engineering?
Corey Greeneltch:
It's super helpful, when you think about the process of an engineering kind of receiving this handed off file and being able to make that instant connection, that experience, to be like, "Oh, I'm inspecting this and I see the name of that component, or I see a token." And you're like, "Oh, I know what that is." That connects me mentally over here to Storybook, or whatever resource I'm using. We have got some example [inaudible 00:08:51] file as well. But to make that kind of spark fire, that's the only ... I mean, you can have linkage in there, and we do kind of link to our Storybook and help to increase the jump from, okay, associate this file with those files. But yeah, naming is incredibly powerful with those things. And then also, obviously, the engineers work pretty closely with our token files and injecting those into Figma, so there's that seamless integration.
Chris Strahl:
Got you. It's interesting because there's a lot of focus in that common workspace, that place that is between design and engineering. Most people are doing what you guys are doing, which is a convention structured way of managing, not just the handoff, but the actual collaboration around design patterns inside of Figma and code patterns inside of a code repository, and then obviously, the tokens and stuff that are also associated with this. So when you have these designs and intentions expressed in Figma, and then you have this set of coded components that exits in Get. There's a conversation that usually happens between design and engineering that is about the establishment of those patterns. And what you guys are doing right now is what a lot of folks do, which is sort of managing this in convention. What does that conversation look like when you're basically saying, "This name is equal to this name, or this token is equal to this other token"? Where does that take place?
Corey Greeneltch:
One thing that we do that I think is helpful, and I don't know if anybody's really solved this super well because you're dealing with two different, a foot in two different states when you do that, but we actively work together as designers and engineers to work to kind of co-design the API. So at the component creation level, when we are creating new components, we're working together to define those requirements and the scope at that level. And I think what you're asking a little bit more about is kind of as those come together from components more to patterns, and how that nomenclature works. And we don't really have a great system of dealing with that right now.
Chris Strahl:
Got you. And selfishly, that's kind of what we've been focused on at Knapsack, is trying to get to that point where you can create this common understanding between these different worlds because they are very different things. And we kind of view us as the workspace, where that exactly gets done.
Corey Greeneltch:
Yeah. That's one of the things I really, obviously played with Knapsack, and having that playground, that shared space where you can actually manifest those things, that is super helpful.
Chris Strahl:
Thinking about then, the contribution model to this, you have this common idea, this common education, this common understanding of how things in Figma work, how things in code work. What kind of contribution model do you guys use to continue to build upon the design system and continue to improve it?
Corey Greeneltch:
Contribution is such an important part of our daily conversations now. It's an interesting thing that I think the design system community sometimes thinks that it invented itself. We're like, "Oh, what if we figured out a way to have contribution to this?" And one thing that we do is we look a little bit at the established models for open source because a design system, it's just open source software that is intensely aligned with your business priorities and the experience you're trying to create. Really at the core of it, that's all it is.
Chris Strahl:
Right, it's extremely federated. There's lots of different contributors from all over the place. And really, that contribution model where you have this product that is innately built for the consumption in other products, it lends itself very much to similarities in the open source world.
Corey Greeneltch:
Yeah. So we lean a lot on that maintainer model. We're leaning into the community itself. One of the things that we wrote down as tenets within our design system at Compass is that we are curators, not creators. That is what we use to make decisions. Unless we have to, there are sometimes where we have to kind of lean into a pattern or lean into a component because there's such a wide spread of opinion around it. But in general, what we try to do is just get out of the way, is to never, ever be a blocker, never have teams be dependent on us making something.
Chris Strahl:
Because then you're a bottleneck. Right? You hamper the contribution and the adoption of your system within other teams if you always are the gate that people have to jump through.
Corey Greeneltch:
And there's no reason for that either. I think the most efficient thing that a design system can do is be present, be part of the community and the culture, so when teams are building something, they're going to come to us first and say, "Hey, we need this component. Is it on your roadmap?" And we're going to say, "No, that totally does make sense. We're going to look at the wider scope. That is something that probably should be in the design system. Go for it. Run. Build it."
Chris Strahl:
What would you say to somebody that says, "That feels like giving up too much control"?
Corey Greeneltch:
That's not where your energy should be, my friend.
Chris Strahl:
That's a common objection though. Right? The idea of I have this centralized system, and that centralized system becomes a power structure for how people control and manage what ends up in their applications. And I love this particular conversation because it really showcases how the dynamic between a central system and the consumers of that system really plays out. So I'm curious your thoughts on this.
Corey Greeneltch:
And that's almost kind of what the major differentiators between regular open source and design system, politics and governance kind of gets into. That's one of the major differences. I mean, I would say from a control perspective, what we try to do is just get out of the way. I think the teams generally, we try not to get too involved. We try to make sure that, hey, make sure you check with this other team because they're doing something similar, or maybe we establish a bit of a consortium and say, "Hey, product manager one, product manager two, these guys are doing something similar. You should at least kind of keep your intent in check." But really what we want to do is get out of the way, let them launch. And then we'll take that component. We'll globalize it. We'll figure out all the use cases for it because it's already built.
Corey Greeneltch:
And if things do change, I mean if things change significantly, then sure, that's a problem. I don't think that's a huge likelihood. So as things change, that originating team can inject that back into their system at some future point. But the company as a whole has benefited from their work.
Chris Strahl:
Right, and that's I think the value of contribution is what you've hit on right there. Right? The contribution doesn't have to come from any one person or any one team. It can be very federated in the way that people are able to improve the system. It's sort of like the hiker camper model. Right? Leave every place you visit better than when you arrived.
Corey Greeneltch:
Right, right. And you just keep getting more and more efficient over time, at least at the component level. Yeah.
Chris Strahl:
So thinking about this then in terms of a workflow, because it is important to think about the governance model, workflow side of it. But just try to kind of understand how you've adopted this river of design methodology that we've kind of talked about previously. Before the show, you were articulating you have these requirements that come out from business or technical stakeholders. You have a design process whereby those get transformed into Figma files and a representation of the intent of how you solve these business problems. And then that ultimately goes to development engineering, to actually build those things into a product. Kind of guide me through your thoughts about those different stages in that process and how that's really changed for you as you've gotten to this higher level of maturity within the design system.
Corey Greeneltch:
Yeah. And that's something that is constantly evolving and changing at Compass as a whole too. I think it's a really interesting, not to go too wide on this, but it's a really interesting time to be there as this company starts to take a more and more opinionated perspective on building tools for our real estate agents. There's been quite a lot more focus on the product requirements, on the user research. But I think from the perspective of the design system, what we're trying to do is, as all of these different teams start to move away from silos, and that's kind of a place that we've seen over and over again, is that product teams running certain features and feature teams owning features, and there's this squabble and fight over ownership of different areas, we're trying to get away from that as a company. And we're trying to break more into flows and to customer journeys.
Corey Greeneltch:
So really, the design system ends up being kind of the control tower. So all of that work that you mentioned, that whole river of design is happening of product into design and engineering, the design system is still the place that you can go to, to kind of get connections across all of that work that's happening.
Chris Strahl:
I love the thematic idea that the design system represents the connection between teams. One of the things that people love to think about as a representation of design systems is scale. Right? Design systems help you scale. They let you get 30% more out of your engineering team, or your design team, or whatever. But one of the things that we tend to espouse a lot is the ability to kind of break down those barriers between teams because in a more traditional sense, if you have some really interesting, unique thing that's happened in team A, it's oftentimes very difficult to take that really interesting thing from team A and spread it to team B and team C. And I think a design system is really a big part of breaking down that barrier between those different feature teams or product teams.
Corey Greeneltch:
It's huge. And today's culture, as we grow into larger and larger enterprise companies, we lose this idea of a creative director, of a single point of contact for connecting these experiences. So with the design system, we spend a lot of our time answering, quote, unquote, product experience questions, and just kind of giving opinions on things that are more user experience related, rather than: Is this the right component to use? Is there the right variants to manifest this intent? We are quite nosy intentionally. And we try to caveat always to be like, "Hey, check with your product people and verify what you're trying to do here." But we really become the sidewalk, the place of congregation for discussion of a lot of these things, which I love, having that, especially in today's remote culture and we don't really have the connections that we have, the design system can be the place that everybody converges and has these conversations in the open.
Chris Strahl:
Yeah. I mean, you brought up culture. I think that what you're describing sounds to me like culture change inside of an organization, where you had this more siloed, more independent, more I don't know, conflict driven. I'm not sure that's even the right word, but less collaborative sort of approach to how you build products. And you had those voices that were singular people, or folks in dedicated roles that were attempting to create some sort of cohesive experience across the entire organization.
Chris Strahl:
Now that's sort of shifted, and culturally it's about the ability to share, collaborate, create inside of a design system that represents this more federated, more open model of contribution and use, where people are still picking the things that they want to use, and they're still making individual product choices for their individual product teams, but you guys are there to kind of represent the best practices, best case, for how these things all get built. Would you say that's a fair sort of direction?
Corey Greeneltch:
That is totally fair, yes. And as you were talking there, I had this mind, I come from the era of the internet where pre social media were forums. The forums were that's where you got all your information about everything. And as you were talking, I was like, "Wouldn't it be super cool if ... " We always equate design system to Legos. It's almost like this place, this forum, where people come and say, "Hey, we're all using the same Legos. What did you build with those Legos. Let me see what ... And I did this with these Legos. Isn't it cool? I have questions about these Legos." It's a commonality of because you're using the same tool sets. You're kind of trying to follow the same rules, but you're trying to break the rules intentionally and you're trying to make better experiences using these things. So yeah, design systems bring a common language to all of these designers who might not think that they have anything in common with each other.
Chris Strahl:
Yeah. And I think that the wonderful thing about Legos as a sort of metaphor for design systems is that Legos are fun. Everybody talks about how the Lego thing is a little bit tired. I personally love it, and it's not just because I used to run workshops with Legos to represent design systems. I think that it does kind of show the playful side of all of this, and how people should be coming together to try to understand the different ways that you build with the same basic parts. And I think it's really cool that you guys have kind of embraced that idea.
Corey Greeneltch:
And build and break. That's something I always want to emphasize. Please, try to break the Legos. Do cool stuff with it. I don't ever want people to come away from an experience with the design system thinking, "Oh, it's so buttoned up and rigid, and you have to follow all the rules." To your point, all of this should be fun. We became designers because it's fun. We enjoy doing it. And to have to then kind of fit into this super rigid rule set that you have ... And all the solutions are there, and they've all be answered for you, that's no fun. Take them, break them, explore them, do crazy stuff with it. Let us know.
Chris Strahl:
Totally. I think there's a lot of people that really kind of love to embrace that philosophy. I think that it's sometimes hard for organizations to get there because it is kind of nontraditional. And one of the interesting things about this conversation is, it's obvious that you're at a fairly nontraditional place. We talked at the beginning about how you have resources that you would've never even dreamed of in prior parts of your career. And there has been this embracing of both a culture change as well as a change to the fundamental way that you build product as a company. Where do you think the adoption side of this conversation happened? I mean, there is obviously the ability to adopt a model like this where it is fun, it is playful, it is decentralized. And you're not gatekeepers. But how does that adoption happen? I think that there's a lot of people that want this sort of thing, but they just don't know how to get there.
Corey Greeneltch:
We're so lucky. And I want to definitely acknowledge that gratefulness that I am of the situation I'm in because Compass is at its heart an engineering company. It came about from tech. The design system was built by engineers, some really, really fantastic engineers. Dave DeSandro was part of it. Donnie did a lot of stuff. So it really came from this, the infrastructure was built. The plumbing was built. And then we're simply applying design and thoughtfulness to it almost after the fact. But so at Compass, adoption was really second nature because it was always there. And engineers across the board knew that it existed and what it was. And having worked at a couple different places, that is not something that I take for granted. That is a game changer when you're initiating a design system, is that you're getting the hearts and minds of the engineers, and you're building for them.
Corey Greeneltch:
Compass has never really known life without a design system. So when you talk about adoption and where did it happen, adoption's always been there. We're not adopting a child. The child was born at the company. So where we are with adoption is, it's something we talk about a lot, but we have a nuance of definition there because it's not about like, "Hey, how do we get people to use this stuff?" Because they're using it.
Chris Strahl:
Right. It's ingrained in the way that you work.
Corey Greeneltch:
It is absolutely part of the ... We literally just finished, I think an hour ago, we had our annual hackathon results. And out of I think 30 some projects, I think there were maybe two that had UI that didn't use the design system. It's just how we work. So what we're trying to push the needle on in terms of adoption is going wider than that. I was talking to Ben Callahan from Sparkbox the other day, and we were talking about adoption. And he brought up something that kind of blew my mind a little bit around adoption is, adoption's not just about how many features get released in your product that are using the design system component. The design system is so much wider than that. It enables, we talked about these hackathons and R and D. And how many components are being used in Figma that those designs never saw the light of day? But you have made a difference on someone's life, so you have a ... That designer has adopted. They have used your design system to create with. And that's ultimately what you're going for. So how do you get wider?
Chris Strahl:
Right.
Corey Greeneltch:
How do you think more creatively about it?
Chris Strahl:
So I mean, just the nature of using the design system to do something to innovate, it's akin to what you were talking about, about breaking the Legos. Right? It doesn't necessarily matter that you had something that ended up in a final product. But simply using the design system to experiment and to iterate, and to break some things, has value.
Corey Greeneltch:
It does. And we need to give ourselves credit for that. As tech companies in general, we need to give ourselves more credit than just the things that hit the ground. It's about learning from your failures. It's about the tools that you use to get there. We need to be more holistic overall. But yeah, design systems are ... It's not just about the finished product. It's about the culture.
Chris Strahl:
Yeah. I also think there's a rapidness to innovation here that's really interesting. Right? We always talk ancient history now, but the mythical man month, and the idea of building one to throw away. When that innovation cycle for building something to intentionally discard it is very short, that provides a tremendous amount of value to the organization. I love your hackathon example, by the way. I think that, hey, look, we did 30 proof of concept slash new ideas, and almost all of them used the design system to implement a part of it because it was faster and presumably better than building it independently. And so now the design system's not just a tool we use to build product, but it's actually a catalyst for innovation.
Corey Greeneltch:
Yeah. And it is, just to underscore it, I think that adoption should evolve, or maybe it's shorthand for: How invested are you in the community, in the culture? Adoption is just a number of how many components are being used, but taking that up a notch to be like, "What percentage of the lifeblood of the organization are you?" It's fictitious metric land, but yeah.
Chris Strahl:
Right. But I love the idea of thinking about it as more than just counting components. Right? I've always viewed that as, yeah, okay, that's a data point. But it's sort of short sighted in terms of understanding the overall value of a system. What Sparkbox has done to show that adoption is more than just a number, if [inaudible 00:28:49] the really great reports and stuff like that is fantastic because I think it's starting to change people's minds that it's not about: What's your coverage of your design system? Right? This isn't like functional testing where you say, "I have X percent of my features that are fully tested." It's a lot more about: How is this actually getting used in the creative process, not just in the end product?
Corey Greeneltch:
Yeah, exactly. Your components are products in and of themselves. There's a lifeblood to them. They should be growing and evolving and dying and collapsing and re-birthing. Every single one of your components should have that level of life to it, so it's all this living, breathing system, and so I think we have a lot of difficulty because we're trying to be a business. We're trying to be really objective and have numbers wrapped around it. But we're also trying to be part of the living, breathing, learning, loving, dying part of the company. It's hard to measure both sides, obviously.
Chris Strahl:
There's a lot of sort of talk in that sense of this organic nature of design systems, the atoms, molecules, organisms conversation, the idea of how you care and feed a design system. There's all these things that relate to it, much more like an animal or a person. And that personification of it, it can sound kind of a little bit woo woo, but it is really true. Right? This idea that this thing should grow and evolve constantly because the requirements and the needs of the business are growing and evolving too. It just speaks so much to how the work in the design system is never done. And this just needs to be a cornerstone of the way that people think about building product.
Corey Greeneltch:
It is. And that's exhausting. I love it, but it's tough because you're always, as humans, we're like, "Okay, just going to climb that hill."
Chris Strahl:
Right.
Corey Greeneltch:
All right, once we climb that hill, we'll be good. And then everything will be fine. And then you're like, "Wait, there's another hill." It never ends. You're constantly going to the gym with your design system and making it better and strong. And there's never an end to it. And I personally try to make that more fun. That's okay, that's life.
Chris Strahl:
Yeah. Maybe I'm going to reveal a little too much about my nerdy-ness, but I'm playing the video game, Hades, a fair amount lately. And one of my favorite conversations in Hades is with Sisyphus, the person sentenced to push a boulder uphill continuously, and how he has a friendship with his boulder. And I love that and this idea that it's not about whether or not you can make it to the top of the hill. It's about having this sort of sense of accomplishment and camaraderie along the way.
Corey Greeneltch:
Yeah. That's terrifying, but great.
Chris Strahl:
Well, now that I've freaked you out about the fact that you're going to be constantly pushing this rock, I hope you're able to form a bond and a friendship with it. And it sounds like you really have.
Corey Greeneltch:
I have, yeah. This is the work that I was made to do. I'm super duper stoked about it. In my heart, I came up through the era of design and the wonderful world of flash in the early thousands when there was the wild west of design. But I really found my people in information architecture and system design. It just brings such pleasure to me to make order and to make a little marble run that works, to understand how a machine functions and to really, really get into that. So it's my favorite stuff, I get way too excited about it.
Chris Strahl:
Awesome. Well, hey, thanks Corey. I hope you keep pushing back about the entropy in the world, so I really appreciate you being on the show today. And thanks so much for sharing your point of view.
Corey Greeneltch:
Awesome, man. Thank you so much for having me. It's been a blast and we'll talk soon.
Chris Strahl:
Cheers. 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 at the DS Pod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. Check us out at knapsack.cloud. Have a great day.
