Jess Clark from LinkedIn: Old tech, new tech

Jess Clark and Chris discuss the meaning of design systems and the potential of design systems as a service. What can design systems offer us beyond infrastructure? How can approaching design systems as products, rather than repositories, increase their capabilities?

January 5, 2022
by

On this episode of the DS Pod, we interviewed Jess Clark from LinkedIn. Listen to the episode here.

Chris:

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. Today, I'm here with Jess Clark. She is the senior manager of design systems at LinkedIn. She's here to share her thoughts on play, discovery, what they've built over there, and also talk about how design systems are changing the way that their team works at LinkedIn and creates new things. Welcome Jess, really glad to have you.

Jess Clark:

Thanks, Chris. It's great to be here.

Chris:

We started recording arbitrarily because the conversation we were having was just great. We were talking about old tech and new tech and how our dads are the people that we try to explain our work lives to. So we're going to take that as a lead in and jump right into the episode. So I guess the old tech, new tech thing that's kind of fun is my dad is an engineer. He's a civil engineer, very engineering mindset oriented. The way I have to explain design systems to him is always using terms that he's familiar with. He's relatively tech savvy, but at the same time, definitely has never built a website. The fun thing is he builds bridges and parks. And I was like, "So when you go down and you sit down to build a bridge, do you Sketch out every single beam and every single cable or do you think about what is a modular thing that I can do over and over, and over again and just repeat?"

Chris:

And he's like, "Oh, so you're the one that's telling me that I have a bunch of prefab stuff that I need to figure out how to stick together." I'm like, "Yeah, that's it exactly."

Jess Clark:

And even just the terminology, we're moving from this term of design systems to design infrastructure, it starts to get very close to that.

Chris:

So tell me about that because I think that that's a super interesting idea of how this is changing. With all this stuff that flies around this kind of like the new hotness, like network design systems, design ops. I mean, that one's even old hat now. So like design infrastructure, what does that mean to you?

Jess Clark:

It's been around in engineering I think for a little bit. So I think design is trying to figure out what it means for us. As design teams grow and support for design grows, the value of design is becoming known and really relevant to companies in terms of contributing to the business. I think design infrastructure has definitely been a word that's been thrown around that to me really means what is the foundation that you're building for your design teams to be productive and successful every day? So how are we building not just the design system, which I think is the starting point and that's a product that we deliver, but there's so much more than just delivering on that product. There's the service that comes with that, there's the tools that come with that, there's the operations that come with that.

Want to listen to the episode? Check it out here.

Jess Clark:

So it starts getting much bigger in terms of, okay, designers have this product now that they're using. But then you end up needing, "Hey, where is the support when things go wrong? Where is the tooling to help me be even more predictive and successful? Where's the guidance in terms of how I build upon the foundation that you've already given me to exponentially help me do better and do better work?" So to me, design infrastructure is really building upon the foundation that was design systems, it's just growing, it's just so much more now.

Chris:

I really want to dive deeper into that because I think that that's ... That's the fun stuff, right? I have oftentimes been accused of poo-pooing the design system process in favor of what happens after you get the design system. And I mean, this is all headed this way. Once everybody has design systems, which we make strides towards that every day in this community, the question becomes, okay, so now what? And the now what is the more fun conversation to have rather than this is how we implement a design system, which is still important and still relevant. But once you actually have it, now all of a sudden all this other stuff is possible. That's definitely the more fun thing. What this reminds me of is echoes of the DevOps revolution from a decade ago.

Chris:

Remember when all of a sudden you had cloud computing that was accessible through things like AWS and stuff like that. And you actually had these DevOps practitioners that would come into organizations and rejigger the way that people would think about infrastructure. And I think that we're facing that same sort of thing now at this code and design level that is very reminiscent of those early days of the ops transition.

Jess Clark:

