An Interview about Omlet, a new Design System Analytics Tool

Is there a way for me to see if there's a new component emerging and I want to be able to see how many times it's been used.

The tooling is so lacking in that space.

Can you visually tell me what my change will affect? There's a lot of manual ways to do it. This was a kind of a good opportunity for us to think about, can we automate this process from start to end? Imagine a product, you run it, it analyzes your code base and comes up with some dashboards of, you know, commonly looked at data points. And you can also customize it however you want. We just announced the product, actually. It's called.

Hi everybody. We are having an awesome conversation about design system metrics here. So I figured I would be here with my friend Burke to kind of talk about what we have been doing in terms of design systems individually and then collectively in the future of all that stuff. So before we get into it fully, let's do a couple of intros. Burke, can I hand it over to you and then you can tell us who you are and what you've been doing lately?

Yeah, of course. Yeah. I mean, first of all, thanks for having me. This is going to be. It's going to be fun.

Totally.

I'm Berk. I'm one of the co founders of Zeppelin. I'm also the cpo. Uh, I'm. I'm actually a software engineer. That's kind of what I've started doing at Zeplin. Initially, I've been working on our Mac app. I've been working on our integrations with design tools. So a bunch of, you know, typical coding developer stuff. But over time, as the team grew, my role kind of evolved into a product where I've done a lot more PME things and I'm currently sort of leading the, the product team. Kind of my journey over the past, I guess now, seven, eight years at Zeplin.

Nice. Awesome. I have so many questions about that that I will ask you in a minute. But for those that don't know me, I'm Dan Mall. I used to run an agency called Super Friendly, which is focused on design systems. So I've consulted with, I don't know, hundreds of design system teams at this point and just tried to understand all the different things that they're dealing with and how to help on those things. And I since shut that down to really focus mostly on teaching design system teams how to grow all of that in house and how to do it on their own without relying on agencies or external partners or anything. Like that, but really have it be kind of an in house thing that they maintain and grow and evolve over many years. So tell us a little bit more about Zeplin. What's Zeppelin's mission, why does Zeppelin exist and how do you help all of that happen?

Yeah, yeah, it's been a really interesting journey. Like when we first started it was like we were really focusing on, I guess what you call the handoff stage, where our main goal, the main question we were trying to answer is like, how do we get the best specs from designs that developers need just to cut off that manual process where designers have to redline the whole thing. But since then, I guess in the past seven years we've been really thinking about it in a more broader perspective where we've realized whenever you're working with a developer, there's a bunch of things you need to sort of share with them and possibly in a lot of different formats and things. So what we're now focusing on is basically kind of a stage that we like to call design delivery, where it's about almost like prepping your designs for developers where you're basically, you're moving things over to Zeppelin. That's how you finalize things. You can do versions, you can do documentation, sharing, organization. So we're, over the years we've been talking to a lot of folks and just trying to figure out what are these different things that people do whenever it's time to kick off development. And we're trying to automate and just simplify a bunch of things related to that. And outside of that, we've been also working on a brand new product which we'll get into probably later in the show.

Yeah, absolutely. And so, I mean, I think that's a good segue too to like, I know one of the things that you and the team have been focused on in the last recent period is just really paying attention to design system metrics. I know that comes up a lot with your customers and the folks that you all serve. So why, why the interest in metrics, you know, and, and why do, why is that important to Zeppelin folks? You know, I have some anecdotes to share there as well. So curious to see what, what, what.

Your perspective is that actually happened kind of organically. We were trying to figure out like what are some of the things that we can help further for developers. We were talking to a bunch of developers doing just research overall, trying to figure out what are some different pain points that we can start focusing on a common thing that's Kept coming up is how do I measure the success of the components that I'm working on? It felt like there are a bunch of different things that we do that are design systems related within Zeppelin, but we've realized this is actually a kind of a completely different topic, a pretty big space. So we've decided let's not sort of bloat what we have and just not try to find ways to extend Zeplin. Rather just really try to understand what this pain point is and try to come up with a solution. So that's where this whole idea came from. And it's been really interesting to hear, like how a lot of teams are currently struggling just trying to figure out like, well, what do I measure or how do I measure? It's like all of these different steps, it's like completely manual right now. So it was a really interesting space to just do a lot of research on.

Interesting. So I think those are all amazing questions to surface. Do you all have any answers like, are there things that you found with your customers where, like they're asking the questions like, what are the things that we should be tracking to know if we're successful? Do they also have answers to some of those things? Are there patterns that you've spotted in some of that?

