← Dive Club 🤿
Loading summary
Transcript85 lines
- [00:00]
A
Imagine a world where handoff no longer exists and designers are moving fluidly in code.
- [00:07]
B
We're at a point, technically, where there can be a single source of truth. There is no separation between design and.
- [00:13]
A
Engineering in that world where everyone can ship working software. What happens to the role of designer.
- [00:20]
B
If you are still operating under the mindset that, oh, it's all right, if I take a month to come out with this design and expect the team to now redo my design from scratch in code, I think you're going to find that that's acceptable anymore. You got to be building stuff. I mean, at this early point, if you're not able to jump in and start writing code and start understanding the code, what are you doing?
- [00:41]
A
Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with Drew Wilson, and we're going to do a deep dive into his startup, Opacity and his vision for the future of design tools. We're going to go deep into components, how AI is reshaping team workflows, and what designers can do to succeed seed in this new world. So let's begin by learning a little bit more about Drew's background and what led him to start up again.
- [01:12]
B
What I do now, which is design and engineering, is not only something that I do for work, but it's also like a hobby, and it's what I like to do for fun. The idea of getting to build a software workflow the way that, you know, I would like it to work and the way that I think would be the better way for it to work is super fun and motivating, because not only am I building something that I think other people will dig, but I'm going to like it, right? I have this idea of what the ideal workflow can be for building software. I'm trying to meld the opacity vision with what that is, right? I'm not just building a software tool and seeing maybe it works, maybe it doesn't. I had this idea of, like, here's like, I think the best way it can work. Having been a designer for almost 30 years, engineer for almost 30 years, and doing management for, like, the last 15, and working with teams and having my own teams working on teams. I feel like I've got a good idea of how this stuff can work, and I just want to make the tool that enables that.
- [02:13]
A
What part of it's broken to you when you look back on your experience? Where does the pain exist that you're then using as the entry point to this workflow and kind of reimagining things.
- [02:23]
B
If you're just a designer, it's super motivating and super fun to be finished with your design. Nothing's ever totally finished, but you know what I mean? Like, you're. You're delivering it and you're like, my gosh, it looks so good. I can't wait to see if it turns out the way I hoped. Very fun feeling. But if you have the unfortunate circumstance to also be an engineer, you know that most of the work is in engineering. It is not in design. And by most, I mean not necessarily the headspace, but I mean, the length of time spent building the thing is mostly engineering. And so when you get a design that's just literally the starting point, you haven't even actually done any real work yet. It's just a pretty picture. If you are an engineer designer, the pain happens as soon as you finish the design because you have this designer and you being like, yeah, it looks so good. And then this overwhelming feeling of dread, of like, oh, my gosh, I haven't even started. Now I got to build the whole freaking thing. And it's just a horrible feeling, and I'm just sick of feeling that feeling. And so that's one of the main reasons I'm building opacity, is to get rid of that feeling.
- [03:33]
A
Real quick message, and then we can jump back into it. Every time I think that I understand the depths of Mobin, I realize that I barely scratched the surface. Like, earlier today, we were in a live design session, and in a single search, I found the exact transition that we wanted to reference. And I also just learned that Mobin has curated iOS pages for Dynamic islands, widgets, and even live activities. It is truly the ultimate source of design inspiration, and I use it constantly in my practice. I can't recommend it enough. Just head to Dive Club Slash Mobin to get started. That's M O B B I N. Framer just went from a web builder to true design tool. With their latest release, they just launched design pages, which give you a freeform canvas to explore in and all of the tools that you need, including vector editing. That way you can experiment and play without having to think about things like responsiveness. And then, whenever you're ready, you can turn any iteration into a web page with a single click. No imports, no copying and pasting. Design pages are truly a game changer, and you can start using them today. Just head to Dive Club Framer. Okay, now on to the episode. I like that you use the word workflow, because that's something that I've been gravitating towards so much recently. Like, we're not even talking about features like this is this opportunity in time where we can kind of just fundamentally reimagine the workflow for how software gets built and how we interact with people and at what points along that journey. So then when you kind of imagine this potential future where all these problems go away, what do you believe about that future that then is influencing the very specific product strategy decisions that you're making? Early stage with opacity we're at a.
- [05:19]
B
Point technically, and we have been for a while, technically, where there can be a single source of truth. There is no separation between design and engineering. That's how it is today. And the tools that exist today continue to further that gap between those two disciplines. You know, like Figma, for example, has dev mode. Like in the tool, in the sales process, they say y' all are separate, but I don't think it should be that way. I don't think it technically has to be that way. Just we don't really have any tools yet to give us a single source of truth. So we no longer have designers editing and manipulating this source of truth over in their design tool and the engineers doing the same thing in their source of truth, in the code. And then this person's trying to keep in sync with that, and that person's trying to keep in sync with this, and they're always separate and they're never the same. Companies will spend their entire life cycle trying to get them to be in sync, but they'll never be in sync. And so it's a massive waste of manpower, woman power, and it's a massive waste of creativity and money. And we can just get rid of that. And I think that it will be gone. And I'm hoping that opacity is the way that that will happen. But I think in the future we'll have a single source of truth and it's not going to be this double split thingy going on.
- [06:30]
A
What does that look like from a workflow standpoint then? If both people are working on the same source of truth, like, can we just go a little bit deeper?
- [06:37]
B
It could be explained pretty easily technically, if you take a look at, let's say, Figma, because everybody listening to this is working in Figma, which is a great tool. If you're working at Figma, you're clicking and drawing boxes and rectangles and adding drop shadows behind the scenes. What's actually happening is there's GL code that is rendering what a drop shadow is, what a stroke is, what a box is, the size, everything. Right. And so there is actually a single source of truth in that tool. There's the code and the display of that. Right. But the majority of drawback is that Figma decided to build their Canvas not in like CSS browser technology. They built it in WebGL. So, I mean, it's kind of browser, it runs in the browser, but it's not the dom. Right. Which is what products use. Software products use the dom. And so now that is essentially just a pretty picture. It's totally useless. You can't really have it also be the dom. And so there's a bunch of tools that have been built to like, oh, let's inspect it with AI and then like we can copy out the react and you can paste it in over here. But that is, that is still furthering the gap.
- [07:40]
A
And it's a band aid. Yeah.
- [07:42]
B
If you ever copy and paste instantly, you have two sources of truth. So that will never work to get to this feature where there's a single source of truth. Figma already did it, y'.
- [07:49]
A
All.
- [07:50]
B
If we just had WebGL browsers, who would have a single source of truth, but we don't. And so there needs to be a single source of truth where a designer can draw things on a canvas, but it's actually creating, you know, this underlying DOM object, actual browser code, CSS driven code. And then the engineers just grab those things. They're not copying and pasting, they're grabbing the actual code and referencing it from their code files. And you can do that through NPM packages. So you are going to remove the code from the canvas and put a state, an NPM package in a particular state and you call that a version, like version one, but. Right, and then the engineers pull that down in their code base. They're not manipulating it, they're never changing it, they're never actually interacting with that code. They're just displaying it and then maybe passing in some props to change how it displays. Right. But it's all coming from this canvas. And then you update it and you create a version 2. Right, or version 1.2 or whatever, and they update the package the way that engineering has always worked and works today. Nothing changes about that flow. And for the designer, they're still drawing on a canvas. Nothing changes about that flow. It's just now we have one source of truth.
- [08:59]
A
How do you think that impacts the way that designers collaborate with Engineers, then.
- [09:04]
B
There'S a couple answers there. And I think, like, the longer term answer is, you know, what is a designer and what is an engineer? Let's go there.
- [09:11]
A
I think that's more interesting than talking about eliminating handoff. Like, that's table stakes. If we play this out a little bit, like what's the world look like in your mind that you're trying to create?
- [09:19]
B
Handoff fully eliminated. I want to delete the need to ever code out a design again from the history of planet Earth. That'd be great. You can still do it if you want to, but you don't have to. I don't think that an engineer in the future, 10 years, five years from now, is going to look the same or have to be the same, or have to be as smart or as knowledgeable as they are today. I am majorly enabled by Claude code. Right. I can do so much more than I could ever have done before. And I don't mean it made me a better engineer. It makes me more productive. As a matter of fact, I don't think Claude or any coding agent I've ever dealt with is really the best engineer I've ever worked with. Right. If you're a very senior engineer, you can easily guide it and see where it's going wrong and help it along. Right? So that means it's not smarter than you, it's just faster than you, faster than you'll ever be, and could build way more. Right. And so I don't think engineering is going to be the same or the engineer profile will be the same going forward. I think there'll be a lot more engineers. And I think that folks who never made it up to senior level will be able to be super productive and build really cooler things. And then on the other side, the design side, I think the same thing is going to happen. It's going to take a little while longer on the design side, because design is not the same as engineering. For example, engineering, you can have an interview to figure out who's going to be our next engineer. And you put them all up against this coding test and can they do the code or not? There's really one ish way to do these things. And so it's very easy. That's why you can benchmark these coding tests, try to benchmark AI's design taste. You can't. It's kind of, you know, subjective. People want different looks here and there. It's very different. But there is this threshold. You could tell when something's good, right. And So I think that enables more people to be designers, then we'll be able to be engineers. Because at some point AI design will get good enough that it's always going to look good enough. And anybody can be a designer at that point. Literally anybody. The engineer, the actual designer, you know, the soccer mom, the football dad, they can all be designers. And I think that is the future that we're going to. And so I think the team dynamic is going to be very different. This idea of designers and engineers and these two profiles, kind of building everything with the PM in there, delivering messaging, messages in between, I think that's going to go away. I think it's going to be around for a while, but I think eventually it'll go away. And I think there will be even now teams starting startups, younger teams that will not adopt that model at all. And when tools like opacity come to into existence and cursor and cloud code get even better, it's just going to be more pronounced, I think the way that teams are built.
- [12:00]
A
Yeah, because in that world you just have a much greater percentage of people on a team that are committing code. Maybe the types of code they are shipping is a little bit more archetype driven. Like some people gravitate towards the backend myself obviously, like I don't plan to go too far outside of, you know, front end and basic functions kind of thing. Like I still want to design, I would just be doing a little bit more design with, you know, at this like component level. And I guess when I play that out in my head, I still have a bit of a black box in my mind where I'm like, what does the tool look like that I'm using? Because I, you know, for instance, I've been using a lot of Claude code and warp lately. That's my new jam. I think it's awesome. I mean I feel like I have superpowers, like I'm just, I'm just shipping stuff sometimes it doesn't feel creative, you know, it's not great for iterating. It is powerful. But I'm. Sometimes I'm designing and sometimes I feel like I'm like I'm not really designing still. And it feels like I have to pick these very different paths when I want to contribute to the product. Am I going to enter the code world or am I going to enter the design world? And listening to you talk, it feels like you're creating this almost like hybrid middle ground a little bit. But I'm still not 100% sure what that looks like maybe in your mind and then what the touch points are. Between me as someone who in theory is probably doing more visual exploration of code, getting that to engineers, I'm imagining you probably have to, what, get it back from something like GitHub back into the canvas. Like, can we just go a little bit deeper into like, what is that middle ground look like? What are some of the core product mechanics that you're trying to build around?
- [13:36]
B
Coding agents will always work best in the existing coding paradigm we have today, where it understands logic, it uses components and these libraries and cobbles together everything for you. And I think that will be the way that AI continues to excel. It's just that a human interfacing with cursor or with lovable or whatever, they don't really need to know or care how that stuff works. But it is happening under the hood. And I think that highly systematized way, a framework like React, which has a ton of documentation and a bunch of examples and it is a library that says here's how you do these sorts of things, is a perfect playground for AI because through LLM it can in natural language understand how everything's supposed to work and tie together. And that's why it excels at that stuff that doesn't exist in design today. There is no systematized design. The closest thing that we have are code components when you take your designs and turn them into front end components. And so I think that that is still going to be the best way for AI to build out designs. But we don't have this giant repository of a systematized way to build a design. Opacity is, is trying to do that. And so to double click into like how it works, as you're asking the designer if they want a pixel push and they want to like get all the rectangles perfectly rounded, they can. In Opacity, it's that same sort of canvas tool that you would expect in Figma. And then it generates, whenever you click, you know, publish, it generates these NPM packages or Ruby packages or you know, php, whatever you want. And the engineers or the AI in most cases will pull that down and use that in the code base. And designers are pretty familiar with this. They're familiar with Figma's variable system, where you can create variables. And you know that if I'm going to have a button going to make the text a variable so someone can change it later, right? They can create an instance and change it. Now that in engineering is called props. You're passing in Props is typically what's called properties. So you have like a button text property, and you can customize it. So you pull out the button and you customize the text over here, and it shows up here as a different text, right? And so that same thing is how code components work today. And that's how Opacity works as well. As a designer, you are setting up these components and you're setting up the button tag so you can maybe change around the corners. You make that a prop, right? And then the engineers have access to those props, or AI has access to those props. Everything in Opacity, every design and component you create is actually what I call under the hood. It's called a node. It's similar to a DOM object. It describes in object format the design, how it should show up. You know, that node is that systematized design I was talking about, where now there's this one way to describe a design that AI can rely on. And so then in the future, in Opacity, you have this massive community or marketplace or whatever, because you can make these components you create for free. The base UI library, for example, or Shad cn, you can make them for free or for sale. And if you had thousands and thousands of these UI libraries, AI now will know what taste is, what good stuff is, right? It'll have this massive base to pull from when creating designs, and it will know how they're similar and how they're different because they're all built on the same system. So in the future, when it comes to, like, working together, a designer will still be able to just visually design, but they'll be able to go further if they want, right? They'll be able to build out that whole design library, right? That aspect of IT design system. And then the engineers, as a designer, it could be another tool that you use, or you could have an actual engineering team, and they'll know how to work with those Opacity components, because they already do, because there's nothing crazy or new about them.
- [17:22]
A
Okay, I want to speak to a very specific person listening, which is this person who is, like, listening to you talk and you talk about variables, assuming that everybody uses variables, but there's definitely people listening that are slinging rectangles, grouping things, eyedropping everything. And there's probably this underlying question which is like, man, if this is where the world's moving, where's the technical threshold that I have to get to to even be able to make this jump into this next era of tooling, you.
- [17:49]
B
Used to be able to design and you still can your UIs using Photoshop. In some video game UIs they do use Photoshop because sometimes it's a little easier than even Figma. Just there's, there's more editing tools there. It's getting less and less these days. So you used to be able to build a tool like that, which is not even like gl, it's like its own proprietary thing. You can design in whatever you want and you can pass it off to whoever you want. But you are going to be creating a much slower process. And in the future this idea of oh yeah, we're going to raise money and then we're going to build stuff for a couple years and we're going to launch it, I think it's going to be gone. And if you are still operating under the mindset that oh, it's all right if I take a month to come out with this design and expect the team to now redo my design from scratch in code, I think you're going to find that that's not acceptable anymore. That's probably all right. You could still design things the way you want. You may just get less customers or clients because they're going to want that thing to be done as soon as your last pixel is dropped. They're going to want it to be ready to be pulled into their code base. And if that's possible, what in the world are you actually offering them that's actually valuable? You might be hired as an art director to help direct these things. Or maybe you design it all in opacity and someone else comes in and like, you know, adds the variables. But my heavens, it is not that hard to add variables. So if that's the sticking point for you, then I don't know, just take the 15 minutes it takes to figure it out. Like it's not that hard.
- [19:19]
A
Yeah, yeah. Even for myself, one of the tasks that I've been chipping away at is like setting up semantic variables, incorporating like base ui, really making a component library a first class citizen. And I'm doing that for a very early stage product where I'm basically doing all of the design. And the value prop used to be with systematization was like, well, I'm going to standardize things and make it easier for everybody to be on the same page. It's just me. I still see value in it just because it makes it so much easier to work with some of these new tools. That's been a flippening man. Like it's just totally different. Even down to, you know, three to six months ago.
- [19:54]
B
And that's a. Dude. That's such a good point. Like, I. I'm with you. When I was first able to add variables to design components, I think it was Figma's first one that did that. Yeah, I was all about it, right? Because that's what I was already doing in code. And so I'm like, yay, finally I can do this in my design tool. But there's like, no reason to, unless you have a big team.
- [20:13]
A
Yeah, exactly.
- [20:14]
B
There's no re. What are you going to get out of it? Figma's like, yeah, you have variables. Like, you literally can't export these into any normal format. We make it extraordinarily difficult for you to format. We also don't supply them via our API. And so you can't actually. It's like literally useless other than for the design team to, like, make designs easier. But that world is old world now. And so this idea of, like, why should I add variables? It doesn't really give me a lot if I'm a small team. That is a true statement. And there is. What is Figma's real reason for that? There's no real reason. But a tool like Opacity, there is a real, actual reason because it's what your engineers will use, it's what the AI will use, it's what everything will use. Right? And there's this idea of like, ooh, props. It sounds super complex and react and everything, but when you're designing a component, like I said, that button component in Figma, and you give the button, you make that be a variable, right? It could sound confusing, like, how do I make it a prop? In Opacity, there is no idea of like, making a prop this thing. It's just you're exposing the variable you're already using publicly, right? That's all that you do, you just click it and it's now a prop.
- [21:24]
A
I want to pull back the product strategy for a little bit because, you know, you're talking about all these things. I'm nodding along because this is also the future that, you know, I kind of see and I'm excited about. And yet you got a lot of things to build, my friend. You know, like, the table stakes are high in a lot of different directions because you're describing the design tool, you're also describ. You know, I guess you can see a world where this starts to feel a little bit githubby, but more visual. And I don't, you know, we can talk about what that take would be, but there's so much surface area there. So you, as the design founder who has this vision and you're trying to think about how do I bring this into the world, how do you think about sequencing and the right entry points to even start to get momentum into this space where there are, you know, big teams and big players.
- [22:07]
B
It's a massive concern. One thing I do not want to do is launch a tool that is like, hey, we do kind of the same thing as Figma, but it's built on the web CSS thing. Like, yeah, that's not what I want to launch because that's not going to work. Because why would someone switch? You have to do the full end to end and that has to be your V1 because someone has to have the experience using your tool of like, okay, I designed my thing like Figma. What the crap is different about it? Well, what the crap is different about is I can actually see this thing working in code right now. Right where I'm trying to insert is into design teams at, you know, any, anywhere from a startup to like a large enterprise. Be like, hey, use Opacity. And here's what's going to happen. You're going to pull up Opacity, you're going to click our one click import from Figma. It's going to pull down all your code, all your design components and all your variables into Opacity, make them one to one. So now with one click, you're in Opacity and oh snap, everything's here. And you now get two things you didn't have over at Figma. One, all of that design is now code and it's in code components and your engineers can pull it down at that very second and start using it. Two, and this is something we haven't talked about yet in this discussion, but you can now collaborate with your team because in Opacity there's this whole PR flow built in. And you mentioned GitHub and I'm a huge fan of GitHub and engineers don't know how good they've got it for so many years being able to collaborate and designers have nothing. So the ability inside the Opacity tool to like make changes and it actually, you know, you don't have to care or know about it, but created a different branch behind the scenes. And so you have a PR button, you create a PR and then your design team members can go in and review all your changes down from like the very, you know, did I Change the transparency. Did I change, you know, this, the corner radius, it shows you everything visually as well as listed out. And then you can approve that pr, you can comment on it. All the same sort of things you can do in GitHub. Once you approve it, it gets merged in and a new version package is created. So that whole flow, end to end has to be done and ready. And so that's what we're working on right now. So we're pretty close. The next major thing for us to do is to redesign Opacity in Opacity. And as we do that, we'll be going through and using the tool a bunch and, you know, find all the issues and everything. If we could design Opacity, which I had already designed in Figma Incompleteness, if I can design that from scratch in Opacity itself and then take those NPM packages and use them in Opacity itself, that's going to be. We're golden.
- [24:44]
A
Have you started that process yet?
- [24:46]
B
I've done it a few different times, but we're in the middle of making like larger architectural changes. So you just delete that crap and then you got to do it again. We're almost at the point now where we're going to be ready to do it. I'll be live streaming that as I do it.
- [25:01]
A
Nice. I mean, I'm excited about that. I've been making a point to design Inflight while using Inflight for every single checkpoint, just to get feedback on what I'm working on. And sometimes the level of Inception is too much like. It actually is like a little bit aggressive. So I feel for you at times. I'm sure it's going to be a little bit trippy.
- [25:19]
B
Yep, a hundred percent. Yeah. And I've been working on another tool to help me build faster because I like building with AI and it's been a super fun. But there's like some limitations to building with AI, one of them being that it can't see what it's doing. And so I've been a big fan of Claude code. I use cursor and then when Claude code got a little better, I started using that directly in VS code. And that's all I use now. And yeah, I love it, but it can't tell what the crap it's doing. Like the most common thing that ends up happening when I work with AI is like, all right, just log some stuff to the browser, log it, I'll copy the logs and I'll paste it back in and be like, all right, I See what's wrong, then I'll try to change it. We'll log more and copy and paste. Like, why the heck are you doing this? There should be. It should just have a browser. And so I built this thing over the last 10, nine or 10 days called loop to help me build opacity faster. And it is a new IDE to work with AI and it uses your cloud code account and then it has a browser built into it, and it automatically sends and receives between the AI chat and the browser those console logs, as well as it has a bunch of terminal views in it. So the server side can send and receive server logs to the AI, so it can run as continuous loop. Additionally, it has Chrome MCP tools built in, so it knows about the Chrome browser and it can use all the dev tools in there, including taking screenshots. So it can be like, oh, I see what's on there, I see what's wrong. All on its own. It's really cool. And watch that in a little bit here, a couple days.
- [26:56]
A
10 days, huh? You're quite the hacker.
- [26:58]
B
Well, hey, been doing it for like 30 years, so, yeah, no, it's cool.
- [27:01]
A
I mean, you're. You're talking. I'm like, man, I would use that tomorrow. Like, the amount of. The amount of screenshots that I paste into Warp right now is absurd.
- [27:10]
B
I was going through the same thing. Like, why has nobody done this yet?
- [27:13]
A
This is absurd. I've been designing products every day for the last 15 years, but in the last six months, everything has changed. With AI in the mix, I'm cranking out ideas faster than ever. But none of that matters if I can't get the feedback that I need to get the team aligned. And right now, getting async feedback still kind of sucks. So I'm building the product I've always wanted, and it's called Inflight. I use it every day to share ideas and get feedback from the team, and it's totally changing the way that I work. So I'm excited to show you. Right now I'm only giving access to Dive Club listeners, so head to Dive Club, slash Inflight to claim your spot. I have another, you know, maybe slightly philosophical question about the future of design as it manifests in the future of our tools. And there's the spectrum that I have in my head where on one end we are really leaning into the ceiling of what the models can become. And a lot of quote unquote design, which maybe is more slinging around components. Who knows that's happening. With natural language. And the AI is kind of leading the charge a little bit. And on the other end of the spectrum, we have complete direct manipulation where we have, you know, toolbars everywhere and all these different controls for everything that you'd want to do. When you think about the future of opacity, how do you think about where you want to fit on that spectrum?
- [28:34]
B
No, it's definitely a good point. I myself am, you know, more like I want all the introspection because I'm an engineer and I like that kind of stuff and I want to direct AI. I don't think everyone's that way, and I don't think that's going to be the most common thing, especially going forward. I think people are going to be like, I don't freaking give a crap. Just do whatever you want. Just make it work.
- [28:54]
A
Especially when the baseline is good.
- [28:55]
B
Yeah. Yes, absolutely. And I think that's where it's going to be. And so for opacity from the beginning, I've decided I don't want to play in the prototyping tool space whatsoever. Like, that's being done to the nines. People are doing a great job. I don't want to do it at all. I'm concerned more about the. Not the 0 to 1, but the 1 to end. So the evergreen software, like the actual company and the reason AI falls down on its face so much for folks trying to build something is the one shots things incredibly well. And you're like, oh, my gosh, look at all this. And then the pain starts because, like, no, no, no, no, no, no. Put the thing over here. No, no, no, no. You just change that button to this, make it put it back. And it's at that point when you're trying to, like, direct it visually where you want it. Yeah, because most people, all they care about is they want it to look a certain way and work a certain way. They don't care about how. And that is like a more visual way to work. And so we don't really have those tools yet. Cursor is not that, cloud code is not that. And. And even lovable and et cetera, those prototyping tools, they're not that. Because you can't say, here's what's in my mind, here's the look I want. Stick to this, please. You need something like a design system. And so opacity essentially is a way to make design systems really easy. Right. Visual components. And so building with opacity means you're defining what this stuff should look like, and so when you ask Opacity's AI, hey, can you make me a toast component or a button or a form, it will stick within your design system. And then you can also change the creativity slider so it can go a little outside of those bounds, but it's going to stick with what you've got. And so that way, as you're building with it, it's going to be like a true design or engineering partner. It's never going to like throw something on the screen that's like, where the heck did that come from?
- [30:47]
A
You know, you're reinforcing my growing belief that design systems are just going to be the foundation of almost everything in terms of how we design and explore.
- [30:56]
B
Software in the future in the populace. There's this idea that design system means it's not creative. And, and I can understand that in the way that design systems are used in that we design something. In figma, the engineers coded out. Now it's coded. Now if we want to like change the design, it can't be too wild of a change because then they're going to have to recode everything. That's why it's not creative. It has nothing to do with anything else other than that one thing. And the reason for that is we're talking about man hours, woman hours. We're talking about spending money to recode something when it already works. Why the crap would we do that? Just change the design slightly, don't change it massively. Well, if you didn't have two sources of truth, all that goes completely out the window. And it doesn't matter how crazy you change your stuff because you have these components that are automatically created for you. And so the whole recoding it thing goes away. And so design systems can be as creative as you want and you don't have to feel like you can't work outside the box you already made for yourself.
- [31:59]
A
Can I push on that a little bit? Because I want to, I want to be sure I understand your vision for how this components can work in a system like this. Because you're talking about the value of like not having to rebuild something. But there is also the value from a system standpoint of this standardization where it's like, yeah, well this component is also used in these three other places. So it's not that you can't change it because it creates unnecessary work, but you can't change it because it also is like not going to just work out of the box with these other places. So it's like that's a value proposition of design systems, which I don't actually think is as relevant in an AI world that's more enterprise y in my mind. You know, it's like, don't mess it up. We're trying to create a system where you can't mess it up. Whereas there's this other value of design systems that has felt like it's increasing in dialogue that I'm seeing over the last even six months, which is like, okay, we need more semantic structure for these models to be able to interpret in order to effectively create designs on our behalf and wield style guides and things like that. And maybe by separating those out, you're a little bit more focused on the ladder. Like, do we need more flexibility in components, too? Does that even make. I'm not even sure if there's a question there. It's like, I don't want to let you get away too easily. Basically, with that last answer.
- [33:11]
B
I don't know what kind of component we could take here, but if you're going to say like a table row or something like that, right, and you have this component and it gets used in multiple places, you can feel free to go as bananas as you want in a world where you don't have to recode the thing. You work at a place that is using this table row, multiple places. So you got to be mindful, you can't, you know, delete all this, you know, all these individual data tabs or something like that out of there, because then what the heck are people going to use? So you have to be mindful of that. But I don't think that's really the restriction that we've had to date. To date we've had the restriction of, okay, our table row looks like this, and it's made up of like 20 divs, and it's wrapped in this way and that way and this way. We don't really want to change that structure because we've coded it all. So if you're going to change stuff, it's got to keep the same structure. But the CSS can change, the colors can change, maybe the padding. You know, we can make it look pretty different. The structure's got to stay the same. That makes sense, goes away with opacity. You could totally change the internal structure, the divs, everything. You just want to maintain the props. That's all you care about. As long as they can continue to pass in the same bits of data with the same contracts, the same prop names, maybe you're good. You can Change the underlying, the internals of it. You could change everything about how the CSS works, everything about how the divs are structured. Absolutely everything you could change. And so you can get it looking very different and still maintain that contract that you have with the engineers and with your, with your system.
- [34:36]
A
That makes sense. I like drawing the line between cosmetic changes and foundational changes.
- [34:40]
B
It's kind of on the designer, whoever's in control of that, to decide how it looks. Right. And so you'll have more control there. You just have to maintain the contract. As a matter of fact, in opacity, when you create props, you add your props. As I mentioned before, you're just basically making, exposing a variable you're already using as public and then you can actually deprecate. And so what that does is in the typescript files that we generate, it will deprecate those props, meaning that the intellisense of the ide, the person's using the engineer. So like the VS code or whatever, they have this thing called intellisense that will, when you hover over a variable or a prop or something, it'll have this little window that pops out and it describes everything about how that is. It will deprecate it. So I have like line crossed out. It'll do all that cool stuff for you. Cool. So that way regular human engineers and also AI engineers know when to not use something or if this is no longer supported, all those hints are already like built in, which is really cool. And it's just, just further showing that like you really can change a lot in the past or even today. The reason we don't do it is just because of man hours.
- [35:41]
A
Right now the line exists between the high fidelity vector and actual front end code. There's a line in the sand that's drawn between roles basically. And it's very clear that designers or you know, whatever, that more visually inclined builders, if we want to refer to it that way, are going to leapfrog that line pretty far and start owning most, if not all of the front end. Like for someone that is listening to this, who, they don't want to become a full stack engineer. They want to keep being a professional designer and be paid to think through the UX of complex products. And they're willing to do whatever it takes to secure their spot in this new world. Like how far, far do they go? Like how far into the front end, how far into the code base? Where is that new line in your mind where you're just like, yeah, you know, if you, if you Got to this point, like I think you could probably be a UX designer who's dabbling in code and this is where we would start to get a little bit more technical, where it's like totally fine. Like you got to be more engineering minded to succeed in this area.
- [36:43]
B
Yeah. I think in the past the advice has always been if you're a designer and you want to take things to the next level and be even more productive and valuable in your craft, learn engineering. So that way you understand how the stuff works. Because ultimately you're building software UI that is actually built using code. And if you don't understand how code works, you're going to have a very limited view of the best way to build this design, which I think is true. It just helps to know engineering a ton. But I don't think you will have to because we're telling engineers now, don't worry about known react, just use AI, you know, because it's true, it's going to know it way more than you will. And there's no reason to. There's no reason to. So starting now, I don't think it makes a ton of sense for a designer to have to understand front end engineering or code because they're probably not ever going to be using it in the future. And if all you care about is the design and the, the, you know, the UX of the thing, something like Opacity is exactly what you want because you're not just delivering your clients a picture, you're delivering them working code that you've already worked through, you've already added the events to, you've already prototyped it in Opacity and so you've already got it all working and now you're delivering front end engineered.
- [38:00]
A
Yeah.
- [38:01]
B
To your clients. And so you can't continue to only care about design.
- [38:05]
A
I never thought about it that way, but you're right. Like the pushback on people who have no idea how code works is again like in a vector based tool, they're slinging rectangles and they're making something that makes absolutely no sense in CSS land. Like it's just not feasible for XYZ reasons. But if you are using a tool that is DOM based, if you made it, then it's real. Like you don't actually have to understand anything. That box is already checked. I've never thought about that before. You're right.
- [38:34]
B
It's that idea of the canvas being the same as the production environment in Figma. It is not that way, nor will it ever Be that way. However, in other tools besides Opacity, I think even Framer uses React. The canvas you're using is the production environment. It's a browser rendering HTML and CSS and so it will look one to one and that's a benefit. Like I remember Figma would often talk about, we made our canvas faster. We made our canvas faster. We made our canvas faster. But in the world of real software products, you don't necessarily want that. If there's some slowdown with the way that you're deciding to rendering stuff based on your CSS properties, you want to see that before it goes into production. And so it's not actually necessarily a benefit to make anything faster in the canvas. If you're doing a Dombrace canvas with the idea of everything in here is going to go into a DOM based product.
- [39:26]
A
I've definitely created my share of lags from using the Figma to Framer plugin, where all of a sudden I'm like, yeah, yeah, maybe I should tone down that blur a little bit.
- [39:35]
B
Yeah, that's the thing is like you put all this crazy stuff in Figma and then you put in code, you're.
- [39:39]
A
Like, yeah, this is like maybe the 10th and the 11th layers on this shadow could go like, I probably don't need those.
- [39:45]
B
That there illustrates. Like I'm a big fan of Figma and what they've done for design, but I just don't think that they built, nor did they desire to build a software development or a software design tool. You can do that in there, but you can also build, you know, design a poster for your lost kitten, do floor plans for your next, next house, design the UI for like a video game. You could do all those things in Figma. It's a general design tool and it's great at it. It has this killer vector system. The new stuff with Figma Draw that like Raji and stuff are working on is super similar, like making Illustrator even more accessible because you're already using the tool. And so I don't think it needs to ever go away. I just think that it is not built for software design, full stop.
- [40:28]
A
Okay, then let's talk a little bit more about the future of the role. Because if I combine a few different things that you are talking about, you're talking about this idea that one, I mean the models are just going to get better and better at design. Like it's scary to think about how good the baseline for AI output will be even 18 months from now. That's an eternity, you know, so maybe that's variable number one. Variable number two would be, I think we're going to have a world where high quality components that you can sling around on a canvas based UX are going to be way more accessible. Because the reality still is like the best libraries, like, yeah, maybe you have some charity project where someone is like recreating them in Figma, but it's like not easy to just start messing around with ShadCN, you know, for me. And so you can see how this type of environment gives designers access. I mean, maybe you even have future community plays in mind where it's like, yeah, I could pull from thousands of libraries of components that are all exceptionally high quality and the AI super so good at using them. My question then is like, how does a professional UX designer differentiate themselves in that world? Like, what are the traits that I could bring to the table maybe two years from now that would get me the really sought after jobs when I get this level of fidelity and interactivity and polish effectively out of the box?
- [41:49]
B
You could do that exact same thing you're describing with templates going back 20 years, right? There's always these templates that you could, that you can create for WordPress or for Squarespace or for Framer. And people still encourage and people still make businesses building templates today, Shopify templates, et cetera. And so you can get going, bam, right away, sign up for Shopify, click buy on the template, I'm done. Right? You could do that already, but still people are paying to have custom Shopify sites built. Just the nature of being a person is you want to be a unique snowflake and you want to show that you're different. And so you want your website and business to look a little different. And of course there's going to be the people that are fine with templates. There always be those people. And maybe, I don't know, maybe it's the majority of people, but I think there's always going to be, especially as a company gets larger, there's always going to be a desire to differentiate themselves. And so the only way to do that is to go out and find somebody to help you do that. Now, I don't know if that means that person is going to build something 100% from scratch, like zero pixels on the screen, drawing every pixel themselves.
- [42:55]
A
Gray rectangle number one.
- [42:57]
B
Yeah, I mean, we don't technically even do that today. We used to do that if you're in like Photoshop version 2 and below, where you would have to like literally draw Everything now it's like the tool creates the drop shadow for you, you know, creates the, the gradation from thick shadow to like transparency. You don't have to do that anymore. Like, so a lot of it is kind of done for you. But I don't know when there is a proliferation and there will be a proliferation of really well designed components that the AIs are just going choose out of the gate and you can just like pick and choose a style you can natural language describe and then bam, there it all is and they could even tweak it. So it's totally unique to you technically. Where do you fit in as a designer? I don't know. I think you're going to be the ones building those components. I think you're going to still be hired to be the person maintaining the opacity file or the whatever file. Right. There's still going to be engineers, they're going to be employing AI and they're still going to be designers to be employing AI. But realistically there's going to be a lot less. But maybe that's fine because there's going to be a lot more companies because it's going to be so much cheaper to start a company, to be a lot more companies. So maybe everyone's just going to be going, instead of like one large company with everybody, it's going to be a bunch of smaller companies and that's where everyone goes.
- [44:02]
A
I love it.
- [44:02]
B
I don't know.
- [44:03]
A
That's kind of my thesis actually for where this all heads because we only, we stop the conversation about, well, you need less designers. And also I do think you can make the argument that the space for design differentiation is, is shrinking, it's becoming more important, but it is shrinking because even the templates that you were talking about, they were five out of 10. You know, a good one was five out of 10. We're all getting close to a world where the defaults are going to be 7 out of 10, 8 out of 10. Like we got a little, little headspace left for design to truly come in and create something that is actually unique. But I think that desire for unique, hopefully 100x is just because it's so much cheaper to make software and everybody wants to build something and everybody wants to be unique and there's room for design to slot in in that world. Maybe that means more designers are fractional. That's kind of part of the thesis for me as well, but definitely kind of where I see things going.
- [44:55]
B
I agree, and I don't know I think the web and this idea of software design is such a new industry, 30, 40 years old. It's not that old. And it was the wild West. Up until 15 years ago, we weren't even sure which browsers we wanted to use. There were so many browsers and you had to like build them all. We weren't even sure what front end tech we wanted to use. It was just the wild West. I mean that still will always go on, but everyone's landed on React. Things are starting to solidify. It used to be hobbyists were the only people doing this. And then 20 years ago that changed and now there's people who like, I want to move up the ladder and become a go from junior designer to senior to then staff. Like that's their idea of what it means to build in tech. To me that's totally foreign because I'm in here for a hobby. I'm doing this no matter what. But it's a regular job now, you know, and so when it becomes a regular job, there's going to be tons of money pumped into it, which has been, there's going to be a ton of innovation, which there has been. And at some point it's just like any other job. A lot of things are going to get obsoleted as they get automated. And so just because, you know, pixel designing used to be a thing, doesn't necessarily mean it will be a thing, you know, Like, I don't know, if you look at Apple Mac OS 26, iOS 26, you know that thing Apple used to like set the bar, like the bar that everyone went after. But with this release, they didn't like, they did not come out with the best. They rolled back that liquid glass so hard. There's like one place where you could find liquid glass and that's like the toggles. Other than that, it's just 100% gone and it's now like frosted glass. But it's basically just pure white. I mean, you can barely see anything behind it. I mean, they just rolled it back so hard and now you're stuck in this like gas. It kind of looks good, honestly. Doesn't look very mature. It looks like a for fun sort of thing. It does not look like the next evolution of design whatsoever. I don't imagine many people are going to be mimicking it like they used to with everything. And so I don't know, are we at some sort of limit with how good design can be for this particular use case? A desktop machine, a phone, right? There's going to be new UIs, like Vision and you know, the glasses, stuff like that'll be totally new and fun, but for what we have, I mean, are we at the limit? Is there a need for us to like come up with something new and unique every time other than just it's new, buy it?
- [47:09]
A
I mean, even what you were saying about how much we've kind of zeroed in on react, for instance, there's a flywheel that exists with AI too now, where of course we're going to pick the thing that the models are best at because it accelerates our ability to build the thing, which then creates even more demand for people to pick the thing. And it's like you could see this loop tightening to a point where there is a level of standardization that pros and cons, right? I mean, I don't want to be at the top of the S curve any more than anybody else does, but we probably are given that perspective, especially as someone who's seen these different cycles, you know, like you have a bit more of a zoomed out view. And I guess I'm interested then in, given the amount of surface area and the size of the swing that you are taking, how does that shape the type of people that you want to surround yourself? And I won't say that you're going to hire someone that has the title UX designer, but presumably you're going to hire people that bring the skill of design to the table. So then what signals would you be looking for in that type of person that would get you to the point where you're like, yeah, that's the person that I want to go to battle with.
- [48:15]
B
For me, building a design tool, one of the prereqs is people got to understand that space and they have to have lived in that space in some capacity. But also it may be counterintuitively, I don't know, they can't just be a designer. There's not really much space for just a designer on a team where you're building a product that, you know, as a small team we use AI, you gotta be building stuff. I mean, at this early point, if you're not able to jump in and start writing code and start understanding the code, what are you doing? Right? There's not a lot of design artifacts, which is crazy. Like, even if you're a company the size of Figma, once you design that ui, there's marketing design artifacts, not a lot of other design artifacts. You know what I mean? Like the product kind of is what it is. It's not like expanding enormously. They add on these other teams. But I don't know I of feel that way about most teams. I don't know. Like that's why design teams are always the smaller teams compared to engineering because there's just not a lot of artifacts that come out of the design. Org that are, that are pure product. Right. They're mostly marketing and that sort of thing which if you're running a business is just as necessary. And honestly some of the coolest stuff there is. When I think of like really well designed stuff, oftentimes it's marketing stuff that I think of. It's not just necessarily ui. So it's not a knock at all on marketing. Probably the most important job in the design. Org for a business is the marketing stuff. That's how people know about what you're doing. But on the UI side at this point, people have to understand and have worked in design tool, like for me to work with them. But I'm. I want folks that are engineers because that's the bulk of the work.
- [49:49]
A
For someone listening who's inspired by the things that you're saying, you've done some job of convincing them that this is where the world is headed. And I'm sure there's some subset of people listening that are like, man, I just need to future proof myself. Maybe that's even a little bit scary to hear you say some of these things. Is there a practical next step that somebody can take? Like they're listening to this over the weekend, they open up their laptop on Monday. It feels so big and ambiguous to become an engineer. Like how do you get started? Do you have any advice for people in that position?
- [50:19]
B
You know, up to this point, the idea would be I'm going to become an engineer, I'm going to watch these videos on these courses, et cetera, et cetera, and figure out how to become a good engineer. I don't think you have to do that. I think it would be useless to do that because it's going to take you a couple decades to get to be a really good senior engineer. There will be no need for you at that point to be a really good senior engineer. You can just be an average engineer and be just as effective. Right? There will always be a need for senior engineers. So if you're inclined, please become one. But you don't need to be. You just need to start working with AI and try to separate in your mind AI as a political statement and as a cultural thing from the practicality of working with AI to build a product. If you're afraid of AI or you don't want AI, just set that aside and be like, this is literally just an LLM is not a scary thing. It's all it knows is what we feed it. It doesn't come up with things on its own. We're surprised by how it can pull information that's seemingly randomly, but all that information we've already given it. Right. So you don't have to be scared of it. Open up Claude AI if that's too intense for you. Open up Cursor if that's too intense for you. Lovable bull b0 any of those things and just start building something that you wish existed and just see how far you get. Start prototyping that thing. Inevitably. What happens if you use those v0lovable tools? At some point you're gonna be like, well, I can't really get any further than this. I need to like actually dive in a little deeper. The way that you do that is you eject out of those tools, you take your code base and you put it in GitHub and then you use VS code and cloud code or you use Cursor and those will give you a little more fine grained control. The more mature way to build software, then you could turn that into a more real product. But be warned that this is all very engineering. If you ever want to go beyond just this little, like, let's build a fun little game thing in lovable. It's very engineering. There is no way as a designer to just like build something like that.
- [52:11]
A
What's the Opacity timeline right now? Give people an idea of where you're at and what some of the next milestones are. We're going to hold you to them rigidly too. So any dates will be submitted in the YouTube thumbnail.
- [52:21]
B
Yeah, next major milestone for us is to, like it said, for me to redesign Opacity and Opacity. At that point I'll be able to start pulling people in into alpha. So hopefully we're a couple weeks away from that. Let me rephrase a few weeks away from that. The loupe tool will be out probably later this week. When you listen to this podcast, it should be out and you can test out. That Alpha loop is interesting in that I think it's the first product I've ever built where I never opened up a design tool even once. And I built this purely just with. With Claude code and then also with Loupe itself a little bit. And the reason for that is I do want it to look good and look designed and be attractive. It is not right now, but that's all right. I'm going to design Loupe inside of Opacity. So I've already designed Opacity in Figma and I'm going to redesign it in Opacity. But Loupe will be the first thing designed for the first time in Opacity.
- [53:14]
A
Maybe we can have a part two little screen share heavy. I'd love to see some of that. That'd be fun.
- [53:18]
B
Yeah, that'd be super cool.
- [53:20]
A
One final question before I let you go for context, for people listening, this is not your first rodeo as a founder, Design founder. So what are some of the lessons that you've internalized from earlier in your career that are shaping how you approach this startup this time around?
- [53:34]
B
I had always bootstrapped, never raised money my whole career up until 2016. And I raised money for a company that I was already bootstrapping for a couple years, raised a small seed round. A couple years later, sold that to GoDaddy. It became their e commerce platform. Then I did a straight up VC backed company, got into yc, that was a bank that I ran for four years called Letter and then I tried raising it for another company. It didn't totally work out and then for this one I did raise money from the get go and so I raised a pre seed so that way I could start working on this stuff more seriously. The approach that I'm taking with this one is kind of a merger between the other two. When you're bootstrapping, you're trying to hold on to every single penny that you have and not spending anything more than you can because you literally can't. You can like maybe go into credit card debt which I did in order to fund things, but that's about as much as you can get. You can't. You don't really have deep pockets and so you're kind of limited. And now on the VC route it's totally opposite. You have as deep pockets as you raise and then you can spend that as quickly or as slowly as you want and it's all up to you. And so what I did with that one is I went out and built up a team over the course of a year, about 10 to 12 people, which I'm not going to do this time. I'm going to just go even slower in terms of hiring and stuff and not because I want to overcorrect for some mistake I made, but because you don't need to I already have like a bunch of AI agents working for me and honestly they're doing so much more than hiring a team of seven engineers. It's insane. It is absolutely insane. And so doing things a little differently because of the state of product building today, but very much we'll be doing like a traditional VC backed company. It's just a better way to go about it. Especially today where if you have more money, you will have more, more eyeballs and, and you'll win in most cases if you have the most eyeballs. I mean, if you go back and you look at just competitors in general, like even in the auth space, if you look at those that won and that went public, for example, the one that raised more money more quickly won, right. You can, you can look at fintech and see the exact same thing play out. It plays out everywhere. It's a real phenomena. It's a real thing. If you want to win, that's what you got to do. You got to be the biggest player in the market. Now I'm not saying this is the only way to do it. If you don't care about that crap, you just want to make something for yourself or you know, something you think is cool, go for it. You do not have to do this, but for me, I, I do want to do this. And so that's why I'm taking that route.
- [56:01]
A
In this space you probably do too. It's a hot space because you're going to be competing against people that are VC backed.
- [56:06]
B
So yeah, it would be very difficult to build something like this bootstrapped. At this point in my journey it'd be identical, but it's once, you know, the launch comes and then afterwards having the dollar to pull in the right people. Because here's the, here's the brass facts, however you say that phrase, I don't.
- [56:24]
A
Know, but it hit me.
- [56:26]
B
Whatever. I think, because the golden facts is that if you have the best investors behind you, you will be able to attract the smartest people because they will see that as being the least risky and the most likely to have a big win. Right? So if we're all spending eight hours a day, eight to 16 hours a day, working on stuff and we can choose where we work on stuff, we're probably going to want to choose the one that we think is going to have the most impact for the world and also for us personally. And that happens when you have the best investors. You're able to attract the best team members in there. And that's like you talking about flywheel earlier. It's a flywheel, and so there is literally one way to go about it. Purposely doing it helps you get there.
- [57:09]
A
I'm excited to follow along with the journey and I appreciate you coming on and sharing a little bit about the vision where you're at, and it's inspiring. And also, I just kind of want this to exist, you know, like, this is the way that I want to work as a designer. This is how I want things to evolve and take shape. I'm excited and I'll be rooting for you. So appreciate you.
- [57:29]
B
Thanks, man. And. And thank you for having me on. It's been super fun talking about this. Let me just caveat what I said earlier. It does not mean I will be successful in making that stuff happen, but I'm going to try. I just don't want to sound like I'm.
- [57:42]
A
That's all you can do. That's all you can do. All right. Well, I appreciate you doing all right.
- [57:46]
B
You too, man. Thanks again.
- [57:48]
A
Before I let you go, I want to take just one minute to run you through my favorite products because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobin is how I find design inspiration. Paper is how I design design like a creative. And Raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full time. So by far, the number one way to support the show is to check them out. You can find the full list at Dive Club Partners.