DesignOps Island Discs - S02E03: Laura Kennedy

Luke Murphy
Luke Murphy
  • Updated

The deprioritization of design systems

For episode three we float over to Chicago to talk with Laura Kennedy, lead designer on design systems at GoodRX, who has worked on a whole bunch of design systems in the last five years. Fitting, with it being so close to Halloween, that we talk to Laura about the spookiest of all design system concepts... deprioritization. Laura shares some signs to watch out for that your system may get deprioritized, how to avoid it ever happening, and what to do if it unfortunately does arise.

Show notes

The Transcript

Luke: So I suppose a good place to start is how did you get into design systems? What was your journey like?

Laura: I've always been wanting to be a graphic designer, like my entire life, I was kind of a nerd in high school. And even sophomore year of high school, I was looking at colleges and looking at graphic design programs. So the majority of my career was actually spent in the design agency, advertising world. Once upon a time, I actually even did packaging and print work and brand guidelines and things like that. But slowly went from a print web hybrid designer to more web and then product base, it was a slow transition kind of like leaving the design agency world and then moving into a product design opportunity at a startup

Luke: Ah, cool. And so did you didn't start when you switched across to doing product design, you didn't start in design systems?

Laura: Yeah. I started immediately into design system work. I think I got kinda lucky just in the sense that I had an old coworker of mine who was on that design system team. And he kind of told me about it and was like, Laura, I think you'd be a really good fit for this, you should really look into it and apply. And in general, I'm a really detail-oriented person and in my agency life, I would even write design style guides, which kind of lends itself to writing about component documentation and really trying to write up those annotations for dev handoff. I was already kind of doing that at the agency world, but I just kind of levelled up a bit when I moved on to design systems.

Luke: It's not the usual sort of path in either. It's usually people do the sort of straight-up product design and then go, oh no, this would be way easier if I had a system behind it.

Laura: Yeah. I got maybe kind of lucky too because this was back in 2017 and I think Brad Frost didn't even write the atomic design book until 2016. So it was still in its infancy then. So I got in on the ground floor of how to build a design system and be on a design system team.

Luke: That's not a bad way! So obviously the way that you ended up on the podcast was because you're part of design system slack, and I noticed you popping up in a conversation about, deprioritizing design systems, which is an area that I think a lot of people want to know about. It happens to a lot of people that their design systems get deprioritized. But not a lot of people have had experience of it happening before when they come to it. And a lot of people don't really know how to handle it and what to do with it, because it's one of those things where it’s like your resources are taken away or the entire design system, it's just like, yeah we're going to shelve that for a while. It's a bit of a shitty, shitty thing to happen. So, I mean, I suppose you've had it happen a couple of times or once in the past, right?

Laura: Yeah. So actually it happened even on my first design system that I worked on. I'm now on my third design system. So that's kind of exciting for me. But yeah, it even happened kind of back in that infancy original design system. I feel like we started off with the best of intentions and when I joined the team they already did all that foundational work, a lot of that was already established and it was a well-staffed, well-funded team that were maybe 12, 14 of us on the team. We had product support, we had a scrum master. We had obviously eng and an information architect and a tech writer and every single discipline were on the team. Those were the dream days and that's my dream state that I want to get back to. We were just a really well-organized team a really well-oiled machine. We were just cranking out components. We had a roadmap we were relating it to the product roadmap. It was a dream state, but then it slowly started going off the rails when resources we're getting pulled off of our team, onto other internal initiatives with product feature work. I totally understand how that can easily happen, at the end of the day, we also need to ship a product, but it was starting to take away the benefits of having a design system because we didn't have that oversight. We were just being pulled in too many different directions and it was impossible to stay in the loop on things.

Luke: Did it come as a surprise to you when it started to happen?

Laura: You know, it was so slow, in hindsight I didn't realize it until after the fact, no one ever blatantly said your design system is getting deprioritized. They almost took it for granted how well it was running, but then when they took away the resources, it just very slowly got off the rails. We lost product support, a lot of those disciplines suddenly now design and eng were needing to make a roadmap and make all of our tickets and run around talking to the other product teams, trying to see what their needs were for new design system components. We weren't spending the time making the thing, we were spending the time doing the investigatory managing stuff on top of the work that we were also doing on other teams. So it was like, we had two jobs, cause it was project management, being a designer on product work and then also being an individual contributor on the design system too. So it was a lot. And then things we're just going off the rails and then people started leaving cause they were unhappy. And you know, it was a startup. I think they started to have maybe financial woes. So there were layoffs in the org and it made us just very uncomfortable and not feel secure in our jobs.

Luke: I mean, it doesn't sound like an ideal situation. And so it does kind of sound like the perfect storm of everything starting to unravel. And I'm guessing that's the point where it just fell apart. People left and nobody was replaced. Sounds about right?

