Interview: Developing and deploying Design system, with Toni and Kari from Vaisala

Toni (00:04): If you have a lot of legacy, it definitely will impact the design system quite heavily, and you need to put more work on it to make it work for the whole company. Let's say that you have four different technologies that you build front-end up on. So it's definitely a more challenging solution than when you have only one or two, for example, like other things, and you want to move to a new one. Lauri (00:27): Welcome to DevOps Sauna. My name is Lauri. Remember a while back, we discussed with our CTO Marko about design systems and how they are connected to DevOps. Well, we invited two experienced people from our customer, Vaisala, Toni Lehtimäki and Kari Heikkilä. Marko Klemetti, our CTO, is holding the mic. Let's dive right in and listen to what Toni and Kari say about the design systems. Marko (00:59): Hello, everybody. I am Marko Klemetti, the CTO of Eficode, and I've been working around design systems for a number of years from the developer's and especially the DevOps point of view. And today, we have Kari and Toni talking with us today on design systems by Vaisala, so if you could just introduce ourselves. Kari (01:24): Yeah. Hi, my name is Kari Heikkilä. I have worked quite long in Vaisala, and all my career there been doing something related to user interfaces from the time that there was no design systems yet until now being the Design Lead of our design system, which is called Rockhopper. Toni (01:46): Hello, my name is Toni Lehtimäki, and I've been working with Vaisala for a few past years now, working in our design system team as a tech lead. I do a lot of stuff with Kari and always been enthusiastic about front-end related stuff and user experience and accessibility and whatnot related to front-end development. Marko (02:09): Cool. Sounds awesome. So grasshopper seems to be the term. If we start from the very beginning, what challenges did you have to decide on going for a design system, or did the idea for a design system come from somewhere else? Kari (02:26): Yeah, actually, it's Rockhopper. Marko (02:29): Rockhopper. Sorry. Kari (02:30): Yeah, it's a species of penguins, one of the few ones of those that do not slide on its belly, but it's boldly jumps from stone to stone going forward and always having a bad hair day. Yeah. What challenges did we have back in time? Marko (02:48): Yeah. Why did you start doing a design system essentially? Kari (02:54): I think kind of started around 2016, creating the style. Probably we didn't talk about or use the name of design system at that time yet, but we did have a previous platform and style. And the previous version mixed front end and back end nicely together, and everything was considered reusable there, all the components or customizations of those. So eventually, it becomes something that's not very reusable as such. And it was quite slowly evolving that priority tended to be on the backend side of those services. We needed speed, and we needed also new style. Everyone was doing flat and modern-looking style at that time. We were still on gradient style, and that was quite difficult to get back ported on the Platform 10. So we needed to have a fresh start with modern web technologies and a fresh style. Marko (04:07): Sounds reasonable. So if we look back awhile still, when you started, what did you expect to get out of having a design system? So what were the things you were expecting back then? Kari (04:22): Actually, the speed and possibility to put more weight on UX and usability. Definitely. Marko (04:32): Cool. So before asking what you're expecting today, I guess we should jump into what the design system, the Rockhopper, you're calling it. So how did you first build and define the first version of the design system? So you were mentioning like gradients on flat UI back then. So how did you define the first version? Kari (04:56): Good question. Not sure when it really turned out to be a design system, but what would you think, Toni? Would it be that moment when we started to create our component library, the first version of it? Toni (05:14): Yeah, maybe that's clear steer to the pathway of design systems. So there was first just the style, and then the technical aspects followed and community-related stuff, too. So kind of found out it's not just a style guide. It's not just a component library. So it's neither of those in isolation. So we found out that we should have this... Actually, we call it design and development systems wanting to emphasize the glue between the designers and the developers. Marko (05:49): Was there a specific project you were working on at the time? Or how did you start with the design system? So was it implemented on one, or did you do it separate from the project you had or...? Kari (06:03): Well, the style evolved on a bit separate track first. So there were pilot project that started to use it and evolve it. They didn't have the legacy code, so they could go forward quite fast. But then, on the component library side, it was partly as an independent thing that we had, for example, help from Eficode trying to kick the component library alive, the first version of it. And partly also our application projects very involved in helping development and we tried to get cooperative activity around it. Toni (06:49): Yeah, and I think we had few projects that were in a key part of developing the component library at its first stages before we started to take it forward to other projects. So that's what I remember that we had few projects being the pilot in a way. I think that it's needed, that you need some, some project to PST, the spearhead to go forward with the stuff. Marko (07:18): Yep. So would you say that if someone wants to start working on design systems, should they, in your opinion, start with defining the components, or would you go for a project now that you have the design system in place and work it together with the project? This is also something I don't have a definite answer over in my experience, so. Toni (07:40): And I think it doesn't have a definite answer, maybe. It depends on the context, but what I think is most important is maybe first to get the buy-in at least on some level that we need a design system, get the reasoning behind it, then the resources behind it. And then it's then depending on the company size and the amount of projects and products that it has that what kind of approach is going to be from there on. But definitely, if there's something going on, like a very kind of, let's say, conveniently around the corner coming some new project, it might be the best thing to go forward so you don't have too much the legacy that you have to be weighing all the time when you try to build something new. Kari (08:31): Yeah. It follows the situation that there would be ideal ways to go forward and plans, but then the reality hits, and there's that one or two projects that just need to be delivered. So then you add up your activities with those. Marko (08:50): Yeah. But that's also, as I said, it's the reality, and that's how we'll go anyways unless you're starting a completely new project and attaching the design system there. But then I feel that you often then miss the needs from the whole development organization or the other projects easily. And then you have to pay back that legacy somewhere else or some other time. Kari (09:14): Yeah. Maybe to add one more thing that we did have tremendously good luck, though, if considering the timing. Since we had the previous platform, which caused slowness, and developers wanted to go forward from that, there was certain kind of pressure and also pain. So they quite eagerly took something new into use, and also time-wise at the same time, the outside world started to speak about design systems. It began kind of a password. So we've ready to jump on board right a way. Toni (09:55): Yeah. So especially from the technical point of view, the time was right. Kari (10:01): I don't think that we really planned for that, but it happened in synchronous time. Marko (10:08): Yeah. And now, if you look at any of the developers of design systems or various different parties who have made some sort of insights and questionnaires over how design systems have been implemented, a lot has happened since those times. And it's like, I would say that the things you just mentioned still apply and are still current. Marko (10:34): Before we jump into the tech stuff, which naturally interests me as well, is I want to ask from the culture today. So how do you today make sure that the design system stays fresh, and if there are new areas that you want to develop or say your brand changes and their icon or color changes, how do you stay flexible, so to speak? Kari (10:59): The good thing with Vaisala is that the products that we make usually they focus on business areas, which do not change quite quickly. So in that sense, also, for example, our style is not changing as fast as in their consumer side of things. So we don't need to update that that often. But anyway, we are constantly evolving and releasing new versions of the system. They might improve the technical side or usability or sometime also of the cost to start. So I think probably that's just everyday business. Marko (11:45): Yeah. Do you have a team working on it currently, or people who are in projects, or how have you managed developing the design system? Kari (11:54): We have model where two of us, me and Toni, full-time working on the design system. Then we have UX team, which has designers working on application products, but they also contribute to the common goal of the design system in creating those designs. And then, we have the developers on the application projects, which then they contribute to the design system. And this way, we try to share the work responsibilities, create also buy-in for the use of the components and design. Marko (12:32): Yeah, and this is also something I would say to the listeners that having only a centralized team working under the design system has way less impact than if you would have the UX designers and even the developers being part of developing the design system. So that is something I would also recommend to have. Marko (12:54): How do you collect feedback? Do have a Slack channel for discussing things over the design system? Or do you have an official way of having the discussions or requests? Toni (13:07): I think we have both. So there's the official and unofficial ways, but we use Teams mostly company-wide, but we also have Slack on some part of the company so we need to be on both. That causes some challenges, of course, keeping everything and everyone in sync. Other than that, of course, running some surveys to find out what people think. And we try to foster this idea of developer experience, so we try to do things from that perspective, and we try to have some collaboration between the teams and projects that we have so that we would get to know those people, and they would get to know us and also introduce opportunities in both from the side of our design system, but also from the side of the project so that we could help each other to make the world a better place, to put it bluntly. But mainly, of course, from the code and design perspective. Hopefully, the world will get better in there, too. Of course, as a company, we work in environment and on monitoring things to reduce, for example, emissions and stuff. So in that sense, we really, at least directly but indirectly try to make the world a better place. Kari (14:36): Hey, and I just remembered that at some point, we started to call ourselves human-friendly design system to emphasize the threshold to contact us, for example, in Teams or Slack or even live, so that the threshold would be low. Marko (14:55): Yeah. And also, as said, building the community around something that involves everybody in the development cycle is usually very valuable for the organization, both for the information flow. So, when you have new people coming in or new innovations coming in, I honestly believe that the design system is one of those places where you can easily share the information without actually having to share it as bulletins or news flashes or anything. You just noticed that, okay, there's a new element coming in. Or this is an idea that has been done in some other place of the organization. Toni (15:36): That's a very good point in many aspects of the benefits of design systems, indirectly that you're in contact to many teams, company-wide, depending of course on the company size, and that causes you to see things done differently. And also, sometimes you see that this is probably done better somewhere else or somebody's being more clever and that information can be then distributed to the other teams too. And that's a great benefit of having this a view, a centralized view around the projects that are doing front-end related sub. But also, the technical solutions, let it maybe map solution, or backend stuff, or whatever infrastructure related. Or even that just a customer journey, whatever. Marko (16:38): Yeah, yeah, exactly. And sometimes I feel like people are talking a lot about DevOps, which we are obviously doing as well. But design system is almost, or in a way, as important part of the culture as thinking DevOps-wise would be because it combines the design and developers in a harmonious and a friendly way at the same time. So, you're working towards the same goal. If we look at pre-design system era, there was still, this is the design I've done in this and this graphic design application. Now change it into code. And suddenly, you have the same goal in everything you do and you fulfill each other's work. Marko (17:24): When you started on doing the design system, and of course today, did you look into any of the open source options? Did you do some of the open source or did you just decide already that you are going to do your own whole style components, library and then design system? Kari (17:44): Right in the beginning we decided that we wouldn't lock ourselves to any single solution. That was the case with the previous platform. And when the previous platform, or the base of it, was not supported anymore. So, it created a bit problems. So, that's why we chose that we would try to go to the atoms and molecules. So they were quite independent pieces or building blocks. And also, try to find the best open source components available for use as a basis. And also, where we could not find such so, then we would build those by ourselves. Marko (18:33): Yeah. And I think looking back, at least now, there have been so many different open source design systems and component libraries that have come and gone, that locking yourself one back then, now looking back, would have created more trouble than actually benefited. So, I think even today, even while there are really good component libraries out there in open source, every organization has to, to some extent, do their own work over it. Toni (19:08): Yes. And we use the third party libraries too. And especially in projects, of course. Sometimes they're used if there's some solution fixed their need. What we found out, or have found out after using some of the party libraries that they still do bring problems with them too. So, one is , of course, they usually add a layer of design already and have a certain look and feel and a way how they interact with the user that might be different, what the company has designed their interactions and branding. So that, for example, creates some below that you necessarily don't want to have. And a proof of that is, of course, that if we look at companies having design systems, most of them have done most of the work from zero to the level that they've achieved. Toni (20:07): One thing, what there is to take, is definitely is that what we do too, is we benchmark all the time through the public ones that there's available. Either made by companies or the general ones that everyone knows. To name a few, of course, like the Material-UI based on the Google Material Design. And then, this Chinese one Ant design. In a way was a feature rich choice, we have some like a burden from there, but they, for example, have not thought accessibility pretty much not at all. Marko (20:40): Yeah, actually the same goes for both of those two you mentioned. Toni (20:45): So, those kind of issues then rise when you want to get rid of those. Or you want to improve something that you are dependent on. And then, you find out that we have a problem that we're dependent on this thing that we can not change. Of course, we can try to push things upstream, but it's not necessarily the push that they're looking for. So, it might take longer, it might not end up at all to the upstream. And upstream, I mean the code side, so if we want to make a code change. Marko (21:20): Yeah. I believe that the key term you used there was bloat. And also, for the ones going for a design system or creating one themselves, bloat is something that definitely, even if it doesn't bother today, it will start bothering at some point. And the point from accessibility and the way the existing design systems behave. And you have to change that, are both points of bloat in a way. And of course, then if you were to go to say, if you take an open source library and fork it for your needs, then you would have to yourself, maintain the upstream or the downstream from the upstream. And then you will have clashes there. Kari (22:06): Yeah. I would say that this approach has worked quite well for us. So, being able to pick the best parts from wherever it is. And that being said, if looking from our applications point of view, they, of course, still use open source components from different sources also. Since as we are not trying to offer everything that a application might need. So, we have the basic building blocks and then they have their special needs. And then, they go find the components that they need from somewhere else. And of course, in that phase, we can help them find good components and recommend things. And of course, help with the styling. Toni (22:54): And that actually is a good point there that we can't provide everything that the applications need. Sometimes design systems or component libraries inside design systems are seen a one stop shop or the full solution, which they're not. Toni (23:12): And if we start to evolve on that direction, we should somehow be aware of that ourselves, that we stopped at development because the more complex things get, the harder it comes from the design system perspective to solve those problems. So, it's a good to note that somehow that what kind of issues you will try to solve, technically and design-wise with design system. And is it reusable for others or not? It's good to be very critical on that perspective. I think for example, one common example, which is quite on the edge is data tables, for example, or date pickers. They're quite complex components, both of them already. Toni (23:58): But in our domain, we have even more complex one than those. Then there's, of course, sometimes pops an idea that, could this be reusable or not? And that is something that you have to very critically review that, is this something that could have a benefit? Although that being said, there is always something that you could do a bit better or where you could help. And so, they can be good design principles, of course, or some kind of guidelines that you can make. So that, for example, the interactions between applications on same kind of problem domain, stay pretty much the same, although that the technical solutions might vary a bit. Marko (24:42): And it's also interesting to seeing the open source community you have, well, you mentioned, Ant design, Material UI. Then the older ones, like Semantic UI, are those what we would today call bloats or one-stop-shop. But then there are such like UI Keep or Rebass, which is an interesting variant of the same police at this side. Being really simple based design system, which you then build upon yourself. Lauri (25:11): This is Lauri again. I wanted to let you know that our folks at Eficode have developed a design game that lets you map out your design and development process. It's called Digital Product Building Toolkit, and you can use it to improve your company's capabilities for creating digital production services. The game is open source under creative commons license, and you can download it from the Eficode website. The link is in the show notes. Now, let's get back to the show. Marko (25:39): Interesting. So, I would love to talk a bit about the tech side. Would you like to walk us through what kind of a tech stack you've chosen for your design system? Kari (25:49): Yeah. So, going to day zero, I guess. I can not remember all the reasoning, but somehow there was quite good, common understanding that we should go with TypeScript. And also, React was chosen. Probably, it was our had matured enough for that day already. Marko (26:14): I'm going to say here out loud, that they're good picks, given the community today. Really good picks. Kari (26:22): Yeah. Yeah. It looks like it didn't go wrong. We collected, I would say, something like 20 developers, maybe more, from various applications. Had there a couple of discussions and collected the viewpoints what they did have. And somehow managed to get the common understanding that TypeScript and React would be the way to go. I remember back in the days, it was not easy for the kind of grasp. For example, I remember, one developer commenting that a Facebook framework, can be that something that can be build upon for years forward? But yeah, it was... And I guess time changed or days changed and those internet giants became serious platform providers also. Toni (27:22): Yeah. And what comes to TypeScript actually, that was a lucky dip in a way because the choice, I think, was made in 2018. Or was it even 2017 when the choice was made? So, it had not yet spiked in popularity. So it was, I think that 3.0 of TypeScript, which introduced a lot of new features to TypeScript, was introduced in 2018. And that's when it started to get a lot more popular. Toni (27:52): Of course, the angular people who stayed with it from the version after version 1, then of course, they had known TypeScript for a while. I think TypeScript was first introduced in 2012. So, quite an old technologies, took almost a decade to mature to popularity. And interesting in a way too. Marko (28:15): Yeah. And now, if you look at one of the ways to look at the popularity is, what do the big stock-listed or soon stock listings startup type companies have in their open source linting tools, such as Airbnb, for example. They're slowly merging to TypeScript linting instead of the old JavaScript linting, which they used to have, being the de facto, so to speak. Which is an interesting move and it fits perfectly into what you are doing currently. Where do you do the design then? Kari (28:50): You mean the tool? Marko (28:51): The tool. And first of all, of course the tool, but then how does it evolve into the via TypeScript component libraries? Kari (29:00): Yeah. We are using Figma. Have been using that for, I don't know, five years already. Marko (29:07): Yeah. Kari (29:08): Can you believe, actually, before that we were using Illustrator. And you can imagine that was a bit painful. Marko (29:17): Yeah. Well, many people use XD now and it's the next version of there. So, I have to say that the traditional one, which I referred to before, designers doing the design. And then someone hopefully writing the code for the components would be Illustrator. Exactly. So Figma must've been a relief there. Kari (29:39): Yeah, yeah. Though, I must say that it was quite early days of Figma when we have alerted it and decided to jump there. So, it didn't have that much of features. And fortunately, it has been going forward quite quickly, but I must say, that there are some issues still for maintaining design system that's not that easy with Figma. But yeah, anyway we jump it onboard on Figma and do our designs there, and have our design token library, for example, the component libraries, we call it "the shadow design system" that's there in Figma for designers. But at the moment, we don't have any automated flow from design to code. Marko (30:33): Yeah, but I said personally, I'm not sure if that's still even feasible because someone anyway has to write the functionalities between the components. And even if they look the same in the design, they might be very different on code level. And as you said, you don't change the design system so much that it would be for your environment changing so frequently. How do you then change the ... If you have a change to some part of say a React component and it might need a change in the Figma, how does this process look like? Toni (31:14): Well, we try to go in somewhat in sync, although for design tasks, we don't explicitly use JIRA, for example. But anyway, in the same ticket, we try to recognize that this also needs a design change or that it needs a design-first, for example, if it's a new thing. So sometimes we go hand-in-hand, sometimes it goes so that the design might be a bit ahead, and sometimes it goes so that the goal goes ahead of the design. So there is indeed some work to keep things in sync. And I think that what Kari mentioned that we've been there from the early days of Figma, that things are getting better, of course, there too. But one thing that we are still lacking in in the design side is a good version control. So we have that in code, but in design it might be somebody accidentally change something somewhere. And if there's a lot of layer of changes, then might be a bit difficult to, first of all, notice it or know who did it, that kind of thing still, I think they're coming at some stage, but obviously there are some technical difficulties handling things that are more closer to binaries than just being text. Marko (32:39): Yeah. And I believe the version control is definitely a question that is not yet completely addressed in order to sketch to the XML format or there on data format, which enabled version controlling while ago. Then there's the InVision who is also doing it, but they all have their shortcomings. And in this case, I have to say that what you said earlier here is that the community is the power. So you don't have any centralized place where you just throw in the code and hope that something comes out of, but you actually work as a community, which then also helps keeping it updated even if the tools aren't yet up for the task. Kari (33:27): Yeah, that's also part of how our responsibility is shared. So I'm trying to take care of that UX side that's in sync and then Toni takes care of the technical side. So this way, if we just remember to keep talking to each others, then we should be able to tackle these kind of things. And of course, the tools are also evolving quite quickly. It might sound that I'm criticizing Figma a lot, but I absolutely love it. Sometimes just hope that they would have a time machine and they would live three years in the future, so be able to have the future features already in use now. Marko (34:13): Yeah, I'm probably going to repeat this over and over today, but that you have been living in the future for taking React and TypeScript back then, I have to say. So it's a legit wish in that way. But yeah, definitely. So I said as long as you remember to talk to each, that's also a very good takeaway for the listeners, because there are areas that you cannot solve technically yet, and probably ever for some parts, so building the community and culture that actually wants to nurture the design system and the culture behind it is the most important part. Kari (34:53): Yeah, talk to each other. That's good general advice for anything, I guess. Marko (34:58): Yeah. And the so-called psychological safety there so that people can say that okay, this component has this and this problem. Can we solve it together? Do you want me to solve it or would you be able to help me out here? I'm still going to ask, even while having been slightly futuristic already back then, what kind of areas or what choices would you change if you could during the path? This is more for the listeners. So what areas do you think that you would have changed or would change today except for, of course, having the features available back then already? Toni (35:35): Maybe from the technical side, it's a tough one, of course, to look in retrospect and think that it would have been wiser back then, but in a way, we would consider the third party libraries more critically and more carefully, that would we take anything from third-party libraries, especially if they're from component libraries itself. We found out that there's a lot of good stuff when, if we talk about React space, there's very composable components which do not add a layer of design, or nearly zero layer of design, but perform very well from the accessibility point of view and usability point of view, and they've built in a way that they're easily extendable. Toni (36:17): So those are definitely what I would look for a bit more that okay, if we need a select, for example, is there a good composable solution already available that we can build a bond and trust the foundations of it? That's a good thing to consider. And also, even if a bit complex, that would it make sense to build it from ground up by ourselves or not? I would consider that. Of course, the speed is of essence in the beginning, and that was the case with us too. So we needed to get things up and running first. So of course some decisions are compromises, and contributing to those decisions. So they were not optimal. Or maybe never decisions are optimal, there are always some kind of compromises between the most optimal and the most feasible solution. Marko (37:18): Yeah. To add here, I honestly believe that if you are able to put something into so-called production use or use it in a customer environment, you are going to make mistakes or you are going to make wrong decisions, but if you don't, then you'll actually never get anything done or you never actually get anything finished. So it's a trade off between, as you said, you had the projects already running and you had to put something in place, and build from there. So I think it's evolution anyways. And the more you can have the evolution in the customer environment, the customer applications, the better feedback and the better probability in succeeding you will have. Toni (38:07): Yeah, I think that is a generally important aspect of thinking of design system, the design in it, the community, and the code side as an evolving or a living organism that is constantly on the move, in a way, so we cannot be in a static state. So in that way, it's not a project that you can finish off and then it's done. Or if you do, then it might be then finishing itself. Kari (38:36): Sometimes I also think that it would have been nice if we would have started even a couple of years earlier so that we would be farther apart, but then that probably would have affected the choice of the tool set and technologies also. So I'm not sure if that would actually been that good thing. Marko (39:00): Yeah, one of my very good friends from Unity said once hindsight is always 2020, and it's a good thing to keep in mind. I do believe that many organizations who started too early started doing the design system over Angular, and well, of course, Angular is not dead yet and might still emerge to be most popular. I wouldn't say no to anything knowing what can happen. But when I look at the React component, the whole component structure and how React forms the whole UI component based, it's so much easier to later on switch to something else. And before React, if you would have started doing design systems, I think that only the CSS and HTML components would have been the ones that you follow them through. How do you adopt and onboard new people to the design system? Is it just, here's the library? Go ahead. Use it. There's the instructions and here's the library documentation," or do you have something official in place for adoption? Kari (40:13): Well, I think this is the part where we try to be human friendly. So we try to meet personally, or as personally as it's now possible with Teams and Zoom. But anyway, if our new developers start, so we book a session with him or her, and have an introductory tour of the design system, and get to know each other. So that again lowers the barriers for communication later. Marko (40:45): Sounds good. Do you have some sort of contribution part of the tour? So how do you contribute or how do you make requests for changes as part of it? Toni (40:56): We do explain that part too, and try to build the culture, then tell how we try operate, and that's part of it. So we explain that there's only two of us full time responsible for design system. So in order for things to succeed and work in more seamless way, we need you too. So we try to express that this is a common thing and try to somehow nurture the common ownership. Of course, that's the most difficult part of everything, that build together. In Open Source world, of course you can see the same thing. You have millions of user for some repository, but then only a handful of people keeping it up-to-date, or in the worst case, something that is used almost by a billion and then you have only one maintainer for the whole project and all the billion companies relying on that one thing to be there for the years coming. So it's an interesting thing, of course. Kari (42:09): Yeah, and that's something that we still have work to do also, and plans through how to make the design system and the component library code easier to approach. And if someone needs to fix quickly something, so how they can get their hands in the code and find the correct things there easy. Toni (42:35): Yeah, that is still a challenge, though. Although, we do have a CI/CD pipeline established, we still use some old technologies there. So we have Jenkins running there, and everything is automated from that side. So we generate the packages that are needed, and the documentation is generated from there, and tests are run, and quality gates, and all that stuff, but it all takes time and there's always some conventions in place. So in a way, although version control, ticket system, and all those are nice things, they also take some ... it's not mental, but this cognitive load on your brains that you just want to get this fixed and you know what the fix is, but then you have to go through this process or you have to jump through the pool and swim to the other side, although you know that you just need to go to the other side and deliver this thing. Marko (43:38): Yeah, you actually couldn't have opened the discussion on a better time. I was just going to ask about this because my favorite topic for 2021 is DevOps becoming a NoOps, which means that everything that goes through your CI/CD pipeline, and the infrastructure, and publishing, and storing artifacts, and everything, it should become something that's not a nuisance, something that just happens in the background automatically, and something that you would have to put the culture in place, of course, to swim to the other end of the pool, but at the same time it wouldn't have the trouble of then doing that bootstrapping or bloat around the process that you would then follow. I guess asking from there, do you now have the Jenkins and CI/CD pipeline in place? Which millions others have as well. Even while there are newer technologies, I would still call Jenkins one of the mainstream solutions. But you have it for the design system, but do you have it also for the products using the design system in such a way that you would have connection between the design system and then the deployment pipeline for the products, or is that something you have separated still? Toni (45:03): So the pipelines that we have running for our component library and our design system related assets, in a way they're separate, but we have the deliverables that go through our in-house hosted Artifactory system and we do currently live in between two systems to deliver the artifacts in this context we were talking about NPM packages that we privately host and also cash, that is for speed. And then for ensuring that if somebody removes an NPM package from the real NPM, then it's still on cash for us or in store for us. But there's not that interconnected, there could be, for example, a future dream of that, that when we release something, it will automatically go into the pipelines of the other. So, that doesn't happen currently. But generally, I'm not 100% certain do all the projects have a pipeline, but I'm pretty sure they do. So, everyone has their pipeline for automating the builds testing and such things in place. Marko (46:24): I've noticed now the GitHub, for example, has their Dependabot, which is a tool that reports updated packages and, or security audits automatically for any requester that you enable it for, I know this, that it also changes the way people look at the pipeline. So there are two things that I'm trying to promote currently. Marko (46:48): The first one is of course that the design system could as well be a place where you also share the pipeline. So when you take the design system in place, it would already have the instructions on how you add it into the pipeline, because you have the components and test templates and probably some linting as well there. So you could pretty easily already connect it to the delivery pipeline of the application and not just the design system. Marko (47:15): And then I guess the other part would be when you are sharing the package as an NPM, some of the organizations have already moved to having this kind of Dependabot in place where you have a version or a branch of your application running the latest version of the design system in the CI/CD pipeline. And then if there are changes in the releases you've done into the design system, you would see the products that would be affected by these changes. And it doesn't have to affect the product themselves, but since they're running a separate branch, it should then show that. Toni (47:54): That's definitely something that we strive for to be in that kind of place in the future. Because I think it's kind of the key take away from DevOps anyway, to increase the trust of the things that do deliver. So, that is something that we desire too. Of course the one part that CI is not so easily resolving is UI regression. And that's something that we frequently consider that should we have some UI regression tests, but those are easily quite flaky and hard to maintain and a lot of false positives there, but we're still, or at least I am still constantly thinking that maybe we could have although, some testers also sometimes, say that it's not that a good idea, but if we can make it somehow that it's reliable, then at least running it sometimes before releases or something like that would somehow make sense, even if it's not totally automated process. Marko (49:00): I think back in the day, at least, I guess Facebook's pipeline included taking a screenshot of all of the views and then zipping it and then someone just going through the screenshots every now and then, or something like that. And then at least we've built an open source library image horizon on top of the Robot Framework testing tool with which you can then compare the components, but the truth is, it's still something that would have an extra trouble to go through, for sure. And then for the JavaScript testing, the Cypress seems to be gaining traction even while it's quite a big framework for testing, but it seems to be gaining traction. So I think that also this accessibility point of view, and then that component UI changes is something that will be solved at some point, but still need some love in addition to that. Toni (49:59): That's true. And we still do have those tools that you mentioned in use already, so we use Robot Framework extensively, that's used a lot, and we also have users for Cyprus too. And especially, when there's not that much resources, it seems to be quite a good solution there. But when having dedicated testers, we use Robot Framework extensively there. But from design system point of view, I think something like a storybook and then some UI testing hooked to that could be the simplest solution to make some kind of UI regression test, just to see, for example, that button didn't suddenly have rounded corners or something like that, which of course sounds quite impossible to begin with. But sometimes they are kind of glitches they would happen and those units would be at least catch-able. Although, mostly the UI box usually occur when you use the components as they're used in the application. So in real views, interacting with each other. Marko (51:08): Perfect. If we start to wrapping up the session, there are a few questions I'd like to ask you about the future coming up. And of course, what kind of things looking back would you change and also seeing if there are some areas that you would give as advice to others. So I've already asked from the technical point of view, but if we look back now and try to wrap up the things we've done, what would you do differently if you had the information you have available now? So do you think that, that the track we've talked today is something that you would still follow or are there some areas that you would change or recommend someone else to take according to your learnings? Kari (51:55): Well, I'm quite happy about the track that we have been able to go forward. Not instantly, nothing comes to my mind that we would absolutely like to change on that way. Marko (52:06): That kind of sounds also as a relief, like if you would give someone an advice to start their design system project today, what would you then say? Toni (52:17): I think put emphasis on the community more than you think you need to put emphasis on it. So it ends up being all about people kind of in the bottom of it or that's the most important foundation that you have, so nurturing that enough is important. Maybe I want to overemphasize it here because it's something that when you get busy with it, you easily neglect it and follow up with it. And especially of course the following year has been very challenging there because we don't have those casual interactions with people at the office. So that's definitely been a challenge for us too. Kari (53:07): That's a good day advice, I would say also that your design system will live or die with the people. So if you manage to get the collaboration and community running, so your design system probably becomes also something that is very frankly welcomed. Marko (53:27): Thank you. Is there something on the other hand that you would then think that when people think of design systems, you would disagree with? Toni (53:35): That's a good question. Maybe there's sometimes too much hopes or dreams put on it, so it doesn't solve your company culture problems, for example. Or if you have a lot of legacy, it definitely will impact the design system quite heavily. And you need to put more work on it to make it work for the whole company. Let's say that you have four different technologies that you build front end upon. So it's definitely a more challenging solution than when you have only one or two, for example, like other things that you want to move to a new one. So those kinds of things we might be a bit over optimistic of those when trying to solve those problems. Marko (54:21): It sounds like something that you would bump into anyway when you are trying to do any kind of a paradigm shift in the organization. Toni (54:28): Well, in a way, that's true. It's not specific. Marko (54:32): It's good to have in mind, also for design systems. So what's next in your journey of design systems? Kari (54:41): I think business as usual, we are trying to improve things, get a bit more component coverage and think how we can help our applications more to go towards their business goals but I'm also thinking that if thinking about the technology life cycle, we have been now some years on TypeScript React and eventually they will get old, everything will get old, so do we recognize that early enough? I would say that maybe with the previous framework, we were a bit late of recognizing that change and this time I hope that we will notice it and can start to adapt in date early. Toni (55:30): Maybe to your earlier question a bit and also a bit going forward too, definitely like the DevOps stuff and also like the common good, so that we have common practices and process in place, how we do code and how we do version control and that sort of stuff. Those are in a way on our kind of roadmap too, although they don't directly come from us, it's something that enables us to design systems effectively. So if you have a good DevOps in place and a good process in version control in place, those definitely will go a long way. Marko (56:10): Thank you. As a last question, is there something else we have not discussed yet, but you would like to say? Kari (56:18): I guess we have pretty much covered about aspects of the wonderful world of design systems here. Marko (56:26): I think at least for me, I'm really happy in, if we look at the journey for today, we started from the need of component libraries and we eventually ended up into having to swim the whole pool to get the design system deployed into being an NPM package shared into the developers and the community behind building it. Honestly, I think this is a very good example for any organization on any point of their design system journey to listen and look into the things that you've done and that working as an example also. So for those who already have a design system in place, or are just starting to implement one. Toni (57:11): I think that's a good way to put it. And I would even more emphasize the fact that when you have the design system in place and you're sharing the common components and design, then leverage it even more extensively to share the good practices for testing infrastructure and coding and design. So that's something might be in the foresight and maybe kind of an under use in a way. Marko (57:41): Very well said. Thank you, Toni and Kari for the session today. It has been a real delight to discuss with you. Lauri (57:50):