Yeah, definitely. I think that design systems has gotten to the point where we can be thought of as librarians. But we're moving from librarian to more of an inventor, an astronaut, someone who's going ahead and exploring new territory. And I think it could be done in a few ways, new types of roles like Jennie Yip talked about with design technologists, new ways of working, new technology that helps us work. So I see that design infrastructure going from I'm a librarian, I'm creating standards, I'm auditing, I'm making sure that we're all going the same direction to actually moving more in the front to say, what direction are we going in? I think a lot of times the people that are on design system teams, we see things before they're coming, we see things on the horizon. And now's the opportunity to say, okay, we've got a really great product, where are we all going? Where is the whole design team and this company going, and what can we put in place or what can we investigate or explore that's going to bring everyone along with us?

Chris:

Yeah. Sorry, I love that. I think the investigating and exploration, one of the things that I've enjoyed most about our pre conversations has been this idea of play and how you work play into the way that people explore and discover and really utilize the infrastructure I guess that you've created. I think that this is one of the most interesting aspects of how you get people to not just adopt a design system but really love it and use it and get a ton of value out of it is you give people this opportunity to experiment. And I think that the way that you've done this is really insightful. And it goes from a very fundamental level of what you view your role as in the organization. So can you talk a little bit about that? I want to understand how you build up this idea of experimentation and play based on how you view your hand in guiding this project?

Jess Clark:

Yeah, thank you. I think it's really interesting as a design leader, I'm leading the team, but my team is the one doing all the really great work moving everything along. So I'm trying to create a space for them to do that exploration, to feel free. But we also have to get stuff done. So I think it's my job to really balance how are we setting the foundation, but how are we creating space to move forward? So my role starts to feel really meta because I feel like I'm creating the foundation and the play space for my team to be able to do their best work and to just run and explore. And then my team is building the product and the infrastructure in order to help all the other teams have the space to be able to explore and run forward and innovate. So I find that part of my role just really enjoyable and really fun.

Jess Clark:

So a couple of ways that I try to lead by example for my team, one is just in the team structure. We've run the third iteration of our design system. And with all of those different stages of maturity, the team has to be structured in a different way. So we started out by saying, hey, we had this like rep, run, rally where we had people deep in the building, and then we had people going and evangelizing about it and talking about it. And then we moved into this-

Chris:

Wait, wait, so rep, run, rally. What does that mean? Explain that to me.

Jess Clark:

Yeah. So rep was ... Well, we'll start with run. Run was the folks who were really deep and just creating the engineering specs and moving the design forward. Rep was people that went out and sat in different teams to help the other designers apply the design system, which was really helpful in the beginning of the system because we didn't really have a system. We're really collecting and auditing at that point. And so those people really were in the different products still sitting on the design system team and bringing all those ideas back and helping the teams really push it forward. And then rally was what we called the design ops and design managers who our job was just to go out and sell the thing. Because at the beginning of a design system, as you're well aware, it's really just about selling the value and helping people understand what a design system is by a lot of Lego type-

Chris:

Yeah, yeah. Houses, Legos, all the stuff, bridges, parks, whatever. So that was the OG crew, as you put it, that was really about implementation and adoption. And then from there, you've shifted as you've started to explore this new model of, okay, we have this design system, it's established. Now, what do we do?

Jess Clark:

Yeah. So the foundation component and library team really came from this new world we're moving from Sketch to Figma and a whole bunch of stuff is coming down the line. So the foundation folks were really focused on design tokens like, what are design tokens? How do we do this? How do we bring the brand to the product? The component team now that we were at a mature stage was thinking about accessibility and all of these things interaction that we really had to think about, which was a really different skillset. And then libraries, the library team was really just working on moving from Sketch to Figma and trying to figure out what tools we're going to use and how we're going to use it to the best of our ability to provide the product to the designers.

Chris:

So talk to me a little bit more about the foundation team. I've been on this design token kick lately. I think Adam Argyle at Google and I talked for like three hours the other day about design tokens, so I've been really into this. Tell me about how you think about how things flow from this foundation of tokens? Because I think this is a cool concept.

Jess Clark:

Yeah. Talk about experimentation. This has been really a lot of work for us the past couple of months and probably year just thinking about how to build a design token infrastructure that ladders up to the product that you actually want to build and you want to provide. So I think this takes a ton of experimentation not only between design and engineering, but in this loop of discovery that we're talking about. Because you first create some tokens, you apply them to the components, and then you discover new things, "Oh, that's not the thing that I wanted to move. That's not the thing that I wanted to theme. That actually ends up creating a product that was not what we intended."

