Interview: Design Systems and DevOps with Marko Klemetti, Eficode

Lauri (00:08):

Hello and welcome to DevOps Sauna. My name is Lauri and I am the chief marketing officer of Eficode. In the DevOps 2020 event, Eficode's CTO, Marko Klemetti, gave a speech about improving DevOps capabilities. In this speech, Marko referred to the design system stating that design system is the voice and identity of an organization, but also a set of styles that represent the organization. He also went on saying that organizations should connect all of their DevOps practices and tools into the design system. I believe that many of our listeners have been involved with either design system or DevOps, but it's not perhaps as well-known to combine the two. I had a chance to talk more with Marko about this connection and where organizations should start with them. Let's get going. How are you?

Marko (01:11):

I'm fine. Thank you.

Lauri (01:13):

That's good. It's happens that I have three podcasts recordings in seven days and this is the first of them. Ask me in seven days, but I'm going to be really proficient in that.

Marko (01:25):

Yeah. I programmed ... I actually made an application last night, which I deployed to Kubernetes, just to front. I started it at six o'clock in the evening, at one o'clock it was already deployed and test passing. Welcome to the modern world with the business logic. Not only the DevOpsy stuff, but also the actual application was done with the UI.

Lauri (01:52):

If it was seven hours from idea to production, how many hours off those you took to optimize your text editor so that you have all the right macros?

Marko (02:06):

I don't do that anymore. I've stopped doing it. I'm actually between text editors, but I'm happy you said text editors because people today use IDEs. I actually use an IDE as well, but I call it the text editors because I've disabled basically everything. The only thing I'm keeping on is Beautify linked. Beautify formats the code, especially if you're getting random JSONs or XML or whichever, you can beautify the code pretty quickly and read it more easily that way with cursory viewing and then I have LinkedIn which is reporting all code style errors on the fly.

Lauri (02:52):

I still think fondly of EMACS with Perl mode and shortcuts for CVS check-in and check-out. That was something. Actually, it wasn't even CVS, I think it was RCS.

Marko (03:11):

Yeah. It must have been that predecessor of it.

Lauri (03:15):

Yeah.

Marko (03:16):

The one that actually does look the files and only have per file version control has completely changed from there.

Lauri (03:27):

Yeah. This is more than 20 years ago. I still have it in my muscle memory. When you have the Emacs open and you press a key stroke and it will automatically format your Pearl, basically your indentation based on the predefined rules. It's a muscle memory. Today, we are talking about something else. We're talking about design and DevOps. Well, you could say that back in time, I was developing software. There was no design because it was all command-line and input was coming from standard input and output was going to standard output, and there was just the software in the middle.

Lauri (04:09):

Now, the world is different, and I have tried to unpack this connection between design and DevOps. To me, the closest I've ever come to that, myself, trying to figure it out for myself is doing Android software development, where you have the material design, which is integrated into the Android studio, so you're doing the software design at the same time and then going back to the code base and then emulating ... running the emulator and trying it out. I understand it's like a single person understanding and very limited definition of it. Why don't we start by just unpacking this connection between design and DevOps for everybody?

Marko (04:53):

Yeah. I think it's best to actually start from saying that there are many different variations of design, and when you talk about Design, you cannot always be exactly sure what you mean. There's service design, which obviously focuses on what kind of services should be created and why, and mostly on the why part defining what we are actually doing and to whom. Then we have the graphical design, which I think more commonly in our industry would be called UX Design. User experience design, which includes what comes from the service design and also parts of how it's supposed to be implemented, and then the beef is in the middle. How should the service look like? How does it behave and what are the graphical instruments you have a connection with the user with?

Marko (05:55):

Then of course, DevOps my favorite subject goes beyond from traditionally, from the first line of code to a change released into production environment adding value to users or whoever the service eventually is for. I would, in this discussion already expand the concept of DevOps. Starting from the first moment, someone comes up with an idea or a change request to the point where it's actually creating value for someone the whole pipeline, including all various designs, the development phase, the release and then of course, maintenance and the production environment, whatever it is.

Lauri (06:49):

Let me ask one deeper level question there. It sounds to me that, we can define the design and we can define the DevOps independently, but where's the connection there? I'll ask it again, how do they tie up?

Marko (07:07):