Laura: Yeah, exactly. Actually the entire design system team ended up abandoning the project and now it probably is shelved at that company because no one's there to work on it.

Luke: And so I'm curious, looking back in hindsight, there were obvious signs that things started to go wrong. Ie. resource being taken away, people being moved off into other teams.  But I suppose in hindsight, were there any other sort of like organizational signs that you now look back and go, oh shit, if I noticed that I maybe would have, had an idea that this was going on a bit sooner.

Laura: Yeah. I mean, I think you have to really pay attention to the lay of the land, like what's going on in the tech org. Read between the lines as to why they're making their decisions. They weren't telling us that there was money trouble, but I think that was kind of bleeding into it since they were a startup. I think that's probably a common problem for startups, and always a common risk.  

Luke: To be honest, it's not just the design systems, whenever any project is getting deprioritized, a lot of it is around the value that it's bringing to the business. And I'm just curious, in that instance, did you guys have any kind of robust measurement or metrics that you were trying to hit as a design system team?

Laura: We did not. And I think that was a critical problem of that design system. So when I eventually left that job and moved on to my next design system, I definitely took a lot of those lessons learned from the last situation to try to set up this new design system for success and not failure. So for that design system, it was kind of scrappy too, really starting it from the ground up, but really was trying to strategize where we prioritize components. So really, really, having a seat at the table with product and trying to strategize, where we can kind of embed and where we can really flesh out components that it's gonna make their job easier to get their new features out. So I think that was a step that was missing from the first design system, but definitely helped set us up for success the second time around for me.

Luke: Yeah, that makes sense. I mean, I've had the same thing. You need to treat your design system as a product in itself, Right? If you're not providing value and if it's not defensible so that when something goes wrong, it's not the first thing on the chopping block because you're like, no, we bring this value, this is what we do. This is how we help.  

Laura: Yeah, I think it also really helps that the second job had sort of the start of a design system, but it felt more like a UI kit. So there were no guidelines in place there. It was definitely like a decentralized design system I would call it. If your listeners listen to last season, they would know what that is. But basically, there was no centralized team working on it and everyone was contributing into it, but there was no oversight management team keeping a high-level view. So when I came in and I was kind of proposing this new system, I was able to really identify, we have 10 different drop-down menus that, we should really kind of consolidate that and clean up our patterns. And it was just because you don't have that oversight counsel or a team or person. That's just really critical for having someone in that position so that they could point out areas for improvement, areas to systematize things, a bit better. And then also writing a documentation website, like zeroheight, I'm not sponsored and paid to say that, I do love zeroheight. So just like spinning up a documentation website so it's crystal clear for everyone.  How would you use the components accurately so you don't run into those consistency issues.  You almost have to do an audit to prove the worth of a design system and then have thought leadership presentations that you would present to stakeholders to try to like get buy-in from them. So that's a step we should have done probably for the first design system. But I think we were also just so slammed we didn't have the time. Time spent writing presentations is time you're not spending actually making components.

Luke: Yeah. And I mean, especially if you're in that golden age where you're well-resourced, you have all the things that you think you need, you don't think you need to do that, you just want to focus on the core IC work and so I suppose having dealt with that yourself, somebody was asking you for advice and like how you deal when you get your design system deprioritized. Do you have any thoughts around that? And especially around when it's worth sticking around and fighting for the system. And at what point you just cut and run is the best decision to make?

Laura: I definitely feel like you have to give it kind of the old college try to make it work. It's almost like an educational component to this, of you just kind of have to teach the org the value of a design system. Showing them the inefficiencies that happen when something is made bespoke or gets added to the library. And then you're just creating tech debt cause there's junk in the library that's not systematized, so it's just an educational component of educating the org.  Kind of like how a design system works and how it's supposed to make their life easier. So, at the second job, I was doing lots of lunch and learns and my tech lead was doing lunch and learns too on the tech side for how to contribute back into the design system library in a proper way that was systematized. So yeah, just really setting up that org for success with all this upfront thought leadership and education. And then, like I said earlier, really just trying to strategize what you're going to work on and relating that to feature work that’s upcoming. So relating it to the roadmap and then also doing user testing. We were testing the initial design that was already live in our product. And then we made design system improvements where we made a more systemized cleaned up pattern, on the UX side we did a one-to-one test and it was crazy how much better the new design system pattern worked, we had a 50% increase in using our filter component. But it was so great to actually like having metrics to really show, like see, we have data to back us up that this is going to benefit our end users, our internal users that are on our tech org. Just really making everyone's lives easier and having that user research to back it up.

Luke: Did you end up documenting that in the design system documentation as well?