Jess Clark:

And so we go back and we restructure the tokens to think, this is the way we want to semantically apply this. And then we apply them to components and then we discover new things. And so I think that actually the design token piece of it, I know Jina Anne talked about this. Every company has to look at it different, it's really where the exploration happens and where as a company and your product, it's really unique. And I think it does take a ton of exploration, which can be challenging if you don't have that mindset because you might be thinking," Oh, we didn't get it right the first time." And nobody gets it right the first time.

Chris:

Oh, you're absolutely right. So this is really fun for me because one of the things I've always really respected about the design discipline is that it just requires a lot of head space and a lot of iteration and a lot of understanding of intention and how you represent that intention. And traditionally what we've done is we've basically said, "All right, give your design team plenty of thinking in the shower time, give people time to do that exploration." And one of the things that I love about tokens in particular is you can actually watch that exploration happen in real time. Introducing a dark mode as a token set is a really interesting thing to watch happen because people start to realize all these fundamental little hinky bits about their app that don't really have dark mode thought of as a part of implementation.

Chris:

And so how do you then go through that and be very intentional about restructuring your components for your other tokens to support this sort of system? And I think that that's awesome because now all of a sudden instead of thinking in the shower or in some private Sketch file somewhere, you're actually able to watch this creative process happen live. And that's really cool.

Jess Clark:

Yeah. And I think this is where it comes back to those hybrid roles and just bringing design and engineering together because you can try as much as you can to have design tooling mirror what's happening, but it's really difficult, and it's so much overhead. Whereas when you bring the design and engineering aspects together, it's fun. You're iterating together, you're able to see it in real time. And you can have those conversations about designers fully understanding why an engineer would build something a certain way, and then an engineer really understanding the ethos of the brand and what a design team is trying to deliver and have fun figuring out how am I going to deliver this? And I think that partnership and that play is really fun in that space. And that's what we've seen really inspire the team, bringing them together instead of having this handoff back and forth. But say, come together and experiment and explore and have fun with it.

Chris:

Yeah. And that expectation, the cross-functional aspect of this is just baked into the way you do things. I think that that's cool. There's a lot of skeptics, right? There's a lot of people that look at that and they say, :Oh man, I have to talk to a developer every day," or, "oh, I have to listen to a designer ramble on about color for half an hour." That don't look at that as immediately something that's fun. But I think the really cool thing about what you've been able to build is you have made it fun, and people want to engage this way with one another. So tell me a little bit about how you fostered that because I think that's a really interesting aspect of overcoming skepticism, overcoming resistance, really changing a culture at an organization?

Jess Clark:

Yeah. And I can talk a little bit about how we did that on the design team and then also how we're doing it between design and engineering. So first with the design team, one thing that we recently did was we were trying to figure out, well, how do we take our design system to the next level? We have a solid design system in place, it's pretty mature, we're working well together. But we want to have more fun and we want to push this into the future, we want to innovate and create. And we want to bring all the other designers along with us. So one thing that we set up was a two-day design sprint to create our own app. And the goal was in two days, we're going to go from not having an app at all or even an idea to having a fully function prototype in Figma for design.

Jess Clark:

So this is before adding the engineering, even though that's our next step to have fun with that. So we had two days, we all got into a virtual room in the last year and we set up Figma. And we just started off with, what kind of app could LinkedIn have to add to their portfolio? Let's just make something up, something that isn't a current product. Because I think it's sometimes difficult in limiting when we're only thinking in the space that we already have. So we did a little brainstorming, spent an hour on that, came up with an app idea. And then from there, we split into groups and really targeted, let's do onboarding, let's do search, let's do discovery tab, let's do filtering.

Chris:

The whole app, app, this Wasn't just let me just design a feature inside of the platform?

Jess Clark:

No, this was a whole new app. So a whole different app that we were going to build that would be something on an app store so that we could show the user experience and how the system comes together. Because it's one thing to have a catalog of parts, to have the guidance, which is really helpful, the standards, which is really helpful. But how do you show how it comes together? Especially when you have an ethos that you're trying to communicate, sometimes words on a page and images just don't communicate that story. So we thought a live app prototype could communicate that story really well.

