Brian (2:27)

Yeah, yeah, I'm smiling because I've also had my own little vantage point just interviewing people. I've interviewed like 200 people since we last talked, something in the ballpark of that. And there was definitely this sentiment around how design systems are dead, yada, yada, yada, and everything's about speed. Design systems just get out in the way. And the pendulum has swung to the complete opposite end, where everyone's doubling down on design systems because it's so clearly a driver of speed. And all the documentation they wrote is actually really valuable. It's just not for people anymore.

Louis Oriosh (2:58)

Yeah, I would say, to be totally honest, January 2025, I thought we are all toasted. We are in trouble here because our jobs are no longer relevant. And that was just thankfully, a temporary feeling. A couple of months. And like, like you said, the importance of those docs, whatever format they were in before, it's going to be the foundation of everyone's workflow going forward. It might just be written slightly differently and for a different format, for a different output, but guidelines are becoming paramount for everything we need to do.

Brian (3:34)

Yeah, maybe we can just go a little bit deeper there. You said the purpose of systems has kind of shifted as a result of AI. What's behind that?

Louis Oriosh (3:42)

A lot of people looked at systems as a team, kind of potentially in the corner doing their thing, raising the bar of quality and making sure that the businesses can scale efficiently and at speed. But now the system becomes the centerpiece of all successful engineering work, because the more we rely on a tool to create our code, the more we rely on a system to tell that tool what to code. And the less we invest in a system, the more we're going to generate just honestly rubbish into our systems that will just pile up like a landfill over the next couple of years and somebody's going to have to fix it. So unless we now treat those systems as a centerpiece for change, then we're going to end up in that situation in a few years where a consultant's going to have to come in and fix all the mess.

Brian (4:28)

You recently published an article called Agentic Design Systems. Can you talk a little bit about your thinking there?

Louis Oriosh (4:32)

This isn't a new phrase at all, but people want to automate a lot of things, and we're in a process now of figuring out what can be automated, what should be automated. And I speak to teams who do want to automate the generation of their components and speak to teams who absolutely do not want to do that and want to automate some other aspects of it. It might be token pipelines, it might be some aspects of documentation. But we're moving to a world where a lot of this work can be done by a tool or an LLM, whatever framer you want to pull on it. And we have to decide as an individual, as a company, or even as a team within a company, what are our roles actually now and what are the tools taking over and decide that as soon as we possibly can, before that decision is made for us.

Brian (5:20)

Real quick message. And then we can jump back into it.

Rid (5:22)

An even smarter version of Lovable just released. It is 71% better at solving complex tasks, which means it can do more work, more, more autonomously. There's more intelligent planning, prompt queuing. You can stack requests while Lovable works. And my favorite part, there's automated testing, which means Lovable now tests your apps

Brian (5:43)

like a real user.

Rid (5:45)

It opens its own browser, navigates flows, investigates edge cases, and catches bugs for you. And the best part is when it finds a problem, it fixes it right on the spot. I genuinely believe Lovable is the easiest way to build software today. So head to Dive Club Lovable to try the new release. You know what I'm excited about the Granola mcp. It allows you to connect your AI tools directly to your Granola meeting notes. And as somebody who's been vibe coding a lot of tools recently, this release is a pretty big deal because my meeting notes are some of the most valuable context that I have. And now I can find specific topics, pull out action items, and get any question answered based on my meeting history. This is all available today and I'm already building with it like crazy. So if you want to join me, Head to Dive Club slash granolamcp. That's Granola mcp.

Brian (6:40)

Now onto the episode. I want to tap into your perspective as somebody who does work with a lot of these teams, given your position and you see a lot. You see what's working, you see pitfalls to avoid. What are some of the most innovative techniques or processes that you're seeing teams adopt as a result of everything that's changing with AI?

Louis Oriosh (6:59)

What I'm seeing is a lot of people feeling empowered and that that could be on one side a technically curious designer, or on the other side it could be a design curious engineer. Or maybe in the other angle of this triangle is a product manager that doesn't feel like they can ship. And all of these people are feeling like within reach, they can get closer to production or maybe just a higher fidelity I'm very nervous about saying that everything can be production now because maybe that's not the point. Maybe we can get higher fidelity prototypes that we can test and validate a lot faster and still throw them away. Because that is the point of prototype a lot of the time is to just test an idea. But what is stopping anybody in this process from contributing to that? And I see this internally at figma or externally with other teams, where people are, for want of a better phrase, bleeding into another person's job description. And I think that is great because we are teams and historically, whether we like it or not, people have worked in their own silos. And you pass it. An engineer a file to build, or a product manager passes you a PRD to investigate. The question is, why aren't we all contributing to all of these phases with expertise? It's not saying that expertise is not required. Absolutely. We now get an opportunity to become even bigger experts or larger experts in our field. But we all collaborate tighter as an individual unit and not relying on those silos.

Brian (8:25)

I know a lot of the answers for this episode are going to depend on the type of team. So maybe we'll hang out in bigger company land for a little bit first. Like if somebody's listening and they haven't actually taken many steps in order to empower non engineers to reach this higher fidelity level of prototyping or maybe have more access to what exists in code. Like what are some of the baseline things that teams are doing that are taking advantage of the moment that, you know, just should be top of mind for pretty much everybody in today's era.