Yeah, there were as we were trying to figure out. Like, okay, this is a topic that we want to get into. We went ahead and talked to a bunch of people and try to understand what are the things you're currently measuring. And I guess there are three or four sort of main themes. The very first one, I think that comes up a lot is just overall measuring adoption. I feel like that's pretty natural. It's almost like if you think of a design system as a product within the company, like whenever you launch a new product, the first thing you want to see is are people using the product. So it's kind of similar in a sense, I guess, where people just wanted to be able to see are people adopting the components that I'm working on. So that's. I guess that comes up really natural. And that's kind of the first step. And then a common theme that sort of as a follow up that came up a lot is can I sort of identify some gaps or some opportunities where maybe a component, an individual component is not used frequently and you want to be able to see that right away and just get our feedback about that individual component, or you want to make a change to a specific component and you want to be able to see, oh, where's this component Used, which teams are using them the most? Stuff like that is. Is also common questions that came up a lot. And I guess a very common theme is also just, I want to be able to show my team the value or the ROI of the design system. So that's obviously one of the top things as well.

Yeah, nice. It's so interesting to kind of compare those against some of the things that I've seen. So I work a lot with the individual designers, engineers, writers, content folks, and I think one of the questions that I see a lot and one of the, like, the areas of interest that I see a lot are I think people want to know that their work means something, right? Their work has purpose. And especially when they're working on design systems, they're like, well, my, you know, as a design system designer or engineer, my job is to help make somebody else's work more efficient, you know, or more consistent. So I see a lot of things around those areas in terms of, you know, efficiency. And when I work with designers and engineers, they're like, I want my work to help people be more efficient, but I have no idea where to even start measuring, measuring that stuff. So those are some of the things that we'd work on together. And some of the things that I've seen people come up with is like, you know, measuring. You know, all of the stuff is about before and afters, right? So they measure, like, without before our design system, you know, what's. What's our. What's our development time? Like, what's our average velocity on a sprint or on a cycle or something like that? And then after the design system, is that going down? Like, is that, you know, are we helping things? And then one of the big ones that has come up for me recently is, is QA time. I've worked with a ton of companies that are like, we spend 60% of our sprint time on QA, and it's like 60, like, more time QA ing than actually designing and building, right? And so, like, teams are going, okay, if we see our QA time drop, you know, those are some good indicators that our design system is actually doing some of the things that we want it to do. So I think a lot of people are, like, are starting there. Do you find that there's, like, a base set of metrics? And then after they kind of get those under their belt, there's. There's more, I don't know, more mature ones or a different level or anything like that?

I guess a very common one is just being able to See just individually, how, how frequently are component are components in the design system being used? I think that's sort of the first step that a lot of teams take. It's just, I mean this doesn't have to be automated even. You could sort of run some manual scripts or something just to pull off. You just want a spreadsheet of basically like here are all of our components and here are how commonly they're used. And that's going to give you, I guess, a bunch of insights around, okay, these are the components that people have invested in a lot. So we have to make sure that they, you know, they perform well or, you know, you basically have this list of components that you want to, you want to make sure that people kind of have everything they need. Because like you said, it's kind of interesting. When you work as a front end developer, the work that you do is immediately like visible to users, but within a design system team, it's almost like there's a, you're kind of in the middle where your work, you're kind of curious, like, okay, I'm spending all this time creating these components, but show me, are people actually using these components and am I being, am I being useful in the things that I do? Another thing that was really interesting to see is usually especially in larger teams, you have your design system team and then there are a bunch of other teams that sort of use the design system team and being able to visualize which teams are adopting the design system more than the others, or if there's a team that's kind of lagging behind. Visualizing those types of things are really helpful in a sense that you're not going to get what you need right away, but you have that visualization. You immediately go and talk to them and try to get more information around like, why are you not adopting the design system and stuff like that?

I mean, I think a lot of the stuff that you're saying is really important and sort of like table stakes for a lot of teams. Why do you think that's so difficult for? You know, because I talk to a lot of teams who are like, we would love to do that stuff, stuff we just can't. Like why, why do you think they can't do that right now? What is so difficult about that?

