Latest / Giant Robots Smashing Into Other Giant Robots / 517: Building Better Design Systems with Luro's Trent Walton

Transcript

517: Building Better Design Systems with Luro's Trent Walton · Giant Robots Smashing Into Other Giant Robots

• VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me. TRENT: Oh, thanks for having me. It's great to be here. WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas. TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing. And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web. VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard? TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that. So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on. VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to. TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit. But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs]. VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach? TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now. But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on? So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time? So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on. And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that. VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support? So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use. TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions. So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens. And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that. WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design? TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down. Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college. And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited. So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works. But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that. And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way. For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff. But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at tbot.io/entrepreneurs. VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started? TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think. And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything. And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day. But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out. But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems. So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match. And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that. So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet. But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have. So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario. VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles] TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that. But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why? These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation. It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build. And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes." And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key. So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here. So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job. But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense. So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much. But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way. So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization. WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play? TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker? So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages." And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well. So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things. You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that. So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places. And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product. So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there. So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff. And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those. VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon? TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general. But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once." And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close. And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring. I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin. We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details. VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on? TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well. So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading. Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test. And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing. And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page. But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose. But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now. WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that. TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this? And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively. So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal. And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time. But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation. So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well. WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand. So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship. TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time? But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun. So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked." They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next. VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today. TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this? So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up. VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building. TRENT: Yeah. Thank you for having me. This has been great fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.