Louis Oriosh (9:01)

This is a non zeitgeisty response. But hanging out together as a team more and building rituals that allow you to collaborate synchronously, asynchronously, that is a Slack channel, It's a document, it's a FIGMA file or other file that you prefer to collaborate in. But doing that as a unit and not saying, I'm the product manager, therefore I own the prd, I'm a designer, therefore I own the design, and I'm an engineer, therefore I own the high fidelity version of this idea. It's a designer having access to the code base, it's a engineer contributing to the PRD and it's a designer, but just flexing in and out of these phases of the process. I'm seeing so many, speaking of large company land, so many large enterprises giving themselves a very aggressive Q1 target of basically reinventing their process. And that is exciting. It's a little Scary. That's what we're doing now is that design process that we thought was true is up for grabs because things can be done faster as a cross functional team, which we always wanted. We always wanted this. This is not a surprise or anything that is kind of out of ordinary. Speaking to CTOs who are telling me that this is not a design leader, it's a technical leader. CTO is telling me that they're able to work a lot more efficiently now. And my question back is what are you doing with this spare time? And their response is building more products. People are seeing that their opportunity for growth is wider now and they can make more products based on user feedback which they can also get faster and build better businesses.

Brian (10:42)

When process is up for grabs. I do think a lot of teams maybe get overzealous. I've even seen it from time to time. I'm sure that you have as somebody who is in more of that role for that scenario. Are there like pitfalls to avoid or signs or signals that would point to the fact that like hey, maybe we are chasing the wrong thing.

Louis Oriosh (11:04)

Yeah, for sure. And this is linking back to the systems centerpiece is I've had a concern for a while that design systems being a siloed team means that people can just say it's someone else's job. And to me a design system is a bar of quality in an organization and that's everyone's job. So the thing about reinventing process means that there's an opportunity for you to say it's somebody else's job or not. And we still have to have clear lines of responsibility and output expectations on each individual. The designer is still doing something specific to a designer's role. It's not, oh, the PM can contribute to prototypes now, therefore I'm not going to make one. So we have to have this level of acceptance of what a role can do at bare minimum plus and that plus is defined by your industry, by your company, by your team, by your leadership, by your experience and your level within an organization. The more optimistic person is looking to widen their skill set to become more generalist. The pessimistic person is, is freaking out in the corner and thinking, I don't know what I can do now because I can do everything. It's up to an organization to decide the bare minimum of what the expected output can be or should be. And the designers stretch it into different angles that they feel like they'd like to. For me that looks like as the the closest opportunity is to become a Better writer as a designer, write more documents because that is in my opinion the best way to communicate an idea. You could use audio, you can record your voice. Regardless, writing down before you commit to a pixel is the best way to get buy in for an idea. And you're not going to get the ability to ship an idea unless you get buy in. So a document is still central to that for me.

Brian (12:57)

Kind of a spicy take in today's world actually like the prototype is the new PRD is the jargon.

Louis Oriosh (13:03)

The thing is that as soon as you commit to a pixel, someone's going to have an opinion on the visual design. But you need to get it signed off that in a, in a forward thinking organization you have to have a design leader, a product leader, whatever the title is, sign off on your idea before we commit to it. And the best way I've seen to be able to do that is to write a document of your findings and your plan and huddle around it as a cross functional team, add comments, ask for other ideas, maybe add a loose mock up of your idea. But before we go and build that high fidelity prototype, let's make sure we're building the right thing. And that goes against my instinct by the way. My instinct is to commit to pixels as soon as possible.

Brian (13:45)

I don't know. I do both. I see value in both for sure. So if anything I think I just appreciate the more nuanced take because it's very easy to come on here and say prototypes instead of PRDs. I, I want to double down on the team structure piece for a second and maybe I'll just toss a hypothetical your way. So let's say that you're brought in as a consultant for a, let's say like a series B org that's growing and they're feeling the pain of having basically made no investment into the design system up until this point they don't have any dedicated people. There's no like dedicated squad that's working on the design system. So given almost like a blank canvas, what would be some of the opportunities that you would pursue and what types of systems or people would you put in place to steward it moving forward?

Louis Oriosh (14:31)

Firstly, I would say back to my point about quality. Quality is everyone's job and quality is everyone's business. And if we don't accept or pursue that, we should be treating ourselves as failing. That is something I just feel deeply. We have to have a high bar and that is company dependent what that looks like. But if we're not pursuing that, there should be consequences because we're going to attract less customers, we're going to sell less business and we're going to produce less revenue. So that should just be sewn into everything we do is what is our definition of quality and how do we get there. That is regardless of the system. Because I think that the pursuance of quality gets you to a system before you even know it. But tactically, I guess you need a technically curious designer and a design curious engineer. And for the system not to be an afterthought or a side project or something you're doing on top of extra work, it should just be a thread through everything that you're producing as an organization. So are we building components as a system? We don't need to put the label on it. Because I worry that putting a label on something like design system can introduce conversations we don't want to have about budget and hiring and specialism versus a front end engineer doing a really good job. And a designer doing a really good job to me produces a system as a byproduct when we start to scale it up. So your scenario, you're building another product, the easiest one is introducing dark mode. That's when you have to start systematizing properly things like tokens. That is a conversation we can have at that time, but by that time, because we've all done a good job, we have CSS variables and we can extend them. If by that time we have raw values across our front end, we haven't done a good job and we would know that as we're building it that like Slack is just not going to fly anymore.