It's, I think it's just, I mean from as we were doing a bunch of research for this, this new product that we've been working on, we've kind of realized that the teams that, who managed to do this on their own they actually have probably at least one person just dedicated to creating these metrics and just visualizing them and making sure that everything's like maintained properly. It's, it's interesting. Probably like design system teams are maybe not even well staffed to be able to, you know, make sure that the system itself is top quality, let alone having one dedicated person just focusing on metrics. So that's probably people due to resourcing, they just not have enough time to do all this stuff in a more granular way. I guess. I've seen a lot of people try to manually solve this. So it's kind of a one off thing where you're like, okay, we're going to gather an inventory of all of our components, how frequently they're used, do a bunch of interviews, but that's a one time thing that you do and then in a year again you kind of have no idea. So I think that part of like how do you even automate something like this is the most tricky part. There are some open source libraries, I think the most popular one is called React Scanner where you run that and it gives you sort of a list of components and how frequently they're used and things like that. But then again it's kind of up to you to make sure you automate that. You sort of visualize that in a format that's really understandable to the whole crew. So it's just a combination of all of these things. I guess it's just making it really tricky.

I mean every team that I've talked to and work with around this problem has always had to like create some sort of custom airtable or like a Google Doc that maybe there's some automations in it. But a lot of teams that I've worked with have solved it just through process because the tooling is so lacking in that space. So they just go, all right, well Fridays are our day to go and talk to all the teams who have adopted and just update our spreadsheets and then we'll tally it manually and that just becomes, it's hard to do because sometimes you forget, sometimes you don't have a chance to talk to these teams. So there's just not a lot of tooling in this space other than some homegrown stuff or a couple of open source things that weren't necessarily meant for your use case. But you know, you try to make it work. I know the, the popular one that I've seen is I think from the segment team, you know, built a custom dashboard, you know, Evergreen, I Think that's built on REACT Scanner if I'm, you know, if I'm not mistaken. But you know, but like that's the only example that I've had to point to for a while. Like, oh look, they built something like this. Maybe you can build your own version of this. And it just seems like, you know, another product to build alongside a design system, which is really tough for a team to do.

And it's, I've also noticed that design tools are doing a much better job in terms of just visualizing this data. You know, in Figma you can have a bunch of this data in terms of like, how frequently are my components being used, are people detaching my components, you know, stuff like that, that's pretty common. But when you think about the sort of similar data, but for components in the code base, there's pretty much, pretty much you're kind of on your own.

It's such an odd thing because analytics have been around for a long time. You know, like you think of any website that you would put up, it seems, you know, it seems absurd to go to say like, well, we're not going to put Google Analytics on that. You know, we're not put some sort of analytics package or something like that on it. And yet we don't have a lot of those things for design system. Do you think that's just because we're early in design systems or what do you think that is?

Probably. And I've also noticed that a lot of the design tooling is starting to get a lot more friendly to tokens and components and things like that. On the development side, even though we have pretty much a million different ways of doing components and we had that for years, this analytics part of it I don't think has ever been so top of mind where people, I guess they were just getting by by just, you know, go talk to the team and try to understand like which components do they use, which they don't. But right now as these as design systems are more top of mind, I feel like especially larger teams, they're having trouble just manually doing this stuff. So I think eventually this is going to be kind of a natural step of building a design system. From day one, you want to be able to visualize and see how frequently your components are being used and stuff like that.

I love that. I think like there's so many things that I think a team should be tracking when they're, when they're evaluating design system success, but all of them are based on just that bare level of, you know, that, of table stakes, of like just knowing how your components are used, you know, if you don't know that, how can you track kind of some of the higher order things? I think one of the best signs of a design system success is actually tracking retention. You know, retention of employees of like people who use the design system or people who have been involved in design system work, whether tangentially or directly, how, how likely are they to even stay at the company, you know, and if you can draw some ties between like people who are doing design system work are generally happier or their work is easier or something like that, that actually makes a lot of impact on how, you know, people outside of the design system will see a design. So how executives might see it, you know, they might see it as actually a useful tool rather than like, oh, that's like a dev thing, right? Or that's like a design thing, you know, that doesn't matter at the executive level. And so. But if we're not able to even track like how often are our components being used, how can we start to track things like, you know, association with the design system team or anything? A lot more of the messier people stuff, you know, if we can't even do the, what should be simpler technical stuff around that.

Yeah, that makes a lot of sense, I guess, from, from your experience, what are those sort of next, what are the next, what is the next step? When you look, let's say you have your components and then you can see like how many times they've been used, what would be the sort of the next thing that you would recommend?