Yeah. Especially when you go to UX Design, which means doing the actual graphical design work for an application or a service, you eventually have to transform that into digital format, which means basically developing that application. The connection comes from the moment you start developing the application. Modern days, when you have the various design applications like Sketch or InVision or Figma or similar, they already do some of the pre-development work for the designers and for the developers. The connection starts when you start actually implementing that design. Usually, these days they go hand in hand, which means that DevOps actually starts already from the design phase.

Lauri (08:07):

Cool. Well, UI Design has always existed, well, apart from the standard output where you're basically passing parameters. UI Designed this not new and translating UI Design into a code is not new. What has resulted in this Design Systems and Design becoming so popular today?

Marko (08:26):

Yeah. I would say that design system has been a hot word for a while already. It does define ... Design System has also various definitions, but one of the best definitions, in my opinion, is that it's a uniform voice, identity and styles of an organization or company, which means that it's defining how the organization is expressing itself in digital graphical format, basically. During these days as the application development is going browser-based or it's going native into mobile applications, it's more and more important to have a harmonious library of styles and components to be used in an organization when new services are created, or the organization is changing styles, or changes are made to various areas of an application. Design systems have been born from the need of having uniform styles within the organization and the application.

Marko (09:41):

I'll give an example, such as forms, buttons, navigations, deeper graphic and things like that. They all go well into a design system that's then scalable and can be replicated within the organization and also in the application design.

Lauri (10:01):

Yeah. Basically, design system is a way for organization to harmonize the expression of themselves in software, largely speaking?

Marko (10:12):

Yeah. Top level would be that. The more earthly definition of course, would be that it's a library of components that are reusable. I said forms or buttons or navigation that you can reuse over and over again, and then if you have changes say, for example, you change your logo or change your colors, the organization change its way of expressing itself, I said, uniform voice, for example, changes, it might have changes in the design. Then design system is a natural place to reflect that change in all of the applications or all of the services the organization has.

Lauri (10:58):

If I tried to apply my knowledge from marketing and from the broader digital transformation, the reason why it has suddenly become so popular is because software is so critical in the interchange between the service provider and the service consumer, then the only way to make sure that the organization expresses themselves properly is by way of design systems.

Marko (11:25):

I would say that reusability is one. You create your styles and then you can reuse and have some definition of them organization-wide. The bigger the organization, the more important it is. The second part is of course, the component. Here we are getting into the more development side. Design system of course includes not only the design, but also the code behind the design and the component. If you have a button, you would have, for example, HTML and CSS code pre-made for the developers to represent that component, which could be, say a button, so the colors of the button, the behavior of the button on hover or pressing the button. Design system includes that.

Marko (12:20):

One of my favorite open design systems is the Australian Government Design System, which you can go ahead and check out at designsystem.gov.au. It includes the design, the HTML and CSS examples, and also, which is modern for today the React components. React is a JavaScript user interface framework that's currently the most popular, originally developed by Facebook.

Lauri (12:56):

Interestingly, you could argue that if an organization publishes good design system, they also put a foot down as to the technology preferences, they would like to see in their organization, and they lower the barrier of adoption of a certain technology because of what they are doing with design systems. Is that farfetched or is it...?

Marko (13:20):

No, that's actually inevitable. What has happened formerly ... before the emergence of design systems, what happened was that you have graphical guidelines, which is one of the basis for design systems. Then the teams or the application development organizations were responsible for developing the components corresponding to that graphical guidelines, which means that all of the different departments or application teams or organizations had to do the same work over and over again, to create their library of components representing the graphical guidelines of the organization.

Marko (14:07):

Now, that we have centralized library, which we here call design system, it suddenly turns into reusability and also harmonizing the way the applications are made. Now, if you have ... that's why I pointed out React, for example. Usually that the design systems that are openly available have already React components in them because of the popularity, which also means that it's cheaper, easier, and more scalable for organizations to start developing their applications with the design that they want to use in such popular areas such as React.

Marko (14:56):

Then if you have legacy applications or legacy technologies in use, you have to have the so-called bootstrapping phase where you implement the design system and the components for that particular area. Yes. It harmonizes, but also it doesn't restrict the use of design. You just have to ... it's more probable that you have to do it yourself.

Lauri (15:26):

Fascinating. Now, you gave an example from Australia Government. My next question would have been, is this a dream or is this reality? At least, there are examples of good design systems that deliver on the idea, but let me ask you the other way. How should these design systems then ... are they delivering on this connection between design system and DevOps and how they should be improved to better fit with DevOps?

