Kim Williams — Head of Product Design at Minted
I’m Kim Williams. I work for Minted, and I’ve been working on design systems for the past five years.
All right, let’s get right into it, Kim. What is the most difficult thing you’re facing right now in relation to design systems? Get it out of your system.
The most difficult thing that I am experiencing right now is getting started, that I am new in a new environment, and more importantly that I’m rolling up my sleeves and getting scrappy. So I would say the toughest part is being new and also shifting gears from having a lot of resources and a lot of team members to having a small and mighty team and trying to figure out how I’m going to balance everything to get this work done.
I love that word, scrappy. Can you talk a little bit about what that means to you?
Yes. So scrappy means to me, in what I’m experiencing currently, is that where you might have dedicated roles, specialization, for specific practices in larger teams, in a smaller team you’re just doing it all yourself. So project management, or the producer role, so planning to user research to design, and yeah, I’m actually really excited about it, making this shift from being quite hands-off and almost like administration and people support, to getting back to design and being a designer.
What do you think are the pros and cons to that? What’s great about being an IC and kind of rolling your sleeves up versus what’s great about doing the management part and leaving the IC stuff to each others?
That’s a good point. And I should clarify that I’m doing both, that I’m both IC and also leading the team. Pros and cons about both, let’s see. Cons, freaking out about all the things and leaving kind of the comfort of having had so much resource. So that’s kind of the con of a shift to be a little bit more scrappy. The pro, of course, is getting closer to the work. I feel so excited. I feel getting back to my roots and why I am even in this industry to begin with. So those are the con and the pro for the scrappy move, and I think pro and con for being a part of the larger team. I think you do get the dedication. You do get the resources. You do get more leverage. You already have a dedicated path for the work, so you feel like you can give it the care. Whereas the path that I’m on now, I’m already thinking about, okay, what is the product roadmap, and of those things, how am I going to fit design system upgrades into the existing product roadmap?
Yeah. Got it. It seems like there’s this accepted notion, which is that if you work at a big company then you can have a big team, and if you work at a small company, you might have a small team. Is there a reason for a big company to have a small team? Have you seen that before? Would you ever engineer that, that like a bigger company can still do well with a scrappier team? Does that work?
I think it comes down to ratio. I’m just imagining that it’s the ratio of the demand on the team relative to how many people they’re supporting.
Oh, interesting. Okay.
You know what I mean?
So I think larger organizations have to have more people to support just all of the demand. The level of service that’s required to support 50 PMs and 1700 engineers is going to be different than the level of support required for five PMs and 50 engineers. It’s every company adjusting to the demand.
Okay. So I guess along those same lines, too, I mean it sounds like a safe assumption would be if you work at a big company, your design system has to be a big one, and if you work at a small company, you can get away with a small design system. Do you believe that that’s true?
I’m going to find out very soon, but I think that that’s a fair assumption. I think that that’s a fair assumption. I think more than anything, what I’m experiencing now, it’s not that you’re skipping any steps, because I’m not skipping any steps. It’s just, it’s accelerated, too. So less layers of people in terms of buy-in and organizational structure that you have to navigate. So it’s not skipping steps, because you have to go through the process. But it’s also, because it’s smaller, it feels like it’s moving much faster. That being said, I’m just a couple weeks in, so it’s hard to say, but I would assume that speed is going to be the biggest differentiator.
Yep. Got it. So just for context, you have worked at large companies before and you’ve moved to a smaller one now just recently. You talked about one of those changes being, well, you’re now in an individual contributor role, whereas you weren’t before, but you’re still managing now and you were managing before. How has your management approach changed at a smaller company now, or how do you anticipate that it might change versus when you were managing at a large company?
That’s a really great question. I feel like going smaller, I feel like I’m a better manager. I feel like this is the best management I’ve ever been able to offer, because you know what, I went through a lot with the larger organizations. I had a lot of successes, I had a lot of failures, and I’ve grown so much in the past few years. And so I feel like I have so much to offer. I feel like I’m in my zone and at the perfect time. With all that’s happening in the world, I feel like I offer my team stability, like I know about working rhythms. So just little things that I’ve picked up and I’ve learned from other leaders too, such as the work rhythm, so having these rituals. So Mondays and Fridays are light, and so the team has had downtime. They can focus. Tuesday and Thursdays, we have reviews. Wednesday is a meeting heavy day where we sync up amongst ourselves, design and with PM and engineering.
So just those things, like really, really good management techniques that I’ve picked up from others along the way that I feel like I have so much to offer this team now. And I feel really, really proud to be able to give them that sense of comfort, you know, little things like I ping them about taking water breaks and stretch breaks and having walking meetings, so that I know that they’re getting out of their homes every day while we talk. And so in these really uncertain times, I lean on the empathy and the situational management training and support that I’ve had throughout the years to offer more than I probably could have years prior.
Yeah. Got it. What are some of the other variables that, you know, you mentioned being in your zone now. What are some of the other variables? Is there a particular size of team that you’re like, this is a sweet spot, or what are some of the other variables that contribute to this being a really good fit?
I think the biggest part of it is that it’s for me just having the freedom to kind of have at it, so to speak, and be able to make choices with my team and kind of move forward. So I think just like for me, just being able to, I think the speed, being able to move quickly with the team and build consensus quickly and move forward. It’s just easier when it’s a little bit smaller.
Yeah, I got it. Now can you talk a little bit about how your team does or doesn’t use the design system? Because you’re not just in charge of a design system there, you’re the head of product design, right? So that probably encompasses a lot more. Do you use a design system, and how does your team interact with maybe another design system team or oversee that design system?
Yeah, so we do oversee the design system, and we do have a dedicated partner in engineering, a staff UI engineer, that is leading up the design system effort. And what’s great is that that partner has onboarded with me, and so we’re both starting at the same time. We’re both going through the auditing process and really, really thinking through how we want to build this thing together, which I think is really awesome. And he comes from the industry with a lot of experience, as well, and so it’s a really, really great fit. It sounds like that one of the best things I can tell from this culture is that everyone’s already bought in to the design system. There are like zero sales that needs to happen at all. So that also makes it much easier.
Everybody’s just really hungry to make improvements to what’s there and see the system proliferated throughout the site. So there is a system, it is being used, it’s not as consistently being used, and it’s not everywhere. So that’s going to be the goal there. And there are some holistic challenges with it, too, and so I think for us getting started, it’s completing this audit phase and then mapping out the core opportunities in our project plan to kind of move forward and address them.
Cool. You mentioned earlier that getting started was just a tough thing, and so it sounds like you have gotten started, at least with audits. Can you talk about how you came to the decision to go, all right, let’s start here? Why audits? Why did you decide to start there?
Yeah. It was also my partner Ian, who is on the technical side, that he was like, “I am starting a Jira board, and I’m going to go point for point through all of these components,” so I was following his lead. I think it’s a great place to start, to just see what is here. I think it’s easy to fall into the trap of being new, starting new in the design system role and wanting to blow everything up immediately. I think it’s really, really important to take a step back and really, really understand where everything is, why things are the way they are, the rationale that got everybody to that place, so that you can then make the appropriate transition to the next place.
Yep. Got it. Let’s go back to being scrappy then. Let’s say you had a magic wand and you could hire, you know, you open up head count and you have more budget that you can hire more team members. What’s missing? Who would you hire? What roles? What would you need in a way that you right now you’re only addressing by being scrappy?
Yeah, that’s a really great question. A role that is often overlooked is the content designer or the content writer. So much about systems is being able to effectively articulate how to use the system, how it works, what are the mechanics behind it, and writing in a way for all of the different audiences. It’s your engineers, your designers, all the different types of designers, visual designers, brand designers, interaction designers. And so I don’t think we give our content peeps enough credit for how much we absolutely need them, and so I would definitely say content, because communication is critical for design systems.
I would also say, other roles, I mean research I think is another one that’s always sometimes back burner, because if you’re lean you don’t always get a researcher. And so I think that that’s important, too. How is it working internally? Research on your internal customers and external customers, as well. So I think those two roles often go unfilled, and I’m always interested in complementing the skills that we already have. So we’re already strong on the design side. So I’d be interested in bringing on special roles that complement what the team has.
Yeah. All right. So maybe we’ll end on this. So I take that to mean you don’t have those content designer, content writer roles, or research roles. So back to being scrappy again, how are you filling the gaps with folks that don’t do that professionally? How does your team manage not having a researcher or not having content designers? What do they do instead?
Yeah, that’s a really good question. So this is where we uplevel our own skills and we rely on our network. So I have an amazing friend LeeAnn and actually chatted with her yesterday. She has been an incredible user researcher for like the last 20 years. She has a long career, and we just chatted through like here’s how you lead a scrappy user research study. Here’s how it’s done, here’s the basics. You knock this out of the park, this is it. Here’s some scrappy tools. You don’t need a big budget. And so I think it’s us really having a growth mindset, and we’re always learning and upleveling our own skills.
And then on the content side, it’s interesting, because I’ve always firmly believed that great designers are great writers, as well. And so it’s just forcing us to be more thoughtful about our words and invest the time there, as well. So yeah, it’s when we don’t have those specialized roles, it makes us more of generalists and forces us to hold ourselves to a higher bar. Like, we may not have that specialist, but we’re going to make sure that this content is as great as it can be and that this research program is thorough.
And so getting up and running, it’s pulling on the resources that are out already out there, pulling on our network, upleveling our education, not reinventing the wheel by having done all of that research ourselves, and just tailoring everything for what we need. It’s like just enough of everything that still allows us to accomplish what we need to accomplish.
I love that. Well, there you have it. The most difficult thing Kim’s up against regarding design systems is getting started and being scrappy. Kim, thanks for getting it out of your system. I’m sure you’re not the only one that’s facing this. I’m Dan Mall from SuperFriendly. Thanks for listening to this episode of Get It Out of Your System.
Sarah Federman — Senior Frontend Developer, Design Systems at Atlassian