Brian (16:32)

I'm feeling that even in my own work, like the difference of even just putting checks in like a Claude MDE file where it's like, hey, we don't use raw values in these places. Here's how we reach for certain types of components and it just is automated in like a GitHub review. You know, it's amazing actually, like you can feel how a very small amount of investment into what this system should be or in maybe your language, like where the quality bar should be and then how much the LLMs help you continuously hit it with every single PR from that point. It's amazing. It really is.

Louis Oriosh (17:08)

Let me present the other side side of the scenario though, is that because we can generate anything we want at speed and so much of the success of an early stage company is how much it makes the end user feel how much they want to return to you. That is incredibly important. Which arguably means Deviation from the system is the win or the key because we need to be able to attract people differently every single time we talk to them. So what does an infinitely flexible brand look like? Because we're boiling it down to the brand at this point. And that might mean that raw values are fine, because for this permutation of the landing page, we're experimenting. And as soon as we get into like a systematization, we're committing to something. So there is definitely an argument of do tokens matter anymore?

Brian (17:58)

Or.

Louis Oriosh (17:59)

Absolutely. They have to be there from day zero because we're thinking about scale at every moment and we have to dance between these two worlds of experimentation and committing to quality. Experimentation can also mean quality. But an over tokenization of something can mean it's so robust we can't deviate from it. And every stage of your product or organization has to figure out where you lie on that line. And maybe because everything can be generated and it can take you half a second to scan a code base to see raw values, does the tokenization actually help you at that point? Or are you pushing the pixels around because you can. So the world we're entering now is, is a raw value fine? Or if it's not, then how do you manage that? If a raw value is fine, let's just limit them to what the brand feels like. And that can be written in document the guidelines that you're talking about. We can express what the brand should make someone feel like and rely on the LLM to get us there. And this is where I like dance over my own words. Because in some ways, deep down I'm thinking system, system, system. In other ways I'm thinking all the teams I talk to every single day. You struggle with this word adoption of people not using the right thing in the right place. And that world is just going to be flipped upside down now. It's already happening.

Brian (19:22)

It's already happening. Yeah. Even the word system is weird now because like the point of abstracting something was to minimize the amount of knobs that you have to turn in order to make changes that scale across the code base. But now it's like the pain of that has diminished so significantly where it's the difference between a 10 second LLM call and a 25 second LLM call. Like, I don't care. You know, it's still going to be able to find all of the things. So like what is assistant at that point? And I do kind of like how you're bringing it back to brand, actually. And like the feeling that you're trying to evoke, because the specific way that that is constructed, I don't know, maybe it does mean less now. I'm not sure. It's weird. Like, it doesn't fit into my box anymore.

Louis Oriosh (20:01)

The challenge we have, and this isn't a new point at all, but if we rely just on generation of code without a very strict indication of brand feeling, we end up with all the things looking the same.

Brian (20:13)

Yeah.

Louis Oriosh (20:13)

And honestly, that is fine for the majority of cases, but if you really want to take your scenario of the. We've received a ton of funding. We need to accelerate. That is not good enough anymore. So we have to figure out what that looks like, what that feels like, what the tone of voice is, what the imagery is. And it dials us back out of what is a component to what is the company's system of approaching acceleration. So taking the label of design system off what we're doing is going to help. It's going to bring you out of the corner and out of the silo and to the center of an organization's change.

Brian (20:50)

It's almost like the baseline quality line for a product. But, like, if you only stayed at that baseline at all times, then it's probably going to be a boring product that someone wants to vibe code in a weekend. Just like given the baseline now, where do you strategically deviate from the system and do things that simply don't exist in the set of rules that we're giving to the models?

Louis Oriosh (21:09)

And there's elevations there. The person spinning something up by themselves at a weekend might help them secure some funding to develop it further. That doesn't mean that that thing you built in 12 hours is what you should ship. It's just a validation point for something. Then you accelerate all the way up to the top of the line, where you've got this fully fledged tokenized system, which you can expand and even acquire and merge companies into and build out a more robust brand in a more horizontal way. But you have to figure out where you are on this line, which won't shift to understand what level of fidelity you need at every single point of a product, not just the system, because the system feeds a product. Product feeds a system.

Brian (21:56)

Yeah. It's like a lot of the value proposition of a system was in making sure that things are consistent and standardized. But it does kind of feel like we're going to be getting a lot of that out of the box. You know, that's not enough anymore. Like, you have to kind of find ways to make it so that there is a level of attachment to a product. And I don't know even I think Shadzien played a huge role in this. There's so much network effects around what the modern web stack is. And the more that we kind of spin this flywheel of like everybody's building with Tailwind, everybody's building with Shadzian, everybody's building on top of Vercel. The baseline is rising. Right. It's like a good, clean, consistent design is table stakes in many ways.

Louis Oriosh (22:39)