Marko (16:02):

Before going there, I'd want to say that there are roughly two different types of design systems. The other ones are open source community driven, available for everybody design systems, such as UI Kit or Material UI or Semantic UI. There's a number of different design systems that are following the same rules as any organization's own design system and have the expandability to be actually moved from the community to an organization use. This is today very popular to follow a generally available design system and transforming for the organization's use.

Marko (16:53):

Then there are those that have been developed for the organization or by the organization. For example, in Finland, one of teleoperators, Elisa, they have their own style guide and style book, which is following the design system rules, and many of the other big organizations are following the same suits by creating their own design systems, which are then proprietary. Now, the fun part starts from there. Now, you have a design system. You have your design components, you have the reusability of the components, and what it the enables. It enables you to kick start new innovations faster so you don't have to start by creating the design component. When you skip over that part, you already know that, we're doing an application for our organization. It has to look like this, but you already have the library ready. It's really quick to start a new innovation or a product development and get into production.

Marko (17:55):

The other benefit of course, is that if your design changes, the design system would be the centralized place to actually do the changes and reflect it through the organization quickly, and way more quickly than when you had your teams creating their own design representations. This is what's beneficial for design systems today. If we'll look at what's happening in the DevOps scene, the actual development work starts from when you have your design system and you start developing the application logic behind the design. You have the bits and pieces in place, how the UI should look like, but you still have to add in the logic.

Marko (18:53):

Now, if we look at the DevOps scene, there are lots of things involved in developing the logic, such as, for example, unit testing. Testing that the logic works, you would have M to M testing or acceptance testing, checking that the user interface actually does the logic that's expected, then you would have some other quality measurements like static code analysis or similar. You have your continuous delivery or deployments. The pipeline that actually releases your application, and then of course you have the release both into what we would here call the staging or testing environment, and then eventually into production environment, so the basic DevOps stuff.

Marko (19:44):

Since the design systems are driven, usually by the design people or the UI developer people, the people who love working with user interfaces and implementing them as code. The DevOps side has traditionally been developed by the people who love automating, who love seeing the applications released into production environment, who love making sure that the production environment is running smoothly and scaling on demand and all that modern DevOps vocabulary. There has been a gap in between. I believe that design system is definitely one of the ways of narrowing down the gap between the design phase and the actual release.

Lauri (20:32):

Okay. This is a digression, but let me put it out there. If design system includes those active components, like what you said there, they actually have the buttons and lists and many UI elements, but they would also have some of the stuff that is more relevant to the developer part ... the development part like test cases. Does that then also mean ... I'm probably phrasing this wrong, but, does that mean that designers have to get more involved in the actual software part? I think it's a different skill and different trait being a designer than being somebody who is then more interested in creating a code that does what the software is supposed to do.

Marko (21:29):

I'm going to answer you yes and no. Why I'm going to say yes, is that, in my opinion, with the emergence of the cloud technologies and harmonizing the pipelines into cloud environments and understanding how the applications are released and how easy it has become, it's more accessible for designers to understand what's actually happening after the design phase, when the application is written into a code or implemented then verified and eventually of course, released. I'll call it continuous delivery pipeline here, but it's accessible for the designer to understand how it functions.

Marko (22:16):

An extension to that is also being involved in a component library to your design system that would contain the parts from the DevOps, continuous delivery pipeline, such as the test templates or the infrastructure or the pipeline templates then helps the application development to connect that the design system and design and the development directly into the actual release or continuous delivery pipeline by using what's already included in the design system. The other side is of course, no. The designers don't necessarily have to know about this, and it depends. It's a personal question if the designers actually want to work on such things. This means that the design system and the design side work for the whole organization is turning into more extended work than just design.

Marko (23:27):

It's involving people from development. It's involving people from the operations or DevOps side, which also means that it includes collaboration, it includes a new side of the culture of development, and it brings the people closer by working on the same goal, which would be the design system. Even if they weren't working on just the design or the code, but it's actually harmonizing the whole pipeline into design system and of course, it will mean that more skills than just design or the UI development is needed.

Lauri (24:08):

Right. In the interest of wrapping up quite a bit of what have been said before, let me try to ask a very succinct question, which is, considering all this, how does a well implemented working design system look like when it seamlessly integrated in DevOps practices and tools? That's the first question. Maybe the second question would then be, how should the organization support this, not only from a tools perspective, but also from a culture and other organizational perspectives?