Chris:

No, it's a neat idea, the idea of let's pilot our system by building this app. So was this something that you guys then legit built from scratch and you did it using the design system and that became this, I guess, moment within the team that people sort of understood what this was all about?

Jess Clark:

Yeah, exactly. We did it from a design prototype perspective. So within two days, we were able to go from idea to having all of the screens created for this prototype. And then probably a week or two after that, we had the prototype all hooked up and ready to go as well as documentation really showcasing that prototype and that study of how it comes together. And I think what was so great about that was not just the end product, this great prototype that we get to share with the rest of the design org, but just how the team worked together. I think the first day when it started off, that was a part of me exploring, experimenting. I was like, "Oh my goodness, is this going to work?" It has a little bit of an awkward start, everybody's split up in groups, we're going to come up with this idea, there's a little bit of hesitation. But we pushed through that first half of the first day.

Jess Clark:

And by the second day, I have never seen the team so excited to work together and so just ready to innovate and explore. Not only were they excited about the prototype and what was happening and how their work and their design system was coming together, they were excited about what this means for the future. They were coming up with all sorts of ideas. One idea is, hey, when we're creating components in the future, we're going to use this prototype to test these components. How does it work with the entire system? How does it interact with them? What does it look like? And I think that was just one of the many ideas that they came up with. And so I think that play space was not only about coming up with a cool product that's going to showcase to all of our design org, but get them really excited about working together and creating a platform to come up with new ideas and ways of working that we hadn't before.

Chris:

I always thought that that was one of the benchmarks of knowing that your system has crossed that chasm of adoption is when people start to build their own little tools and add-ons and processes to the thing that you've created. And it can be as simple as just establishing, codifying some way of working. But very often, that comes in the form of people making little tweaks or little changes to adjust to their own workflow. And the moment that somebody starts to tinker and get curious and explore, You know that you've probably found something that people actually like because they're willing to invest their own time in it to make it better. So I love that story of taking the system, figuring out how to get people involved in it. That app that you guys built, did you guys ever launch that or is that something that is still just a really great test bed for the design system?

Jess Clark:

Yeah. Right now, it's just in a Figma prototype, and we're going to launch it soon to our designers. And then we'd love to work with our engineers and move forward to make it a real thing.

Chris:

Yeah. So tell me about that engineering bridge because I think that's the next step as you say. So when you start to think about how your design and engineering teams interact within the system, what does that look like?

Jess Clark:

Yeah. So recently we started something called show and tell, and I think we meet every week, people sign up. And it's really individual contributor led. So one thing that I found so powerful as design leaders is sometimes we just need to get out of the way and create the space for them. Because when we're coming in and we're creating something as design leaders, it can sometimes feel like homework, feels more like the librarian side of things and less like the astronaut side of things. And I think we created this space for the individual contributors to lead and to come up with topics and just have their own space to play. Even just that empty space of, hey, sign up and share demos with each other, it's amazing how such a simple concept like let's get in a virtual room and share demos with each other can bring that play to life.

Jess Clark:

And so there's so much back and forth now with, "Hey, let me show you the engineering demo," "oh, let me show you the spec and what I was thinking," and having that back and forth. So creating spaces where the managers step back and we put the people that are passionate about what they're doing together and let them run with it is what we've seen really bridge the gap between design and engineering. And to help them understand that we are building one product together. We're not trying to reflect the org. Yes, we have different skillsets and different things that we're bringing to this, but we're building one product together. And it's so much better when we work together on it, and it's so much more fun.

Chris:

Yeah. If you think about what those things have replaced. You've been a part of that organization for long enough that you were probably there when you would do either those really terrible creative review, design review meetings or those really terrible hand-off meetings. They'd always be an hour or two long. They're usually scheduled for an hour, but they usually bleed over to like 90 minutes. Half the people are late or that one VP or creative director or whatever that clearly doesn't actually have time for this really wants to make a point. You have these things that tended to be leadership driven that were mostly facilitation. It was like, okay, let's open Sketch, let's open Photoshop or whatever and go through this design file, and then let's open the actual thing and figure out where pixels need to be moved left or right.