So I think one of the things that's really tough about design system teams and design system work is it's a new thing compared to product design, right? So product design, the job is very clear, which is you make a particular product for your customers and those customers are paying customers or they're subscribers to your product or whatever that is. And then for a design system team, a design system team's customers are the designers and engineers who then make stuff for the other customers. And so they're like one level removed from the end user. And so one of the things that I try to encourage teams to do is like, okay, like yes, the components, the efficiency and the consistency, all that stuff, it matters, it's important, it's table stakes. But then past that, can we tie our work to helping customers, like helping the end customer? Like if we make a, you know, a button component or a dropdown component or whatever, it's hard to Say, yeah, this dropdown component helped one of our customers. Customers do something. But there's got to be a way that we can do that. You know, one example that I use often is, you know, if you were working at Uber, you know, part of the mission of Uber is to help navigate the world, right? That's the way that they say it. That's in their mission statement and their. You know, all that stuff. So if a design system team could then tie their goal somehow to the goal of the company, you know, to say, like, we are helping the company move forward, not just our designers and engineers, but our designers and engineers, users that they're building for, you know, how do. So how do we tie it to the company's mission, to the company's okrs, you know, or things like, things that are happening one level outside of what we're doing? Because I find that designers and engineers and design system teams, they're so insular, you know, that they're just like, I mean, our job is components. You know, we don't care what happens outside of that. So, you know, I like to encourage them to, like, well, think one layer outside of that. Think about how you can help somebody catch a ride to the airport. You know, how can your work help them? And then I think it gives more meaning to, like, well, this is what we need to do with our map component, or this is what we need to do with our, you know, something that's a little bit more outside the generic, you know, buttons and cards and headers and footers and stuff like that. It's like, how can we actually be helping the end customer with our work, even though that's not our job, but we're actually helping our customers to help their customers.

Yeah, that's a. That makes a ton of sense to me. And usually from what I've seen, especially as I guess companies get larger and larger, design system, teams become almost like this. This machine where you're like, okay, it's our job to just build components. You kind of get loose sort of. You kind of lose that connection with the end user. And, yeah, that's. That's. That's definitely something you want to keep.

Yeah, it's. It's like when. Whenever I talk to teams, I'm like, avoid. This is a kiss of death. Avoid being a component factory. Because if people start to see this team as a component factory, you've lost all of the value that. That this team could provide, you know, because they just see you as like, all right, anytime we need a new card we'll just go talk to the design system. And that's not at all the role of the team. And so, you know, this is kind of a good, a good segue into our next session, which is like, I think what makes metrics important is when executives say like, okay, so what good is our design system doing for us? You know, so, and you know, a lot of people start to pay attention to metrics because they go, oh, we're trying to get executive buy in or VP sponsorship or something like that. What have you seen in the role that Metrics, tracking metrics, being able to display them and visualize. What role does that have in just getting overall buy in from design system executives and people outside the design and engineering?

Yeah, I guess this really depends on the company. But some of the teams that we've talked to, this was what's top of mind for them. We want metrics because we want to get buy in. We want to show the return of our investment basically immediately. Some of the first things that they were talking about is, okay, can I, is there a way for me to show the time that we save by sort of creating these components, just measuring the efficiency of using every usable component versus a developer building something from scratch, you know, so you can use these sort of usage and adoption metrics to have some sort of rough idea of like, look, look, this is how much time you've saved over, over the years. Obviously there's a lot of nuance there, but it's, I think it's a good, simple step to just show just the leadership team some of the things that you're working on. They are for sure worth it. Also, there's, it's not just about a developer, you know, creating component from scratch. Whenever you have these components and system in place, it just makes the overall process smoother in a sense that you will start to notice that there's less issues and less bugs coming up and less sort of last minute hotfixes and things like that. I guess the team overall is just happier. And these types of things are kind of hard to measure, but you can kind of tie it to just purely usage metrics and adoption metrics. If you're spending so much time making sure that your website is accessible, the last thing we want to do is a developer coming in and creating their own components. So these types of things are also pretty critical.

I love that. I think that makes a lot of sense. One of the last clients that I had worked with when we were making an executive presentation that I was helping them with One of the things that they were saying was like, we have to show the amount of time saved, right? And that's easy multiplication to do, which is like, let's find the average amount of time that's, that is saved by a developer working on a custom component versus an out of the box component. Let's multiply that then. Times the amount of developers, times the amount of teams, times the amount of time that we're doing this stuff. And I think they came up with something like, so we would save conceivably $250 million over the next year.