Marko (24:49):

I've written an example application for using the design system it can be found from the GitHub under ethical design system example. That's one of the representations what would well implemented be. It means that, in addition to having the design system in place and the components written in HTML, CSS React components, you also have the unit tests such as the UI component unit tests. In this case, the technical term, or the tool used is called Jest. Then it has some examples on how the backend, which means the core code part of such application would be written, which means that when you create a user interface, you have logic behind there.

Marko (25:49):

When you have your design system, there is no reason to not have some examples on how that user interface is connected to the actual backend or the core of the application. Then well implemented would also include the acceptance tests, which in this case, we are part of the Robot Framework Foundation, which means that the acceptance tests should be written in natural language, and there's no reason not to have that as part of the design system as well. Then of course, last but not least, the connection to the infrastructure, meaning, say cloud environment or on demand, whichever you are using, but connection to infrastructure on when you're ready, how do you get that ready, delivered into the environment you're running it in.

Marko (26:47):

Then of course the last connection in well implemented design system would be the delivery pipeline, which means how do you connect your application into the whole automation framework? Here, we call it continuous delivery, so continuous delivery pipeline. As you start working on an application in well implemented design system, you would have it in production environment the same moment you start working on it. This is something I love calling zero day delivery. I actually tried that out last night myself, and it works in such a way that when you start an application, you take a template which is based on the design system and when you make your first comment, it's already connected to your continuous delivery and delivered into production environment.

Marko (27:40):

In this case, GitHub Actions, Kubernetes, which then is completely automated and comes from the original work of the design and then design systems, and just extended to include everything that follows from there.

Lauri (27:57):

It sounds like many things that have traditionally been considered like moments of truths or those moments where you hit the button and cross your fingers, those are the ones that become anti-climatic.

Marko (28:13):

Yeah. That's why I always separate the words delivery and release from each other. Delivery should be the uninteresting part. If you do continuous deployment, you usually deploy unfinished code into production. The code is just working, but it's unfinished. You either hide the functionality from your users, or then just keep it there in the background and nobody knows this is. Release is you actually release that feature for your users. The uninteresting part becomes here for the delivery, which means that you're actually delivering the feature being implemented all the time. You get the feeling of security that what I'm currently creating is still working in production environment, our users are working just fine, making small increments. If you fail, there is a very short way back by roll backing and then the actual release is then done by a decision.

Marko (29:22):

Of course, you might have that particular feature in production for ages before you decide to release it or you wait for a certain moment for the correct release. That's a moment of turning a switch instead of including it into this mayhem of trying to get the features into production and crossing our fingers that they actually work. When doing releases in modern world, you already know that they work, so you failed way before the actual release.

Lauri (29:53):

Yeah. I remember an old expression that software solutions doesn't solve anything until people embrace them. I like to use that as a bridge then to the organizational part, which is, now that, let's say the manufacturing line, in one sense, has been described, then what does it take from an organization to support this connection or this ... the connection between design systems and DevOps?

Marko (30:25):

It is obviously changes the culture. In my opinion, into the modern direction, into the better, more fluently working organization because, I wouldn't say forcing, but not forcing by the organization's point of view. It makes people have to collaborate in order to make something like this happen. It means that you have to have expertise from various areas within the organization and of course, within the various expertise areas of design and develop and DevOps knowledge and cloud knowledge and operations knowledge, in order to succeed in something like this.

Marko (31:12):

What it does, it enables collaboration, but it also forces you to do collaboration around something like this. What it then of course, enables is that you have two things happening. The first one is you have a common library of components that connect the organizational parts together, and also you have a centralized place to go to when you have requirements or something.

Lauri (31:47):

Yeah. You talk about the test cases before and including natural language test cases in the design system itself. It almost sounds obvious to me as well that that culture will then feed into the automation, which is one definition of DevOps in coms, where you have the culture or where you have the automation. You describe that designers, they are not required to learn a developer skill, but they have an opportunity and possibility to engage with the reflection and learning. That also speaks to me as a cultural change, where you create a feedback loop between the people who originate the design system and then they also review how that design system is adopted and then they take the lessons learned from there.

Lauri (32:52):

Maybe it happens that some of the developers have identified, let's say a gap or a missing piece in the design system and they have implemented themselves, but it is good enough for the maintainer of the design system to then adopt it back into the design system. The next round, it's already there. I don't know. I'm just making up stuff here for-

