Managing design system projects - with Varya Stepanova

Welcome everyone to the Product Bakery. Today, Alex and myself talked to Vaya Stepanova about design systems. We talked about the history of design systems and what companies require these days to successfully build a design system as well as measuring it and seeing the impact of it after they have developed it. Alex, what have you took away today? I think it was just great to talk to someone who has seen different companies working on design systems, different approaches, different problems. A lot of things that I've also can connect to my own experience on what goes well, what doesn't go so well and yeah, without taking too much away, enjoy the episode. And before we start with the episode, a short reminder as always, make sure that you follow us on social media, especially on LinkedIn and Instagram. And if you like this episode, don't hesitate to share it with your friends and family and colleagues. Let's get started. Hi, Christian. Hi, Varya. Hello. Hi. So lovely to have you here today. Before we jump to our conversation, as usual, I quickly wanted to use the time to introduce you to the audience. Today we have a special session and very early when we launched the podcast, we shortly talked about design systems. So it's really worth deep diving with you on the topic because you are definitely an expert on design systems with experience coming from front-end developer and you had quite a successful career there. You were team leader for different teams, also some interesting names on your CV from SC5 to Zalando, but then you transitioned into design systems as a design system specialist. And currently you have your own consulting firm where you pretty much help different organizations to build or improve their design systems. So maybe to kick it off, like one thing that I'm generally curious in is like, how did you transition from being a software developer to becoming a design systems expert? Hi guys. And yeah, hi once again, and thank you for having me here. It's great to be in the podcast and thank you for the extensive introduction. Answering to the question, I actually never felt that there was any transition, but it was kind of evolution because even though I have this technical background and I was working as a front-end engineer, overall I have 15 years of front-end engineer career, but it was always somehow focused on component-driven development. And even before the term design systems emerged. Of course, back then the understanding of the phenomena was maybe too technical, modern standards. And the evolution was maybe not transition from front-end developer to designer or manager, but adding these competencies atop of existing. I think it's very interesting actually, if we think of also development, software development and so on, historically, it was always like a profession that tried to improve, be fast by reusing components, reusing code and so on. And actually design picked it up much later in the process because I think designers were used to do things from scratch, hand them over to the developers without like really thinking too much on it. And then this design system theme or the whole topic of design systems came much later. Would you say that having a background also in engineering helped you transition into design systems and build a good understanding there? Yes and no. So definitely knowing how to develop software always helped, especially with different automations, because design system can be very much advanced. And if you can code for yourself, it helps a lot. You don't have to rely on different tools, often paid tools. But sometimes it is an obstacle because there is certain gap between software developer thinking and design thinking. To my understanding, designers see the things in a more holistic way, while the developers, as you pointed out, tend to modularize and componentize everything. But even though design system is focused on these chunks or pieces of interface, it still has to be a very holistic theme itself. So in this regard, the software engineer background might be a little obstacle to that. And this is why I believe it's very important to study design, to understand design as a software engineer, or at least to pair with your design recording. I'm for example, I'm product manager and I don't understand anything. So that's why I was just wondering, because as a product manager, you work on many projects and you have many features on your list that needs to be developed. And I don't care to be the bad guy in this call, how it's be done. To me, it's important that it gets done at some point. I'm just making it worse than it is. But I just try to understand, at which point does it make sense to start thinking about a design system? Ideally, it should be built first, because it turns out to be much cheaper for the business. Unfortunately, it is not always seen by all their team members and especially top levels that they have to invest in the design system. So sometimes they have to compromise and build it later, but I believe that it is always more expensive. And why? Basically, because you have to rewrite your code if it's big on the level. And besides that, when you make, as I mentioned, design system has to be a very holistic thing. And when you change such top level things like typography or some brand alignments, it will always create you some technical depth to make it according to the design system you are building. And I think it's like extra money for development and design. But can you think of reasons why you should not build a design system? So let's say you have full autonomous teams who work on different products with a different designer. Would a design system in such a case make sense? It depends on the size of the project. So sure, you don't have to have a design system for every single project in the world. Some projects can live without it, but sometimes you should have it even for a single one project. It depends on the project size and on how many people collaborate to build this project. But for sure, if you are making a cat's homepage, you don't have to have a design system there. A big project on my list. Fair enough. But I think, Christian, if we think back when we were working on the design system, that was actually what made it expensive for us. We had to refactor so many things. Absolutely. We could not simply, like wherever we introduced something of the design system, then it was inconsistent with what we already had in place. And I also think speaking about when to start it, we started it quite late in the process. The company already existed for quite some time when we joined and then there was a merger with another company and we had to align styles between two different companies. So the way we approached it is that we had a task force at the beginning and then it was running in parallel with the normal product development process. And I always felt like we never really had enough time to focus on a design system because of this approach. So I was wondering if there are best practices. Should I set up a design system team that really focuses only on this or what is your experience also on how to pull it off and how to launch a design system? In my experience, the setup where there is a design system team works better, but in the community there are different approaches. So some people say that shared ownership might work, but I still believe that there should be a facilitator behind this shared ownership. So there should be someone who's really keen on the design system and who likes to move this thing forward. It doesn't even have to be a technical person. It might be like a product owner, but we consider the design system as a product in this case. But there should be some driver behind it. So Christian, you should care more about the design system. I did care in the past. Don't make me look so bad. Christian is like the product manager with the whip in the background. Okay, this is my desired role. When I got assigned to that design system project, there were many people working on it already, but I was missing somehow a holistic view on the whole project status. So I knew there was one designer working on the components for the apps, the other one for the website. They sometimes had chats between each other, sometimes not. There were some teams working on website components. The apps weren't ready. So it was also a kind of a mess, not in a negative way, but there were many people working on different things. And it was hard to me when I came in to get the full picture on what is going on. So I try to understand how do you kick things off? And is there a kind of structured approach to get started with a design system? Yeah, that's a tricky question, actually, because again, I don't think there is the right answer here. It very much depends on the company and how you organize this work. Well, I can probably answer by example. So I can share my experience with the latest design system project. Also, not when we started, but somewhere in the middle, it was a huge mess and how we understood that it's a mess. Basically, the team was always busy, but we could tell nothing about what we have done to the upper levels or to other people. So we were always doing something, but to the outside, it looked like we didn't do anything useful, even though I believe that it wasn't. And we made, back then, we made a kind of little exercise in the team, like how we could structure our activities and how we can present it in Task Tracker. In that case, it was Jira, but it doesn't really matter what exactly the Task Tracker is. But what we actually did, we had a little workshop where we had on the sticky notes, we had different activities, what we're actually doing from day to day. And then we tried to categorize these activities somehow. And we were also attaching smaller sticky notes on top of the normal one with the kind of parameters that we assigned to these activities that we would like to track, or maybe merge these activities by this parameter or something like that. And then apparently, it was completely design thinking process because we were making this, trying to group these stickers somehow. And apparently, we emerged with our own custom project management system, I would say. Yeah. And for that, we needed a bit custom Jira setup, but the IT helped us. And so the outcome was like design system is working on EPICS, design system team is working on EPICS. And the EPIC, we had the only kind of feeling of what EPIC is, but it is something you can communicate to other people. Okay, we have been done this. And inside the EPIC, we had certain stages. And these stages are preparation, design, implementation, promotion, and automation. And every EPIC, it can go through these stages. Some can be skipped, but usually, it goes like that. So the preparation is a very important process for design system. It's not similar to like regular product, because the design system is a product that serves other developers and designers. And we have to ensure that we are delivering for them. And this preparation phase is to align with them. Sometimes it takes quite long, but if made carefully, then there is a design phase and implementation phase. This is similar to a regular process. And after that, it goes promotion. Because again, maybe a bit different from the regular process, but the outcomes of design system have to be communicated to the teams, not in probably in a bit pushy way sometimes. So you're not only just notifying them, but you are inviting them to internal workshops, or to pair program, to co-designing. And this is all has to be counted like work done. So this is what we emerged with this promotion type. And the last one is automation. It's like when you tried some idea, and we know it works. And if we can somehow automate it, we automate. But it's of course not always. You cannot automate creating new components. You have always to do it from scratch, but some things can be automated. Yeah. And so basically that was our custom process. So we created custom task types, issue types in Jira. And so now we know that, okay, what is inside our epics? And we see how it goes like as a stairs, like from stage to stage. And I love that you did that. And it's actually almost the same way how we did it back then at SumUp, if you remember Alex, because I was the Jira admin. So I was able to play around with issue types. Jira heart is already beating louder. Yeah, but I did the same, or we did the same. So we sat down, we broke down the components and screens into epics. And then based on that, we started adding the different tasks and were able to report on an epic level, what is going on. And obviously the epic was connected to a bigger issue type. I think it was back then. I remember an opportunity or an initiative actually. So we had a holistic view by really doing the project management work. And that had worked very well back then, Alex. Also sitting down with the designers and asking them, Hey guys, how do you see this whole thing being broken down into epics? And it's great that we started talking about processes. One thing that I'm also curious about is when we talk about the design system and every change obviously also affects a lot of different people in the company. And yeah, as you already said, need to have like co-creation workshops to get the input from the different teams. But when it comes to the maintenance or to generally have a good approach of making sure, okay, I'm not like building something that's already existing or changing something that might affect another team. Are there any best practices like when it comes to how to maintain a design system and how to collaborate with different teams and roles to maintain it? Yeah. And thank you for that question. Yeah. I'm a big fan of different testing and automations and here is where they can help us. So in the design systems I build, I make sure that we have visual regression tests for sure. They are often omitted and I believe that it shouldn't be done this way. Visual regression tests have always been there and it helped me dozens of times to spot the differences which I definitely would miss. And it ensures the quality. And on top of that, it would be good to have integration tests. So if some edge cases that can be met at the projects where design system is linked, then it's good to kind of have this environment and build kind of integration tests on top of that. They can also be implemented with the approach of visual regression or like some different, but they are kind of more integration tests. And do you have any tips for starting also the development, for example, of a new component? How should I involve, for example, other designers or other developers or different teams, especially in a big organization to make sure that we are building the right thing and building something that's sustainable also for the future? Yeah, I think it is always good to ask people. You can invite them to the planning phase. And at the last project, we actually practiced that there are two planning meetings. So before we are starting to do something, we have the first meeting where we invite everyone interested and we listen to their feedback and suggestions. But sometimes this time is not enough for people to come up with their ideas. And this is why we had a second planning meeting in two weeks, but with the same topic. I know it's a bit slow because we postponed the development and design for two weeks, but it really paid us back because we had very valuable input in this second meetings. And after that, there was like design and creating. But it is more question probably to like people management. I tend to be maybe a bit pushy in a good way because if I know that sometimes someone can be very good input for that, I can directly ask, let's pair a program or let's have a meeting. Do you have time? Let's speak about that. So you have to like have this attitude. I love that. I was asking when is it done? Yeah. And sometimes you really just need to be proactive and pushy. I think, yeah, pushy has a little bit this negative association, but I think it's super important. Yeah. Maybe like proactive would be a better word. Fair point. Absolutely. Yeah. Proactiveness. Involve people, go to them actively, get their input early. I think, and it will help people also outside of design systems. I think in the overall and over product organizations, when you are working cross-functionally and so on, that's super important. I was just wondering, how do you approach communication to especially the upper level of companies? What are the ways to either emphasize for getting started with a design system or reporting on progress? Yeah. That's an interesting question. And I think it bridges us to a design system impact. And I recently had a presentation about that at the inter-design systems conference, if you heard about that. Yeah. And my presentation was mostly about money. So yeah. That's important in business. Yeah. To my experience, business people love to hear about money and it would be very good to set up some metrics that translate design system value into usually how much you could save, or sometimes how much you can earn with the help of design system. And if you want to propose design system, it would be good to promise something with these formulas. But be careful, don't promise too much. Yeah. What would be something that I can promise my CEO if we start building a design system? You can just calculate how much time it would take to support the legacy code, like with five versions of a button and how much cheaper it would be if you have a design system. But for sure, you include the costs of creating design system. But to my experience, usually the people that have done these calculations, they have enormous benefits. And so that business doesn't even believe them at first. So it is also good to show them how you do these calculations so that they at least trust these numbers. Because sometimes the numbers are unbelievable and on a large organization can be millions of euros. And I love that you just mentioned that, because this is also something that I see many times people not doing. And it's not like two crazy calculations. So you can just ask a developer, please tell me on average, how much more time you would spend in just maintaining old code versus rewriting the system. And with some basic data points, you can start adding this up to a couple of million euros sometimes or dollars that clearly show you if I continue in that way, it will slow me down and opportunity costs getting bigger and bigger if I'm not doing it. Yeah, sure. The more advanced way would be if we somehow measure time to market for the new features. And here we transform our conversation from saving to earning, which I believe is more positive, but it is much more complex. Personally, I haven't done this work, but it is an interesting idea. And I think it's positive vibes to the business that we are not only saving, but we are also producing new value and new business opportunities. If you just want to roll out your product to a new country, you can easily identify the market and calculate every day where you're not launching, how much money you would lose. I'm pretty sure the design system is not the only thing that eventually will delay the launch, but it does have an impact. And if you are a B2C product that is very front-end driven, then I think it's a very good way to argue like that. Yeah. And I think the time to market is a super important argument and super good argument because it affects a lot of different parties as well. If I only think like with my design lens on, I get my team to be faster in terms of developing new features because they can rely on already existing components and don't have to reinvent or rethink the whole wheel. You can prototype much faster and therefore test it earlier with your customers because you kind of can quickly move into a very high fidelity prototype by reusing the components. And I think then at the end, there is still the development time also that gets speed up. So in theory, you can just shorten down the whole process and everyone benefits from it. And I think I'm always just looking at the design side of things in my day-to-day business because that's what's relevant. And there it's a massive improvement if you have a design system. Sure, I can relate. And I think maybe the only thing that I sometimes hear or sometimes heard from different designers, and I think now we're somehow getting in a bit of a philosophical area, is like, are design systems restricting us in creativity because I simply reuse things. Do you have any thoughts on that? I also had conversations like that and I heard a lot different opinions. Yeah, I think it's like we have to balance there. Of course, design systems are restricting us and restricting the creativity, but that's the point. Because if we don't have this restriction, we end up with five versions of button. And design-wise, even though it's very creative, it's still not good because it doesn't provide coherent user experience at the end. So we have to be restricted, but maybe not too much. This is why design system has to be leading theme. It can be changed, but it should be aligned with everyone and ensure that this change doesn't break anything. Yeah, I totally echo that. I think for the experience, the consistency is the most important thing. And I would always pick design system over some creative ideas every time that we need to launch something. I hope you will not get hated for that later, Alex. And if I do, I'm happy to stand to that. I guess that's like the business part of design, right? When you work in products. There's trade-offs. You can still be an artist, right? And draw some pictures. Outside work, absolutely. Cool. What do you think are the biggest mistakes that companies make when building design systems? I think that the biggest mistake that many have is that they think of a design system as a project, which ends somewhere. But it's not a project, it's a process. And actually, it's like constantly evolving process. And this is a very important thing to communicate to the business levels. So that when we, especially when we promote this investment idea to them, that these investments have to be constant. Otherwise, they just don't work. I agree. And when we look at that process, I would be also curious to hear from you. What was the history of design systems? So what was the process and where did it start? And where do you see it moving to in the future? The answer would be different for different people. Because many approach design systems from design side. But because I have this technical background, I approach them from the technical side. So for me, it started with this component driven development, and then style guides, and then it breached to the design. And for me, it looks like we are tending to have more tight collaboration and more productive collaboration with the designers. Because last past years, the industry standard was that designers stay aside. And often, the designers for their own team in the company, and they worked maybe as a design agency model. So they're just passing designers to the developers. And it resulted that the products were never coded as they were designed. And at the end of the day, some designers even said, I don't include it into my portfolio. I have nothing to do with that. So I believe that there will be less situations like that in the future. And thanks to design systems as well. So we are more working together in understanding each other and finally delivering what was designed to the users. And how do you feel that new products or tools that we are using nowadays improve also this process? And just thinking of Figma and the way they use components or a sketch, or even like a lot of tools that I've seen that integrate live code, having React components directly translated to design files, and then back again. Do you feel like the landscape is changing? Is there still much to expect from new tools to come to improve this process even much more? Yeah, I think the landscape definitely has changed. And now we have great tools helping us, but there is still a lot of room for improvement. Because if we speak about like my emotional experience, I'm never happy with the tools we have, even though they are great to compare into what we had years ago. But still, there is a lot of room for improvements. And I think really looking forward to the next tools coming. So I believe that we will have an even better environment very soon. Maybe we can give some people some product ideas. What would you say is missing currently on current tools? Well, I would actually, I'm working on a side project, which is yet secret. So I don't want to share that either. Fair enough, fair enough. But I think it's not only the tools that will make the world of design systems better in the future. We know that you're also doing workshops around that. So I think it's a good chance maybe to share with people what you are doing as the other side project in quotes. Yeah, sure. As mentioned, I run consultancy business with myself and the partners, and we are reaching to the community by having the workshops. Last week we had entry-level workshop on design systems. And the key feature there was that the people were working in multidisciplinary teams. They were designers and developers working on some toy project. And we practiced this designer and developer alignment there. So we are going to run this workshop once again in May, and probably later if there are enough interested people. So the name is Hands-On with Design Systems. And I see huge demand in the community for activities like that. And preparing that first workshop, I spoke to hundreds of people, and many said that, okay, we already have design system. We probably don't need this entry-level workshop, but we would love to have to learn about advanced challenges. Because everyone is doing design systems nowadays, and there is no reason to make your own mistakes on the way. It's better to learn on someone else's. Yeah. And at the moment, alongside with offering this entry-level workshop, I'm researching also what are the advanced challenges in the design system world. And probably we come up with something interesting soon. Amazing. We will link it in the description, so everyone can take a look. And yeah, now is the chance. May is coming soon. So take a look and sign up. And share all the challenges that you might have for the advanced design system. Yeah. Feel free to reach out and we will make sure that LinkedIn and Twitter is in the description as well. Okay. Thank you. I have one final question. Now that we talked about design systems and the whole process and your history, what would you say? Do you feel more like a designer or do you feel more like a developer? Oh, that's a tricky question. Say product manager. Say product manager. Okay. I'm happy with that. So question answered. I'm fine. We can close it now. Awesome. Maria, thanks a lot for joining us. It was beautiful. Yeah. Thank you. Yeah. Thank you very much. It was a great experience. Bye.