Laura:Yeah, so we actually even did a whole tech demo just around a lessons learned initiative of this whole table filter rework that we were doing. So just definitely again, emphasizing to the org, Hey, look, we're doing this and it's working, just showing them the data.

Luke: Also it's then valuable going forward as well, cause you're cutting down on conversations that happen in the future. Right? If you are effective at communicating that stuff out as a team, to the rest of the org and to the stakeholders and then, ideally documenting it as well, somebody in three months time is going to be, well, why are we doing this? Or, I want to do this again. Or,  this seems crap, let's throw it out and do it again. And it's like, well actually we have the research and it's here and I can just point you to it, you don't have to the conversations and the arguments again and again.

Laura: Yeah. And it's like, we already figured out the model that worked really well. So we could just kind of repeat that model over and over again. it's just really critical to have that showcase moment of design system wins too, it's almost like a PR campaign you have to do of like, see, see it's worth the investment.

Luke: It sounds like it's maybe a little bit reductionist, but it is the thing that keeps coming up is just treat your design system as a product, which involves product marketing as well.  it involves actually doing decent research and user testing. It involves good project management and product management.

Laura: Yeah. I mean there's definitely a whole bunch of design ops sessions you can do just on this, how to run a successful design system.

Luke: So I suppose there are, as we mentioned before, there are points where you are going to move on to other jobs and other design systems, having now worked on three different ones have you found there's any markers when you're looking for a new team or interviewing at a place or starting at a new place? Are there any markers that you've found for a good team or a good setup for a design system team that you'd advise people to look for for a healthy design system?

Laura: Yeah, I mean, it also kind of helps that I feel like I've lived that in the early days of my first design system of that dream state, where you just had so many different disciplines on the team and we're all just hustling together to create a better design system. So I definitely look for multiple disciplines on the team and well-staffed, you know, there's nothing wrong with a scrappy design systems team. But that's what I had at my second design system I worked on, but when I was moving on to my third, just was really looking for a place where they were really well-staffed, really well-funded. And then they had a contribution model that I personally like working with, which is the centralized contribution model. I think that that's where I am the happiest personally, not that there’s anything wrong with the embed hybrid model, but, just for me, that's my preference. And then also seeing how team morale is, how happy everyone is,  how are things going? Are they running into pain points with running their design system? How are they governing their design system? So try to make sure the whole tech org, from eng to product designers are using the components that are in place in the system for them to use so we keep that consistency. We don't end up in that scenario I kind of described earlier of having like 10 different dropdowns, just because the left-hand doesn't know what the right hand is doing.

Luke: Yeah, actually on the flip side, have you noticed any red flags that you're like, what should people look for to avoid like the plague when they're looking at design system teams?

Laura: I mean, I also just try to, if possible, get a sense of how their Figma library is set up or their documentation. Even better if I can get eyes on it before starting and committing, just like can kind of see like what I'm walking into because just in general, I'm a very detail-oriented, mildly OCD person where I just want my Figma library to be set up in such a very pristine way. So it's just very organized and crystal clear, everything's nice and clean organized and that they actually have good documentation written, cause that was a pain point in my old life of walking into a new company, a new tech org, let alone a new design system in not knowing the rules for anything or not even knowing like which colour do you use for texts, that to me is a huge red flag. So yeah, I'm trying to gauge them on how good their documentation is for sure.  Also if I believe in the company's mission and their goals.

Luke: Yeah, a hundred percent, I think it's almost time that we ship you off to your design ops island. Now. So obviously, before you go, you get to choose a few things to take with you just to make your time on the island a little bit easier. You've got a piece of music, a piece of literature and a luxury item. So I suppose let's start. What music would you take with you?

Laura: I think. Some kind of survival guide podcast

Luke: I haven't had anybody go the logical route yet.

Laura: Well I feel like when I was listening to season one, somebody said a survival book, but II want a survival podcast.

Luke:Yeah. I mean, the best way to learn anything is through podcasts, right?

Laura:Yeah, exactly. And I'm a very practical person and I like guides, so I need a very detailed podcast to help me survive.

Luke: You also get to take a piece of literature with you.

Laura: I have this collection from the Art Institute of Chicago, it's a nice way of experiencing the museum from my home. Last year, with 2020 and being in lockdown, I really missed the museum. So I actually found myself whenever I was feeling down in 2020 looking through my art collection book.

Luke: Aww, it's so wholesome. You also get to take a luxury item. So what luxury item would you take with you?

Laura: I would definitely take my Nintendo switch, and somehow be able to recharge it.  

Luke: Oh yeah, there's unlimited batteries on the island. It's fine.

Laura: Also in 2020, I got really into Animal Crossing, which is basically you design and decorate a deserted island. I'm a designer at heart and it's just like a fun little design game for me

Luke: Amazing, thank you so much.

Was this article helpful?