Chris:

I love the idea that design systems are killing that meeting. And it's because when you all of a sudden have this democratization and this empowerment of people at that individual contributor level, it's no longer incumbent upon somebody at some VP or director level to facilitate these things. They're self-facilitating, they're self-organizing. And that is a really powerful tool in the hands of your individual contributor because it's autonomy, it's empowerment. It's now not just like the voice of one person or the vision of one person that defines that ethos, it's that team. And that creates better products in my opinion.

Jess Clark:

Yeah, definitely. And I think as we've matured and created a pretty strong path forward, an ethos, an opinion on design, it allows that open space for all these other teams too. And so now partnering and bringing the other product design teams along with us, we're trying to give them the foundations and the tools. So we also have Figma plugins that we add to the toolkit to give them that space to build on what we have. And sometimes that means bringing it back into the core system and sharing it with everybody else. And sometimes it means that that product gets to build something really bespoke and unique for themselves that still fits into the ethos and still speaks the same language as the rest of the design system. And I think there's so much power in that. Like you said, moving forward, it gives design teams the autonomy to innovate without moving too far outside of the line where they end up not being a part of the whole system.

Chris:

And share that innovation. I think that's the other side of this that is a huge amount of value is, okay, so I have product team A, product team B, product team C. Product team C does this really interesting, unique innovative thing that's still within the boundaries of the system, but is actually super valuable and super innovative. Traditionally, it's very hard for team C to share that innovation with team A and team B. But through a design system and through that democratization effort through an open forum where those people could show that off, the chances of team A or team B being able to adopt a similar thought process or thinking or innovative concept is way higher. Do you have any real examples that you can think of where you saw this innovative concept sort of come to life and then have that be something that sparked some other sort of creative innovation across the rest of the organization? And through the magic of podcast audio, you can pause for as long as you want here to think about this.

Jess Clark:

Yeah. I think there's quite a few things that we've done. I think design system tends to be an incubator of ideas. And they're not always original to the design system team, I think some of them can be solely based on the fact that we can connect the dots across the organization. We can see a pattern before a lot of times people can see that pattern emerge because we're seeing it through a couple of different products. I think a few things that we've done this with is motion. So looking at motion and looking at all the different aspects where we see initiatives of motion happening on a few different products. And we can pull that together to create some consistency and solid foundation for people to jump off of. We can have an office hours to help people innovate and create and push that forward.

Jess Clark:

That's been something that's been really fun for the organization. We were able to bring together some training, have those folks get trained. And it was people all throughout the organization. So it wasn't just us, we weren't harboring a skillset like motion. We really wanted to create that training so that everybody can do it. And then when they're out there, we help create the psychological safety, innovation safety for them to really innovate and push it forward because it can be scary to do new things. But we can be here to say, "Hey, we have experts, we're going to help review with you, we're going to help you push that forward." So motion was something that-

Chris:

Motion is really interesting because this is something that I see as this really complicated, very difficult thing to pull off. No offense to the design tool people that are out there, but the way that motion works in design tools is definitively not the way it works on the internet. They're getting better, but the reality is that the gulf there is really big. And it's also super hard to do this over Zoom. What does a fade in of 200 milliseconds versus 400 milliseconds look when you're only getting a few frames in Zoom to look at that? And the other part that's really hard on the code side for this that's been a really traditional weakness in the development side of motion is that when you go to change a value, 200 to 400 millisecond fade in, that could potentially be a full continuous integration round trip.

Chris:

And so you can't be like, "Let me see it with 200 and let me see it with 400. And let me only have a couple of seconds of head space between those." Oftentimes, it's several minutes. And by the time you're looking at that again, you're like, "Well, okay, I have no idea if 200 or 400 is better." So the design system giving you that kind of instantaneous feedback around motion and that connection that is between that design tool motion and that actual code tool motion, this is a place where I think that design systems are almost invaluable. It's very hard to do motion well on the web, and it's almost impossible to do it in a remote environment where you're not able to work in the same tool and really understand how things are different.