You know, I don't want people to spend their time reinventing something that already exists. I think that those days are limited. But making it feel like your brand is where you can put the energy on top of a system that is already proven. We've spent so much time trying to figure out how to make accessibility someone's priority or a company's priority. And if you can get that out of a box, take it. You don't need to go and custom spin up your own version of a popover component. The problem has been solved and that is amazing. The quality bar, like you said, is higher. So let's focus on what will help us sell more products. And that might not be the most attractive proposition for the pixel pushing designer, but that's the job and that's exciting. You can get closer to revenue and showing impact and getting closer to that promotion that you're desperate for because you're able to get better access to stakeholders.

Brian (23:33)

I want to dig into workflows and kind of like the practice of a designer again, just kind of tapping into your vantage point as somebody who's talking to a lot of teams. And the first thing I'd love your take on is like how wide is the gap right now between enterprise and startups in terms of the way that designers are operating in these systems, but also just more broadly like approaching their day to day role as a designer, whatever the heck that still means.

Louis Oriosh (23:58)

Now today it feels like it's getting wider. And the reason it feels like it's getting wider is because the access to tools is so vastly different based on your security standards as a company. If you're in a legacy enterprise organization, it might be really hard to get an AI tool signed off. If you're a high flying startup, you've probably just got these things out the box, you sign the contract and you just have these tools. So the have and have nots, or the digital divide is something that we used to call it in this microcosm. It seems to be getting wider. It does Give me a little bit of concern because I don't want people to feel like they could be stuck in a role and not be able to get out of it into a more progressive organization if they're in one that doesn't give them access to tools. So that's something that the industry needs to figure out pronto, because that could be a potential problem. But how people are working, the startups are high flying. They've always been doing that, they're always trying to push the boundaries. But what I have noticed is that people want to get to production a lot faster. They want to almost skip design, and that is a potentially dramatic phrase, but it's how it comes across to I have an idea and I want to get it live on a domain. Now, what's the easiest way to do that? And that was the conversation I was having last week. And on the enterprise level, through an enterprise software, you've got millions of users. You have to be a bit more considerate about how to release something. So that then looks like, how can we shorten the time to production? What tools can we use to accelerate feedback on this? Or how can we increase the amount of users that get access to a beta? Or how do we use feature flags to ensure that a subset of the audience can test this thing out for us? What's the community approach to our software? How can we build a team of people that we can rely on for consistent feedback because they care about us? And that is a playbook that I think everybody will use eventually as you go up the stack from startup to enterprise. But thankfully for me, and for us, is that community people uses, passion is still incredibly important for the success of an idea. It's just that we're doing it faster, but we can't skip the quality, no matter how fast we want to move.

Rid (26:14)

One thing that dive club has made abundantly clear to me over the last year is that the practice of design is changing and the old process of getting feedback just doesn't quite cut it in today's world. That's why I'm excited to announce that Inflight is officially in open beta. It's the feedback tool that I've always wanted, and it's built for a world that moves at the speed of AI.

Brian (26:37)

So I can share my prototypes, give

Rid (26:39)

context in video walkthroughs, and Inflight makes it easy to get the exact feedback that I need to move forward, whether it's voting on directions or maybe even getting the green light to ship a new idea. And all of this is available in a single link that I can drop into Slack or maybe even share with power users to test out a new prototype. I use Inflight every day and it's totally transformed the way that I share work. So I'm excited for you to try the product and if you are ever want to jam about it, just email me at ridflight.

Brian (27:10)

Co. I can't talk workflows without asking you about the Claude MCP release that you just dropped. I think it was literally yesterday. So what are some of the things that that unlocks in your mind that you're excited about?

Louis Oriosh (27:22)

It really does get me pumped for the world that I thought I was entering as a professional a long time ago where I have an idea. I want to test it properly, I want to get it into a browser and I want to feel it, I want to know interactions, I want to know transitions, timing and being able to go from the canvas to the browser, test it and be like that's actually not, not quite right. Let's go back, let's riff on it. That world for a non technical designer is going to open so many doors because you can communicate what your intent is so much faster, because you can push it further. A little phrase that we kind of throw around internally is not faster but further. And that enables people who aren't technical jump in the browser, test something out, open the inspect, say oh, that spacing should actually be 12, it shouldn't be 10 or 8 or whatever it is. Let's jump back into figma and have 10 versions of this thing spinning around. Push that one to the browser, push that one to the browser. Still not quite right. Let's come back via MCP or whatever we're using and have this feedback loop for ourselves without involving an engineer that might take days or weeks to come back through. No fault with their own, just through process. So that's part of the process. Feels like we could speed it up massively. The key to unlock it even further is the system. If you can push from your canvas to the browser and back all connected up to a system that lives in a repo, then we're going to iterate so much faster. That is to me the gold mine of what we've been trying to do.

Brian (28:54)

Same I close my eyes and I picture like just having those two windows side by side at all times. Like that's how I want to work. There's. There's an element of yes, it is the system and they're pointing at the same thing. But sometimes I also just want it to like be a whiteboard, you know, I just want to be able to like quick scratch and like, no, no, no. Like kind of like this instead and just immediately have that go to Cloud or Codex or wherever I'm working and fluidly moving in and out. Like it feels like we'll look back on the last. I don't know what it is at this time, the timelines are blurring in my head.