Marko (33:17):

No. That's actually the two important things, so what I would call scaling by distribution. The team started working on a single system instead of all of the teams working on their own, which of course, makes the work centralized, makes it scalable and also gets the people working together as culture wise. It also forces the organization to come up with practices on how do you actually develop and implement and share the design system and components inside it. How do you collaborate? Do you have a centralized team that's actually responsible for the design system? Do you have your own continuous delivery pipeline for the design system where you can collaborate by pull requests from any of the teams?

Marko (34:11):

Do you decide to make it community driven, such as the Australian Government design system where anyone could go ahead and make a pull request, and then they just have a centralized few people who then decide if these pull requests should be approved and merged into the design system, or how do you manage it? It changes the way you have to decide over all of the applications, how you manage both the DevOps side and the design side, but still not touching into the creativity of the people, but just building the framework.

Lauri (34:52):

I have to ask this. In many organizations who want to adopt lean and agile and DevOps principles, there is a concept called practice community. Let me ask it. Have you come across, or how possible is it that an organization who gets on a journey with design systems would establish a design system practice community within their own organization? That would be the driving force in the organization to then ... well, to start with, define what it is, and then also, aggregate those practices, because I believe that it's not only just sit down and out of a sudden a perfect system comes around, but you have to take the time to also create that system for yourself.

Marko (35:41):

Yeah. One of the ways of developing the design system would definitely be starting a practice community. If your organization already has practice communities in place and the practice communities have certain responsibilities, a practice community would be a natural place to discuss and decide and develop further a design system. What in my opinion, the practice communities have done as a downside of course, is that the organization driven targets and schedules are more difficult to set, which would then probably lead into working groups started from the practice community that actually as the working group has some a schedule and targets that the practice community goes through the discussion decisions on what should be done, and then start to work in group that actually implements it. That would be one way of doing it. Many organizations work this way.

Marko (36:49):

The other way would be having that working group as, especially in the beginning, what I would call as a piloting group, or then what many would understand a center of excellence. Obsolete word in the modern world, but center of excellence is still a valid way of looking into how design systems should be handled, especially in organizations that want to implement new practices, how it could be driven in the beginning. When the first implementation has been done and piloted, it might be reasonable to expire the center of excellence and then turn it into a practice community, for example.

Lauri (37:42):

The center of excellence is almost like a nomination or a role nomination for somebody who is tasked as the primary job to figure it out whereas the practice community is like-minded individuals who find a cause amongst each other to go do that. There are probably many other ways to figure the organization part out as to introducing the design system. If we look at this connection between design systems and DevOps, then from a substance perspective, where should the organization start?

Marko (38:21):

I would presume that any listener that's in an organization that's more than say 500 people, there is already a design system somewhere. If isn't, I'm really surprised. Even if it was just graphical guidelines, that already exists. Exactly the same way as we would do our DevOps assessments on Eficode, the same way the organization should be first starting by mapping out what they already have and making some road map and set off KPIs, how they want to proceed from what they have. Many organizations, I said, already have design systems in place. They even probably have the HTML and CSS libraries connected to the design system in place. They also probably have applications that have been developed over that design system already, so you don't have to start from scratch.

Marko (39:25):

Many organizations today already use Cloud. They have some continuous integration or continuous delivery pipeline in place. The areas are very new in the organizations that want to start developing their design systems further. What they just have to do is define what they're after and how do they want to proceed with implementing it. Should it be some new product they start developing or should they start a new venture on developing the design system because their brand is changing? Or, as they have moved to any of the cloud providers, should they add in the infrastructure definition somehow into the design system or even near the design system accessible for the people who start developing the applications, so that even if you didn't have the whole package in place already, you start bringing the components and the people and the culture closer together.

Lauri (40:28):

Well, that sounds easy. Doesn't it?

Marko (40:32):

Well, I would say that it's relatively easy, but it doesn't happen overnight. The same happens with any DevOps implementation or any new practice implementation in modern organizations. I hate to say this, but they are not rocket science, but it takes time. Usually, where we bump into is that things are considered difficult and happening way faster than they actually do, and they're both wrong. Usually, things are relatively simple to implement. The hard part is changing the culture and the practices, of course, but that's a whole other story, and they take more time than you expect.

Marko (41:24):