Jess Clark:

Yeah. And we're experiencing those challenges for sure. I think this is where design engineering really has to come together because when you're doing a handoff, it just doesn't work. You have to have dedicated people who are passionate and interested in it and willing to go forward into the unknown to figure it out together and do that exploration discovery loop that we talked about where there's going to be challenges, and you're going to have to start over and think about different ways of doing it. I think a lot of people on the design system team, they have that kind of gumption, they really want to solve the challenge. They really want to move forward where no one has been before and figure it out. And I think that's also exciting to have folks like that on the team because you need that. Because if you give up on the first time that you hit a wall, it won't work.

Chris:

So when you think about the more complicated concepts like that and getting people to be in the same place, does that start with foundations for you guys? In terms of motion, do you guys have animation tokens that are established inside of your design system? And then how do you codify that idea to start to build that foundation of collaboration on these more difficult concepts? Adaptive colors is another one or semantic palettes or any number of other things. How do you think about the starting point for all of those more challenging concepts that don't have good design and dev analogs?

Jess Clark:

Oh yeah. For us, I think that's where we really see ourselves as the core and the foundation. What's the story that our brand through our design system is trying to tell, and how do we create the design tokens that tell that story? It's really like reading the words and giving it to the product teams to write the books in that way. Because when we look at motion and we look at colors, we can try to write the book. But it doesn't work, we don't have the context, we don't have the people. And so we really try to create only the foundation and then provide them with as much context as we can, tell the story to them and show them the different tokens and what they mean to us and what we think they mean to the brand and to our company and our product, and then let them explore.

Jess Clark:

And I think that that can be challenging for some design system teams who might be in the realm of governance is the way because I think that we have to open it up to allow those teams to explore and play in that space and then come back to us to say, "Here's the motion tokens I applied to this toast, to this page. And here's what came of it. Here's what it looked like on product, here's how the members reacted to it." And then bring that back to us so that then we can start to codify and create standards around that. But I think it makes sense to start with the base, share that out and give them that place base to bring it back to us. Which goes back to that discovery loop that we have to be comfortable with in experimenting.

Chris:

I think it's also great because you're giving professionals the autonomy to be professionals. Obviously, there is still some sort of governance and review here. If somebody comes back and you're like, "Oh my God, the name is blinking. What is happening?"

Jess Clark:

Yes, office hours, office hours.

Chris:

But at least in the general practice of those things, I've felt that if you give people a sense of trust and a sense of autonomy, that like I'm giving you guardrails and these guard rails are very broad, the lanes are wide. Now, I want to see what you're capable of creating. People try to take that on as a personal challenge to make something really incredible.

Jess Clark:

I kind of compare it to painting the asphalt. When you think back when we were kids and there was the lines on the ground to play games. There were a few games that we knew, there's these squares, and they're painted and you can play whatever you have in mind. But then you can also create your own games in the same space. And I think it's really similar where I think the design system, we create rules and we create the guidelines, which are really important. But when people come up with new ways of doing things, it's really exciting, and we should see it as that. Because that kind of exploration is what we can build upon in the future. I had a quote that I thought of from Mina Markham, she led Pantsuit, Hillary Clinton's campaign.

Chris:

Yeah, yeah, Mina has been on the podcast, we love Mina.

Jess Clark:

Oh, awesome, she's fantastic. And one thing she said was her job is to make sure the system is module and flexible enough to be used in unpredictable ways. And that really just settled on me pretty early of the unpredictable part, because I think people think of systems, and they think predictable, the system is here to make things predictable. And going back to writing the rules, I think in some ways that's true. We want things to be predictable, but we're creating something predictable so that people can do something unpredictable with that. And that's what makes it so fun.

Chris:

That's really great. It goes back to the thinking about a design system is a product that serves other products inside of an organization. One of the like early lessons in product management is people will use and break your product in very unpredictable ways. And I think that that's a great idea for design systems is you give, just the innate nature of human beings, you give people a system and people work to exploit that system in the way that most benefits them. And that's good, that's something that should be enabled not discouraged.

Chris:

And I think that when somebody takes the time to fully understand the system well enough to explain it for their needs, you know you've created a really good system. I also love the idea of the paint on the asphalt. It reminds me of my time in elementary school adding on with chalk extra squares, the hopscotch and being like, "Why are there just 10 squares? There should be 14." And I think that that's a really interesting fun, and again, playful metaphor for what we're doing here because chalk is your implementation whereas paint is your guideline.

Jess Clark:

And I think, going back to building the team, I think what Jennie Yip said earlier was design system really is this incubator of new things. One of that being new types of roles and these new hybrid roles that are showing up, blended roles, people with different backgrounds. One thing that I've really loved about leading a design systems team is having the ability to bring on people under the team that have different backgrounds and different experiences. Not everyone on our team even has a traditional design background. I think we're bringing on people who have this hybrid engineering design background to help create tools and plugins.

Jess Clark:

We also have people from customer service backgrounds now who went to UX boot camps to learn about product design. Because so much of that stage after maturity is working with your design team and helping them, bringing them along, helping them understand how to use things, helping them know how to build upon your library, teaching them about how to use the guidelines, how to build on them, how to move everything into the future. So I think that's also been a really fun part of exploring what does a design system team look like? Who are the people you need on your design system team? And even moving into that larger idea of design infrastructure, who are the people we need to bring along? I think we can have fun with that, I think we can experiment and explore and start looking at different types of backgrounds to bring them along, to create that great team that's going to move us into the future.

Chris:

Absolutely. One of the things that I love with this is ... So we tend to think about design system teams as developers, designers, maybe a product owner or three thrown in. I love the idea of content people, of marketing people, of people that are interested in microcopy and stuff like that as a part of a design systems team. Because I think that that category that we tend to lump in as other or miscellaneous in terms of those roles, I think there's a lot of exploration to do there that is actually really interesting. Even take your title as senior manager of design systems, that title probably didn't exist three years ago. And so this opportunity to explore these new hybrid roles, these new ideas of what a common stakeholder that developers, designers, et cetera, role into as we start to create this infrastructure. The way this changes organizations is a really interesting topic.

Jess Clark:

Yes.

Chris:

Yes, I agree.

Jess Clark:

Well, I've been on the journey so long, I'm not quite sure. Actually, I think it's really just been a natural evolution from style guide.

Chris:

I think it's an interesting journey. As somebody that owns 'a design system', that's innately a cross-functional role. And so it's not really a product owner, but it kind of is. It's also not really a cross functional role up, but it kind of is. How does that actually look?

Jess Clark:

Yeah. I think in every company design systems, design infrastructure, they all look so different. I think some folks that I talked to design and engineering roles up together. Sometimes design and engineering and design ops role together. Like you said, content, accessibility. Design systems is a product, so there's an aspect of that that ... Some have product owners, we don't have a product owner. So I think the engineering manager and I really work together to move the product forward and have that strategy. In some companies, they have a product owner. But I think it really depends on what works for that company and that team and what that role looks like. To your point, it's really a mystery. If you look on the outside of people's title, I think it's not really a reflection of what's happening inside. People don't know what to do with these titles, similar to what would be user experience designers, UX, UI, product designers.

Jess Clark:

I think design systems is going through a similar evolution now that even small companies are looking for design systems. You can go on LinkedIn right now and find a bunch of design system roles that are open, especially at all these small companies. And you read each description, and some have accessibility, some are engineering and design, some are just design, some are content. Some say you need to manage the pipeline of the design system as well as create the design system, as well as ship it. So I think we're really trying to figure out what it looks like to be a part of design systems, what is design systems? And moving towards design infrastructure, what's next? I think on the engineering side there's a lot of things like developer happiness, developer productivity. And that's what my team is really working on now, we're really looking at what does designer happiness and designer productivity look like? Because that's beyond just the design system product.

Chris:

So all those things that you talked about, those roles probably didn't exist three years ago, and they certainly didn't exist five years ago. And so that represents to me a broader organizational change. And I think that as we get to this idea of design infrastructure and we get to this idea of how do we look beyond just the ones and zeros that are flying around everybody's screens, into what makes us more productive, more capable teams. I think there's a lot there that is an interesting new way of thinking about product where instead of having just one product owner for a product, you start to think about the patterns that go into products and the ideas of what those products should be composed of. And then you start to think about, how do I put people in a area of responsibility that is one aspect of that product that is composable from a design system?

Chris:

And that job of that person for, I don't know, that log-in experience or that sign-up experience or whatever is to try to create the best possible outcome for users in that particular pattern or domain. And that's where I see this going. Because ultimately the role you have in the organization is very broad. And now you're trying to figure out how that broadness can be leveraged to make a better team. I think that there's also a area that is a little bit more fine grained where instead of the idea of let's go have somebody own a whole product, let's go have somebody own a portion of experience that is composable from a system. Interesting stuff to think about.

Jess Clark:

It's so interesting being a design leader of an organization because I think it's hard sometimes to communicate what my role is. What is the role of a design leader in any case, especially for something like a design system and leading a team and how you lead a team? It's hard to describe because a lot of it is not reacting to, but really being the person that your team needs every day, which is a different role every day. And that's why my role itself is really exploratory, to your point, with the organization. It's how can I show up today and be the person that the design organization needs? How can I connect the dots in the design organization to move us forward, to innovate, to create, to work better together and create our best work? That's why I love my role, and that's how I try to show up every day and not look at any kind of box of a job description.

Chris:

I think the exciting part about that too is you get to actually define what this role means to an industry. I love being in the early phases of some big wave that you see coming. Most of the people that listen to this show, most of people that are on the podcast, they all see the same thing. We see this as the future. And being able to be a part of constructing that future is one of the most rewarding things you can do career-wise is you get to take the moments that you spend doing your job, share those with other people. And that constructs a blueprint for this industry, for this new way of thinking about how we build digital products. And I think that's amazing.

Jess Clark:

Yeah. We're talking about play, and I think what I love so much about this is that cooperative play idea, these games that are more about cooperative play. I think it results in collective payoffs, it's like win-win, everybody has fun. People get to innovate, people get to explore. I just find so much enjoyment out of making sure I'm removing blockers and doing the boring things to make sure that everybody else can use that as a foundational point to move into the future. And I love watching what people do with it.

Chris:

Yeah. I always feel really fortunate that I get to talk with great people like you on this podcast because it helps me construct an idea for where this is all headed just through these conversations. And to listen to a bunch of really awesome dynamic people talk about the cool shit that they're doing in their career that is related to this is always just so rewarding. I guess that's my way of saying thank you so much for being here, for sharing your story. I think it's an incredible journey that you've been on, gosh, 11 years or something like that at the same organization. We were talking a little bit before, I think we hit the record button of your start where you were literally managing front desk security. And now here you are leading design systems. Do you want to share something about that journey real quick because I think it's an interesting one?

Jess Clark:

Yeah. I graduated college during the recession. And at the time, I was going to school for design at a local college. And I got the job as the front desk reception, it was a temp job. So I went actually to a couple of different internet companies, places like Cisco and Citrix and LinkedIn. And I loved LinkedIn from the beginning, the people there and what they were trying to build. And one day the VP of design at the time came to me and said, "What are you up to?" And I just said, "Well, I'm studying for design. But it's the recession, there's no jobs. So I'm just trying to do what I can here and do my best." And he offered me a design internship, and I was able to be the first design intern at LinkedIn, and from there, the first junior designer. And it's been an amazing journey ever since.

Chris:

That's awesome. Well, again, thank you so much, Jess, for sharing. Really appreciate you being here. We got to have you back to have a deep dive on that tools discussion at some point. Really love just your energy and the way you brought it today, so thank you very much.

Jess Clark:

And thank you Chris for having me and for creating the space for everyone who is moving design systems forward.

Chris:

That's all for today. This has been another episode of the Design Systems Podcast, thanks for listening. Our producers are Ryan Peterson and Shayna Hopkins. 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 comment. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.


Get started

mention benefits and reasons why creating an account is ok. mention the best outcome timeline

Get started

mention benefits and reasons why creating an account is ok. mention the best outcome timeline