Paul: Hi, there and welcome to PodRocket. I'm your host Paul, and today we're joined with Daniel Ley and Jonas Ulrich. Daniel is the co-founder of kickstartDS, along with Jonas. We're going to be talking about design systems today, we're going to be talking about front-end development and what you folks have to bring to the table when it comes to what the web looks like. Welcome to the podcast. Jonas: Hi. Daniel: Hi, Paul and thanks for having us. Paul: Yeah, thank you for coming on. Because, like you folks noted before, we're kind of in a design system kick right now. Pun not intended. We're going to start talk about kickstartDS. It's a low code solution, right? So what does that mean? What's a 30 second elevator pitch for people tuning in, they just want to know really quick what it is? Jonas: Yeah, I mean I can try. It's a starter kit that enables digital teams to build their own design system in a really efficient way. And the low code pretty much means that you have some integrations that you can use off the bat, that are just ready to use. Like integration into Gatsby, for example, to have a working website team also running. Paul: If we have a Gatsby integration, does that really just mean you're going to install the core? You're going to install the integration, it's going to link up and you can maybe get up and running? Jonas: Use your page elements inside your CMS, for example. So complete the picture, one other puzzle piece would be a generated config for example. For Sanity, for your Headless CMS. And you have a full website stack, in addition to your design system that exactly fits your components, the structure you found for yourself. That's the low code part in the whole thing. Paul: One of the things you have on your website, if you visit. It's a very colorful website, people want to see a fun website, kickstartDS.com or... Hold on. Let's make sure. Jonas: That's right. Paul: Thank you, kickstartDS.com. One of the phrases you have is, "It's as easy as squeezing a lemon." Who came up with that one? Daniel: I think this was mostly me who came up with that catchy term because, I'm not a front end dev, but I'm more caring about the product management and UX part of the piece. And what I could see, that also with my history in other companies setting up a design system, implementing a design system, was quite a pain. And often, code sided, was really, really harsh. And when I met Jonas and when we dipped into kickstartDS, I really thought, that is super easy for front end dev. And when we did our user research, talked to devs, they also were pretty excited about how easy this. And that's basically where I did end up with that "Easy like squeezing a lemon." Paul: We know this is true, because like you said, you're not a huge front end person. And one thing I find as a content creator, is when I go onto podcasts and I know less about a subject matter expert. You can therefore create a better system that's much more... or better piece of content that's approachable for people. So if you say it's "easy like squeezing a lemon" not being a front end person that gives me, also as a back end guy, a lot of confidence. That indeed I'm not going to be wading through the JavaScript jungle just to get my components working. Let's talk about the components a little bit. How many components do you have in the framework right now? Jonas: I think we have one right on the start page. Let me see, it's 30, 33. It's written there. But it depends on how you count, to be honest. There are some heavyweight components that really pull their weight, that do a lot of stuff. And there's the tag label, which is not that interesting if you look at it closer. I'd say it's more like 5 to 10 core components, that do like 80% of the stuff. And then lots of stuff that's next to it. Like a post or a block post or stuff like that. So about 10 to 15 really of most of the time used components. Paul: When we're talking about low code, we're talking about 10 components. That sounds like it matches up right there. Is it allowing people to really quickly scaffold their pages with these 10 components? Jonas: Yeah, but that would be exactly the part that's not no code. And what distinguishes it from no code, because you have to have a front end dev go in there and create the components based off of our building blocks. The expectation would still be for someone to create his own design system, with his own naming for components, his own component uses. Because otherwise, it wouldn't really be his design system. It would just be a theme-ing of our solution, which is not our intention. You really go into that and map it. But that is really easy, because we have lot of tooling and scaffolding stuff for you to make that easy. But if you've done, that then you can connect it, for example, to your CMS, to your Gatsby Theme and stuff like that. So that's where the low code part really kicks in. You still set up your own design system. And we think that should be the way it is. You shouldn't just skin something, because a design system really should be expression of your use of information display on the web. How you utilize your brand and that should all be pretty custom. We don't pretend to be a product that you just buy off the shelf in a package, and click install and you have your design system. You still have to think about what you want to do. We can't do that for you, and we don't want to do that. Paul: Do you think that maybe we could go into a quick two or three minute example about, what is an example of skinning a piece of your project. And, going the full nine yards and creating a design system around that maybe piece of functionality would look like? Jonas: Yeah, I think we can do that term. One example I just... For example wrote up for our documentation, because we are pretty busy writing documentation right now for our upcoming release. Its writing a small guide on exactly that kind of layering of components, where you just think about what you want to build. So when that example, it was an interstitial component. Something you can insert between default content to have something really obvious, really eye catching. And that was just thinking about the structure. For example, there it was having a topic, having a text and having a link that you can include. Those were the three options that you would need for that component. And then, the next step is to look at the set that we already have, and to see if any component matches that behavior that you want to have. And then you just go into that, you create your schema files. Also we use a lot JSON and schema for the base definition for your components or you just one time write it down, what's the structure, what types of fields are those that you have in there. And then you can just create your React template importing the component from our base component set and just wiring it up. And you have stuff like automatic typing or yourself and so it gets really easy to do that hookup part of the process. But you're really getting the components from the design system in the bag. And that's the way where you say "re-skinning" because what you would use for that would be our... I think we took the storytelling element, which is a really big component which has 40 options I think, which we would never advise someone to use in his own component. You should reuse that to the set that you need for your use case and that's what we chose here. So you have 40 options but only three are user choosable in this design system. The rest is hard coded, the decision is taken when integrating the component by the front end dev. And we think that's the good way of layering this kind of decision process where still being a productivity boost because you don't have to actually code the button. You have it in the back, but it's not your ready made button. That's the distinction I want to make. So you still have to apply it to your use case. Paul: I really like that definition. You have to apply it to your use case. You're redefining the API to be a specific phenotype of functionality. Jonas: And we think that's super integral to creating your design system. And if you buy into a solution that says it's a design system but there's no domain mapping as part of creating your design system, then it can't really be a design system. You are just taking something off the shelf and using it as is. And we have a bit higher standard for what we would call a design system. So that would be pretty much part of every design system for us at least. Paul: I think it kind of brings my brain back to the library versus framework distinction you're using versus working with something. Jonas: Yeah it's more a framework and next to the code, which is one super important part we think is a lot of best practice and structure that we bring into it too. So how you can structure things so you don't have to think about how your build pipeline could work and how your releases could work. So you have semantic releases in your design system that just makes sense. So all that stuff comes with it, which makes it really easy for teams that don't have that kind of knowledge because it's pretty special knowledge you have to say nowadays to know all that stuff about those big pipelines, about the processes, everything that's going on with packaging. It's super hard for your regular team to do it on the site because that's often what's expected of them and that's where we really see a solution like ours being integral to really doing quality work going forward. Paul: That instills a huge confidence in me because like I said, I'm a backend guy so when I want to go do front end stuff, seeing how it's done at these high performing groups and companies and you're like wow, I want to do that for my group with two or three just so we have it organized. But oh god, if you're not in that space it's very challenging. So what's an example of a best practice or some bowling alley guardrails that you put up for folks like me who might be coming in and wanting to make a good design system? Jonas: Yeah, I'd say the first thing would be aforementioned JSON schema part. So really more or less forcing you to think about your structure because it's not optional, you have to write on that structure. It's the starting point for everything else. But another thing would be having a token structure that's already set up for you. So we have a pretty sophisticated design token structure that's using style dictionary in the background that's already connected up for you. So it's ready to spill all those tokens into your React components that then use them for their component tokens. You can use those component tokens to quickly change the way things look and fear by just changing the tokens around. We've really taken to having a complex layering there. Complex not meaning you have to interact with it but you can. So by default you would maybe just define 10 main branding tokens and those would be generate your design token set, which has a lot more semantic tokens for example that are already there. Stuff like what should my primary text be looking like on backgrounds for example, on a dark background or on light background. Stuff like that is already set up for you and hooked into your components. And then you can go into there and just change it up yourself by changing the alias structure of your tokens. For example, telling the button that's inside another element to maybe have another text color and choosing from another semantic color or maybe you're building a new component that's completely for you, it's completely custom but you still have all that design talk and structure in the background. So if you have some text and it's an interface element, you already know that you can choose the front end text color token. It's ready made for you in a semantic structure. So having those kinds of structures set up for you from the start I think is something that really helps with that, which has those guard rails. So you won't have some problems. Maybe one other example, we've really struggled a long time with having invert ability as a concept in our components and it's not the same as dark mode, which sometimes gets confused. It's that you can invert something and everything that's on that inverted part correctly inverts with it. Paul: This is like negative, right? You think of it like- Jonas: And it needs to be scalable so you can set something as negative in a negative and should be positive again. Paul: Right? Okay. Jonas: It's layerable, so that's a concept we've integrated pretty deeply into our token structure so you can just easily change. For example, every section just invert a true or false makes everything change according to your design token structure in a really well behaved way. Paul: That sounds super. I used one big honk and framework that we all know which is Material UI and I just want to focus on this one aspect of it that was really nice, which is the themeing and skinning piece. Because when I had never touch front end before you come in there and they're like, oh you're going to make two levels, it's going to be your primary, secondary. It's a well known thing that people do, but if you come into the framework they really walk you through that. They're objectifying these different layers of interoperability within your design stuff. And that's what the token sounds like it's doing here. You're saying we're going to make this object, this idea called a token. Can I think of them like tags almost like for the components or why did you name it a token versus a tag? Cause my mind goes to a tag. So maybe... Jonas: I mean it's pretty much coming from the design side of things I'd say, maybe Daniel can tell something about design tokens. I wonder where that's coming from because calling it a component token for me at least is the extension of calling other things design tokens or branding tokens and stuff like that. So it comes from that side, I'd say. Daniel: Yeah, I would also say I do not know the real history of that term, but I saw it popping up in the design space more and more often in the last few years and it's rather really the smallest building block of something. So it's a color hex code or maybe the radius of a corner. So it's really, really one simple design decision overall because when we're talking about tokens, we are also talking about a decision which was done once between maybe the design team and the marketing team and the branding team and even the devs and in regards to the visibility. So that are the decisions being taken and then somehow being defined in the token. So... Jonas: Yeah, I mean the component token, as I've said, just the extension of that because even in your tokens itself, you have layering. In our case for example, you have base scales, something like your primary color, your primary color, 90% opacity, 80% opacity. So you have a scale. So those scales are your base values and you use those in your semantic tokens. So you have something like your text color foreground and you say text color foreground is just an alias format, color scale, 80%. So you even have there, you have layering inside just your design tokens themselves, but this gets converted to component tokens and then layered inside of them again. So it's just the extension. Paul: So you don't have to use all those layers, but you're providing the in so to speak, if you want to make that distinction within your organization. It sounds like you guys really put a lot of effort into how the teams are going to interact to create the product. Jonas: And I think that's pretty much back to... Based on our background because we've been an agency for 15 years before doing this. Building exactly those kinds of websites for clients. And we've always had a pretty big focus on front end for as long as I can think and have always developed up front end in isolation from our backend integration and then painstaking the integrated it into the backend systems by copying Handlebars templates into PHP, stuff like that. But we've always written up front and as its own thing and we've pretty early on identified that we don't need to rewrite everything every time. So we've had a library set up pretty early on that we've developed. I mean at least five to seven years before then, making the decision one and a half years ago to really double down on that front end part because we were honestly a bit fed up with the agency world too. We wanted to work on a nice product that we're really passionate about and that was always our main passion. So we just took what we had as library for us solving that problem for us, for ourselves and really thought hard for the last one and a half years. So that could apply to others and what we have to change in what we already had to make it more approachable for others. Because it was pretty much solving our problem. And you could see it in the code too and in the applicable use cases. We had to invest that time in, to learn how do people want to use something like this, what's important to them. Paul: So Jonas and Daniel, did you start this design agency together 15 years ago? Jonas: No, but we know each other almost that long. Paul: You know each other, okay. And now you're working on kickstartDS. So when the design agency, you noted it kind of gave birth to this beginning library that solved your problems. What was one of the things that made you pull your hair out? I'm talking about problem zero, the one that just made you stay up those one or two nights and you're like, I'm just going to pump the solution out because it's just such a pain point on the team in the way we're communicating. In respect to the design solution. Jonas: I don't think there was that moment. I think we were that curious and passionate about that topic itself that we just did it pretty early on it. I'm not sure it was actually solving a problem when we did it. Paul: Okay, you just had the foresight and you were like, "This is going to be necessary" and it's going to... Jonas: I still remember and I said it and we had a small talk as an intro before this and I mentioned the Brad Frost podcast you just published and he's a huge inspiration for what we are doing. And just seeing the way that he introduced architecture and structure to the front end world, at least in my view, was a huge inspiration for us to think about those problems when building our own stuff. Paul: Would you say the ideal customer right now is another design firm for somebody checking out kickstartDS, or who should go check it out? Daniel: That's something we're still exploring about. But we do target, medium to larger enterprises at first. We guess that companies with more than a hundred employees do have a couple of digital touch points. And that makes them or provides them maybe the need for a design system. At least that's what we believe and what we're convinced of. And so we do focus firsthand digital teams inside a company and then on another customer segment could be an agency doing that stuff for other companies as well. But the design system part in our opinion is strongly related to an inside work in a company. So as Jonas already said, there's lots of terms or vocabulary the company has in regards to their front ends and UIs and that's where design system should relate to. And we guess it's just like an agency can consult and build it together with a company, but it's not something an agency can build and hand over because a design system needs to be vibrant inside that company Jonas: And I mean we always joke that as a design system is 50% technical, 50% processes. So about stakeholder management, who is involved, who's making decisions, you won't have a great... I mean maybe you think it's a great design system, but it won't be great if it's not used inside your company. And that's pretty much a political thing in most of these companies. How this decision is made, who does take that decision in the end. And you really have to manage that to ensure that the design system can be a success. And that's also part of the best practice thing we've been talking about. We really try to get that knowledge into our documentation, into our block entries to help people on that front. Because for someone to use kickstartDS in a successful way, he has to do it like that. And we believe that that's way easier in your own organization than as an agency that's more looking for a copy paste blueprint that can be more or less reapplied in their interest without many changes. And that's not really matching, not a hundred percent on that part. Paul: So if I wanted to play with this myself, do you have a open source solution available? Jonas: I mean that's what I've a bit hinted at before with that release and all the documentation stuff because right now it's all closed. So as I've said, we've been using it for roughly one and a half years now testing it in pilot projects ourselves, testing it with first select partners that really know how we work, where we know how they work to slowly get to know how kickstartDS actually works in production, so to say. So that's what we've been doing the last one and a half years and now we're ramping up to our first big release that includes open sourcing. Much of that, what I've called best practice and the core architecture of it. There will still be stuff that's not completely free. Mainly a content module of components that we've written for really marketing landing page heavy contexts that will be a small subscription based model where you can buy access to the module so it won't cost you an arm or a leg. But it will be a really small fee that you can pay to have some more components that do some cool stuff for you that you won't have to build yourself. But the main part, like the button, the section, stuff like that will all be the open source part, including the documentation. Even how you would build our commercial components. So you could just go into there and build them yourselves and if that's the better proposition to you then fair game. Paul: Yeah, right. I mean it's all about supporting the bilateral support between your team and the teams using your stuff. Jonas: And that's the balance we're thinking about here. And we have some thoughts about the integration layer because there's lots of potential on that front too. To enable automatic integration for CMS solutions, stuff like that. But that's a bit further in the future. Paul: Yeah, I was about to ask what's one of those things in the future CMS management's coming up. But... Jonas: Yeah, those automatic integrations are something that's getting a lot of steam in the wider community I think too. Really thinking about how do you compose all those headless systems? How do you actually build a good website now that's also performing on the web that has good performance that can be split tested. That has personalization and all of that with different systems in the background and the front end is just one part of it. But we think it's a pretty vital part because it sits between all those headless systems, all this composability stuff and the end user. So in between that you will always have a front and that gets ran up and it will always be in your interest to have it consistent, to have it brand compliant. That will always be, at least for the companies of the size, Daniel talked about they have that interest, they're really interested in controlling that. Paul: And on the non-technical front maybe what are some of the organizational partners you're working with or growths that you guys are having that you're excited about? Is there somebody that you can share on the podcast? It's okay, if you can't. But, is there somebody you're working with that is a really awesome for feedback in the product that you're excited that you're working with that you maybe want to share? Daniel: Yeah, maybe there's one large German university the Ruhr University of Bochum, which I guess is one of the largest universities. Jonas: I think the 7th largest or something like that in Germany. Daniel: And they have a strong need for design system. And that's pretty typical for lots of customers, they are not really deep inside that system thinking of a design system, what does it mean? So that's often where we now and all those pilot projects start with a consulting project, what we call the design system initiative. Where we also let's teach the customers and coach them into that kind of thinking. And it's on a larger scale, not only the developers but also design folks, maybe people from marketing or course stakeholders. We find out in that process and then it's on the one hand telling them how modern design system can look like and what are the best practices and what is worse to implement and what are the values they can get out of it. And then it's really starting with not the main project, the biggest project, rather finding out a pilot project where they can test and integrate kickstartDS and implement it and apply it for that touchpoint and then scale from there. And again, coming back to that customer, they have lots of content driven websites, so it's worth for them to rely on something like kickstartDS. And... Jonas: I mean they have hundreds of departments with widely different background knowledge about web development inside those departments themselves. So you will have some that just know how to click together something with Bootstrap you will have some that won't do any development at all, just use of the shelf solutions or others that are really knowledgeable about it and want to have something new. That's what was really interesting for us with that project to see how something can span from all that modern React headless world all the way down to something just talking about HTML. Because that's probably something we should note too, that we are not requiring the user to use React on its own website. It's just the templating layer that we've chosen because every component library needs a templating layer. As I've said before, it was Handlebars for us, but that's just not that modern anymore and you don't have many benefits that React has as a templating layer with that. So in practice those customers, like the university, they're actually using the HTML output. So they just have an HTML tab in their storybook. They download a static asset with super old called index.css index.js, integrate that into that page or even have it on their own CDN lying around for people to use. And then people can go deeper from there. Paul: If you're enjoying the podcast and you want to learn more about design systems or really anything related to development, we have a whole plethora of episodes in the past and one's coming and just like Jonas mentioned, we have one or probably two or three more about design systems. So tune into PodRocket, we got more great stuff coming for you. And now I'm going to lead into the outro because I want to point people in the direction of where they can learn more about kickstartDS. So I mentioned the webpage, which is very fun looking and we should all go look at it to see fun colors and get inspiration about how webpages should be. Because we're all... I'm sick of the white ones guys. There's so many just white webpages that have. It feels like a flyer, this one is playful. So check out the webpage, the documentation that's also accessible from the webpage of course. Do you guys have? Jonas: Not yet. I have to say that's part of the upcoming release. So... Paul: I spoke too soon. Jonas: When we're releasing, and that will be pretty soon. So end of the month, start of November will be the release. So then the repository will go public. You can just check our code directly, which we think is super great because we would love to hear feedback about what we've built. So we are pretty excited about that. And then the docs will also go online. Paul: And if people wanted to maybe watch a video or follow you guys, do you have any YouTube talks about what you're doing? Jonas: We do have some YouTube videos online, but they are a bit outdated currently. So we've really been heads down the last months and weeks to focus on the release. So there's not that much currently, but you can pretty much expect some new stuff after the release to showcase what we did here. Daniel: Yeah, exactly. So we will start growing that community once we have that release, which is a major milestone for us. Jonas: And we have a small Discord server, we're on Twitter. So if you research you will find some way to connect to us now too. But we're really looking forward to do that after the release and have a wider public audience looking at everything and telling us what they think. Paul: The Discord server is great. That's becoming a very popular medium for growing communities, so we can find that through the website right, it's linked? Okay, great. Jonas: And we have a registration, so if you just want to know when the release occurs, we have a small registration form on the page as we promise on the site. We will just sent you that one email when the release is ready. It's not a mailing marketing list or anything like that. it's just as a hook to be modified when we are actually live with it. Paul: Well Jonas and Daniel, thank you for taking the time to come on. I'm sure there's going to be some people coming to the Discord server and to check this out and hopefully you can inspire some teams to start actually using design systems and improving our front end hygiene in general. Jonas: Yeah, good luck. Daniel: Yeah again thank you very much for having us.