That's why we prefer piloting. Meaning if you have a new application on the way, I would start developing the design system around that application and selecting technologies that are most probable to be the application technologies in the upcoming applications or services. By that way, you already cover the future services in the design system. Then while you develop the legacy or the obsolete applications, you might have or services, you start extending the design system there.

Lauri (42:03):

I have one more question that I will test with you, but it is also a digression. Before that, is there something else you think should be said about this subject we haven't discussed?

Marko (42:17):

Yes. There is one very important thing. We've already talked how you scale up and how you're able to scale by distribution, how you're changing your culture, how you're getting people working together with the centralized design system, and how it's helping your organizations. One thing I want to add is that now, as ... we started from design systems being driven by the designers and the UI development, which is traditionally, just goes like that. The traditional organizations usually are divided so that it's a natural place to start from and then you have to involve the developers and the DevOps people or operations people into the work, if you want to start creating a so-called extended design system.

Marko (43:07):

One thing I want to mention is that once you get there, once you have the continuous delivery pipeline in place ... you're talking about the so-called zero day delivery, which means that when you start a new service based on the design system, you're basically in the production at the same moment, at least the same day, you've created a pipeline that's all automated. Many of the culture elements such as the practices used by the development organizations are actually connected to that pipeline, which means that if you want to add or change a technical practice, you have in place in your organizations.

Marko (43:56):

Few good examples would be using pull requests or reviewing pull requests, using security audits, adding new LinkedIn or style checks into the code style you're actually writing. They're all automated boring tasks for the computer. Those can be added into the practices by introducing them into the design system and the pipeline, the continuous delivery pipeline lying within the design system. Which means that when you take the design system, you don't only take the components and the automation and the templates, you're actually picking a part of cultural practices with you, and it supports your future culture at the same time. That I feel is one of the strongest powers of doing this kind of modern design systems.

Lauri (44:58):

Interesting how that, even if you didn't know that it answers or gives an answer to my question, the bonus question that I had in mind, because I wanted to stretch what goes in the design system with one more thing. Again, forgive me with my ignorance on the technical details, but speaking of Cloud, which is one more buzzword out there, and speaking of infrastructure as code, which oftentimes goes together with Cloud, it would be curious to know your thoughts as to including infrastructure as code definitions into the design system so that, when somebody gets started with a new project and they would adopt an organizational design system, it would already ... in the same way it dictates design elements, it would already dictate ... dictate is the wrong word, but make a strong recommendation towards a operations part of that project.

Marko (46:03):

Not only would, but should. I said, it's an integral part. When you talk about roughly divided into design, continuous delivery, and then the infrastructure as code, as in the operation side, they all should be integral parts of the design system. You won't be able to do the zero day delivery or continuous deployment unless you have the infrastructure defined as part of the design system. The application I did last night and deployed to Kubernetes, it also included, not only all the volume mounts and the definitions of different services, it also included the DNS level stuff such as HTTPS certificates and the domain definitions, which means that you suddenly have your service already in the internet domain, well, modern applications often are with the scalable infrastructure in place as defined by the people in the organizations who know that part best, which would be say, Cloud architect, for example.

Marko (47:20):

There is no need to have the developers or the designers thinking through how they are going to release these applications, but instead, they only already have the templates from design system and they know the persons who they can ask for more information. It all comes from the first step of starting to do an application.

Lauri (47:42):

Wow. Well, it's very clear for me now that when you say that the moment you start developing you are in production. I can't paraphrase it to you word by word, but-

Marko (48:00):

Yeah. In the future, I feel that when you ... the optimal situation, of course, is that someday the design applications such as the Sketch or Figma, whatever, when you create your first button, you already see it in the production environment replicated there. Actually, it only does need a configuration file defining what you need and press play. That would be the way design system should be used.

Lauri (48:27):

Yeah. You press the button, and you're in production. Well, thank you for this conversation. It was a fabulous, intriguing. It brought us from long time ago from Emacs and Per Mode and RCS, all the way into Today. I think we have made a good 25 years of evolution in this conversation. Thank you for that. I'm looking forward to talking to you to the next time.

Marko (48:52):

Thank you.

Lauri (48:55):

That was fascinating. Thinking that designers have a way to get closer to development and developers having a way to deploy their code from the very first comment, all according to the organization's brand and design guidelines. How awesome is that? In order to help you get started we have collected all references in the show notes. Make sure to take a good look at them. As always, we are happy to hear back from you for further ideas about future episodes in the podcast. In the meanwhile, take care of yourself and keep zero day delivery.