Right.

Which is ridiculous amount. But in order to even get that number, they had to go like, well, they had to do like a two week project. Looking into their telemetry and looking into their. It was just a hard thing to come by even because those analytics are just not readily available. It's like we have to go and do a research project essentially to even get those numbers, to be able to even make an estimate. And I think that's part of the barrier to entry here is that it's just hard to get that data. The data itself, when you have it, is really valuable and really convincing. But even just getting your hands on that data sometimes turns into their own projects.

Yeah, yeah, yeah, for sure. And there, like I said, we've talked to teams where there's just one person who's dedicated to just maintaining and just working on these metrics. So not a lot of teams have that luxury.

Yeah, that's right. Yeah. Well, there's a saying that in order to do something, you got to break some eggs. You know, something like that. So you all have been breaking some eggs over at Zeppelin. You know, you tease this product, this new product that's coming out, like, why don't you talk a little bit about that? What's happening over there? You all are super interested in metrics. Maybe you can tell us a little bit about why and what you're doing about it.

Yeah, yeah, it's. So like I said, this sort of, this new product actually came along as we were trying to, like we were just talking to developers and trying to figure out what are some other things we can do in Zeppelin that can make the, you know, their experience much better. And whenever this topic came up, we kind of started to focus on it because we realized it was a common theme. Like whenever we talk to a developer who's specifically working on a design system team, this was the first thing that they would tell us. It's just like, I guess questions like, how are My components being adopted over time and is there a way for me to see if there's a new component emerging and I want to be able to see how many times it's been used. Maybe it's worth moving over to our component library or stuff like, hey, I'm going to go update this component that we had for a while, but I don't even know where it's used. It's going to be. Can you sort of visually tell me where my change, what my change will affect? Things like that came up a lot. So as we started researching this, we realized that there's a lot of manual ways to do it. So this was a kind of a good opportunity for us to think about can we automate this process from start to end? Where imagine a product, you run it, it analyzes your code base and comes up with some dashboards of commonly looked at data points and you can also customize it however you want. So that's kind of where this whole thing came from. And we've just announced the product actually. It's called Omlet and it's. We've kind of, we've decided to keep it kind of separate from Zeplin in a sense because there are things that we do design systems wise in Zeplin, but they're not really related. So we didn't want it to be confusing to folks. So it's kind of a kind of standalone product. But we're pretty excited about it. It's been, it's been probably a little more than three, four months since we actually started getting feedback from actual users and so far it's been going pretty well. Yeah, that's kind of where we are right now.

That's awesome. Can you walk us through a little bit about how might you use Omlet? So you have a code base. What do you do to get up and running with Omlet?

Yeah, so we wanted to, like I said, keep it as simple as possible. Where the, the product itself is just a. It's. It's a web app combined with a command line tool. So you basically install Omlet as a command line tool. Currently works with React only. Since we're just getting started, it made sense to just work with React. What it basically does is it sort of goes through your whole code base and collects a bunch of information about how components, how many times the components have been used. It also collects the dependency tree of components as well. So you can have a sense of, oh, this component has been used five times in this component and seven times in this other component. Things like that too. So all of this information, when we collect it, we basically have a web app where everything's visualized. What's been really interesting is that initially we were thinking about, okay, we're just going to sort of collect this data and build a UI where people can query whatever they want. But then we realized as we are talking to these teams, there are all of these common metrics that people look at stuff that we just talked about. So why not give them a dashboard right away with all of that stuff built in so you can immediately start even if you don't know what you want to track. It's going to give you some suggestions. But we kind of also wanted to make it customizable. And a lot of common questions people were having around data is it could be very specific. Let's say they have a set of deprecated icons and they want to be able to see which teams across our company are still using these deprecated components and how is that number changing over time. So we've also came up with some ways of, like, you can tag your different groups of components and then do visualizations based on that. So that's kind of where we are. It's still very early, but this is kind of almost like our, hey, here we go. This is an area we want to get into. And give us as many feedback as you need, and we're going to continue working on it.