Rid (29:25)

But it's like the last like three

Brian (29:26)

to six months, right? As this blip on the radar where we had this false choice as designers, where you had to kind of pick this path and it was very difficult to traverse to the other one. And as a result, I wake up every day and I'm like, am I even a designer anymore? Because a lot of times in the startup environment, like you're describing, like I just opened up a local host and bring an idea to life and hit, hit send, you know, and all I'm doing is writing code. Am I still a designer then? I don't know.

Louis Oriosh (29:54)

This is the beauty that the role is getting wider and you tap in and out of whatever makes sense to you. When I first started and I was contributing to front end in professionally, I stopped because things got so complex to set up an environment. I remember Docker and NPM install and react and bundling, and I just thought that is not where I am right now. Firstly, I've got no idea what you're talking about when you say these terms. And if it takes a couple of hours for an engineer to help me set something up, we've kind of gone down the wrong path. So we reverse out of that into a designer being able to do this without thinking about what any of those things mean, the idea wins. It's not a technical barrier that you have to jump over and pushes people further away, which is what happened to me, pushed me further away from production and more into the polishing pixels on the canvas kind of Persona. And now we can reverse out of that one and maybe meet somewhere in the middle where the canvas is very important for ideation, collaboration and general direction exploration. But the browser is where we commit to it. We bounce back and forth between these different mediums to get the right idea, which I think is just exactly what we want.

Brian (31:10)

I love the idea wins. It definitely feels like that's where we're headed. And in that world, I'm pretty bullish on designers.

Louis Oriosh (31:16)

Anybody with an idea is the beauty of this. I like the word maker because it kind of doesn't define specifically your role in an organization. If an engineer wants to play around with interaction details, absolutely, go for it. If a designer wants to tweak the border color on a card because they've spotted that there's a better contrast against the background in this particular screen, please go and change that token value. Don't feel restrained by the process. That was before.

Brian (31:46)

I like how multiple times you brought it back to collaboration too. Because something that I'm feeling a lot is like, yeah, I'm empowered. For sure, I'm empowered. I can do a lot. But sometimes it kind of feels like, especially in a remote company, it's just me and my agents, you know, like, all I am doing is just wielding my agents all day and I end up collaborating with Claude so much more than other people. And I don't know, it's like it's one of those tiny little signals. I'm like, huh, this feels weird. I don't know. I don't know what to do with it yet. There's so much changing.

Louis Oriosh (32:16)

But do you think you're learning?

Brian (32:17)

Oh, I'm learning like crazy.

Louis Oriosh (32:19)

I think that bouncing back and forth between you and a tool to get more sure of your idea before you commit to, hey, everybody, what do you think about this? I don't see a problem with that. Outsourcing everything you do to something is where I get a little bit more concerned. Because, yeah, we are the experts in seat to bring something to market. And if we're outsourcing our ideas, our output, our definitions of anything to a tool, then we just need to ask ourselves what we really want to be doing. And I would feel deflated as a maker, as a creator, if I was just pressing like, go, go, go all day on a tool. Sometimes I do. If I'm making a Figma plugin and I'm coding it, I absolutely don't look at that code. But if it works, I'm happy I still have the idea.

Brian (33:09)

I'm laughing because like yesterday, basically all I did was work on front end and I use conductor now and I

Rid (33:15)

basically, it's Pavlov's dog a little bit

Brian (33:18)

because you just live from one of the toot of the conductor horn to the next. Like, it feels like I'm playing this whack a mole game where it's like, all right, that agent needs me. Okay, now that agent needs me. Now this agent needs me. I feel this trap sometimes where, like going back to what you were talking about earlier, it's so important to get buy in and to be sharing early and often because when you can play ping pong with an agent all day on your idea and go way further than previously possible as a designer, where I'm sweating the details on every single part of this front end architecture and all the hover states and interactions and everything, it's tempting to just keep refining and keep refining versus popping out and be like, hey, I'm. Look, I'm working on this. Like, these are the couple directions that I'm thinking where that came very, very naturally when my process was slightly more defined and always started with me, you know, hitting F on a canvas and drawing the rectangle. Whereas now I can jump much further as step one. A lot of pros and cons, I guess we'll put it that way.

Louis Oriosh (34:15)

Don't get me wrong, I will start in code two. And I think that starting from anywhere philosophy is the new way of working. You might start in a document, you might start in a canvas, you might start in a front end, you might start in any of those places, but ultimately you're going to be bouncing through the tools at some point. You might start in a slack thread, to be honest.

Brian (34:37)

Yeah.

Louis Oriosh (34:37)

And that will always come back to a process that goes linearly through these phases if you want to keep riffing and get the best possible output. But yeah, I don't have a problem with starting in code because sometimes you need to feel something to know what's wrong. And it can take a lot longer often to draw it out on the canvas than to say, hey, generate me a web page for this thing and be like, nah, that's not right. I would say, though, these tools are not for hey, make me an app or hey, make me a website. That's just not how they're designed and not necessarily how I think we should be using them, but boiling it down to real specific, even like component level creation versus broad. Please solve the world for me using these tools.

Brian (35:22)

