Joanna Kirtley — Design System Lead at Liberty Mutual
My name is Joanna Kirtley and I work at Liberty Mutual Insurance. I'm the product owner of our design system, which is focused on consumer facing products and services. This is my first experience in a design system role. So before this I was doing design strategy and product design work.
Nice. All right, Joanna, let's get right into it. What is the most difficult thing you're facing now in relation to design systems? Get it out of your system.
Okay. The most difficult thing right now is that we have so much to do and not enough time or resources.
Okay. So how do you deal with that? Do you hire vendors? Do you prioritize a backlog? What are some of your techniques in managing that?
We have a backlog. It's a very extensive backlog and we basically just have some really ambitious goals for Q1 of all the components we want to either add to the system or revise in the system. And we're working through that list as fast as we can.
Yeah. Nice. About how many components are in the system now?
I'd say there's about 12 and the system is about a year and a half old. So, that's not actually that many and we feel like we're behind. But to give you a sense of what we have on our plate, we are trying to get about 10 into the system in this quarter.
Nice. Double by the end of the quarter.
It's funny, all the people I talked to about design systems, no matter what the number is, they always feel like they're behind, right?
So it's like, you talk to some teams that are like, “We only have 86 components in our design system.” And I was like, “Well, we only have five components in our design system and it always feels like we're behind.” Why do you think that is?
We have a lot of people asking us for stuff, so it feels like we're just trying to keep up with the demand and we know that delivering on those requests is part of the way we get design system adoption. And so it's like, “Oh, I wish we could just move a little faster and get those things in.” But we can't because we've set some really high standards for ourselves of making sure that all the components are designed really well, that they're coded really well, that they're accessible and that they've been kind of vetted by a wide group of people. And so to meet that high bar just kind of takes a lot of steps.
One thing that I find with design systems is that the challenge is almost never the design part or the development part. It's not writing good code, it's not doing a good user interface. A lot of times it's just the decision-making that comes with like, “What do we do next and when do we decide not to do it?” So as a product manager, how do you decide, okay, you are working on 10 components for the next quarter, why not 12, why not 15, why not 20? How do you prioritize those 10 and is it just first come first serve depending on what people are asking for or do you have a different way to go about it?
I feel like we have a few different things we think about kind of like the number of requests. So if a feature seems really popular or a component seems really popular that rises to the top. There's also, we've used the matrix of effort versus impact, that kind of thing. So kind of matching those number of requests with the effort it takes to build those to try to do some of the easier ones earlier so that we can get some quick wins.
Yeah, I would say one of the problems we've had or challenges we've had is we set some priorities and then new requests come in and we don't know whether to stick with our original plan or whether to respond to those new requests. Because again, we're trying to be responsive to people but we had a plan and do we stick to the plan? That's where we have some trouble trying to figure out what to do.
Can you talk more about that? Because no doubt some people get disappointed because their request is not as high up on your backlog as they would like it to be. How do you deal with that? How do you manage that? Is there a lot of expectation management going on or is it just kind of like, “That sucks. Sorry, come back next quarter.”
Yeah, I think it's definitely being communicative to those people who have like, “Hey, we heard your request, but realistically this is where it is on our timeline.” And I've thought about, I think, this quarter we might start publishing more of our timeline internally to the company so that they have a sense of when things are coming. We've done that informally but not through our design system site.
And then the other thing we've tried to enable is helping people create their own components and we call it a secondary repo level. Each kind of major team within our group has a secondary repo associated with them where they can build their own stuff and then promote it up to the design system. So, that kind of gets them something in the moment. And it's not official design system components, but we can work with them as they do that and kind of get it most of the way there for them.
Well, let's talk a little bit about the communication channels because that seems to be an important way to help people with their expectations on some of that. How do those requests come into you? Is there a Slack channel? Is this through email? Is it bumping into people in the hallway? How do requests come in and then how do you communicate that back out?
It's really all of the above.
We have an intake form on our site, so that's where a lot of kind of minor things like, “Hey, I'd like a new icon or I found this bug,” come in and that's great because it's through Jira and kind of gets tracked really well. But more frequently I think people come to us on Slack or in the hallway and say, “Can you do this thing?” And then we have to kind of feed it back into our systems so that we don't lose track of it.
We also do weekly design reviews with each portfolio group. So our team is split into roughly three or four portfolios. So each of them we do a design review and a lot of times that's when some of the things come up is a designer has made a decision. It's not in the design system. Maybe we allow it this time, but we say, “Hey, we really need to get that feature into the design system going forward.”
Yeah, that makes a lot of sense, because I would imagine that the design system team has kind of purview as to what all the portfolio teams are doing. Whereas the designers and developers on the portfolio teams maybe have a limited view as to what others are doing. How do you manage that balance? Do you tend to kind of police it? Does design team tend to police that stuff? Do they tend to be seen as helpful? How do the portfolio teams interact with a design system team?
Yeah, I do feel like we're a little bit of the police where our team is putting a big focus on design excellence this year and they've asked the design system team to kind of think about governance from a design perspective. And so those weekly design reviews are meant to be a little bit of police but also feedback and just making sure we're all doing a good job and doing it consistently across the portfolios. Also, I run a quarterly audit where I look at the digital experience from a design system compliance perspective and kind of ding people if they're off.
Which I feel kind of bad about, but it is effective not only in getting people to change things that they might be inclined to ignore because they don't really care, but also in helping me see trends where a missing component is really leading to a lot of inconsistency. And so that, again, would lead us to prioritize that component.
Where did the mandate for the design excellence come from? Does that come from leadership? Is that kind of a ground up thing?
Yeah, this mostly came from leadership. We actually had a leadership change on our digital team last year. And so with the new leader coming in, she actually was our CMO previously. So a big focus on kind of design and creative. And I think with her coming in there's been a lot more focus on making sure that both our stuff is really great but also that there's a consistent flow from the marketing to the digital places where the customers or perspectives will land.
Yeah, that makes sense. Well, maybe the last topic then for us is how many people do you have on the design systems team?
So we have six on our design system team. We've got three kind of at the lead level. So I'm the product owner, we've got a creative lead and we've got a technical program manager. And then we've got one sort of key designer and two developers.
You talked about one of the biggest challenges being you have so much to do and not enough time. Would having more people on the design system team help to solve that?
I do think so. I think both more developers and designers would be helpful, because I find myself getting in the weeds a lot of times like, in the sketch file trying to build components and make the symbols and all of that stuff. And that is kind of only one of many responsibilities that I have. And so whenever I'm working on kind of my core job means I'm not doing that work and we just don't have enough people to do that. But I'm also aware that with more people comes more trying to manage everything and keep everybody on the same page. And so I think there's sort of a threshold. I think I could see our team expanding to nine people and then that might be about the right size for us.
Nice. That would be the sweet spot of not too much management, but still being able to get more done.
Awesome. Well, I think that seems like a good place to leave it. There you have it. The most difficult thing that Joanna is up against regarding design systems is there's so much to do and not enough time. Joanna, thanks for getting it out of your system. I'm sure you're not the only one facing this. I'm Dan Mall from SuperFriendly. Thanks for listening to this episode of Get It Out of Your System.
Maya Hampton — Product Manager, Digital Design Systems at REI