I love that. That's awesome. I had a chance to kick the tires on it yesterday and it was magical. It was great because it gives you that visualization, which I think already is just such a difficult thing to have when it comes to design systems. So, you know, I installed it in a repo, in a design system repo that I have, and it was like, cool, we're watching. We're tracking your stuff now. And I was like, oh, I have a dashboard generated in a couple of minutes of like, all these things that some things that I knew were there. And I was like, oh, this is an interesting way to look at it. And then some things that I'm like, I didn't even know that this was stuff that I should be looking at. So that was really helpful too. So from a design system perspective, at least from my perspective, it was really easy to set up and install. What about for like an adopting team of a design system or a design system component, would they need to do anything to configure to make sure that their adoption is tracking properly an omelet or anything like that?

Not necessarily. I Mean, we kind of, like I said, try to keep this as simple as possible. You simply sort of run the. Run the tool which does that first, takes you to that first step of analyzing your components. I guess one thing that could be valuable if you have kind of a more established, larger design system is to, like I said, tag different components. Because what we've kind of realized is that design system teams usually have different versions of their design system. And it's a common. Like, as we're migrating from V2 to V3, we want to be able to see how that's going. So if you'd measured usage across all of these versions, it would be pretty confusing. So if you have a more established design system, I guess make sure to go through, tag these different versions and tag those deprecated icons so you can have a more customized view of all these different things.

That's awesome. Where is Omelet in the lifecycle of development? Is it publicly open? Can anybody sign up for it? Is it in beta? You know, where is, where is it currently?

It's currently actually in early access, but actually by the time this might come out, it might probably be in public beta because it's going to happen pretty soon. Up until this point, we were working closely with a few teams, just trying to make sure that whatever we work on makes sense for them. And right now we're kind of going into a phase where we're just, okay, we want more people to come in and test this thing. We're hoping to have at least 3, 4 months of a beta where we just again, continue to work closely with folks. And then we're going to be. Yeah, on ga, I guess, probably sometime this summer.

So cool. Who's the ideal user of Omlet? Who are the people that you're hoping sign up for either early access or beta program or something like that?

A lot of the teams that we talked so far have a, like a pretty established design system where in the sense it's like it's been through multiple versions and iterations and things. But what would be really interesting is just to also work with team teams that are just starting out, because probably when you're kicking off a new design system, this could be an afterthought, but we're hoping that it's not. So it would be great to be able to, just for a team that's just starting out, we're able to see their experience of like, you know, how does Omlet help you make decisions along the way and things like that. So I'm really Interesting to see to work with more sort of these teams that are just starting out.

I love that. All right, so you're here to hear first, everybody, if you are a new design system team or are just starting up with something like this, it would be really interesting to see how you might use a thing from the very beginning of your design system process. So the Zeppelin folks and the Omlet folks are looking for that last thing then as we wrap up here is what can you tell us? I know you can't tell us everything, but what can you tell us about the future of Omlet and the kinds of things that you want to eventually be able to visualize down the road?

There are a couple sort of more short term things. Omlet only supports React right now and that's something we want to expand to more frameworks. Another thing that's again short term is that we've been really focused on component usage, but a common theme is also to do a similar thing for tokens, stuff like colors and textiles. So that's also something that will be coming up pretty soon. But longer term, we're really thinking Omlet as a tool that will, you know, help with just design system adoption overall. It's not just the step where everything's done and then you're just analyzing what happens if we can get into a state where when a developer is coding, if we can point them to the right resources. This is this kind of where we, where we want to take this thing to. But obviously that's going to take us a little bit more time.

That's so cool. Well, Berk, thank you for spending this time with me and talking a little bit about metrics and then Omelette. I think that's really exciting that that's coming out. I think one of the things that I love about the design system space, especially now, is, you know, we've been talking about this all as a community for, you know, years now, and now we're getting the tooling finally that supports some of the things that we really want to do. So, you know, I'm all in favor of seeing as many companies as possible throw their hat in the ring and start to build tools like this, because I think without it, that's the ceiling. The ceiling is only the things that we can do manually. So I love that you all are helping automate that for folks and I think it's going to be really exciting to see how all of that develops over the next couple of years.

Yeah, I mean, thanks for having me over too, because we can't do this on our own. It's just going to be a kind of a thing that we work with a bunch of different themes together. We're going to figure it out together, basically. So, yeah, it's. It's great to be able to share this with, with a, with a larger audience and see what they think.

Awesome. Very cool. Well, hopefully we'll have a chance to have another conversation with you in a couple of months or next year or something like that to see how all of it has grown and, you know, just to see how this all develops. So thanks again for being here, and let's do it again soon.

Awesome. Thanks. So.