I got a YouTube comment today and it was some skeptic saying, like, I haven't yet to see an AI design that solved a real problem. And I'm like, hold on a second here. What does an AI design mean to you? You know, because to me that's assuming all we're doing is just saying, make me a website. It's like I'm using AI to get a level of control that I've never had before, you know, and bouncing in and out of tools constantly.

Louis Oriosh (35:47)

But don't get me wrong, the, the average person who starts at a restaurant, they need a website. And if they can get that done in 15 minutes they're going to take it. And that is totally fine by me because if I can go and read the menu of the website and it looks kind of nice, I can get the contact details. I know where they're based, I know what the prices are. I as a consumer also wouldn't mind that when we start to talk about software, we're entering a much different game. And that's where make me a software doesn't fly.

Brian (36:15)

I'm helping my buddy right now who's starting a local contracting business and he really wanted a website. And I ask him questions like, you know, what do you want on your website? He has no answers. He has no idea, you know, so make me a website is not only valuable because maybe the skill is not there, but also the ability to articulate what you want is not there for the vast majority of people who do not do design or do not operate in software. And so being able to just spit something out on the page is probably the easiest way to even arrive at what you actually want. Because you can see and be like, ah, I don't want that. I want this instead. You know, so I do see a ton of value in that.

Louis Oriosh (36:52)

Additionally, this isn't a new thing either because we've had the ability for people to go and spend $5 on someone making them a website for a while. And that made more makers or more people who cared about websites in this case. And the way that that's the same way I look at this now is more people are going to be able to create their ideas. We're not in a position to tell people what they can or can't make. But as soon as that restaurant website needs to open another chain or another store, then they might need a better website. That's where they probably engage in a professional to build a better system.

Brian (37:28)

All right, so it's one thing to talk theoretically about how the world is changing. I want to talk a little bit about your story though, because you drew us this picture of January 2025. It's a little bit, you know, there's a nervousness about where is all this going, what does this mean for my role? Obviously everything has changed from that point. So can you talk a little bit about your personal journey with AI and where these inflection points are?

Louis Oriosh (37:52)

Yeah, I took a while of self reflection and ruing what was about to happen and came out stronger. I can't even tell you the amount of react courses I bought over the past five years.

Brian (38:06)

I can remember at least three or four yeah, exactly.

Louis Oriosh (38:09)

You've been calling me out on this. I haven't finished any of them because I just don't have the interest or time. But Q2, last year, 2025, I thought, hang on a second. I could make plugins as a very easy entry point into what I've been trying to learn, pull up an AI tool in that early days. Early days. That's funny to say that in the early days of this, it was an Enterprise ChatGPT license, and I was asking it to help me make a plugin, copying code from the browser into my ide.

Brian (38:45)

Like a caveman.

Louis Oriosh (38:47)

Like a caveman. And it worked. And I thought, oh, right, okay, we've got something really powerful here where I can jump over those courses that I've wasted money on and shipped a plugin very quickly. A week, two weeks, something like that. Then it got faster, a couple days, the next couple of hours. And I think I've published maybe five or six Figma plugins or widgets over the past 12 months, which is kind of nuts because they work, they solve problems. There's thousands of users. People are giving me feedback. It's open source. People can look at the GitHub repos they can contribute it to if they want. I received a GitHub star on one of the repositories.

Brian (39:26)

Look at you, Joe.

Louis Oriosh (39:27)

What the hell's happening here?

Brian (39:28)

That's amazing.

Louis Oriosh (39:29)

And I think that is what we have on the table is the ability to make utility tools for our use cases at speed using these tools. So I've gone from the ChatGPT in the browser, copying code back and forth, to a more integrated workflow where I'm using a. A tool that allows you to have LLMs based in the IDE. I'm just chatting, bouncing back and forth, rewriting, rewriting, rewriting, getting back into GIT workflows and branches and all that sort of stuff, and hosting my code and GitHub pages for landing pages. This just opened doors that I had previously closed, and I'm able to work faster on these ideas, get them out faster, get validation faster, and solve problems. So all of these plugins or widgets have come from just conversations with the community about what they're struggling with and spotting an opportunity to help. So I'm in effect, able to do my job better as well.

Brian (40:24)

It's inspiring because I'm also the kind of person who has bought more coding courses than I care to admit. I went through a whole boot camp.

Rid (40:32)

I don't actually think I ever technically

Brian (40:33)

graduated from it, but I spent all the money. They still took all my money. I just didn't get the gold star at the end. I think I actually had some giving up of hope. There was like a couple years. It was like, I'm never going to be able to do this. Like, I'm never going to be able to do this. And going back to your word empowering, I guess. Like, I don't know. I'm at the point right now where if I have any free time at all, I just want to build things. Like, I just feel like I can just shoot lightning out of my fingertips, you know, it's amazing.

Louis Oriosh (40:58)

So I've been keeping a Google Sheet of startup websites for a couple of years. There's probably eight or nine hundred websites in this Google sheet. I've had a goal of just putting it somewhere. And two nights ago I opened my laptop on the couch. I'm just chatting away and saying, I want to make this website. Here's my Google sheet. What can we do? And they planned it out, we built something. And then I closed the laptop and haven't done anything with it since. So I can make a bunch of new stuff and I still don't finish them, but I'm still able to feel like that hour or so in the evening was really useful to just explore. And I can explore a higher fidelity. I used to work with a guy over a decade ago, an engineer, and I would just come to him on a daily basis like, I've got a new startup idea. Let's build the Twitter for this, or let's build a new property management website, whatever it was. And he'd say, yeah, I've got some developers. I've got in my contact book probably going to cost us 50, 100,000 to make it. And I think, okay, end of the idea. And now I'm thinking spend a couple of days prompting away and probably realize the idea is not good. But at least I've been able to flex that and test it out. And maybe one idea one day will mean something to me. I can commit to it. But instead of committing financially, now it's committing with time, a little bit of money, like a monthly subscription. As a designer, I think I'm not alone in this. Sometimes you just want to throw things at a wall and feel what sticks. And probably most of the stuff doesn't, and that's okay, but we can do it faster now.

Brian (42:26)

It also changes what the definition of success is too. Because when software is expensive, in order to be successful, it has to have some Semblance of scale. You know, it wouldn't make sense for you to make something for your immediate group of friends in a world where you are having to spend the amount of time and money required to do it. But now, like, I made a Super bowl app just for my family, just to play games together while watching the game, and 15 people used it and it was a massive success and I will totally do it next year. And it again. Yeah, took me about two hours.

Louis Oriosh (43:00)

The key thing I think, though, is just because we can make something doesn't mean it has to be widespread or has to have mass appeal. Because the reality is, if you wanted to do that as a business, that's the wrong place to start. Yeah, you need to go and market the idea now rather than build it. And I've also worked on sort of startups as a side project where that hasn't been the focus, where a couple of years has been sunk into building something with no one who knows about it, and that market shifted. And that won't change. Just because we have access to the tools, we can make things faster, we can get it into production, doesn't mean there's any eyeballs at all on it. And no one's going to sign up to this thing. So keep it tighter, keep it the scope smaller, and maybe something for your family is the best place to get that itch scratched.

Brian (43:44)

There's a phrase that I'm on a mission to use as often as possible on this podcast, which is the niche economy, because I totally think that's where this is headed. You know, you can create something that solves a problem for a thousand people. Kind of what you're doing with your favorite plugins, you know, people wouldn't look at that and be like, that's your startup or that's your business, you know, but all of a sudden like, well, what if you could do that 20 times as a designer, you just solve any problem that you can find, you know? So given that, given all of your expirations, given this windy journey of the last 18 months for you, that probably feels like a lifetime. I know it does for me. How the heck are you thinking about your career moving forward, given where you're at?

Louis Oriosh (44:23)

Honestly, don't know, because I've never known. I've never planned my career. Just taking the shots that have come up, or put it a different way, I've taken a lot of shots and some of them make the basket and some of them don't. But I would not stop shooting, and I don't Know where that ends. The industry shift will settle inevitably and things will boom up and down and I'm kind of just holding on and focusing on what I like to do, which is help the community at scale build better software. Where does that go? Hopefully just better software. What does my role in that look like? Using my platform to enable people to do that? Do I have a one year career plan? No. 2? 5? 10? Absolutely not. Six months? No. Three months? No. The amount of things that are changing on a weekly basis means that I think that it's a fruitless task for someone like me to try and plan their career because I, I can't even rely on a company's roadmap at the moment to know where I fit in that and that's for everyone. So I'd say I'm going to continue doing what I enjoy, pushing that as far as possible, putting as much pressure on that as possible. If I'm not enjoying it, then what's the point?

Brian (45:34)

Do you feel pressure though as somebody who is in more of like an education role to keep up with everything, especially given how quickly it's moving, that is difficult.

Louis Oriosh (45:43)

I'll be honest. It's being resigned to the fact that I will never know everything and I didn't and I never will. The market getting much wider is kind of crazy. The tools, the expectation on designers to in some places become a lot more technical. I'm never going to be able to talk at the level of a full time react engineers. This is just not going to happen. But hopefully I can help facilitate the conversation between the designer and that engineer to build a better workflow for them in that company. So yeah I do feel personal pressure, not professional pressure to just know what is required at what elevation to get the work done and I'll figure that out. It gives me the opportunity now to lean into different parts of the role, different parts of the industry and to find new enjoyments that to me over the last year has been getting back into GitHub contributions that me in the next 12 months, who knows? I'd hate to lose touch with the importance of writing. I hate to lose touch with the importance of quality bars pixels are still incredibly important. Personally I've been focusing on visual design quite a lot so that's always going to be there. It's open like but take my shots.

Brian (46:52)

I think I'm someone who has always just been the ultra early adopter everywhere. Like I was obsessed with scrolling on product hunt every single day for years, try every single tool like I just came so Naturally to me. And I think I've wrestled with this reality that I actually can't be that person anymore. Like it's impossible. There are too many tools, too much is changing every single week. And so it's almost like a failure state to try. But then you have to develop new razors to use internally to figure out where do I invest my time? What is worth pursuing? Why is 80% of my Twitter feed open call hacks? You know, I don't even. I don't even know, you know, it's a little bit intense as somebody who is just trying to kind of hang on for the ride, you know, and I'm sure everybody feels that, which is why I was asking the question, because I know you do feel some pressure to stay up to beat.

Louis Oriosh (47:47)

I do events every week and people always put their hand up and be very honest and say that they're scared, they don't know what to do. And that is tough to hear. But we have the platforms to enable people to understand what is possible. And I think that you can easily be paralyzed by limitless possibilities. Even what you talked about then, about opening Twitter and seeing a specific type of content, you can just be flooded by people seemingly doing very similar things. I think that's probably one of the reasons, other than the obvious, why Twitter community felt like it failed a little bit because people didn't know where to fit in or didn't know what to talk about because everything just felt like everyone was saying the same thing. So communities are still very important. If people don't know where to go to find their like minded people, they're just going to be feeling like they're alone. So community is still incredibly important for people's careers satisfaction and to know what to do. I just don't know where it is a lot of the time because it feels a bit fragmented.

Brian (48:45)

I want to try a little bit of an out there question before I let you go because I think there are a lot of narratives out there right now and some of them are probably quite safe to ignore and they're just overblown, some of them. There is some truth and designers should kind of take it seriously. I'm wondering if anything comes to mind for you in terms of a narrative that there's not that much truth to it right now. You know, like you can safely ignore this, whereas, you know, actually this is where the world is heading and we can't just bury our heads in the sand as designers.

Louis Oriosh (49:19)

I went to my parents house at the weekend and I felt a Very strong tonal shift in dinner conversation. My parents didn't go to university, but AI was raised as a topic of dinner conversation after dinner conversation, after a few glasses of wine. And the prevailing thought, at least in my circles, is probably negative first when it comes to this stuff. But people were just telling me their use cases. My brother, older brother, has a finance background, his wife is a psychologist. My sister works on admin tasks for a company that sells fire extinguishers. These people are not who we are, but they were talking about how their jobs, their lives have been made easier with these tools. So my prevailing narrative that I think we tell ourselves is not the mass market consumer narrative. And I think that as the dust settles, people will find real use cases that help them every day. And that's hard for me as somebody so into it to see because I get hit on Twitter with negative thoughts all day. But I can see through it to the everyday consumer. Has a use case for this. My friend who works in marketing, he has a personal OpenAI subscription with projects. He's got tons and tons of documents running all the time, helping him immensely with his everyday life. He's got adhd, it helps him a lot. So I take myself out of the negative first mindset, which is, as a natural pessimist, quite difficult. My personal one of a narrative that I have but don't project necessarily is whether we like it or not as designers, makers, people. Most software sucks and people don't really care about the pixels. And that has been a challenge for designers, me included in previous roles, to convince people to care about it. But the role now is because there's so much software on the market, because there's so many websites, so many businesses, we have to focus on sales, we have to focus on getting revenue and getting users and signs ups and acquisitions. So the pixels are secondary to the success of the business. And we can come to the pixels at a point where it makes sense or not at all. As we generate more things, more software is going to be created, more websites going to be created, more apps by people who don't have a design background. We just got to accept that and not try to fight it. There will be roles that you go for where your manager or manager's manager doesn't really care about the pixels. And that is a fight not worth fighting. I don't think at the moment I

Brian (51:54)

was thinking about my own answers. I think there's a narrative right now where people who maybe are slightly more skeptical of AI say the blurring of roles is Just because businesses want to pay less and of course they want you to do more and that's what's really happening. But everything will settle. I don't really believe that's true. I think that we have drawn an artificial line between a picture of the front end and the actual front end, just based off of the technical capabilities that were available to us. And I think that the actual front end will fall under design and that it actually is just a whole collection of things that totally fall under the definition of ux. But as an industry we've refused to admit that. And so we've just punted it off to front end engineers who don't really care about the details as much as us, but that at some point we're just going to realize that's just UX design and that's the new role.

Louis Oriosh (52:53)

There are more businesses being created. The hopeful argument of smaller teams means smaller teams in more places on more problems being solved. As a person who enjoys that startup accelerated pace kind of atmosphere, that's exciting. But for somebody who enjoys working in very large organizations, that might be the opposite feeling for you. But I do see more startups, more opportunities to raise money and build your own ideas now.

Brian (53:22)

Yeah, I totally agree. It's like there was a line. This is my economic brain thinking, but there was a literal line on a graph where if you could not generate this much profit based off of this problem, it's not worth pursuing. It doesn't make financial sense to do this. And that line has just fallen. So there's a whole subset, there's this whole category of problems that previously nobody had the financial incentive to solve that are just wide open. Look around you. Like local businesses. Oh my goodness. There's so many problems that anybody listening to this is totally capable of solving on their own, fully.

Louis Oriosh (53:58)

Take a shot.

Brian (53:59)

Take a shot. Yes. Yes, I like it. Well, I can't think of a better line to end on than take your shot. And Louis, I appreciate you coming on and giving us a little bit of like the insider scoop, but also just telling it how it is because I think you're feeling this like everybody else. You know, it's a crazy time and sometimes it's good to just shine a light on the reality. And I appreciate you coming on today and doing that with us.

Louis Oriosh (54:22)

It's always fun. Thank you very much. Pleasure as always.

Rid (54:25)

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 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.